Learn2Skills for AWS Community Builders

Posted on Jul 26

Amazon ECS Service Connect now supports Zone-Aware routing

#aws #ecs #containers #networking

Zone-aware routing in Amazon ECS Service Connect ensures that traffic between microservices is routed to the closest available service instance within the same Availability Zone (AZ). This minimizes latency, reduces cross-AZ data transfer costs, and improves application performance. Below is a detailed breakdown of how it works:

1. Core Components Involved

Amazon ECS: Manages containerized services.
AWS Cloud Map: Handles service discovery (registers service instances and their endpoints).
VPC Subnets & AZs: Tasks run in subnets mapped to specific AZs.
Service Connect Configuration: Enables service-to-service connectivity with discovery.
DNS Resolver: Resolves service names to IPs, aware of the source AZ.

2. How Zone-Aware Routing Works (Step-by-Step)

Step 1: Service Registration with Cloud Map

When you enable Service Connect for a service, ECS automatically registers each task (container instance) in AWS Cloud Map.
Each task registers with:
- IP Address: The private IP of the task (which resides in a specific subnet/AZ).
- Port: The port the service listens on.
- Metadata: Optionally includes custom attributes (e.g., AWS_ECS_AZ=us-west-2a).

Example:

A payments-service task running in us-west-2a registers as an instance in Cloud Map with IP 10.0.1.10:8080.

Step 2: DNS Query from a Source Service

When a source service (e.g., orders-service) wants to call payments-service, it uses the Service Connect endpoint (e.g., payments.local).
The source service makes a DNS lookup for payments.local.

Step 3: AZ-Aware DNS Resolution

The VPC DNS resolver (AmazonProvidedDNS) processes the query and:
1. Identifies the source task’s AZ: The DNS resolver checks the subnet/AZ where the orders-service task is running (e.g., us-west-2a).
2. Queries Cloud Map: Requests all instances of payments.local.
3. Filters instances by AZ: Returns only IPs from the same AZ (if available). If no instances exist in the same AZ, it may return instances from other AZs (fallback behavior).

Example:

orders-service runs in us-west-2a.

Cloud Map returns payments-service IPs only from us-west-2a (e.g., 10.0.1.10:8080).

Traffic stays within the same AZ.

Step 4: Connection Establishment

The source service connects directly to the resolved IP(s) using HTTP/HTTPS or other protocols.
No cross-AZ traffic occurs if an instance exists in the same AZ.

3. Key Mechanisms Enabling Zone-Aware Routing

A. Cloud Map + VPC DNS Integration

Cloud Map stores instance locations (via IPs in AZ-specific subnets).
VPC DNS leverages this data to filter responses based on the resolver’s AZ.

B. Subnet Mapping to AZs

Tasks are launched in specific subnets, which are tied to AZs. The IP address of a task inherently reveals its AZ.

C. Service Connect Configuration

Defined in your ECS task definition:

  "serviceConnectConfiguration": {
    "enabled": true,
    "services": [
      {
        "discoveryName": "payments.local",
        "portName": "payments-port",
        "clientAliases": [{ "port": 8080 }]
      }
    ]
  }

This tells ECS to register the service in Cloud Map and enable AZ-aware DNS.

4. Benefits of Zone-Aware Routing

Benefit	Explanation
Lower Latency	Traffic stays within the same AZ (network hops are shorter).
Reduced Cross-AZ Costs	AWS charges for data transfer between AZs. Zone-aware routing minimizes this.
Improved Availability	If an AZ fails, traffic automatically routes to other AZs (fallback).
Simplified Architecture	No need for load balancers or custom routing logic for intra-service calls.

5. Fallback Behavior

If no instances exist in the source AZ, the DNS resolver returns IPs from other AZs. This ensures connectivity isn’t broken, but latency may increase.
You can configure health checks in Cloud Map to avoid routing to unhealthy instances.

6. Example Scenario

Architecture

VPC: vpc-12345678 with subnets in us-west-2a, us-west-2b, us-west-2c.
Services:
- orders-service (runs in us-west-2a and us-west-2b).
- payments-service (runs in all three AZs).

Workflow

An orders-service task in us-west-2a calls payments.local.
DNS resolver in us-west-2a queries Cloud Map.
Cloud Map returns only payments-service IPs in us-west-2a (e.g., 10.0.1.10:8080).
Connection is made within AZ, avoiding cross-AZ transfer.

If payments-service has no instances in us-west-2a, DNS returns an IP from us-west-2b (next closest AZ).

7. Monitoring & Metrics

CloudWatch Metrics: Track ServiceConnect metrics (e.g., ServiceConnectLatency, CrossAZDataTransfer).
Cloud Map Health Checks: Ensure only healthy instances are returned.
VPC Flow Logs: Analyze cross-AZ traffic patterns.

8. Requirements & Best Practices

Enable Service Connect in your ECS task definitions.
Deploy services across multiple AZs for high availability.
Use Private DNS Names: Service Connect uses <service-name>.local by default.
Avoid Manual Load Balancers: Service Connect replaces the need for ALBs/NLBs for intra-service discovery.
Subnet Design: Ensure subnets are correctly mapped to AZs.

Summary

Zone-aware routing in ECS Service Connect leverages Cloud Map and VPC DNS to automatically route traffic to service instances in the same AZ as the caller. This reduces latency, cuts cross-AZ costs, and simplifies service-to-service communication without requiring custom routing logic. By design, it ensures optimal performance while maintaining resilience through AZ-independent fallbacks.

Amazon ECS Service Connect zone-aware routing

DEV Community