Amazon ECS Networking Explained: VPC, ALB, Subnets, and Security Groups

Amazon ECS networking is the architecture layer that controls how containers receive traffic, communicate with dependencies, stay isolated, and remain reachable during deployments. For production ECS services, networking is usually where reliability and security problems appear first.

A strong ECS network design usually combines a VPC, private subnets, an Application Load Balancer, target groups, and security groups. The goal is simple: expose only the load balancer publicly, keep ECS tasks private, and allow only the traffic paths the system actually needs.

Table of Contents

• ECS Networking Model
• VPC Basics
  • What the VPC Provides
  • ECS Inside the VPC
• Subnet Design
  • Public Subnets
  • Private Subnets
  • Multi-AZ Layout
• Load Balancer Architecture
  • Why Use an ALB?
  • Listeners and Target Groups
  • Health Check Routing
• ECS Task Networking
  • awsvpc Mode
  • Task IP Addresses
  • Port Mapping
• Security Groups
  • ALB Security Group
  • ECS Task Security Group
  • Database Security Group
• Outbound Access
  • NAT Gateway
  • VPC Endpoints
• Service-to-Service Traffic
  • Internal Load Balancers
  • Service Discovery
• Common Mistakes
• Production Checklist
• Conclusion
• More Articles to Read

ECS Networking Model

ECS networking should be designed around controlled traffic paths. A task should not be reachable just because it exists. It should be reachable only through the intended entry point, usually an Application Load Balancer or an internal service endpoint.

For most production APIs, the preferred model is public ingress through an ALB and private task execution inside the VPC.

Internet
  -> Route 53
  -> Public Application Load Balancer
  -> Target Group
  -> ECS Tasks in Private Subnets
  -> RDS / DynamoDB / Redis / SQS

VPC Basics

A Virtual Private Cloud is the isolated network where ECS services run. It defines IP address ranges, subnets, routing, gateways, and network boundaries for application components.

ECS does not replace VPC design. It depends on it.

What the VPC Provides

The VPC provides the private network where ECS tasks, databases, caches, and internal services communicate. It also controls how traffic enters and leaves the system.

ECS Inside the VPC

ECS tasks using awsvpc networking receive their own network interfaces and private IP addresses. That makes each task behave like a small networked resource inside the VPC.

This is powerful because security groups can be applied directly to tasks. Traffic rules can be written around application boundaries instead of host boundaries.

VPC
  Private Subnet A
    ECS Task: 10.0.10.25
    ECS Task: 10.0.10.48

  Private Subnet B
    ECS Task: 10.0.20.31
    ECS Task: 10.0.20.66

Subnet Design

Subnets divide a VPC into smaller network segments, usually across Availability Zones. ECS subnet design affects availability, routing, security, IP capacity, and load balancer placement.

A clean production design usually separates public ingress components from private application workloads.

Public Subnets

A public subnet has a route to an internet gateway. Resources placed there can be publicly reachable when they have public IP addresses and permissive security rules.

In ECS architectures, public subnets usually host Application Load Balancers and NAT gateways, not application tasks.

Public Subnet A
  Application Load Balancer node
  NAT Gateway

Public Subnet B
  Application Load Balancer node
  NAT Gateway

Private Subnets

A private subnet does not directly expose resources to the internet. ECS tasks in private subnets can receive traffic from internal resources such as an ALB, but they are not directly public.

This is the preferred default for ECS services because it reduces the public attack surface.

Private Subnet A
  ECS API task
  ECS worker task
  Redis node

Private Subnet B
  ECS API task
  ECS worker task
  RDS standby

Rule of Thumb: place the load balancer in public subnets and ECS tasks in private subnets unless there is a clear reason to expose tasks directly.

Multi-AZ Layout

Production ECS services should run across multiple Availability Zones. This reduces the chance that one AZ issue removes all task capacity.

VPC
  Public Subnet A
    ALB node
    NAT Gateway

  Public Subnet B
    ALB node
    NAT Gateway

  Private Subnet A
    ECS Task A
    ECS Task B

  Private Subnet B
    ECS Task C
    ECS Task D

Load Balancer Architecture

ECS services often use an Application Load Balancer to receive HTTP or HTTPS traffic. The ALB provides stable ingress while ECS tasks can be started, stopped, replaced, or scaled behind it.

The load balancer should be treated as the public entry point. Individual task IP addresses should be treated as temporary implementation details.

Why Use an ALB?

ECS tasks are replaceable. Their IP addresses can change during deployments, failures, and scaling events. An ALB hides that churn from clients.

• Stable endpoint for clients.
• Health-based routing to healthy tasks only.
• HTTPS termination with managed certificates.
• Path-based routing for multiple services.
• Deployment safety during task replacement.

Listeners and Target Groups

An ALB listener receives traffic on a port such as 80 or 443. Listener rules forward traffic to a target group. The target group contains ECS task IPs and ports.

HTTPS Listener :443
  Rule: /api/*
    -> Target Group: orders-api
       -> Task IP 10.0.10.25:8000
       -> Task IP 10.0.20.31:8000

Health Check Routing

The target group health check determines whether a task is safe to receive traffic. A task can be running from ECS's perspective but still unhealthy from the ALB's perspective.

GET /health

Expected:
  200 OK
  {"status":"ok"}

Important: ECS service stability depends heavily on health check correctness. A bad health check can either send traffic to broken tasks or constantly replace healthy tasks.

ECS Task Networking

ECS task networking controls how containers receive IP addresses, expose ports, and communicate inside the VPC. Modern ECS services typically use awsvpc network mode.

This model gives each task a network identity, which makes security and routing easier to reason about.

awsvpc Mode

In awsvpc mode, every ECS task receives an elastic network interface. The task gets a private IP address from the subnet where it runs.

This makes task-level security groups possible. Instead of protecting a shared EC2 host, traffic rules can protect the application task directly.

ECS Task
  ENI: eni-abc123
  Private IP: 10.0.10.25
  Security Group: sg-ecs-api
  Container Port: 8000

Task IP Addresses

Task IP addresses are dynamic. A task started today may have one private IP, while a replacement task may have another.

Applications should not depend on fixed task IPs. Traffic should go through an ALB, service discovery, internal DNS, or another stable routing layer.

Port Mapping

Port mapping connects the container port to the target group. With awsvpc mode, each task has its own network interface, so multiple tasks can use the same container port on different task IPs.

{
  "portMappings": [
    {
      "containerPort": 8000,
      "protocol": "tcp"
    }
  ]
}

The target group should route traffic to the same port the container listens on. If the application listens on 8000, the target group should target task IPs on port 8000.

Security Groups

Security groups are one of the most important ECS networking controls. They define which traffic is allowed between the internet, load balancer, ECS tasks, databases, caches, queues, and internal services.

A good security group design follows application communication paths, not convenience.

ALB Security Group

The ALB security group usually allows public HTTPS traffic. HTTP may be allowed only to redirect to HTTPS.

ECS Task Security Group

The ECS task security group should usually allow inbound application traffic only from the ALB security group. It should not allow public inbound access.

ALB Security Group
  Inbound:
    443 from internet

ECS Task Security Group
  Inbound:
    8000 from ALB security group

Database Security Group
  Inbound:
    5432 from ECS task security group

Production Note: referencing security groups is usually better than using broad CIDR ranges. It keeps rules aligned with service boundaries.

Database Security Group

Databases should allow inbound traffic only from the application services that need access. For example, PostgreSQL should allow port 5432 from the ECS task security group, not from the whole VPC.

Outbound Access

ECS tasks in private subnets often need outbound access. They may pull packages at startup, call external APIs, reach AWS services, or send telemetry.

Outbound design should be intentional. NAT gateways are simple, while VPC endpoints can reduce public internet dependency for AWS service traffic.

NAT Gateway

A NAT gateway allows private subnet resources to initiate outbound internet connections without accepting inbound internet connections.

ECS Task in Private Subnet
  -> Route Table
  -> NAT Gateway in Public Subnet
  -> Internet

NAT is common for private ECS tasks that need external API access. The trade-off is cost and dependency on NAT availability.

VPC Endpoints

VPC endpoints allow private resources to reach supported AWS services without routing through the public internet.

Trade-off: VPC endpoints improve private connectivity and can reduce NAT traffic, but they add networking resources and configuration to manage.

Service-to-Service Traffic

ECS systems often contain multiple services that need to communicate internally. This traffic should not go through public endpoints unless there is a specific reason.

Internal routing can use an internal load balancer, service discovery, or application-level messaging through queues.

Internal Load Balancers

An internal ALB is useful when one private ECS service needs stable HTTP routing to another private ECS service.

orders-api
  -> internal ALB
  -> payments-api ECS service
       -> payments task A
       -> payments task B

Internal load balancers are useful for HTTP services, path routing, health checks, and stable internal DNS names.

Service Discovery

ECS service discovery allows services to find each other through DNS names instead of hardcoded task IPs.

This is useful for private services, but it does not remove the need for good timeout, retry, and failure handling.

Common Mistakes

ECS networking mistakes usually come from exposing too much, relying on unstable task addresses, or treating security groups as an afterthought.

• Running ECS tasks in public subnets when only the load balancer should be public.
• Allowing inbound traffic from 0.0.0.0/0 directly to task ports.
• Using task IP addresses directly instead of ALB, DNS, or service discovery.
• Putting all services in one broad security group.
• Opening database access to the whole VPC instead of specific application security groups.
• Using one subnet or one Availability Zone for production services.
• Forgetting outbound access for private tasks that need ECR, logs, secrets, or external APIs.
• Using heavy health checks that fail during temporary dependency issues.
• Ignoring IP address capacity when many tasks run in small subnets.

Production Checklist

A production ECS network should expose only what must be public, isolate application tasks, and make service-to-service traffic explicit.

• Use a VPC layout with multiple Availability Zones.
• Place public ALBs in public subnets.
• Place ECS tasks in private subnets by default.
• Use ALB target groups for HTTP services.
• Allow task inbound traffic only from the ALB security group.
• Allow database inbound traffic only from the ECS task security group.
• Avoid direct public access to ECS task ports.
• Use lightweight health checks for target groups.
• Use NAT gateways or VPC endpoints for private task outbound access.
• Monitor subnet IP capacity for awsvpc-based ECS services.
• Use internal ALBs or service discovery for private service-to-service communication.
• Document allowed traffic paths as part of architecture design.

Conclusion

Amazon ECS networking is the foundation of safe production container deployment. ECS tasks are dynamic and replaceable, so stable routing, private subnet placement, load balancer integration, and security-group-based access control are essential.

A practical ECS network design exposes the ALB publicly, keeps tasks private, allows only required traffic paths, and uses VPC routing, target groups, health checks, NAT, and VPC endpoints intentionally.

Key Takeaway: ECS networking should be designed around controlled access: public traffic reaches the load balancer, the load balancer reaches private ECS tasks, and tasks reach only the dependencies they actually need.

More Articles to Read

Continue with ECS articles that explain the runtime model, compute choices, workload patterns, deployment behavior, and production operations.

• Amazon ECS Task Definitions, Services, and Deployments Explained
• AWS Fargate vs EC2 for ECS: Architecture Trade-Offs
• Running Production APIs and Background Workers on Amazon ECS
• Amazon ECS Deployment Strategies and Auto Scaling
• Amazon ECS Best Practices for Production