Access ECS APIs Privately via VPC Endpoints (2026)

You can access ECS APIs privately from within your VPC using VPC Endpoints, avoiding the need to traverse the public internet.

Here’s how it looks in action. Imagine you have an EC2 instance in a private subnet that needs to call the DescribeTasks API to check the status of your ECS services. Without a VPC endpoint, this call would go from your VPC, through an Internet Gateway or NAT Gateway, out to the public internet, and then to the ECS API endpoint.

With a VPC endpoint for ECS, the traffic stays entirely within the AWS network. Your EC2 instance makes a request to the ECS API. This request is routed by the VPC’s route tables to the VPC endpoint. The VPC endpoint then forwards the request to the ECS service, and the response comes back through the endpoint, all without ever touching the public internet.

The core problem this solves is security and network simplicity for private resources. If you have sensitive applications running in private subnets, you generally don’t want them to have direct outbound internet access just to talk to AWS services. VPC Endpoints provide a secure, private pathway.

There are two types of VPC Endpoints: Interface Endpoints and Gateway Endpoints. For ECS, you’ll use an Interface Endpoint.

An Interface Endpoint is essentially an Elastic Network Interface (ENI) with a private IP address in your subnet that serves as an entry point for traffic destined for the service. You create an Interface Endpoint for ECS in your VPC. When you do this, AWS provisions ENIs in the subnets you select.

Here’s a typical setup. You’ll need to create the endpoint in your VPC, specifying the service name, which for ECS is com.amazonaws.<region>.ecs. You’ll also choose the subnets where the ENIs should be created and the security groups that will control access to those ENIs.

aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0123456789abcdef0 \
    --service-name com.amazonaws.us-east-1.ecs \
    --vpc-endpoint-type Interface \
    --subnet-ids subnet-0123456789abcdef0 subnet-0abcdef0123456789 \
    --security-group-ids sg-0123456789abcdef0 \
    --region us-east-1

Once created, the endpoint will have associated DNS names. By default, if you have DNS resolution enabled for your VPC, you can use the standard public DNS names for ECS (e.g., ecs.us-east-1.amazonaws.com), and they will resolve to the private IP addresses of the endpoint ENIs. This makes the transition seamless. Your application code doesn’t need to change; it just uses the regular AWS SDK calls.

You can also configure private DNS for the endpoint, which means the public DNS names will resolve directly to the endpoint’s private IPs without needing to rely on AWS’s default public DNS resolution for the region. This is often preferred for stricter network control.

The security groups attached to the endpoint ENIs are crucial. They act as a firewall, determining which resources within your VPC can connect to the ECS API via the endpoint. You’ll typically want to allow outbound TCP traffic on port 443 from your EC2 instances or other resources to the security group associated with the endpoint.

{
    "IpPermissions": [
        {
            "IpProtocol": "tcp",
            "FromPort": 443,
            "ToPort": 443,
            "UserIdGroupPairs": [
                {
                    "GroupId": "sg-0123456789abcdef0" // The security group of your EC2 instance
                }
            ]
        }
    ]
}

And on the endpoint’s security group, you’d allow inbound TCP traffic on port 443 from the security group of your EC2 instances.

{
    "IpPermissions": [
        {
            "IpProtocol": "tcp",
            "FromPort": 443,
            "ToPort": 443,
            "UserIdGroupPairs": [
                {
                    "GroupId": "sg-abcdef0123456789" // The security group of the VPC endpoint ENI
                }
            ]
        }
    ]
}

A key aspect often overlooked is that Gateway Endpoints are only for S3 and DynamoDB. Interface Endpoints are the mechanism for most other AWS services, including ECS. This means you pay for the Interface Endpoint based on the hours it’s provisioned and the amount of data processed.

When you create an ECS service that needs to pull container images from ECR, and your EC2 instances are in a private subnet without direct internet access, you’ll also need a VPC endpoint for ECR to allow those instances to pull images privately.

The next logical step is to secure access to specific ECS resources using endpoint policies.