AWS ECS: Orchestrating Containers Without Kubernetes

Orchestrating containers became incredibly relevant around 2015. That’s when engineers began to see the Kubernetes vs Mesos vs Docker Swarm wars. Eventually (roughly 2017/2018), Kubernetes took the winning prize. Orchestrating containers became a reality.

The other reality, however, was that many engineers and organizations didn’t want the complexity of Kubernetes. Although it continues to get easier, there is still a fair amount of complexity. For smaller organizations and startups especially, they don’t have a team that can just manage Kubernetes.

That’s where you see services like AWS ECS come into play.

In this blog post, you’ll learn what ECS is and how to deploy applications with it.

Prerequistes

To follow along with this blog post from a hands-on perspective, you'll need the following:

1. An AWS account. If you don't already have one, you can sign up here.

If you don't have an AWS account and/or don't want to sign up, you can still read through the steps in this blog post so you know how ECS is configured.

ECS Breakdown

AWS Elastic Container Service (ECS) is a container orchestration service. Much like how Kubernetes orchestrates containers for you, scales them, and ensures self-healing, ECS does the same thing. The way that ECS orchestration works from a "backend technology" perspective is unknown as it doesn't use Kubernetes, but its own proprietary software.

The key reasons that you'd want to go with ECS are:

1. If you don't want Kubernetes complexity.
2. If you're already running in AWS and don't plan on leaving.

Let's start with the first - k8s complexity. Although containers and Kubernetes is very much "the default" now, there are still plenty of organizations that want to move into this style of app modernization, but either don't have the expertise in house, the time to dedicated to the move, or the budget to hire engineers that can handle these workloads. Using ECS, the goal is that the majority of the work is "automated" for you and taken care of from an orchestration perspective. However, Kubernetes is getting easier. With services like AKS Automatic and EKS Auto Mode, managing Kubernetes at the cluster level is becoming less and less of a need.

The second part is if you're already running in AWS, but don't have any intention of leaving. The truth is that although cloud-based services (and this is for all clouds, not just AWS) are great, the more you're embedded in specific/dedicated cloud services that do one particular job, the harder it will be for you to leave. On the flipside, if you're using AWS Elastic Kubernetes Service (EKS), it's AWS-specific, but if you want to move to Azure Kubernetes Service (AKS) or Google Kubernetes Engine (GKE), you'll have to refactor slightly, but it's still Kubernetes so containerized images and Kubernetes Manifests will still work. The level of refactoring is if you're using AWS-specific services like RDS for databases running in k8s, but are moving to another cloud.

At the time of writing this, ECS only orchestrates containers, so all of your workloads may not move over to ECS if you're already on Kubernetes. For example, if you're using KubeVirt, you may not be able to run those workloads on ECS, but other "services" like Istio Ambient work. It'll come down to a matter of research on your end to figure out what you're currently running in Kubernetes and what will be "portable".

Overall, ECS is a great solution if you need a production-ready orchestration platform for containerized workloads, but don't need the bells and whistles that Kubernetes gives you. Other services that fall into the "ECS" category are GCP Cloud Run, Azure Container Instances, and Azure Container Apps.

Now that you know about ECS and why you'd want to use it, let's dive into how to get started using ECS.

Clusters

A Cluster is, as the name suggests, a cluster. It's a virtualized hardware environment that runs on various systems/servers to orchestrate containerized workloads for you. In the case of Clusters for AWS ECS, it's where your Task Definitions (more on that in the next section) will run.

1. Within the AWS Portal, search for aws ecs and click the Elastic Container Service service.

2. Within the ECS service, you'll see an option for Clusters in the left pane. Click the Clusters button and then click the Create cluster button.

3. The first step will be to create a cluster name and optionally, a namespace. The Namespace is just like in Kubernetes - it's a collection of services that make up an application stack.

4. The second step will be to choose the infrastructure. With ECS, you have two options:
   1. Fargate, which is a Serverless service in AWS.
   2. EC2.
5. Fargate gives you a little extra "automation" in the sense that you don't have to manually configure the instances and Fargate bursts workloads out as needed. If you have application stacks that always require a specific resource amount, however, EC2 may be the best choice. For example, running GPU-centric workloads with EC2 may be ideal.

6. You can also set up monitoring, encryption, and tags, but that's optional.

7. Once complete, click the orange Create button.

Now that the Cluster is created, let's create a new Task Definition to run on the Cluster.

Task Definition

The Task Definition is like a blueprint of how your containerized application is going to look. It contains everything from the name to the infrastructure where the container should run to the resources the container needs to storage and everything in between. It's important to note that the Task Definition cannot run without a Cluster.

1. Within the Task definitions section, click the orange Create new task definition button.

2. Choose the Create new task definition button, but you can also do the configuration with JSON if you'd prefer.

3. Give the Task Definition a name.

4. Choose your infrastructure requirements based on what the application task will need to run in terms of launch type and architecture. You'll also need a task role, which is an IAM role with the permissions to deploy ECS. For more information about this Role and what permissions are needed, check out this link.

5. This is where the magic happens. You can configure the name of the container, the container image path, all of the port mappings, and resource needs (CPU and memory).

For testing purposes, you can use Nginx. The Image URI is nginx:latest.

6. You'll also see a ton of optional options to configure your container like network settings and environment variables.

7. Once complete, click the orange Create button.

The final step is to deploy the containerized application, which you'll see in the next section.

Deploy Your Workload

The Cluster and the Task Definition is now created, which means you can deploy your containerized application to ECS.

1. Click the blue Deploy button.

2.When running Task Definitions on a server, you have two options:

1. Task
2. Service

A task is a single instance of a task definition. A service is a setup that runs multiple tasks simultaneously.

For the purposes of this blog post, you can choose task as, chances are, this is in a Dev environment. If you need more scalability, a service is recommended.

3. Configure the environment if anything needs to change, but chances are this can stay as default while you're testing out the deployment. You can, however, change things like the Capacity provider if you have clusters that run both Fargate and EC2.

4. You can leave all of the defaults. At the end of the page, click the orange Create button.

You'll now see that the application is running.

Closing Thoughts

AWS Elastic Container Service is a great solution if you need to get a containerized application or full application stack deployed without using orchestration platforms like Kubernetes. Within a few steps, you can get a containerized app deployed and ready to use. The only thing you'll need to remember is that to use ECS, you'll need a container image created as ECS doesn't provide a specific service to create a container image for you.