CI/CD & Deployment Pipelines on AWS

The plain-language idea

A CI/CD pipeline (commonly GitHub Actions, for a team not running AWS's own CodePipeline) needs two things to actually deploy to AWS: a way to authenticate as something with the right permissions, and a target-specific deploy step that differs by what's being deployed.

Authentication first, because it's the part people get wrong: a pipeline should never hold a long-lived AWS access key as a stored secret. The current standard is OIDC federation — GitHub Actions requests a short-lived, temporary credential by proving its identity (which repo, which branch) directly to AWS, and IAM trusts that proof instead of a static key. This is the same "temporary role over long-lived credential" instinct from this track's IAM lesson, applied specifically to CI.

See it in a real thing: three deploy targets, three deploy steps

• Static frontend (S3 + CloudFront): aws s3 sync ./dist s3://my-bucket --delete, then aws cloudfront create-invalidation for the non-hashed entry file — exactly the two-tier caching strategy from this track's CloudFront lesson, now as the actual deploy command.
• Container (ECS/Fargate): push a new image to ECR (AWS's container registry) tagged with the build's git SHA — the same build-once-promote-everywhere principle from the Docker track — then update the ECS service to point at that new image tag, which triggers a rolling deployment: new tasks start and pass their health check before old ones are stopped, so capacity never drops during the deploy.
• Lambda: aws lambda update-function-code, pointing at a new deployment package or container image — the fastest of the three, since there's no server to roll, just a function definition to swap.

What people usually miss

Watch out

• A long-lived IAM access key stored as a CI secret is a real, common security liability, not a convenience shortcut that's merely suboptimal. If that secret leaks (a misconfigured log, a compromised dependency in the build), whatever permissions it carries are compromised indefinitely until someone notices and rotates it — an OIDC-issued credential is scoped and expires automatically.
• s3 sync --delete removes files from the bucket that aren't in the local build output — necessary to actually clean up assets from old builds, but a real, destructive flag: syncing the wrong local directory, or one missing expected files, deletes production assets, not just adds new ones.
• A rolling ECS deployment can still ship a broken container, just more slowly and safely than an all-at-once replacement — a rolling strategy limits blast radius and downtime, it doesn't validate that the new version is actually correct. That's what the health check itself has to catch.
• Deploying a new Lambda function version doesn't mean traffic switches instantly, if the function uses aliases and weighted traffic shifting — a real, deliberate pattern for gradually moving traffic to a new version (5%, then 50%, then 100%) instead of an instant cutover, specifically to limit exposure if the new version has a problem.

Why this matters in interviews

"How does your CI pipeline actually authenticate to deploy to AWS?" is a real, specific security-and-practice question — "we use OIDC federation, not a stored access key" is a concrete, current-best-practice answer that signals real production experience, versus not having a specific answer at all.