Containers

Introducing Amazon ECS Anywhere

In 2014, AWS introduced Amazon Elastic Container Service (Amazon ECS) as a simplified way for customers to address the complexity of managing containers on their EC2 instances at any scale. As adoption increased, customers responded with a new challenge: remove the undifferentiated heavy lifting of having to deal with EC2 instances. In 2018, we announced AWS Fargate, a serverless platform to run containers without having to deal with infrastructure details.

In the last two years, customers sought more flexibility in where they could deploy containers using Amazon ECS. They had an increasing number of use cases that required applications to run outside AWS Regions and closer to their other services, wherever they may be located. In 2019 and 2020, we made a series of announcements that made launching Amazon ECS tasks outside of the AWS Region a viable option. We introduced AWS Outposts, a service that extends AWS infrastructure, services, APIs, and tools to customers’ premises using AWS owned and fully managed hardware. We also introduced AWS Wavelength and AWS Local Zones to accommodate specific latency and network connectivity, with full support for Amazon ECS.

However, some customers asked for more options. For example, some of them have made significant capital investments in their data centers. These customers want to make good use of that capacity albeit they understand it may require more work to manage it. Other customers operate in a highly regulated industry. They may have specific compliance or regulatory requirements that force them to own and operate their infrastructure. While these customers may be all-in on cloud, they also have to consider the practical constraints (financial resources or specialized workloads, for example) that inhibit them.

Customers love the simplicity of Amazon ECS and the fact that “it just works.” However, their deployment requirements may go beyond AWS owned infrastructure and they can’t afford to use different container management technologies for different deployment targets. To make their investments sound, they need to focus on a single experience that allows them to achieve the flexibility that they need.

Today, we are announcing Amazon ECS Anywhere (ECS Anywhere), an extension of Amazon ECS. Available in 2021, ECS Anywhere will allow customers to deploy native Amazon ECS tasks in any environment. This will include the traditional AWS managed infrastructure, as well as customer-managed infrastructure. All this without compromising on the value of leveraging a fully AWS managed, easy to use, control plane that’s running in the cloud, and always up to date.

The following is a high-level visual representation of the Amazon ECS data plane flexibility. It includes the new ECS Anywhere deployment model that will come to fruition next year:

 

  • Customers will continue using the familiar managed ECS control plane that is running in the Region. This is where the ECS cluster objects will continue to be defined
  • The AWS Systems Manager agent will install on customer managed operating systems and turn those operating systems into “managed instances.”
  • A new converged version of the existing open source Amazon ECS agent will install on these managed instances (leveraging SSM Distributor, for example). These instances will register into an ECS cluster previously defined in the control plane in the Region.
  • A new launch type (and compatibility requirement) will be introduced. This will be in addition to the existing “EC2” and “FARGATE” launch types and is currently dubbed “EXTERNAL”. This new launch type allows the Amazon ECS control plane to run tasks on non-AWS managed infrastructure. We also aim to introduce support for ECS Anywhere in Amazon ECS capacity providers. Capacity providers remain the strategic way to manage capacity in an application-first Amazon ECS world.

These will be regular ECS tasks and will have, for example, a “task role” and a “task execution role” assigned. This means they will be able to interact, if need be, with cloud services in the Region as if they were deployed in the Region. However, there will also be effectively local resources running on customer managed operating system and with local network connectivity. This will allow Amazon ECS applications deployed “externally” to appreciate low latency and high bandwidth when connecting to services running in proximity in the same data center.

Finally, the following are the high-level tenets we are using to build ECS Anywhere:

  • The Amazon ECS control plane will remain in-region. This provides users the familiar simplicity of using Amazon ECS without compromising on the infrastructures they need to deploy their applications.
  • The only information sent to the Amazon ECS control plane in the Region is what is required for managing tasks. This includes host health, container activity (such as “launched” or “stopped”), and container health checks if configured.
  • Amazon ECS Anywhere is infrastructure agnostic. The ECS Anywhere agent is not opinionated about infrastructure details, and could work with VM, bare metal, Raspberry Pi, and other infrastructure types running supported operating systems. Having said this, the supportability of ECS Anywhere scenarios at the time of general availability may be artificially limited due to other constraints.
  • In disconnected scenarios, ECS Anywhere tasks continue running on customer managed infrastructure. Cloud connectivity is required to update or scale the tasks, or to connect to other in-region AWS services at runtime.

Note that these capabilities are currently in development. Some details may change before general availability.

This is an exciting evolution for Amazon ECS and we are looking forward to its general availability next year. In the meantime, to see scenarios where ECS Anywhere could help, check out this early demo. Join our mailing list for updates about ECS Anywhere.

[ Update 5/28/2021 ] With the general availability of ECS Anywhere, we are making available the code we have used to build and record the demo below. Check it out on GitHub.

Massimo Re Ferre

Massimo Re Ferre

Massimo is a Principal Technologist at AWS. For about 25 years, he specialized on the x86 ecosystem starting with operating systems, virtualization technologies and cloud architectures. He has been working on containers since 2014 and that is Massimo’s current area of focus within the compute service team at AWS . Massimo has a blog at www.it20.info and his Twitter handle is @mreferre.