Managing environments and approved versions

Automating Deployments on AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Same code, three environments

• Promote a Lambda version from staging to prod
• Same artifact, no rebuild
• One API call updates the prod alias; the code never changes
• That's "build once, deploy many"

Approved versions, per service

• Lambda: aliases point to function versions
• ECR + ECS: image tags + task-definition revisions
• API Gateway: stages with deployments
• S3: object versions in versioning-enabled buckets

How Lambda aliases work

• A version is an immutable snapshot of the function
• An alias is a named pointer to a version
• Update the alias to promote a version
• Aliases support weighted routing for canary releases

ECR tags and ECS task definitions

• ECR images are immutable per digest
• A tag is a moveable label on a digest
• ECS task definitions reference an image:tag or @digest
• For production, pin by digest to lock the exact bits

API Gateway stages, briefly

• A stage is a deployment of the API
• Each stage has its own URL and deployment history
• Promote by deploying the API to the next stage
• Stage variables hold per-environment runtime values

Promoting a version

• Build the artifact once
• Validate it in dev, then staging
• Update the prod alias or tag, no rebuild
• The same artifact runs in every environment

Keeping configuration separate

• Code stays the same across environments
• Configuration holds the dev-vs-prod differences
• Stage variables, env vars, Parameter Store, Secrets Manager
• Never hardcode environment values in the artifact

Let's practice!

Automating Deployments on AWS