All Services
Containers
Amazon Elastic Container Service
ECS orchestrates containerized workloads. Fargate supplies serverless compute while ALB, ECR, and CloudWatch form a common production baseline.
Explore pricing models, common use cases, infrastructure support, and the AWS services that commonly work with Amazon Elastic Container Service.
Amazon Elastic Container Service pricing and cost programs
Pricing model: Orchestration plus selected compute
- On-Demand
- Service-specific
- Reserved Instances or reserved capacity
- Service-specific
- Savings Plans
- Service-specific
- Spot
- Service-specific
Billing dimensions: Launch type · Underlying compute · Observability · Data transfer
Programs and modes: EC2 launch type · Fargate · Fargate Spot · ECS Managed Instances
ECS control-plane pricing and purchase options vary by launch type; underlying compute terms apply.
Free Tier: Not applicable — verify current offers
Pricing reviewed 2026-07-25. Reviewed against the linked official AWS pricing page. Recheck regional rates and program terms before purchase.
Official AWS pricing
Official AWS sources reviewed 2026-07-21.
Why implement Amazon Elastic Container Service?
- Provides AWS-native container orchestration without requiring teams to operate a separate Kubernetes control plane.
- Runs tasks on Fargate, EC2, or managed capacity and integrates with IAM, VPC networking, load balancers, Cloud Map, and CloudWatch.
- Supports long-running services, one-off tasks, scheduled work, deployment controls, service auto scaling, and capacity providers.
How to implement Amazon Elastic Container Service
- Publish an image to ECR and define containers, CPU, memory, ports, health checks, secrets, logging, volumes, task roles, and execution roles in a task definition.
- Choose Fargate or an EC2-backed cluster, configure awsvpc networking and security groups, then create a service or run standalone tasks.
- Attach an ALB or NLB when needed and configure deployment health, auto scaling, CloudWatch or FireLens logs, alarms, and rollback behavior.
Amazon Elastic Container Service best practices
- Prefer awsvpc networking so tasks receive security groups, and keep inbound and outbound rules restricted to required peers and services.
- Use separate least-privilege task and execution roles, immutable image references, one primary process per container, and stdout or stderr logging.
- Handle SIGTERM for graceful shutdown, define container and load-balancer health checks, right-size tasks, and spread services across Availability Zones.
Amazon Elastic Container Service use cases and server impact
- Containerized web services and APIs
- Microservices and background workers
- Scheduled and event-driven container tasks
Replaces a self-managed container scheduler; choosing Fargate also removes container-host provisioning and patching, while EC2 capacity retains host responsibilities.
Official implementation resources
How Amazon Elastic Container Service works with other AWS services
Arrows show the documented technical direction. Reciprocal navigation does not imply a reverse technical dependency.
Official AWS sources reviewed 2026-07-25.
Elastic Load Balancing → Amazon Elastic Container Service
An ECS service registers tasks in a load balancer target group, and the load balancer forwards traffic only to healthy registered targets.
- Why teams use it
- This lets tasks scale or be replaced without changing the public endpoint.
- Permissions and networking
- Align target type with the ECS network mode, open only required security-group paths, and give ECS permission to manage target registration.
- Pricing and security caveats
- Load balancer capacity and ECS task compute are billed separately. Health-check mistakes can remove every task from service.
Amazon Elastic Container Service → AWS Fargate
ECS uses the Fargate capacity provider or launch type to run task definitions without customer-managed container instances.
- Why teams use it
- The pairing removes host provisioning and patching while retaining ECS service scheduling and deployment controls.
- Permissions and networking
- Set task CPU, memory, networking, execution roles, and task roles explicitly; place tasks in subnets that can reach required registries and services.
- Pricing and security caveats
- Fargate bills requested task resources and duration. It trades host-level control and some placement flexibility for reduced infrastructure management.
Amazon Virtual Private Cloud → Amazon Elastic Container Service
ECS tasks using awsvpc networking receive elastic network interfaces in selected VPC subnets and are controlled by security groups.
- Why teams use it
- Teams can isolate application tiers and use private connectivity while keeping routing policy independent from container scheduling.
- Permissions and networking
- Plan address space and subnet capacity, restrict security-group ingress, and provide NAT or VPC endpoints for required outbound service access.
- Pricing and security caveats
- NAT gateways, public IPv4 addresses, endpoints, and cross-AZ traffic can add cost. A VPC does not automatically make workloads private or secure.
AWS Identity and Access Management → Amazon Elastic Container Service
ECS task execution roles let the ECS agent perform launch-time actions, while task roles provide AWS credentials to application containers.
- Why teams use it
- Separating platform and application permissions limits credential scope per workload.
- Permissions and networking
- Do not collapse execution and task permissions into one broad role; constrain trust policies and protect task-role credentials from neighboring workloads.
- Pricing and security caveats
- IAM has no additional charge, but every authorized downstream service operation can incur cost. Roles do not provide network isolation.
Amazon Elastic Container Service → Amazon CloudWatch
ECS can send container logs to CloudWatch Logs and Container Insights can collect aggregated cluster, service, task, and container metrics.
- Why teams use it
- Centralized telemetry helps teams correlate deployment state with resource pressure and application failures.
- Permissions and networking
- Configure log drivers, retention, encryption, and execution-role permissions; enable enhanced observability only where its detail is useful.
- Pricing and security caveats
- Container Insights and log ingestion add charges beyond ECS or Fargate compute, and high-cardinality telemetry can increase cost quickly.
Architecture patterns using this service
- Run a containerized web application on Amazon ECS and Fargate — Store immutable images in Amazon ECR, deploy tasks with Amazon ECS on AWS Fargate, route HTTP traffic through an Application Load Balancer, and observe the service in CloudWatch.
- Build a resilient three-tier application on AWS — Route requests through an Application Load Balancer to an EC2 or ECS application tier, keep Amazon RDS private, and govern supported recovery points with AWS Backup.
- Run queue-backed asynchronous workers on AWS — Buffer background work in Amazon SQS, process it with Lambda or ECS workers under a concurrency ceiling, keep state in DynamoDB, and use dead-letter queues, redrive, and CloudWatch alarms to keep the system honest.
- Fan out AWS events to isolated consumers — Publish one event to EventBridge or SNS, give every consumer its own SQS queue, retry policy, and dead-letter queue, and let each consumer scale, fail, and deploy without touching the others.
Planning guides that use Amazon Elastic Container Service