M. Ibtsam

Posted on Jan 2

From Zero to ECS: My Journey of Deploying a Micro-service with AWS CodePipeline, CodeBuild & ECS

#devops #automation #aws #microservices

“Some projects don’t start with confidence. Some start with chaos… and slowly teach you who you really are.”

Yesterday, I built a fully automated CI/CD pipeline on AWS, a project that initially seemed simple but turned into a challenging endeavor filled with valuable lessons, broken builds, IAM nightmares, and ultimately, the sweetest green deployment. This wasn’t just about deploying a template website. This was about building a micro-service pipeline, learning to trust automation, and fighting with AWS until it finally smiled back.
Let me take you through the journey

The Beginning: A Dockerfile, a Template, and a Dream

It all started with a simple static website template from Templatemo. Beautiful. Minimal. Lightweight.
I wrote a small Dockerfile on top of Ubuntu + Apache:

FROM ubuntu:latest

# Install Apache and tools
RUN apt-get update && \
    apt-get install -y apache2 apache2-utils wget unzip && \
    apt-get clean

# Set working directory
WORKDIR /var/www/html

# Download the template and name the downloaded file
RUN wget https://templatemo.com/download/templatemo_597_neural_glass -O template.zip

# Extract and copy files
RUN unzip template.zip && \
    cp -rvf templatemo_597_neural_glass/* . && \
    rm -rvf template.zip templatemo_597_neural_glass

EXPOSE 80

CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]

One container.
One decision.
One microservice.
This service would not live inside a monolith. It would be independent, deployable on its own, and scalable on its own. And AWS would handle the rest.

Building the Pipeline That Would Change Everything

AWS CodeCommit became my Git server — a quiet place where everything begins.

Each commit in my Dockerfile triggered a pipeline.

Step 1 — CodePipeline picks up the commit
Step 2 — CodeBuild builds the image
Step 3 — Pushes to ECR
Step 4 — Updates ECS test cluster
Step 5 — Manual approval
Step 6 — Production deployment behind an ALB
The heart of the build was my buildspec.yml:

version: 0.2
phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws --version
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - REPOSITORY_URI=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME

  build:
    commands:
      - echo Build started on $(date)
      - echo Building the Docker image...
      - docker build -t "$REPOSITORY_URI:$IMAGE_TAG" .

  post_build:
    commands:
      - echo Build completed on $(date)
      - echo Pushing the Docker image...
      - docker push "$REPOSITORY_URI:$IMAGE_TAG"
      - echo Writing image definitions file...
      - printf '[{"name":"%s","imageUri":"%s"}]' "$CONTAINER_NAME" "$REPOSITORY_URI:$IMAGE_TAG" > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

The moment I saw my first image appear in ECR, I knew I was getting somewhere.

The War With IAM Roles, Policies, & Security Groups

Let me be honest.
This was not a project.
This was a battlefield.
The biggest enemy?

IAM Roles
Security Groups
Trust Policies
Missing Permissions
SNS Publish Denied Errors

At one point, CodePipeline screamed:
“sns:Publish is not allowed for this role.”
And I just sat there… staring at it like:
“AWS, yaar, ki problem hai teri?”
I fixed it by adding its policy.

Creating Test & Production Clusters

I separated environments:
Test Cluster (Dev environment)

Every commit goes here first
Behind an ALB
Quick validation
No manual approvals

Production Cluster

Behind an ALB
Scalable
Auto-recovery
Requires manual approval through SNS

This is where the pipeline became… real.

The Sweetness of Manual Approval

Before deploying to production, CodePipeline sends me:
An SNS Email

The email asks:
“Do you approve this deployment?”

This made the deployment feel like signing off on a release in a real company.

Once I click “Approve”, the production ECS service pulls the new image and updates behind ALB without downtime.

Why This Project Mattered More Than I Expected

This project wasn’t just CI/CD.
It taught me:

Microservices give freedom One service, one task definition, one pipeline, independent scaling.
Cloud architecture humbles you Security groups and IAM remind you that the cloud is powerful, but not forgiving.
Automation is addictive One commit → full deployment Zero manual server management.
CI/CD is not a luxury - it’s a survival Modern development = pipelines + containers.

The Final Deployment, The Moment I Trusted the Cloud

When the ALB finally showed my website live and healthy…
It felt magical.

I didn’t open any EC2 machine.
I didn’t configure any OS manually.
I didn’t copy-paste files.

Just:

Write code
Commit
Approve
Deploy

That’s the real confidence CI/CD gives you.

If You’re Moving to Cloud, Move With Courage

If you’re shifting from monolithic apps to microservices…
If you want to understand real AWS DevOps…
If you want to feel the thrill of automation…
Then build a pipeline like this.

Break it.
Fix it.
Fear it.
Love it.

Because every green checkmark on AWS teaches you something about yourself.
And that’s why this project matters.

DEV Community