Deploying Dockerized Microservices to AWS ECS Fargate with CodePipeline

Introduction

In modern DevOps workflows, teams often break applications into smaller parts called microservices and run them in containers. Deploying these containers in a way that’s easy to manage, cost-effective, and can grow with demand is really important. That's where Amazon ECS Fargate and AWS CodePipeline come in, they let you run and update these services automatically without managing servers. AWS Fargate is a serverless compute engine for containers, and when combined with CodePipeline, you get fully automated CI/CD. In this article, I’ll explain how it all works and show you step-by-step how to deploy your container-based services using these tools.

Prerequisites

Before we begin, ensure you have:

• Basic knowledge of Docker and AWS
• AWS CLI configured
• A GitHub repository with a simple Dockerized microservices application.
• An existing VPC and subnets (or allow Fargate to create one)

Architecture Overview

GitHub → CodePipeline → CodeBuild → ECR → ECS Fargate

• GitHub: hosts the source code and Dockerfiles.
• CodePipeline: detects changes and triggers deployment.
• Build: CodeBuild (build Docker image and push to ECR)
• ECS Fargate: deploys containers using the latest image.

Implementation Steps

STEP 1: Dockerize your app - Your microservice should include a Dockerfile like this.

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]

STEP 2: Push Your Code to GitHub - Push your microservice to a GitHub repo if you haven’t done so at this stage. This will be the source for your CodePipeline.

STEP 3: Create an Amazon ECR Repository - Before deploying your Dockerized microservice to ECS Fargate, you need a place to store your container images. Amazon Elastic Container Registry (ECR) is AWS's fully managed Docker container registry, and it's where you'll push your built images for ECS to pull from. You can do this manually using the AWS Management Console, Using the AWS CLI or via IaC (Terraform) during infrastructure provisioning.

STEP 4: Define Buildspec for CodeBuild - The buildspec.yml file is a configuration file that tells AWS CodeBuild exactly what to do when it runs. It defines:

• Commands to run during each phase of the build process
• How to build your Docker image
• Where to push it (ECR, in our case)
• What (if anything) to output as artifacts AWS CodeBuild reads this file at runtime to carry out your instructions step by step.

version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password | docker login --username AWS --password-stdin <your-ecr-uri>
  build:
    commands:
      - echo Building Docker image...
      - docker build -t my-service .
      - docker tag my-service:latest <your-ecr-uri>:latest
  post_build:
    commands:
      - echo Pushing image to ECR...
      - docker push <your-ecr-uri>:latest

artifacts:
  files: []

Replace with your actual ECR repo URI.

STEP 5: Create an ECS Fargate Cluster - To run your containerized microservices on AWS, you need an ECS (Elastic Container Service) cluster. When using Fargate, AWS handles the underlying server infrastructure, allowing you to focus only on your container and application code.

• Go to ECS → Task Definitions → Create
• Use Fargate launch type
• Add container with image: :latest
• Set port mappings (e.g., 3000)
• Set memory/CPU (e.g., 512MB/256 CPU)

STEP 6: Create CodePipeline - AWS CodePipeline is a fully managed CI/CD (Continuous Integration and Delivery) service. It automates building, testing, and deploying code every time you make a change.

• Go to CodePipeline → Create Pipeline
• Source: GitHub, Choose Connect to GitHub, and follow the instructions to authenticate with GitHub.
• Build: Add build stage page, for Build provider, choose CodeBuild. (create a project using the buildspec.yml in step 4)
• Deploy: ECS → Fargate → Select your cluster and service created in steps 5

CONCLUSION

ECS Fargate + CodePipeline offers a modern, scalable foundation for deploying containerized microservices. Whether you're starting from scratch or modernizing legacy apps, this setup provides a future-proof, low-maintenance path to continuous delivery in the cloud. This approach is particularly well-suited for microservice architectures, where deploying and updating individual services frequently and independently is a key requirement. With the setup described in this article, each microservice can be connected to its own pipeline, reducing deployment risk and making rollback strategies easier to implement.