Getting Started with Amazon ECS Anywhere – Now Generally Available

Since Amazon Elastic Container Service (Amazon ECS) was launched in 2014, AWS has released other options for running Amazon ECS tasks outside of an AWS Region such as AWS Wavelength, an offering for mobile edge devices or AWS Outposts, a service that extends to customers’ environments using hardware owned and fully managed by AWS.

But some customers have applications that need to run on premises due to regulatory, latency, and data residency requirements or the desire to leverage existing infrastructure investments. In these cases, customers have to install, operate, and manage separate container orchestration software and need to use disparate tooling across their AWS and on-premises environments. Customers asked us for a way to manage their on-premises containers without this added complexity and cost.

Following Jeff’s preannouncement last year, I am happy to announce the general availability of Amazon ECS Anywhere, a new capability in Amazon ECS that enables customers to easily run and manage container-based applications on premises, including virtual machines (VMs), bare metal servers, and other customer-managed infrastructure.

With ECS Anywhere, you can run and manage containers on any customer-managed infrastructure using the same cloud-based, fully managed, and highly scalable container orchestration service you use in AWS today. You no longer need to prepare, run, update, or maintain your own container orchestrators on premises, making it easier to manage your hybrid environment and leverage the cloud for your infrastructure by installing simple agents.

ECS Anywhere provides consistent tooling and APIs for all container-based applications and the same Amazon ECS experience for cluster management, workload scheduling, and monitoring both in the cloud and on customer-managed infrastructure. You can now enjoy the benefits of reduced cost and complexity by running container workloads such as data processing at edge locations on your own hardware maintaining reduced latency, and in the cloud using a single, consistent container orchestrator.

Amazon ECS Anywhere – Getting Started
To get started with ECS Anywhere, register your on-premises servers or VMs (also referred to as External instances) in the ECS cluster. The AWS Systems Manager Agent, Amazon ECS container agent, and Docker must be installed on these external instances. Your external instances require an IAM role that permits them to communicate with AWS APIs. For more information, see Required IAM permissions in the ECS Developer Guide.

To create a cluster for ECS Anywhere, on the Create Cluster page in the ECS console, choose the Networking Only template. This option is for use with either AWS Fargate or external instance capacity. We recommend that you use the AWS Region that is geographically closest to the on-premises servers you want to register.

This creates an empty cluster to register external instances. On the ECS Instances tab, choose Register External Instances to get activation codes and an installation script.

On the Step 1: External instances activation details page, in Activation key duration (in days), enter the number of days the activation key should remain active. The activation key can be used for up to 1,000 activations. In Number of instances, enter the number of external instances you want to register to your cluster. In Instance role, enter the IAM role to associate with your external instances.

Choose Next step to get a registration command.

On the Step 2: Register external instances page, copy the registration command. Run this command on the external instances you want to register to your cluster.

Paste the registration command in your on-premise servers or VMs. Each external instance is then registered as an AWS Systems Manager managed instance, which is then registered to your Amazon ECS clusters.

Both x86_64 and ARM64 CPU architectures are supported. The following is a list of supported operating systems:

  • CentOS 7, CentOS 8
  • RHEL 7
  • Fedora 32, Fedora 33
  • openSUSE Tumbleweed
  • Ubuntu 18, Ubuntu 20
  • Debian 9, Debian 10
  • SUSE Enterprise Server 15

When the ECS agent has started and completed the registration, your external instance will appear on the ECS Instances tab.

You can also add your external instances to the existing cluster. In this case, you can see both Amazon EC2 instances and external instances are prefixed with mi-* together.

Now that the external instances are registered to your cluster, you are ready to create a task definition. Amazon ECS provides the requiresCompatibilities parameter to validate that the task definition is compatible with the the EXTERNAL launch type when creating your service or running your standalone task. The following is an example task definition:

{
	"requiresCompatibilities": [
		"EXTERNAL"
	],
	"containerDefinitions": [{
		"name": "nginx",
		"image": "public.ecr.aws/nginx/nginx:latest",
		"memory": 256,
		"cpu": 256,
		"essential": true,
		"portMappings": [{
			"containerPort": 80,
			"hostPort": 8080,
			"protocol": "tcp"
		}]
	}],
	"networkMode": "bridge",
	"family": "nginx"
}

You can create a task definition in the ECS console. In Task Definition, choose Create new task definition. For Launch type, choose EXTERNAL and then configure the task and container definitions to use external instances.

On the Tasks tab, choose Run new task. On the Run Task page, for Cluster, choose the cluster to run your task definition on. In Number of tasks, enter the number of copies of that task to run with the EXTERNAL launch type.

Or, on the Services tab, choose Create. Configure service lets you specify copies of your task definition to run and maintain in a cluster. To run your task in the registered external instance, for Launch type, choose EXTERNAL. When you choose this launch type, load balancers, tag propagation, and service discovery integration are not supported.

The tasks you run on your external instances must use the bridge, host, or none network modes. The awsvpc network mode isn’t supported. For more information about each network mode, see Choosing a network mode in the Amazon ECS Best Practices Guide.

Now you can run your tasks and associate a mix of EXTERNAL, FARGATE, and EC2 capacity provider types with the same ECS service and specify how you would like your tasks to be split across them.

Things to Know
Here are a couple of things to keep in mind:

Connectivity: In the event of loss of network connectivity between the ECS agent running on the on-premises servers and the ECS control plane in the AWS Region, existing ECS tasks will continue to run as usual. If tasks still have connectivity with other AWS services, they will continue to communicate with them for as long as the task role credentials are active. If a task launched as part of a service crashes or exits on its own, ECS will be unable to replace it until connectivity is restored.

Monitoring: With ECS Anywhere, you can get Amazon CloudWatch metrics for your clusters and services, use the CloudWatch Logs driver (awslogs) to get your containers’ logs, and access the ECS CloudWatch event stream to monitor your clusters’ events.

Networking: ECS external instances are optimized for running applications that generate outbound traffic or process data. If your application requires inbound traffic, such as a web service, you will need to employ a workaround to place these workloads behind a load balancer until the feature is supported natively. For more information, see Networking with ECS Anywhere.

Data Security: To help customers maintain data security, ECS Anywhere only sends back to the AWS Region metadata related to the state of the tasks or the state of the containers (whether they are running or not running, performance counters, and so on). This communication is authenticated and encrypted in transit through Transport Layer Security (TLS).

ECS Anywhere Partners
ECS Anywhere integrates with a variety of ECS Anywhere partners to help customers take advantage of ECS Anywhere and provide additional functionality for the feature. Here are some of the blog posts that our partners wrote to share their experiences and offerings. (I am updating this article with links as they are published.)

Now Available
Amazon ECS Anywhere is now available in all commercial regions except AWS China Regions where ECS is supported. With ECS Anywhere, there are no minimum fees or upfront commitments. You pay per instance hour for each managed ECS Anywhere task. ECS Anywhere free tier includes 2200 instance hours per month for six months per account for all regions. For more information, see the pricing page.

To learn more, see ECS Anywhere in the Amazon ECS Developer Guide. Please send feedback to the AWS forum for Amazon ECS or through your usual AWS Support contacts.

Get started with the Amazon ECS Anywhere today.

Channy

Update. Watch a cool demo of ECS Anywhere to operate a Raspberry Pi cluster at home office and read its deep-dive blog post.

New – AWS App Runner: From Code to a Scalable, Secure Web Application in Minutes

Containers have become the default way that I package my web applications. Although I love the speed, productivity, and consistency that containers provide, there is one aspect of the container development workflow that I do not like: the lengthy routine I go through when I deploy a container image for the first time.

You might recognize this routine: setting up a load balancer, configuring the domain, setting up TLS, creating a CI/CD pipeline, and deploying to a container service.

Over the years, I have tweaked my workflow and I now have a boilerplate AWS Cloud Development Kit project that I use, but it has taken me a long time to get to this stage. Although this boilerplate project is great for larger applications, it does feel like a lot of work when all I want to do is deploy and scale a single container image.

At AWS, we have a number of services that provide granular control over your containerized application, but many customers have asked if AWS can handle the configuration and operations of their container environments. They simply want to point to their existing code or container repository and have their application run and scale in the cloud without having to configure and manage infrastructure services.

Because customers asked us to create something simpler, our engineers have been hard at work creating a new service you are going to love.

Introducing AWS App Runner
AWS App Runner makes it easier for you to deploy web apps and APIs to the cloud, regardless of the language they are written in, even for teams that lack prior experience deploying and managing containers or infrastructure. The service has AWS operational and security best practices built-it and automatically scale up or down at a moment’s notice, with no cold starts to worry about.

Deploying from Source
App Runner can deploy your app by either connecting to your source code or to a container registry. I will first show you how it works when connecting to source code. I have a Python web application in a GitHub repository. I will connect App Runner to this project, so you can see how it compiles and deploys my code to AWS.

In the App Runner console, I choose Create an App Runner service.

Screenshot of the App Runner Console

For Repository type, I choose Source code repository and then follow the instructions to connect the service to my GitHub account. For Repository, I choose the repository that contains the application I want to deploy. For Branch, I choose main.

Screenshot of source and deployment section of the console

For Deployment trigger, I choose Automatic. This means when App Runner discovers a change to my source code, it automatically builds and deploys the updated version to my App Runner service

Screenshot of the deployment settings section of the console

I can now configure the build. For Runtime, I choose Python 3. The service currently supports two languages: Python and Node.js. If you require other languages, then you will need to use the container registry workflow (which I will demonstrate later). I also complete the Build command, Start command, and Port fields, as shown here:

Screenshot of the Configure build section of the console

I now give my service a name and choose the CPU and memory size that I want my container to have. The choices I make here will affect the price I pay. Because my application requires very little CPU or memory, I choose 1 vCPU and 2 GB to keep my costs low. I can also provide any environment variables here to configure my application.

Screenshot of the configure service section of the console

The console allows me to customize several different settings for my service.

I can configure the auto scaling behavior. By default, my service will have one instance of my container image, but if the service receives more than 80 concurrent requests, it will scale to multiple instances. You can optionally specify a maximum number for cost control.

I can expand Health check, and set a path to which App Runner sends health check requests. If I do not set the path, App Runner attempts to make a TCP connection to verify health. By default, if App Runner receives five consecutive health check failures, it will consider the instance unhealthy and replace it.

I can expand Security, and choose an IAM role to be used by the instance. This will give permission for the container to communicate with other AWS services. App Runner encrypts all stored copies of my application source image or source bundle. If I provide a customer-managed key (CMK), App Runner uses it to encrypt my source. If I do not provide one, App Runner uses an AWS-managed key instead.

Screenshot of the console

Finally, I review the configuration of the service and then choose Create & deploy.

Screenshot of the review and create section of the console

After a few minutes, my application was deployed and the service provided a URL that points to my deployed web application. App Runner ensures that https is configured so I can share it with someone on my team to test the application, without them receiving browser security warnings. I do not need to implement the handling of HTTPS secure traffic in my container image App Runner configures the whole thing.

I now want to set up a custom domain. The service allows me to configure it without leaving the console. I open my service, choose the Custom domains tab, and then choose Add domain.

Screenshot of the custom domain section of the console

In Domain name, I enter the domain I want to use for my app, and then choose Save.

Screenshot of user adding a custom domain

After I prove ownership of the domain, the app will be available at my custom URL. Next, I will show you how App Runner works with container images.

Deploy from a Container Image
I created a .NET web application, built it as a container image, and then pushed this container image to Amazon ECR Public (our public container registry).

Just as I did in the first demo, I choose Create service. On Source and deployment, for Repository type, I choose Container registry. For Provider, I choose Amazon ECR Public. In Container image URI, I enter the URI to the image.

The deployment settings now only provide the option to manually trigger the deployment. This is because I chose Amazon ECR Public. If I wanted to deploy every time a container changed, then for Provider, I would need to choose Amazon ECR.

Screenshot of source and deployment section of the console

From this point on, the instructions are identical to those in the “Deploying from Source” section. After the deployment, the service provides a URL, and my application is live on the internet.

Screenshot of the app running

Things to Know
App Runner implements the file system in your container instance as ephemeral storage. Files are temporary. For example, they do not persist when you pause and resume your App Runner service. More generally, files are not guaranteed to persist beyond the processing of a single request, as part of the stateless nature of your application. Stored files do, however, take up part of the storage allocation of your App Runner service for the duration of their lifespan. Although ephemeral storage files are not guaranteed to persist across requests, they might sometimes persist. You can opportunistically take advantage of it. For example, when handling a request, you can cache files that your application downloads if future requests might need them. This might speed up future request handling, but I cannot guarantee the speed gains. Your code should not assume that a file that has been downloaded in a previous request still exists. For guaranteed caching, use a high-throughput, low-latency, in-memory data store like Amazon ElastiCache.

Partners in Action
We have been working with partners such as MongoDB, Datadog and HashiCorp to integrate with App Runner. Here is a flavor of what they have been working on:

MongoDB – “We’re excited to integrate App Runner with MongoDB Atlas so that developers can leverage the scalability and performance of our global, cloud-native database service for their App Runner applications.”

Datadog – “Using AWS App Runner, customers can now more easily deploy and scale their web applications from a container image or source code repository. With our new integration, customers can monitor their App Runner metrics, logs, and events to troubleshoot issues faster, and determine the best resource and scaling settings for their app.”

HashiCorp – “Integrating HashiCorp Terraform with AWS App Runner means developers have a faster, easier way to deploy production cloud applications, with less infrastructure to configure and manage.”

We also have exciting integrations from PulumiLogz.io, and Sysdig, which will allow App Runner customers to use the tools and service they already know and trust. As an AWS Consulting Partner, Trek10 can help customers leverage App Runner for cloud-native architecture design.

Availability and Pricing
AWS App Runner is available today in US East (N. Virginia), US West (Oregon), US East (Ohio), Asia Pacific (Tokyo), Europe (Ireland). You can use App Runner with the AWS Management Console and AWS Copilot CLI.

With App Runner, you pay for the compute and memory resources used by your application. App Runner automatically scales the number of active containers up and down to meet the processing requirements of your application. You can set a maximum limit on the number of containers your application uses so that costs do not exceed your budget.

You are only billed for App Runner when it is running and you can pause your application easily and resume it quickly. This is particularly useful in development and test situations as you can switch off an application when you are not using it, helping you manage your costs. For more information, see the App Runner pricing page.

Start using AWS App Runner today and run your web applications at scale, quickly and securely.

— Martin

 

Modern Apps Live: Learn Serverless, Containers and More in May

Modern Apps Live is a series of events about modern application development that will be live-streaming on Twitch in May. Session topics include serverless, containers, and mobile and front-end development.

If you’re not familiar, modern applications are those that:

  • Can scale quickly to millions of users.
  • Have global availability.
  • Manage a lot of data (we’re talking exabytes of data).
  • Respond in milliseconds.

These applications are built using a combination of microservices architectures, serverless operational models, and agile developer processes. Modern applications allow organizations to innovate faster and reduce risk, time to market, and total cost of ownership.

Modern Apps Live is a series of four virtual events:

If you’re a developer, solutions architect, or IT and DevOps professional who wants to build and design modern applications, these sessions are for you, no matter if you’re just starting out or a more experience cloud practitioner. There will be time in each session for Q&A. AWS experts will be in the Twitch chat, ready to answer your questions.

If you cannot attend all four events, here are some sessions you definitely shouldn’t miss:

  • Keynotes are a must! AWS leadership will share product roadmaps and make some important announcements.
  • There are security best practices sessions scheduled on May 4 and May 19, during the Container Day x Kubecon and Serverless Live events. Security should be a top priority when you develop modern applications.
  • If you’re just getting started with serverless, don’t miss the “Building a Serverless Application Backend” on May 19. Eric Johnson and Justin Pirtle will show you how to pick the right serverless pattern for your workload and share information about security, observability, and simplifying your deployments.
  • On May 25, in the “API modernization with GraphQL” session, Brice Pelle will show how you can use GraphQL in your client applications.
  • Bring any burning questions about containers to the “Open Q&A and Whiteboarding” session during the Container Day x DockerCon event on May 26.

For more information or to register for the events, see the Modern Apps Live webpage.

I hope to see you there.

Marcia