AWS ECS Private Deployment with VPC Endpoints

When deploying AWS ECS (Fargate or EC2) in a private subnet, you don’t necessarily need an Internet Gateway or NAT Gateway to access services like ECR, ECS, or CloudWatch Logs. The key is to configure VPC Endpoints so that ECS tasks can securely connect to the required AWS services over a private network.

Architecture Overview

VPC Subnets

• Public Subnet ×2 → ALB
• Private Subnet ×2 → ECS (Tasks/Services)

Service Exposure

• Private ECS → Public ALB → Internet

NAT Gateway

• Not required for ECS.
• ECS communicates with ECR and CloudWatch Logs via VPC Endpoints.
• If other external internet access is needed, a NAT Gateway can be added.

Preparing ECS Deployment

1. Containerize the Application

• Prepare a Docker build environment (locally or on an EC2 instance).
• Write a Dockerfile and build the image.
• Attach an IAM Role with ECR Push permissions.

2. Create an ECR Repository

aws ecr create-repository --repository-name my-app

• Create the ECR repository.
• Verify repository visibility (private).
• Enable Scan on Push.
• Use View push commands in the console to push your image.

Create an ALB

• Place the ALB in Public Subnets.
• Use the default HTTP (80) listener if suitable.
• Target Groups (TG) can be automatically created when configuring ECS services.

Task Definition

• Task Role: Required only if the container must access other AWS services (e.g., SSM, DynamoDB).
• Task Execution Role: Mandatory. Provides ECR Pull and CloudWatch Logs permissions.
• Port Mapping: Define the container’s exposed port(s).

VPC Endpoints

For ECS running in private subnets, you need at least four VPC Endpoints:

1. com.amazonaws.<region>.ecr.api (Interface)
2. com.amazonaws.<region>.ecr.dkr (Interface)
3. com.amazonaws.<region>.logs (Interface)
4. com.amazonaws.<region>.s3 (Gateway)

• The S3 Gateway Endpoint must be attached to the Route Table.
• The other three are Interface Endpoints that connect directly to private subnets.

Creating the ECS Service

Launch Type

• Fargate: Fully serverless. No infrastructure to manage. Supports Fargate Spot for cost savings.
• EC2: Requires managing EC2 instances in the cluster. Provides more customization and control.

Networking

• Select private subnets.
• Disable public IP assignment.
• Ensure the service runs in the same VPC as the VPC Endpoints.

Load Balancer

• Connect the ECS service to the ALB.
• Target Groups can be automatically created and registered.

Security Group Design

Option 1: Single SG (Simpler)

Apply the same SG to ALB, ECS, and VPC Endpoints.

• Inbound: Source = ECS Subnet CIDR, Port 443
• Outbound: All destinations, Port 443

Option 2: Separate SGs (Recommended)

• VPC Endpoint SG
  • Inbound: Source = ECS SG, Port 443
  • Outbound: All, Port 443
• ALB SG
  • Inbound: Source = 0.0.0.0/0 (or restricted CIDR), Port 80/443
  • Outbound: All, All
• ECS SG
  • Inbound: Source = ALB SG, Port = container port
  • Outbound: All, Port 443

Fargate vs. EC2: Key Differences

In most cases, Fargate should be the first choice for simplicity and reduced operational overhead. EC2 launch type is useful when you need specialized workloads, GPU support, or deep OS-level customization.

Conclusion

• ECS services in private subnets can operate without a NAT Gateway by leveraging VPC Endpoints.
• Fargate provides simplicity and scalability, while EC2 offers more control and flexibility.
• For security, separating SGs for ALB, ECS, and VPC Endpoints is the recommended approach.

🛠 마지막 수정일: 2025.09.29