Skip to main content
In this lesson we cover containerizing an application and running it on AWS using Elastic Container Service (ECS). Topics included:
  • What are containers and why use them
  • Common container-related challenges
  • What a container orchestrator does
  • An overview of AWS ECS and its launch types (EC2 vs Fargate)
  • Tasks, task definitions, services, and load balancing in ECS

​
What are containers?

Containers package an application together with everything it needs to run — application code, runtime, libraries, and dependencies — into a single portable, lightweight unit. This enables consistent builds and runtime behavior across environments: you can build and test locally and run the same container in production without reconfiguring the host. Think of containers as lightweight alternatives to virtual machines: they include only the components the application requires, start faster, and are easier to move between hosts and environments.
A presentation slide titled "What are containers" that explains containers as a tool to package and deploy applications with their dependencies using short bullet points and colored keywords. The left side shows icons of a containerized app, server racks, and stacked container images.
Running containers on a single host presents availability and scaling risks: if the host fails the application goes down. Production-ready container deployments typically require:
  • Multiple container instances across multiple hosts for redundancy and high availability
  • Load balancing to distribute requests across container instances
  • Networking so containers can communicate across hosts or networks
  • Health checks and process monitoring to restart crashed containers
  • Host-level failure detection to reschedule containers onto healthy hosts
  • Automated scaling to match traffic changes
Orchestration systems exist to handle these operational concerns and make containers reliable at scale.
A slide titled "Container Challenges" showing three host boxes with container icons and user-group icons above; the left host displays a crossed-out (forbidden) container while the others show normal containers.

​
Container orchestrators — responsibilities and options

Container orchestrators are the control plane that address the challenges listed above. Typical orchestrator responsibilities:
  • Deploy containers across multiple servers
  • Load-balance requests to containers
  • Provide container-to-container networking
  • Restart failed containers automatically
  • Relocate containers when hosts fail
Popular orchestrators include Kubernetes (open source), Apache Mesos, and AWS ECS (AWS-managed). They vary in complexity, operational model, and feature set.
A presentation slide titled "Container Orchestrators" showing logos for Kubernetes, Apache Mesos, and ECS on the left. On the right is a bulleted list of responsibilities like deploying containers, load-balancing, providing container-to-container connectivity, and restarting failed containers.
Quick comparison — orchestrators

​
Overview of AWS Elastic Container Service (ECS)

AWS ECS is a fully managed container orchestration service that provides the control plane for deploying and managing containerized applications on AWS. ECS handles task scheduling, service management, and integrates with other AWS services for networking, logging, and scaling. ECS requires compute resources to run containers. You choose one of two compute launch types:
  • EC2 launch type — you provision and manage the EC2 instances (hosts) that run containers.
  • Fargate launch type — AWS provisions and manages the underlying compute so you run containers in a serverless model.
ECS is an AWS-managed, proprietary orchestration solution. If multi-cloud portability is a requirement, plan accordingly.
A presentation slide about AWS Elastic Container Service (ECS) showing the ECS logo routing to three container icons. Bullet points note ECS is a fully managed container orchestration service by AWS that runs containers on EC2 or Fargate and is proprietary to AWS.

​
Why choose ECS?

ECS trades some flexibility for simplicity and tight AWS integration. Compared to Kubernetes, ECS has fewer concepts to learn and can be quicker to adopt if you’re already using AWS. Consider ECS when you want a managed orchestration experience with deep AWS service integrations and lower operational overhead.

​
ECS launch types — EC2 vs Fargate

ECS itself is the orchestration/control plane. The launch type determines where and how containers are executed. EC2 launch type
  • You provision and manage EC2 instances to host containers.
  • You are responsible for the host OS, security groups, patches, and running a container runtime (e.g., Docker or containerd) and the ECS agent (many ECS-optimized AMIs include these).
  • ECS schedules containers onto the EC2 instances you register.
  • This option gives you full infrastructure control and is suitable if you need custom host configuration or runtime access.
A slide titled "EC2 Launch" showing an ECS control plane and a cluster of EC2 instances with stacked components (patches, firewall, ECS Agent, docker) and Docker icons. Bulleted text notes you must manage the underlying EC2 infrastructure while ECS manages the containers, giving you full control.
Fargate launch type
  • AWS manages the underlying compute; you do not provision EC2 instances.
  • Fargate follows a serverless model: when you run a task, Fargate provisions the required compute and runs your containers.
  • You pay for the compute resources your tasks use; there are no long-running EC2 instances to manage.
  • This reduces operational overhead but provides less control over host-level configuration.
A slide diagram explaining AWS ECS Fargate: it shows the ECS control plane, Fargate-managed infrastructure, and a cluster with container (Docker) icons. Bullet points note that Fargate is serverless, creates servers on demand, and removes the need to provision EC2 instances.
Choosing between EC2 and Fargate

​
ECS tasks and task definitions — blueprint and workflow

Core workflow:
  1. Create a Dockerfile for your application and build a container image.
  2. Push the image to a container registry (for example, Docker Hub or Amazon ECR).
  3. Create an ECS task definition that specifies which image to run and the container settings (CPU, memory, ports, volumes, environment variables, etc.).
  4. Use the task definition to run tasks (the running instances of the definition) inside an ECS cluster.
A task definition is the blueprint that specifies container images, resource requirements, port mappings, volumes, environment variables, and other runtime configuration — conceptually similar to a service in Docker Compose.
A slide titled "ECS Task Definition" showing a flow from a user icon to a Dockerfile, then to Docker Hub (whale) and finally to an ECS task definition file. Bullets note it’s a blueprint for how containers should launch, including CPU/memory and image/ports/volumes.
Example (Docker Compose snippet for comparison)
A task is the running instantiation of a task definition. A single task definition can include multiple containers; when you run the task, all containers defined in that task definition start together.
A slide titled "ECS Tasks" showing a Task Definition document icon with arrows to two container/task icons inside an ECS boundary. Bulleted text explains a task is an instance of the task definition and runs containers with settings from that definition.

​
Services — maintaining desired task counts

An ECS service ensures a specified number of task instances are running and healthy. A service:
  • Uses a task definition to create and maintain the requested number of tasks
  • Monitors tasks and replaces failed tasks
  • Re-schedules tasks onto healthy hosts if an EC2 instance fails (EC2 launch type)
  • Is typically created per application component (e.g., frontend, backend, worker), with a configured desired count for each

​
Load balancers and traffic distribution

When multiple task instances are running across hosts, you typically place an AWS load balancer (for example, an Application Load Balancer) in front of them. The load balancer accepts incoming requests and distributes traffic across healthy container endpoints. ECS integrates with load balancers so that when you update or scale a service, ECS can register and deregister task endpoints with the load balancer and rely on its health checks.
When you create an ECS service you can optionally attach it to a load balancer. This lets ECS manage target registration and health checks for your running tasks automatically.

​
Further reading and references

For step-by-step tutorials and examples, consult the AWS documentation linked above and the Docker/ECR guides to learn image building, pushing, and creating task definitions for ECS.

Watch Video