Q: What is Amazon Elastic Container Service?
Amazon Elastic Container Service (ECS) is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances. Amazon ECS eliminates the need for you to install, operate, and scale your own cluster management infrastructure. With simple API calls, you can launch and stop container-enabled applications, query the complete state of your cluster, and access many familiar features like security groups, Elastic Load Balancing, EBS volumes and IAM roles. You can use Amazon ECS to schedule the placement of containers across your cluster based on your resource needs and availability requirements. You can also integrate your own scheduler or third-party schedulers to meet business or application specific requirements.
Q: Why should I use Amazon ECS?
Amazon ECS makes it easy to use containers as a building block for your applications by eliminating the need for you to install, operate, and scale your own cluster management infrastructure. Amazon ECS lets you schedule long-running applications, services, and batch processes using Docker containers. Amazon ECS maintains application availability and allows you to scale your containers up or down to meet your application's capacity requirements. Amazon ECS is integrated with familiar features like Elastic Load Balancing, EBS volumes, VPC, and IAM. Simple APIs let you integrate and use your own schedulers or connect Amazon ECS into your existing software delivery process.
Q: What is the pricing for Amazon ECS?
There is no additional charge for Amazon ECS. You pay for AWS resources (e.g. EC2 instances or EBS volumes) you create to store and run your application. You only pay for what you use, as you use it; there are no minimum fees and no upfront commitments.
Q: How is Amazon ECS different from AWS Elastic Beanstalk?
AWS Elastic Beanstalk is an application management platform that helps customers easily deploy and scale web applications and services. It keeps the provisioning of building blocks (e.g., EC2, RDS, Elastic Load Balancing, Auto Scaling, CloudWatch), deployment of applications, and health monitoring abstracted from the user so they can just focus on writing code. You simply specify which container images are to be deployed, the CPU and memory requirements, the port mappings, and the container links.
Elastic Beanstalk will automatically handle all the details such as provisioning an Amazon ECS cluster, balancing load, auto-scaling, monitoring, and placing your containers across your cluster. Elastic Beanstalk is ideal if you want to leverage the benefits of containers but just want the simplicity of deploying applications from development to production by uploading a container image. You can work with Amazon ECS directly if you want more fine-grained control for custom application architectures.
Q: How is Amazon ECS different from AWS Lambda?
Amazon ECS is a highly scalable Docker container management service that allows you to run and manage distributed applications that run in Docker containers. AWS Lambda is an event-driven task compute service that runs your code in response to “events” such as changes in data, website clicks, or messages from other AWS services without you having to manage any compute infrastructure.
Using Amazon ECS
Q: Does Amazon ECS support any other container types?
No. Docker is the only container platform supported by Amazon ECS at this time.
Q: I want to launch containers. Why do I have to launch Tasks?
Docker encourages you to split your applications up into their individual components, and Elastic Container Service is optimized for this pattern. Tasks allow you to define a set of containers that you would like to be placed together (or part of the same placement decision), their properties, and how they may be linked. Tasks include all the information that Amazon ECS needs to make the placement decision. To launch a single container, your Task Definition should only include one container definition.
Q: Does Amazon ECS support applications and services?
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 Elastic Load Balancing. 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 (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).
Q: Does Amazon ECS support dynamic port mapping?
Yes. It is possible to associate a service on Amazon ECS to an Application Load Balancer (ALB) for the Elastic Load Balancing (ELB) service. The ALB supports a target group that contains a set of instance ports. You can specify a dynamic port in the ECS task definition which gives the container an unused port when it is scheduled on the EC2 instance. The ECS scheduler will automatically add the task to the Application Load Balancer’s target group using this port.
Q: Does Amazon ECS support batch jobs?
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.
Q: Can I use my own scheduler with Amazon ECS?
ECS provides Blox, a collection of open source projects for container management and orchestration. Blox makes it easy to consume events from Amazon ECS, store the cluster state locally and query the local data store through APIs. Blox also includes a daemon scheduler that can be used as a reference for how to use the cluster state server. See the Blox GitHub page to learn more.
Q: Can I use my own AMI?
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.
Q: How can I configure my container instances to pull from Amazon Elastic Container Registry?
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.
Q: How does AWS Fargate work with Amazon ECS?
With Fargate, the concept of server provisioning, cluster management, and orchestration completely goes away. Amazon ECS uses containers provisioned by Fargate to automatically scale, load balance, and manage scheduling of your containers for availability, providing an easier way to build and operate containerized applications.
Q: How should I choose between using AWS Fargate with Amazon ECS or just using ECS?
Amazon ECS supports Fargate technology and customers will be able to choose AWS Fargate to launch their containers without having to provision or manage EC2 instances. AWS Fargate is the easiest way to launch and run containers on AWS. Customers who require greater control of their EC2 instances to support compliance and governance requirements or broader customization options can choose to use ECS without Fargate to launch EC2 instances.
Security and Compliance
Q: How does Amazon ECS isolate containers belonging to different customers?
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 that are available for 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 EC2 instances use an IAM role to access the ECS service.
- Your ECS tasks use an IAM role to access services and resources.
- 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 EC2 resources as Dedicated Instances. Dedicated Instances are Amazon EC2 Instances that run on hardware dedicated to a single customer for additional isolation.
Q: Can I apply additional security configuration and isolation frameworks to my container instances?
Yes. As an Amazon EC2 customer, you have root access to the operating system of your container instances, enabling you to take ownership of the operating system’s security settings as well as load and configure additional software components for security capabilities such as monitoring, patch management, log management and host intrusion detection.
Q: Can I operate container instances with different security settings or segregate different tasks across different environments?
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.
Q: How do I configure IAM roles for ECS tasks?
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 form the ’Task Role’ drop-down or using the ‘taskRoleArn’ filed in the JSON format.
Q: Can I use Amazon ECS for Protected Health Information (PHI) and other HIPAA regulated workloads?
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 Docker 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.
Q: Can I use Amazon ECS for US Government-regulated workloads or processing sensitive Controlled Unclassified Information (CUI)?
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.
Service Level Agreement (SLA)
Q: What does the Amazon ECS SLA guarantee?
Our Compute SLA guarantees a Monthly Uptime Percentage of at least 99.99% for Amazon ECS.
Q: How do I know if I qualify for a SLA Service Credit?
You are eligible for a 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.
Transition to new ARN and ID format
Q: What is changing?
Starting November 15th 2018, Amazon ECS resources will transition to a new format for Amazon Resource Names (ARN) and identifiers (ID). The Amazon Resource Names format change will impact ECS Tasks, ECS Container Instances, and ECS Services. The identifier format change will impact ECS Tasks and ECS Container Instances. These changes will enable the recently launched tagging and cost-allocation features.
Starting today, you can opt-in to use the new tagging feature and adopt the new ARN and ID formats for your ECS resources. After you opt-in, the new ARN and ID format will apply to your newly-created resources; your existing resources won’t be affected and will keep their existing ARN and ID. Please visit this documentation for instructions.
Q: How does this impact me?
In many cases, you won’t need to make any system changes to handle the new format. If you only use the console to manage AWS resources, you will not be impacted and should update your settings to use the new ARN and ID format. If you interact with AWS resources via APIs, SDKs, or the AWS CLI, you might be impacted, depending on whether your software makes assumptions about the ARN or ID format when validating or persisting resources' ARN or ID. If this is the case, you might need to update your systems to handle the new format.
Some failure modes could include:
If your systems use regular expressions to validate the ARN or ID format or parses it to extract information from it, you might see errors when new formats are encountered.
If there are expectations about the ARN or ID length in your database schemas, you might be unable to store them. In particular, the new ARNs contain more information and are therefore longer. The new IDs are shorter.
Q: Will this affect existing resources?
No. Only resources that are created after you opt-in to the new format have the new format. Once a resource has been assigned an ARN/ID (old or new), it will retain its ARN/ID throughout its lifecycle regardless of any opt-in or opt-out actions you may subsequently take. For example, if you have an existing ECS Service before you opt-in, the ECS Service will retain its old ARN/ID after you opt-in. Any new tasks launched by that ECS Service after you opt-in will however have the new ARN.
Q: Which ECS resource ARNs are changing?
The ARN change will affect 3 resources: ECS Services, ECS Tasks, and ECS Container Instances.
Q: What will the new ARNs look like?
The new ARNs for ECS Container Instances, Services and Tasks will include the cluster name and are as shown in the table below:
Q: Which ECS resource IDs are changing?
The ID change will affect 2 resources: ECS Tasks and ECS Container Instances.
Q: What will the new IDs look like?
The new IDs will be shorter in length (32 characters) and will not include any hyphens. See the table below for an example of an old and a new ID.
Q: I have now opted-in, how do I transition my resources to the new formats so that I can tag them?
In order to ensure continuity, all existing ECS resources will retain their ARNs and IDs throughout their lifecycle. This means that only newly-created resources will get the new format. To transition your existing Tasks running in a Service, you can trigger a new Service deployment. To transition your ECS Services, you can delete and re-create the ECS Service. Finally, to transition your ECS Container Instances, you need to drain the container instances and register new ones.
Q: What is the deadline to adopt the new formats?
Through the end of December 2019, new ARNs/IDs will be available for opt-in via APIs and the ECS Console. All accounts can opt-in and out as needed for testing. Starting on January 1, 2020, the option to switch formats will no longer be available, and newly-created ECS resources will all receive the new ARNs and ID formats.
Q: Will new accounts be automatically opted-in?
Until March 31st, 2019 all newly-created AWS accounts will continue to default to the current formats. Starting April 1st, 2019, all newly-created accounts will be automatically opted-in, but you will retain the option to opt-out until December 31st 2019.
Q: How do I opt in and out of receiving new ARNs/IDs?
Throughout the transition period (Now through the end of December 2019), you can opt-in to receive the new formats by using the new ECS APIs or the EC2 Console. Instructions are provided in this documentation.
Q: Can I opt-in only a specific IAM user or IAM role in my account?
Yes. You can opt-in a specific IAM role or IAM user. Resources created by an IAM role or IAM user will get an ARN/ID format based on the opt-in status, at the time of creation, of the user or role that created the resource. Additionally, opting-in or opting-out the root-user will apply the change to the entire AWS account, unless an IAM user or role explicitly overrides the opt-in status for themselves.
Q: What will happen if I take no action?
If you do not opt-in to the new format during the transition period, you will automatically begin receiving the new formats starting January 1st, 2020. We do not recommend this approach. We recommend testing the new formats in advance during the transition windows to identify and resolve any potential issues.
Q: What if I prefer to continue using the old ARN/IDs for my resources created after December 31st 2019?
Unfortunately, starting January 1st 2020, all newly created resources will get the new ARN and ID format. This will enable to you to benefit from current and upcoming ECS features such as tagging and cost-allocation.
Q: If I opt in to new ARNs/IDs formats and then opt back out during the transition period, what will happen to resources that were created with new formats?
Once a resource has been assigned an ARN/ID, that ARN/ID will not change. Resources that are created with new ARN/ID will retain the new ARN/ID regardless of later actions. The only way to remove the new ARN/ID will be to delete or terminate the respective resources. For this reason, exercise caution and avoid creating critical resources with the new format until you have tested your tools and automation.
Q: What should I do if my systems are not working as expected before the transition period ends?
If your systems are not working as expected during the transition period, you can temporarily opt out of the new formats and remediate your systems. Starting January 1st 2020, regardless of your account settings, all new resources will receive the new ARN and ID formats, so it is important for you to test your systems with new format ARNs and IDs before the transition period ends. By testing and opting in earlier, you give yourself valuable time to make modifications to your tools and workflows and you minimize the risk of any impact to your systems.
Q: What will happen if I launch resources in multiple regions during the transition period?
You have the flexibility to opt-in region by region. This means that you can have a mix of regions where your opt-in status is different. If Amazon ECS launches new regions during the transition period, these regions will behave like existing regions. In other words, up until December 31st 2019, you will be able to choose whether you would like to use the new or old ARN format.