Soru

Zorluk: ZorModernizing Workloads using Containers (ECS and EKS)

Sidero Logistics is modernizing its on-premises containerized warehouse management application by migrating the workload to AWS. Due to strict data residency regulations and a latency requirement of less than 5 ms5\text{ ms} to local automated sorting systems, the application's processing containers and database must run on AWS Outposts deployed in the local warehouse. The company demands high availability with a Recovery Time Objective (RTO) of less than 1 minute for local component failures. Crucially, the solution must remain fully operational—including the ability to schedule, scale, and restart containers locally—even during a temporary WAN outage that disconnects the AWS Outpost from the parent AWS Region. Which architecture should a solutions architect design to meet these requirements with the least operational complexity?

  1. Deploy an Amazon EKS local cluster directly on the AWS Outpost, hosting both the Kubernetes control plane and the worker nodes on the Outpost hardware. Configure the cluster to use local EBS volumes on Outposts for persistent storage.Cevap
  2. B
    Deploy an Amazon EKS cluster with the control plane in the parent AWS Region, and launch the application containers using AWS Fargate on AWS Outposts. Use the Amazon VPC CNI plugin to allocate local IP addresses from the Outposts subnet.
  3. C
    Deploy an Amazon EKS cluster with the Kubernetes control plane running in the parent AWS Region, and configure a managed node group on AWS Outposts to host the application. Rely on the regional control plane to detect node failures and automatically reschedule pods to maintain the target RTO.
  4. D
    Deploy an Amazon EKS local cluster on AWS Outposts. Associate a Route 53 Private Hosted Zone created in the parent AWS Region with the local VPC, and configure the on-premises systems to resolve container services directly via the default Route 53 Resolver without local endpoints.

Cevap

Deploy an Amazon EKS local cluster directly on the AWS Outpost, hosting both the Kubernetes control plane and the worker nodes on the Outpost hardware. Configure the cluster to use local EBS volumes on Outposts for persistent storage.
Deploying an Amazon EKS local cluster directly on the AWS Outpost ensures that both the Kubernetes control plane and worker nodes run locally on the physical hardware. This configuration allows the cluster to remain fully functional, including scheduling new pods, scaling, and recovering from local node failures, even when connectivity to the parent AWS Region is lost. Using local EBS volumes satisfies the local data residency and low-latency storage requirements.

Adım Adım Çözüm

1
Evaluate the survivability requirement under WAN disconnection.
Identify that if the control plane remains in the parent AWS Region, container scheduling, scaling, and auto-healing will fail during a WAN outage.
The regional control plane must communicate with worker nodes to perform scheduling and lifecycle operations.
2
Determine the supportability of serverless container runtimes on Outposts.
Rule out options recommending AWS Fargate on AWS Outposts.
AWS Fargate is not supported on AWS Outposts; physical instances or local nodes must be managed directly.
3
Verify local storage and DNS resolution requirements.
Select Amazon EKS local clusters which deploy the control plane locally on the Outpost, and ensure local data storage and resolution components are configured to survive WAN outages.
EKS local clusters run the Kubernetes API server, controller manager, scheduler, and etcd locally on the Outpost hardware, guaranteeing complete local operationality.

Anahtar Kavram

Amazon EKS local clusters on AWS Outposts allow running the Kubernetes control plane locally, ensuring that the cluster remains operational and capable of scheduling, scaling, and evicting pods even when disconnected from the parent AWS Region.
Bu soruyu puanla