ECS is a fully managed container orchestration service that simplifies the deployment, management, and scaling of containerized applications. Customers can launch non-Fargate versions of Amazon ECS within an AWS Outposts Rack deployment for full-scale container orchestration:
Figure 5.16 – Launching an ECS cluster within a deployment by selecting an Outposts subnet
The supplemental services of Amazon Elastic Container Registry (ECR), AWS Identity and Access Management (IAM), Network Load Balancer (NLB), and Amazon Route 53 require AWS Region connectivity. The lack of access to these supplemental services means that no new clusters can be created, no new actions can be performed on existing clusters, instance failures will not be automatically replaced, and CloudWatch logs and event data will not propagate.
Amazon Elastic Kubernetes Service (Amazon EKS)
EKS is a managed Kubernetes service that runs in AWS regions as well as on-premises. The Kubernetes control plane can be deployed into the AWS region or on-premises within AWS Outposts but both deployments are fully managed by AWS. The control plane manages key components of an EKS cluster such as application availability, cluster data, and scheduling for containers.
Amazon EKS on Outposts enables customers to leverage on-premises cluster capacity in a low-latency manner using the same tools and APIs that customers use to access Amazon EKS in the AWS cloud. Customers can deploy Amazon EKS cluster nodes onto both virtual machines and bare-metal servers within their AWS Outposts Rack deployments.
Customers deploy their Amazon EKS worker nodes into an AWS Outposts Rack deployment by using self-managed node groups versus managed node groups. Compared to running EKS in-region, this shifts more of the responsibility for updating nodes to the customer whenever new Amazon EKS-optimized AMIs are released for use.
Customers can create Amazon EKS clusters in two ways:
Extended clusters: The Kubernetes control plane runs in an AWS region but the nodes run on AWS Outposts. This approach is generally chosen to minimize the compute capacity footprint required for an AWS Outposts Rack deployment. The primary consideration is the stability of the service link connection as any disconnection of a cluster’s nodes from its control plane is likely to disrupt cluster manageability and application availability.
Local clusters: The Kubernetes control plane and nodes run on AWS Outposts. This is typically done to minimize the impact of service link disconnections:
Figure 5.17 – Selecting an EKS control plane location