Devops Zero to Hero #7 — Deploying Containers with AWS ECS

AWS ECS to deploy a 3-tier application in production

Published in

AWS Tip

9 min readMar 19, 2024

In my previous blogs on the series, Devops Zero to Hero, I have deployed containerized applications with docker and docker-compose. It was fine for testing the application but not good enough to deploy them In production.

If you want to deploy a container-based application in production, AWS provides two options —
1. ECS: Amazon Elastic Container Service — Ideal for users who want a simpler and fully managed container orchestration solution
2. EKS: Amazon Elastic Kubernetes Service — A better fit for users who require the flexibility and scalability of Kubernetes for container orchestration.

In this blog post, we will use ECS to deploy a WordPress application in a containerized way. I will use the AWS console to create all resources in this blog post.
I will cover the Terraform deployment in the next blog with another real-world example.

What is AWS ECS?

AWS ECS is a fully managed container orchestration service that allows you to run Docker containers in a scalable and highly available manner.

Key Features of AWS ECS

ECS enables you to run and manage Docker containers on a cluster of EC2 instances or Fargate(Serverless compute)
ECS integrates seamlessly with other AWS services ELB, VPC, IAM, AWS CloudWatch, and AWS CodePipeline, enabling you to build comprehensive and scalable applications.
ECS Provides built-in auto-scaling capabilities.
ECS integrates with AWS Cloud Map for service discovery, making it easy to dynamically discover and connect to services running in your ECS clusters.
ECS distributes containers across multiple Availability Zones within a region to ensure high availability and fault tolerance.

ECS architecture

ECS architecture comprises key components working together for container deployment and management:

Clusters: An ECS cluster is a logical grouping of tasks or services.
Tasks: Fundamental unit of ECS, tasks run containerized applications on EC2 instances or Fargate tasks.
Task definition: It is a blueprint for your application. You define parameters like Docker image, CPU, memory, networking, and dependencies.
Service: Maintain desired task count in a cluster, scaling automatically. Ensures high availability by distributing tasks and restarting failed ones.
Container Instances: EC2 instances or Fargate tasks running Docker daemon and hosting ECS containers.
ECS Agent: Lightweight daemon running on each container instance, managing container lifecycle tasks like starting, stopping, and restarting containers.
ECS Control Plane: Centralized management component orchestrating container deployments and managing cluster resources.

ECS allows you 3 options to run your container-based application.

AWS Fargate — AWS manages the underlying infra where your containers will be running
AWS EC2 instances — You run containers on the EC2 instances that you manage.
On-prem VM — You run your containers on on-prem VMs

Create an ECS cluster with an AWS Fargate option as I am too lazy to manage the EC2 instances and all that pain that comes with it.

Deploying a 3-tier containerized application on ECS

The process is simple —

You first create an ECS cluster with AWS fargate.
Create a task definition with a WordPress docker public image. You can also use a private container image from ECR
Deploy an ECS service that will use an application load balancer which will be used to access the application.
Create an RDS MYSQL instance with WordPress to store the application data.
Connect the database with the application
Access the application with ALB(Application Load balancer) DNS name.
You can also map your ALB DNS with a custom domain you own. I will not be doing this in this demo.

Let’s get started with the ECS demo

1. Create an ECS cluster

You can either run the containerized application using ECS Service or Task.

Containers designed to complete a single task and then terminate are better suited to run as Tasks.
If you want to run a container-based application with load balancing, autoscaling, etc, then you use ECS services. Ultimately you will be running tasks but service will be managing that.

Before you run tasks/services with AWS ECS, you need to create a task definition. In task definition, you define the basic configuration of how you want to run your docker container.

2. Create ECS task definition

You can create the task definition with UI or with JSON.

image — This can be a public image on the docker hub or a private image stored in AWS ECR.
name — the name of the task definition
family — this is the task definition family name, it can be anything you wish.
You have multiple options such as defining the container port, adding volumes, environment variables, execution role, etc.

You can copy the below JSON, paste it to the task definition, and create. make sure you update your AWS account ID.

One thing to note is that the container and host port should be the same.

{
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "family": "ecs-demo-wordpress",
    "containerDefinitions": [
        {
            "name": "ecs-demo-wordpress",
            "image": "wordpress",
            "essential": true,
            "portMappings": [
                {
                    "name": "http",
                    "containerPort": 80,
                    "hostPort": 80,
                    "protocol": "tcp",
                    "appProtocol": "http"
                }
            ]
            
        }
    ],
    "volumes": [],
    "networkMode": "awsvpc",
    "memory": "3 GB",
    "cpu": "1 vCPU",
    "executionRoleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ecsTaskExecutionRole"
}

You can create the same with UI, and let me show you that one if you find JSON scary to look at.

Choose the default options and create. A few important things to notice about the

Task role: A task execution IAM role is used by the container agent to make AWS API requests on your behalf. If you don’t already have a task execution IAM role created, AWS will create one for you.

You do not require this for this example as we will use a simple WordPress image that does not depend on AWS services.

Task execution role: You can use the default role or create your own. This role will allow ECS to pull the image from ECR

Choose one of the above options and create an ECS task definition. By default, it will create version 1. You can update the task definition and create a new version of the task definition.

3. Create an ECS service

Select the launch type as Fargate. This is the serverless option, i.e. AWS will manage the underlying EC2 instances for you.
For deployment type, use the Service
Desired tasks as 2, i.e. ECS will ensure that the 2 application containers will always be running. If any container goes down for some reason, ECS will bring up another container.

Scroll down, expand the networking options, and below.

VPC — Use the VPC you want to applications in.
Subnet — Choose 2 or 3 zones for high availability.
A security group that will allow inbound and outbound connections to container applications. Make sure that the security group allows inbound and outbound on HTTP port 80 so the Application load balancer can talk to the container.
ALB — Create an application load balancer that listens on port 80.
You can also configure autoscaling and volumes if required.

Create the service. It will take a few minutes to create.

4. Accessing the application

We can use the DNS name for the application load balancer we created to access the application(Service).

Use the DNS name of ALB to access the application

As I mentioned before, WordPress requires a MySQL database to work. In the above prompt, we should be providing the database details.

As of now, we have not created any databases. Let’s create one with AWS RDS.

Note: Make sure you create the rds instance in the same VPC as your ECS so they can communicate using a private IP. Your RDs also need to allow inbound communication from ECS so attach a security group that allows inbound on the db port(port 3306 for mysql).

Create an RDS instance.

Choose MYSQL database

Template — You can choose the appropriate db instance for your use case — I chose a free-tier Instance.
DB instance name — WordPress
DB super user — admin
For the superuser password, select the box with Manage master credentials in AWS Secret manager

Choose the EC2 instance class you want to use for your database. I chose db.t3.micro as it costs less but you can choose any other class as per your requirement.
Choose the storage type and allocated storage capacity. If you want higher performance, use the SSD disk with a higher size as disk throughput is directly proportional to the disk size. Also, it will cost you more, so find a balance between the performance and cost
Disable the public access as you should never allow public access to your databases.

Choose the existing security group or create a new one. The existing security group must allow inbound connection on the database port from VPC CIDR( as your ECS container will need to talk to it).
Choose the password authentication. You can also enable the IAM or Kerberos authentication as well.
Also, expand the section with additional configuration and give a name for a database you want to be created by default. If you do not provide this information, RDS will not create a database.

RDS details

Once your RDS instance gets created, you can find its details in the connectivity and configuration tabs.

For the DB master password

Go to AWS Secret Manager and you will see a secret, retrieve the secret value and this will be your DB password. We will use this while connecting the DB to the WordPress application.

6. Connecting database to WordPress application

Copy the user and password from the secret manager
the host will be the endpoint and the DB will be the database name

Run installation and you are done. Your application is ready. Now use the same DBS name to access the application. It will redirect you to the default WordPress home page.

If you found this blog post useful then clap, comment, and share.

Don’t forget to follow, and subscribe so you won’t miss any of that content.

About me

I am Akhilesh Mishra, a self-taught Devops engineer with 11+ years working on private and public cloud (GCP & AWS)technologies.

Writing is my way of learning new tools and technologies around Devops. It helps me explore various tools, and libraries and try new ways of doing things.

I also mentor DevOps aspirants in their journey to devops by providing guided learning and mentorship on Topmate.

Connect with me on Linkedin: https://www.linkedin.com/in/akhilesh-mishra-0ab886124/