DEV Community: Mayank Thakur

GlobalMart — CI/CD Pipeline on AWS

Mayank Thakur — Sun, 23 Aug 2026 17:01:00 +0000

Zero-touch deployment of a React e-commerce app from GitHub to EC2 using AWS CodePipeline and CodeDeploy.

Push to main, walk away. The pipeline builds the app, versions the artifact in S3, and rolls it
out to EC2 with health checks and automatic rollback — no SSH, no manual scp, no downtime window.

Why this project exists

Manually deploying a build to a server is fine once. It stops being fine the tenth time: someone
copies the wrong folder, forgets to restart the web server, or deploys from a dirty local branch,
and nobody can say which commit is live.

This project replaces that with a pipeline where the commit SHA is the single source of truth for
what is running in production. The goal was not "get a React app onto EC2" — it was to build the
release path properly: versioned artifacts, an agent-driven deploy with lifecycle hooks, health
verification before traffic is served, and rollback on failure.

flowchart LR
    DEV[Developer] -->|git push main| GH[GitHub repository]
    GH -->|CodeStar Connection webhook| CP[AWS CodePipeline]

    subgraph CP_STAGES [Pipeline]
      direction TB
      SRC[Source stage] --> BUILD[Build stage<br/>CodeBuild + Node.js]
      BUILD --> DEPLOY[Deploy stage<br/>CodeDeploy]
    end

    CP --> SRC
    BUILD -->|versioned artifact| S3[(S3 artifact bucket)]
    S3 --> DEPLOY
    DEPLOY -->|pull + lifecycle hooks| AGENT[CodeDeploy agent on EC2]
    AGENT --> NGINX[Nginx serving /var/www/globalmart]
    NGINX --> USER[End user]

    AGENT -.->|deploy + app logs| CW[CloudWatch Logs]
    CP -.->|state change events| SNS[SNS notification]

    IAM[IAM roles:<br/>pipeline, build, deploy, instance profile] -.-> CP_STAGES

Trust boundaries worth noting: the pipeline role can read the artifact bucket and start
deployments; the EC2 instance profile can only read that one bucket. The instance never
holds credentials that can modify the pipeline. Compromising the web server does not give an
attacker the ability to ship code.

Pipeline stages

Stage	Provider	What happens	Failure behaviour
Source	GitHub via CodeStar Connections	Webhook fires on push to `main`, source zipped to S3	Pipeline stops, no artifact produced
Build	AWS CodeBuild (`buildspec.yml`)	`npm ci` then `npm run build`, output packaged with deploy scripts	Pipeline stops before anything reaches the server
Deploy	AWS CodeDeploy (`appspec.yml`)	Agent pulls artifact, runs lifecycle hooks, swaps web root	Automatic rollback to last successful revision

CodeDeploy runs OneAtATime against the deployment group, with the deployment marked failed if
ValidateService cannot get a 200 from the app — so a broken build never stays live.

Deployment lifecycle hooks

ApplicationStop     → scripts/stop_server.sh      stop nginx gracefully
BeforeInstall       → scripts/before_install.sh   install deps, clear old web root
Install             → (CodeDeploy copies files)   artifact → /var/www/globalmart
AfterInstall        → scripts/after_install.sh    set ownership + permissions
ApplicationStart    → scripts/start_server.sh     start and enable nginx
ValidateService     → scripts/validate_service.sh curl health check, fail non-200

Repository layout

Globalmart-cicd-pipeline/
├── appspec.yml              # CodeDeploy instructions — MUST be at repo root
├── buildspec.yml            # CodeBuild build steps
├── scripts/
│   ├── before_install.sh
│   ├── after_install.sh
│   ├── start_server.sh
│   ├── stop_server.sh
│   └── validate_service.sh
├── src/                     # React application source
├── public/
├── screenshots/             # pipeline runs, deploy events, live app
└── README.md

Configuration

`buildspec.yml`

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 20
  pre_build:
    commands:
      - npm ci
  build:
    commands:
      - npm run build
  post_build:
    commands:
      - echo "Build completed for commit $CODEBUILD_RESOLVED_SOURCE_VERSION"

artifacts:
  files:
    - build/**/*
    - appspec.yml
    - scripts/**/*

appspec.yml and scripts/ must be listed in artifacts — if they are not in the bundle,
CodeDeploy has nothing to execute and fails immediately.

`appspec.yml`

version: 0.0
os: linux

files:
  - source: /build
    destination: /var/www/globalmart

hooks:
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 60
      runas: root
  BeforeInstall:
    - location: scripts/before_install.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 120
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 120
      runas: root
  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 120
      runas: root

`scripts/validate_service.sh`

The hook that makes this a real pipeline rather than a file copy:

#!/bin/bash
set -e

for i in {1..10}; do
  code=$(curl -s -o /dev/null -w "%{http_code}" http://localhost/ || true)
  if [ "$code" = "200" ]; then
    echo "Health check passed on attempt $i"
    exit 0
  fi
  echo "Attempt $i returned $code, retrying..."
  sleep 3
done

echo "Health check failed — triggering rollback"
exit 1

IAM roles used

Four distinct roles, each scoped to one job. This is the part most tutorials collapse into one
over-permissioned role.

Role	Attached to	Permissions
`CodePipelineServiceRole`	CodePipeline	Read/write artifact bucket, start CodeBuild, create CodeDeploy deployments, use the CodeStar connection
`CodeBuildServiceRole`	CodeBuild project	Write artifacts to S3, write CloudWatch Logs
`CodeDeployServiceRole`	CodeDeploy application	`AWSCodeDeployRole` — describe and tag EC2 instances
`EC2InstanceProfile`	EC2 instance	`s3:GetObject` on the artifact bucket only, plus CloudWatch agent permissions

The instance profile is intentionally read-only and single-bucket. No s3:*, no wildcard resource.

Setup: reproduce this pipeline

1. Prepare the EC2 instance

# Amazon Linux 2023, t3.micro, security group: 22 (your IP only) + 80 (0.0.0.0/0)
sudo dnf update -y
sudo dnf install -y nginx ruby wget
sudo systemctl enable --now nginx

# CodeDeploy agent (region-specific bucket)
cd /home/ec2-user
wget https://aws-codedeploy-ap-south-1.s3.ap-south-1.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo systemctl status codedeploy-agent    # must be active

Tag the instance Name=globalmart-prod — CodeDeploy targets the deployment group by tag.

2. Create the AWS resources

S3 bucket for artifacts, versioning enabled, all public access blocked
CodeDeploy application (EC2/On-premises) + deployment group targeting the instance tag
CodeBuild project pointing at buildspec.yml
CodePipeline: Source (GitHub via CodeStar Connection) → Build → Deploy
Attach the instance profile to the EC2 instance

3. Verify

git commit --allow-empty -m "test: trigger pipeline"
git push origin main

Then confirm, in order:

CodePipeline shows Source succeeded within ~30 seconds
CodeBuild logs show npm run build completing
CodeDeploy shows all five lifecycle events green
curl http://<EC2-public-IP> returns the app
On the instance: tail -f /var/log/aws/codedeploy-agent/codedeploy-agent.log

Troubleshooting: what actually broke

Real failures hit while building this, and the fixes. Kept here because these are the things
tutorials skip.

ApplicationStop failed on the very first deployment
The hook script from the previous revision runs during ApplicationStop, and on deployment #1
there is no previous revision. Fix: use "Ignore ApplicationStop lifecycle event failures" on the
first run, or make the script idempotent with systemctl stop nginx || true.

InstallError: The deployment failed because a specified file already exists
CodeDeploy will not overwrite files it did not place there. Fix: rm -rf /var/www/globalmart/*
in before_install.sh, or set the file overwrite behaviour on the deployment group.

ScriptFailed with exit code 126
Shell scripts committed without the execute bit. Fix: git update-index --chmod=+x scripts/*.sh,
or chmod +x inside before_install.sh before the hooks run.

npm run build killed on a t2.micro
1 GB of RAM is not enough for a Vite/CRA production build; the OOM killer takes the process and
the log just says "Killed." Fix: build in CodeBuild rather than on the instance (which is what
this pipeline does), or add swap on the instance if you must build there.

Deployment stuck at Pending, then timed out
The CodeDeploy agent could not reach the service. Causes seen: agent not running, no instance
profile attached, or a private subnet with no NAT and no VPC endpoint. Fix: systemctl status codedeploy-agent, confirm the instance profile, check egress.

AccessDenied pulling the artifact from S3
The instance profile lacked s3:GetObject on the artifact bucket, and separately the bucket was
in a different region than the deployment. Fix: scope the policy to that bucket ARN and keep
bucket, pipeline, and instance in one region.

Monitoring and observability

CloudWatch Logs: CodeBuild build logs, plus the CodeDeploy agent log shipped from the instance
CloudWatch Alarm on EC2 StatusCheckFailed and high CPU
SNS topic subscribed to CodePipeline state-change events, so a failed deploy emails immediately
Nginx access and error logs streamed via the CloudWatch agent

Cost and teardown

Running cost on free tier is effectively zero; outside it, roughly a few dollars a month —
t3.micro on-demand, S3 storage in the low cents, CodePipeline at one dollar per active pipeline
per month, CodeBuild billed per build minute.

Teardown, in this order, to avoid orphaned charges:

# 1. delete the pipeline   2. delete the CodeBuild project
# 3. delete the CodeDeploy app + deployment group
# 4. empty and delete the artifact bucket (versioned — delete all versions)
# 5. terminate EC2   6. release any Elastic IP   7. delete the IAM roles

An unreleased Elastic IP on a terminated instance is the classic surprise bill.

Production hardening — what I would add next

Honest list of what this pipeline does not do yet:

Terraform for the whole stack, so the pipeline itself is version-controlled and not click-configured
Blue/green deployment behind an ALB and Auto Scaling group, replacing in-place deploys and eliminating the brief serve gap
Test and security gates in the build stage: unit tests, npm audit, and SAST as blocking steps
Manual approval action before production, with a staging deployment group ahead of it
S3 + CloudFront for the static React build instead of EC2 — cheaper, faster, and no server to patch
Secrets via Parameter Store / Secrets Manager injected at build time rather than baked into the artifact
Container path: Docker image to ECR, deployed to ECS Fargate, for reproducible runtime environments

What this project demonstrates

End-to-end CI/CD design: source, build, artifact versioning, deploy, verify, roll back
CodeDeploy lifecycle hooks and health-gated releases, not just automated file copying
Least-privilege IAM across four separate service roles
Linux service administration and web server configuration on EC2
Debugging distributed deploy failures from agent logs
Cost awareness and clean resource teardown

Pipeline executions, CodeDeploy lifecycle events, EC2 status, and the running application

Author

Mayank Thakur — Cloud, DevOps and SRE
GitHub · LinkedIn · mayankthakur9181@gmail.com

3 Tier Application On EKS

Mayank Thakur — Sat, 22 Aug 2026 16:45:45 +0000

I built a 3-tier application running on Amazon EKS, deployed by a GitHub Actions pipeline that runs on every merge to main. The first version of that pipeline had two secrets sitting in the repo settings: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

Github- https://github.com/itzmayank01/3-tier-user-platform-devops

They worked. They were also a bad idea, and getting rid of them taught me more about EKS authentication than anything else in the project.

This post is the setup I ended up with. It includes the part that broke for me and that most tutorials skip: getting past IAM is only half the job, because EKS has its own authorization layer on top.

Why long-lived keys are a problem

An IAM access key does not expire. If it leaks, it stays valid until someone notices and revokes it. In a CI pipeline that risk is real:

The key lives in repository settings, and anyone with admin access to the repo can see who added it
A malicious or careless workflow change can print it, exfiltrate it, or use it for something unrelated
Rotating it means updating every repo that uses it, so in practice nobody rotates it
A fork or a compromised third-party action widens the blast radius

OIDC replaces that with a token that lives for the length of a single job.

How OIDC actually works here

Four steps, and it helps to hold the whole picture in your head before you start:

GitHub Actions mints a short-lived JSON Web Token describing the job: which repo, which branch, which workflow
Your workflow sends that token to AWS STS
AWS checks the token signature against a registered identity provider, then checks the claims inside it against your IAM role's trust policy
If both pass, STS hands back temporary credentials that expire when the job ends

No secret is stored anywhere. The trust is in the claims, not in a shared string.

Step 1: Register GitHub as an identity provider in IAM

You only do this once per AWS account.

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com

If you have used GitHub OIDC before, you may remember passing a certificate thumbprint. AWS no longer requires you to manage that for this provider - it verifies and rotates the certificate itself. If your tooling still demands a value, older guides use 6938fd4d98bab03faadb97b34396831e3780aea1.

Check that it landed:

aws iam list-open-id-connect-providers

Step 2: Create the IAM role and its trust policy

This is where most of the security lives. The trust policy decides which GitHub jobs are allowed to assume this role.

trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

aws iam create-role \
  --role-name GitHubActionsEKSDeployRole \
  --assume-role-policy-document file://trust-policy.json

Read the sub condition twice. It is the only thing standing between "my main branch can deploy" and "anyone who opens a pull request against my repo can deploy". Some patterns and what they mean:

Pattern	Who can assume the role
`repo:my-org/my-repo:ref:refs/heads/main`	Only jobs running on the main branch
`repo:my-org/my-repo:environment:production`	Only jobs targeting the `production` environment
`repo:my-org/my-repo:pull_request`	Any pull request, including from forks
`repo:my-org/*`	Every repo in the org
`repo:*`	Anyone on GitHub. Never do this.

I use the environment form for production, because GitHub environments let me add a required reviewer on top. IAM enforces which jobs can assume the role; GitHub enforces who can trigger those jobs.

Then attach permissions. The deploy role needs very little - enough to look up the cluster endpoint:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "eks:DescribeCluster",
      "Resource": "arn:aws:eks:ap-south-1:111122223333:cluster/my-cluster"
    }
  ]
}

If the same job also pushes images, add the ECR actions it needs (ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, ecr:PutImage, ecr:InitiateLayerUpload, ecr:UploadLayerPart, ecr:CompleteLayerUpload). I prefer two separate roles - one for build and push, one for deploy - so a compromised build step cannot touch the cluster.

Step 3: The workflow

name: Deploy to EKS

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/GitHubActionsEKSDeployRole
          role-session-name: gha-deploy-${{ github.run_id }}
          aws-region: ap-south-1

      - name: Update kubeconfig
        run: aws eks update-kubeconfig --name my-cluster --region ap-south-1

      - name: Deploy
        run: |
          kubectl set image deployment/frontend \
            frontend=111122223333.dkr.ecr.ap-south-1.amazonaws.com/frontend:${{ github.sha }}
          kubectl rollout status deployment/frontend --timeout=120s

Two things to notice.

permissions: id-token: write is not optional. Without it, GitHub never mints the token and the credentials step fails with something like Could not assume role with OIDC. This is the single most common failure, and the error message does not point at the missing permission. Also note that declaring a permissions block resets all permissions to none, so you have to list contents: read explicitly if your job checks out code.

Tag images by commit SHA, not latest. ${{ github.sha }} makes every deploy traceable to a commit, and rolling back is just pointing at the previous SHA.

Step 4: The part tutorials skip

At this point my pipeline authenticated to AWS perfectly and then died on the kubectl step:

error: You must be logged in to the server (Unauthorized)

The credentials were fine. The problem is that EKS has two separate layers. IAM decides whether you can talk to the cluster's API endpoint. Kubernetes RBAC decides what you can do once you are there. A brand new IAM role has an AWS identity and no Kubernetes identity at all.

You have to explicitly map the role into the cluster.

The modern way: EKS access entries

Access entries are an EKS API, so you manage cluster access with the same tooling as everything else. First check what your cluster is using:

aws eks describe-cluster --name my-cluster --query 'cluster.accessConfig'

If authenticationMode is CONFIG_MAP, switch it:

aws eks update-cluster-config \
  --name my-cluster \
  --access-config authenticationMode=API_AND_CONFIG_MAP

Then create the entry and give it a scope:

aws eks create-access-entry \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::111122223333:role/GitHubActionsEKSDeployRole \
  --type STANDARD

aws eks associate-access-policy \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::111122223333:role/GitHubActionsEKSDeployRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope type=namespace,namespaces=production

AmazonEKSEditPolicy scoped to one namespace is usually right for a deploy role. It can update workloads and nothing else. Resist reaching for AmazonEKSClusterAdminPolicy - it is the AdministratorAccess of EKS.

One direction-of-travel note: you can move CONFIG_MAP to API_AND_CONFIG_MAP to API, but you cannot go back. Migrate deliberately.

The older way: the aws-auth ConfigMap

If you are on an older cluster still using CONFIG_MAP mode, you edit aws-auth in kube-system:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/GitHubActionsEKSDeployRole
      username: github-actions
      groups:
        - deployers

Then bind deployers to a Role or ClusterRole with normal Kubernetes RBAC. Two warnings if you go this route: a bad edit here can lock everyone out of the cluster, including you, and if your IAM role has a path (/ci/GitHubActionsEKSDeployRole), you must strip the path out of the ARN before EKS will match it.

Gotchas worth knowing before you start

Could not assume role with OIDC - the missing id-token: write permission, nine times out of ten
Not authorized to perform sts:AssumeRoleWithWebIdentity - your sub claim does not match. Print github.ref and github.workflow_ref in a debug step and compare them character by character with the trust policy
You must be logged in to the server (Unauthorized) - IAM is fine, the cluster mapping is missing. This is Step 4
kubectl hangs, then times out - your cluster API endpoint is private and a hosted runner cannot reach it. You need a self-hosted runner inside the VPC, or a VPC-connected alternative
The role works from your laptop but not from CI - you are probably testing with a user that has broader permissions than the role. Assume the role locally with aws sts assume-role and retest

What you actually get

After the migration my repo has zero AWS secrets. The credentials a job holds are valid for that job only, scoped to one namespace, on one branch. If someone gets a malicious workflow merged, the worst case is bounded by an IAM policy and a Kubernetes RBAC binding instead of by whatever those static keys happened to be allowed to do.

That is a much better position to defend, and it took an afternoon.

Next in this series: cutting that same pipeline from five minutes to two and a half with self-hosted runners and parallel stages.