marcio.cloud
All projects

CI/CD

CodePipeline → S3 Static Site Deploy

A CI/CD pipeline that builds and deploys a static web app to S3 + CloudFront on every push to main. Demonstrates the AWS-native delivery toolchain: CodeCommit/GitHub, CodeBuild, CodePipeline, S3.

AWS CodePipelineCodeBuildS3CloudFrontIAMbuildspec.ymlGitHub
Architecture diagram for CodePipeline → S3 Static Site Deploy
Architecture diagram — created in Lucidchart.

Problem

Manual `aws s3 sync` deploys are fast to set up and the first thing that breaks the moment a teammate joins. I wanted a properly gated pipeline: source on GitHub, automated build, deploy to S3, with permissions scoped exactly to the resources involved.

Solution

Built an AWS-native pipeline. CodePipeline detects pushes to GitHub, CodeBuild runs the build defined in `buildspec.yml`, and the pipeline deploys the artefact to an S3 bucket fronted by CloudFront. Pipeline service roles are least-privilege — the deploy stage can `s3:PutObject` only to one bucket prefix.

Architecture

  • CodePipeline source stage: GitHub webhook triggers on `main`.
  • Build stage: CodeBuild image runs `npm install` + `npm run build`.
  • Deploy stage: artefact uploaded to S3, CloudFront invalidation issued.
  • All IAM roles scoped to the exact resource ARNs and actions needed.

Outcomes

  • Push-to-deploy time under 90 seconds end-to-end.
  • No more `s3 sync` from laptops — deploy is reproducible and audited via CloudTrail.
  • Single-tenant IAM roles meant a compromised build job couldn't touch any unrelated bucket.

What I'd do differently

AWS-native CI/CD is verbose but excellent for compliance-heavy environments — every action lands in CloudTrail. For pure speed on a small team, GitHub Actions is usually faster to iterate on. Knowing both is the right answer.