Question

Difficulty: MediumModernizing Workloads using Containers (ECS and EKS)

Luminary Healthcare is modernizing its legacy patient record indexing engine by migrating it to AWS. The workload consists of a front-end user interface container and a back-end indexing processor container. The legacy code is hardcoded to communicate over the local loopback address (127.0.0.1127.0.0.1) on port 80808080. The company wants to deploy this solution to Amazon ECS using the AWS Fargate launch type to eliminate EC2 instance provisioning and minimize operational overhead. Traffic between the two containers must remain private and secure without transiting external load balancers. Which configuration should the Solutions Architect select to meet these requirements?

  1. Define both the front-end and back-end containers in a single Amazon ECS task definition, and deploy it to a service using the AWS Fargate launch type. Because AWS Fargate requires the awsvpc network mode, the containers will share the task network namespace and communicate over the loopback interface.Answer
  2. B
    Define the front-end and back-end containers in separate Amazon ECS task definitions, configure the task definitions to use the host network mode, and deploy them to the same ECS cluster using the AWS Fargate launch type to bind the containers directly to the underlying host interface.
  3. C
    Define the front-end and back-end containers in separate Amazon ECS task definitions, deploy them to separate ECS services using the awsvpc network mode, and route traffic between them using an Application Load Balancer with a Route 53 Private Hosted Zone that is created in the AWS account but not associated with the VPC.
  4. D
    Define both the front-end and back-end containers in a single Amazon ECS task definition, configure the task definition to use the bridge network mode, and map the containers using Docker links to allow direct port communication over the bridge network interface on AWS Fargate.

Answer

Defining both containers in a single task definition on AWS Fargate allows them to share the task's network namespace (due to the mandatory awsvpc network mode) and communicate over the local loopback interface (127.0.0.1127.0.0.1).
Defining both containers in a single task definition under the AWS Fargate launch type is correct because AWS Fargate mandates the awsvpc network mode. Under awsvpc, all containers within the same task share the same elastic network interface (ENI) and network namespace, allowing them to communicate via localhost (127.0.0.1127.0.0.1) on their respective ports, fulfilling the hardcoded configuration without external load balancers.

Step-by-Step Solution

1
Analyze the legacy application communication requirements.
The application expects front-end and back-end containers to communicate over localhost (127.0.0.1127.0.0.1) on port 80808080.
Identifying the networking constraints dictates that the containers must share a network namespace.
2
Evaluate AWS Fargate launch type networking options.
AWS Fargate only supports the awsvpc network mode.
Understanding that other modes like host or bridge are unavailable is critical for filtering out incorrect architectural designs.
3
Determine the task structure that enables localhost sharing under awsvpc.
Placing both containers in the same ECS task definition allows them to share the same Elastic Network Interface (ENI) and communicate over the loopback interface.
This matches the localhost communication constraint while using Fargate's required networking model.

Key Concept

Fargate Task Networking
Rate this question