Amazon ECS FAQs

Visit our Getting Started page for more information on how to start using Amazon ECS. Whether you are new to Amazon ECS or you already have a use case in mind, you can choose your own path and follow the curated learning steps to get started.

Modern application (say Microservices) architecture recommends to split your applications into the individual units, and Amazon ECS is optimized for this pattern. Tasks are the smallest unit of compute in Amazon ECS and allow you to define a set of containers you would like to place together, their properties, and how they may be linked. Tasks include all the information Amazon ECS needs to make the placement decision. To launch a single container, your task definition should only include one container definition.

Yes. The Amazon ECS service scheduler can manage long-running applications and services. The service scheduler helps you maintain application availability and allows you to scale your containers up or down to meet your application's capacity requirements. The service scheduler allows you to distribute traffic across your containers using ELB. Amazon ECS will automatically register and deregister your containers from the associated load balancer. The service scheduler will also automatically recover containers that become unhealthy (i.e., fail ELB health checks) or stop running to ensure you have the desired number of healthy containers supporting your application.

You can scale your application up and down by changing the number of containers you want the service to run. You can update your application by changing its definition or using a new image. The scheduler will automatically start new containers using the new definition and stop containers running the previous version (waiting for the ELB connections to drain if ELB is used).

Applications and microservices deployed to Amazon ECS leverage the Application Auto Scaling service to automatically scale based on observed metrics data. Amazon ECS measures service utilization based on CPU and memory resources consumed by the tasks that belong to a service and publishes CloudWatch metrics, namely, ECSServiceAverageCPUUtilization and ECSServiceAverageMemoryUtilization, with this data. Application Auto Scaling can then use these predefined metrics in conjunction with scaling policies to proportionally scale the number of tasks in a service. Additionally, there are use cases where a service’s average CPU and memory usage alone are not reliable indicators of when and to what degree to execute a scaling action. For this, Application Auto Scaling also supports scaling a service based on a custom metric specification that represents a CloudWatch metric of our choosing, which may be better suited. This includes metrics that track other application aspects such as number of HTTP requests received, number of messages retrieved from a queue/topic, and number of database transactions. You can now use CloudWatch metrics or Prometheus metrics of your choosing.

To learn more, please visit: Autoscaling Amazon ECS services based on custom CloudWatch and Prometheus metrics

Amazon ECS enables you to run a wide variety of applications with the same experience and tooling across a diverse set of compute options:

• AWS Fargate: AWS Fargate is a serverless, pay-as-you-go compute engine. It removes the burden of server provisioning, cluster management, and orchestration. Amazon ECS uses containers provisioned by AWS Fargate to automatically scale, load balance, and manage scheduling of your containers for availability, providing an easier way to build and operate containerized applications.
• Amazon EC2: With Amazon on ECS on EC2, you own the EC2 instances and have complete control over all aspects of infrastructure management. For instance, you can select specific EC2 instance types or customize the underlying operating system. You can use Auto Scaling Group Capacity Providers to manage the scaling of EC2 instances.
• On-premises virtual machines (VM) or servers:
  • Amazon ECS Anywhere provides support for registering an external instance such as an on-premises server or virtual machine (VM), to your Amazon ECS cluster. 
  • The capacity can be located in any of the following AWS resources:    
    • Availability Zones
    • Local Zones
    • Wavelength Zones
    • AWS Regions
    • AWS Outposts

Yes. Amazon ECS supports autoscaling compute infrastructure for both AWS Fargate and Amazon EC2, so that you can focus on building and scaling your applications rather than the underlying infrastructure.

Amazon ECS with AWS Fargate provides you a serverless experience, as AWS Fargate automatically provisions, scales, and updates the compute infrastructure needed for your applications.

For your applications that require Amazon EC2 capacity, Amazon ECS provides Auto Scaling Group Capacity Providers which automatically scale Amazon EC2 instances in response to the capacity requirement of your applications. You can create an Amazon EC2 Auto Scaling Group (ASG) with your desired configuration for Amazon EC2 instance types, Amazon Machine Image (AMI), network settings, etc. and create a Capacity Provider to automatically scale Amazon EC2 instances in that ASG based on the scheduling needs and load for your applications. manages the scale-in and scale-out actions of the ASG based on the load your tasks.

Amazon ECS capacity providers are the interface through which you can define the capacity needs for your applications. Capacity providers allow you to define flexible rules for how your applications run on different types of compute capacity, and manage the scaling of the capacity. Capacity Providers work with both Amazon EC2 and AWS Fargate. Amazon ECS provides predefined capacity providers for AWS Fargate and Fargate-Spot capacities for every cluster. For Amazon EC2, you can create your own ASG capacity providers to manage scaling of an Amazon EC2 Auto Scaling Group. When running Amazon ECS tasks and services, you can split them across multiple capacity providers, for instance to run a service in a predefined split percentage across AWS Fargate and Fargate Spot capacities.

Yes. You can use Amazon ECS Run task to run one or more tasks once. Run task starts the task on an instance that meets the task’s requirements including CPU, memory, and ports. You can also use AWS Batch to plan, schedule, and execute your batch computing workloads using on Amazon ECS, so you can focus on analyzing results and solving problems. 

Yes. You can use any AMI that meets the Amazon ECS AMI specification. We recommend starting from the Amazon ECS-enabled Amazon Linux AMI. Partner AMIs compatible with Amazon ECS are also available. You can review the Amazon ECS AMI specification in the documentation.

Amazon ECR is integrated with Amazon ECS allowing you to easily store, run, and manage container images for applications running on Amazon ECS. All you need to do is specify the Amazon ECR repository in your task Definition and attach the AmazonEC2ContainerServiceforEC2Role to your instances. Then Amazon ECS will retrieve the appropriate images for your applications.

AWS Fargate offers serverless compute to run containers with Amazon ECS. AWS Fargate allows customers to launch their containers without having to provision or manage Amazon EC2 instances. AWS Fargate is the easiest way to launch and run containers on AWS. Customers requiring greater control of their EC2 instances (to support compliance and governance requirements or broader customization options) can choose to use Amazon ECS with Amazon EC2 instances.

Amazon ECS is integrated with Elastic Load Balancing, allowing you to distribute traffic across your containers using Application Load Balancers or Network Load Balancers. You specify the task definition and the load balancer to use, and Amazon ECS automatically adds and removes containers from the load balancer. Specify a dynamic port in the task definition, which gives your container an unused port when it is scheduled on an Amazon EC2 instance. In addition, use path-based routing to share a load balancer with multiple services.

Amazon ECS supports Docker networking and integrates with Amazon VPC to provide isolation for containers. This gives you control over how containers connect with other services and external traffic. With Amazon ECS, you can choose between four networking modes for your containers that cater towards different use cases:

• VPC Mode: This mode assigns each running Amazon ECS task a dedicated elastic networking interface, allowing containers full networking features in a VPC, just like Amazon EC2 instances.
• Bridge Mode: This mode creates a Linux bridge that connects all containers running on the host in a local virtual network, which can be accessed through the host's default network connection.
• Host Mode: This mode adds containers directly to the host’s network stack, exposing containers on the host's network with no isolation.
• None: This mode disables external networking for containers.

• Service Connect: Amazon ECS Service Connect simplifies service discovery, connectivity, and traffic observability for Amazon ECS. It helps you build applications faster by letting you focus on the application code and not on your networking infrastructure. You can use Amazon ECS Service Connect to define logical names for your service endpoints and use them in your client applications to connect to dependencies. Amazon ECS Service Connect helps send your traffic to healthy endpoints and provides rich traffic telemetry in the Amazon ECS console and in Amazon CloudWatch. Native Amazon ECS deployments are more robust with Amazon ECS Service Connect, as it supports automatic connection draining that helps your client applications switch to a new version of the service endpoint without encountering traffic errors. With Amazon ECS Service Connect, you can:
  • Set the way client applications connect to their dependencies in just one step
  • Write and operate resilient distributed applications with logical naming
  • Monitor and distribute traffic between Amazon ECS tasks without deploying and configuring load balancers
  • Deploy services faster and deliver seamless integration of Amazon ECS microservices comprising an application
• Service Discovery: Amazon ECS is integrated with AWS Cloud Map to make it easy for your containerized services to discover and connect with each other. AWS Cloud Map is a cloud resource discovery service that lets you define custom names for your application resources. It increases your application availability because your web service will always discover the most up-to-date locations of these dynamically changing resources.

• Monitoring
  • You can monitor your Amazon ECS resources using Amazon CloudWatch, which collects and processes raw data from Amazon ECS into readable, near real-time metrics. These statistics are recorded for a period of two weeks so that you can access historical information and gain a better perspective on how your clusters or services are performing. There is no additional charge for this. To learn more, please visit, Amazon ECS CloudWatch metrics.
  • For enhanced metrics, use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices, available for your Amazon ECS clusters running on Amazon EC2 and AWS Fargate. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. For Amazon ECS, Container Insights collects metrics at the cluster, task and service levels on both Linux and Windows Server instances. It can collect metrics at the instance-level only on Linux instances.Network metrics are available only for containers in bridge network mode and awsvpc network mode. They are not available for containers in host network mode. To learn more, please visit, Using Container Insights.
• Logging
  • Amazon ECS allows you to record all your Amazon ECS API calls and have the log files delivered to you through AWS CloudTrail. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by Amazon ECS. CloudTrail provides you a history of API calls made from the AWS Management Console, AWS SDKs, and AWS CLI. It enables security analysis, resource change tracking, and compliance auditing.
• AWS Config
  • AWS Config integrates with Amazon ECS to provide you visibility into your configuration of AWS resources in your AWS account. AWS Config allows users to monitor and track how resources were configured, how they relate to one another, and how the configurations and relationships change over time. AWS Config enables you to simplify compliance and security, operational troubleshooting, and resource administration.
• Third Party
  • Amazon ECS supports an entire ecosystem of third-party observability vendors by embracing open container standards. For more information view the Amazon ECS Partners page.

Costs for Amazon ECS tasks running on AWS Fargate are available in AWS Cost and Usage Reports (CUR) and AWS Cost Explorer automatically. You can use managed as well as user-added tags to aggregate and allocate costs to new and existing business units, teams, or applications for your Amazon ECS tasks.

Learn more about Amazon ECS usage reports.

You can access cost and usage information for Amazon ECS tasks running on Amazon EC2 instances in AWS Cost and Usage Reports (CUR) by opting into Split Cost Allocation Data for Amazon ECS. Split Cost Allocation Data generates task-level costs for Amazon ECS tasks running on Amazon EC2 instances by analyzing each task’s resource consumption based on the price of the instance, and the percentage of CPU and memory resources consumed by the containers running on the instance. Split Cost Allocation Data automatically ingests managed and user-added tags for your Amazon ECS tasks, allowing you to aggregate and allocate costs to new and existing business units, teams, or applications. You can opt into Split Cost Allocation Data for Amazon ECS from the AWS Cost Management console preferences. Then you can opt into Split Cost Allocation Data for your individual CUR reports from the CUR reporting preferences in AWS Billing console. 

Learn more about enabling split cost allocation data.
 

Amazon ECS schedules containers for execution on customer-controlled Amazon EC2 instances or with AWS Fargate and builds on the same isolation controls and compliance settings available for Amazon EC2 customers. Your compute instances are located in a Virtual Private Cloud (VPC) with an IP range that you specify. You decide which instances are exposed to the Internet and which remain private.

• Your Amazon EC2 instances use an IAM role to access the Amazon ECS service.
• Your Amazon ECS tasks use an IAM role to access services and resources.
• Your Amazon ECS tasks running on AWS Fargate run in isolated virtual machines.
• Security Groups and networks ACLs allow you to control inbound and outbound network access to and from your instances.
• You can connect your existing IT infrastructure to resources in your VPC using industry-standard encrypted IPsec VPN connections.
• You can provision your Amazon EC2 resources as Dedicated Instances. Dedicated Instances are Amazon EC2 Instances that run on hardware dedicated to a single customer for additional isolation.

Yes. As an Amazon EC2 customer, you have root access to the operating system (OS) of your container instances. You can take ownership of the OS security settings, as well as configure additional software components for security capabilities such as monitoring, patch management, log management, and host intrusion detection. 

Using Amazon ECS with AWS Fargate drives high levels of security with the ability to assign granular permissions to each task, giving you a higher degree isolation, network access control, and IAM control when building applications. With AWS Fargate, every task runs in a separate virtual machine (VM), providing more isolation than two tasks sharing the same host. Each task also has its own network interface allowing the security group to be applied to each task, with control over the incoming and outgoing traffic.

Yes. You can configure your different container instances using the tooling of your choice. Amazon ECS allows you to control the placement of tasks in different container instances through the construct of clusters and targeted launches.

Yes. Customers can configure their container instances to access a private container image registry within a VPC or a registry that’s accessible outside a VPC such as Amazon ECR.

You first need to create an IAM role for your task, using the 'Amazon EC2 Container Service Task Role’ service role and attaching a policy with the required permissions. When you create a new task definition or a task definition revision, you can then specify a role by selecting it from the ’Task Role’ drop-down or using the ‘taskRoleArn’ filed in the JSON format.

Amazon ECS meets the standards for PCI DSS Level 1, ISO 9001, ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, and HIPAA eligibility.

For more information, visit our compliance pages.

Yes. Amazon ECS is HIPAA-eligible. If you have an executed Business Associate Addendum (BAA) with AWS, you can use Amazon ECS to process encrypted Protected Health Information (PHI) using containers deployed onto the AWS Fargate launch-type or Amazon EC2 compute instances.

For more information, please visit our page on HIPAA compliance. If you plan to process, store, or transmit PHI and do not have an executed BAA from AWS, please contact us for more information.

Yes. By using the AWS GovCloud (US) region, containers and clusters managed by Amazon ECS can meet the requirements to sensitive data and regulated workloads with your containers. For more information, visit our page on AWS GovCloud.

Customers can also deploy their workloads on Amazon ECS using AWS Fargate in a manner compliant with Federal Information Processing Standard (FIPS) 140-2. FIPS is a U.S. and Canadian government standard that specifies the security requirements for cryptographic modules that protect sensitive information.

Our Compute SLA guarantees a Monthly Uptime Percentage of at least 99.99% for Amazon ECS. AWS makes two SLA commitments for Amazon ECS and AWS Fargate: (1) a Multi-AZ Included Container Service SLA that governs Included Container Services deployed across multiple AZs; and (2) a Single Task/Pod SLA that governs Included Container Service tasks and pods individually. Please see the AWS Fargate and Amazon Elastic Container Service SLA page.

You are eligible for an SLA credit for Amazon ECS under the Compute SLA if more than one Availability Zone in which you are running a task, within the same region has a Monthly Uptime Percentage of less than 99.99% during any monthly billing cycle.

For full details on all of the terms and conditions of the SLA, as well as details on how to submit a claim, please see the Compute SLA details page.