Managing environments and approved versions

1. Managing environments and approved versions

Welcome back! In this video, you'll learn approved-version mechanisms across services, promote a Lambda version from staging to prod, and keep configuration separate from the artifact. Let's get started.

2. Same code, three environments

You've tested a Lambda version in staging. Now you need it in prod, but you don't want to rebuild. The right move: promote the same version by updating the prod alias to point at it. One API call, no code change, the same bits run everywhere.

3. Approved versions, per service

Every AWS service that runs your code has its own way to mark "this version is approved for this environment." Lambda uses aliases that point to numbered function versions. ECR stores immutable container images with tags, and ECS task definitions reference specific image tags by revision. API Gateway uses stages, each pointing to a deployment of the API. S3 keeps object versions when versioning is enabled; it's similar in spirit, so we won't dive into it here. The mechanisms differ, but the goal is the same: a stable pointer to the version each environment runs.

4. How Lambda aliases work

Lambda aliases are the cleanest example. A version is a frozen snapshot of your function that you never change once it is published. An alias like prod is just a named pointer to one of those versions. Say AWS just published version 7 while prod still points at version 5; to promote, you move the prod pointer to version 7, with no code change. Aliases also support weighted routing, splitting invocations between two versions; that's the mechanism behind the Lambda canary deployments you saw in Chapter 2.

5. ECR tags and ECS task definitions

For containers, ECR stores immutable images, each identified by a content digest that always refers to the exact same bits. A tag, by contrast, is a movable label that can be repointed to a different image later. ECS task definitions reference either an image:tag or an image@digest, so revision 12 might use my-app:staging, and revision 13 uses my-app@sha256.... In production you typically pin by digest rather than tag, because tags can be moved out from under you. Pinning the digest guarantees the same bits run in every environment.

6. API Gateway stages, briefly

You met API Gateway stages in Chapter 2. To recap: a stage is a deployment of your API at a point in time, dev, staging, and prod each get their own URL and their own deployment history. Promotion means deploying the API to the next stage rather than rebuilding endpoints. Stage variables hold per-environment runtime values, like which Lambda alias to call, so the same API points to different downstream resources per stage.

7. Promoting a version

The promotion pattern is the same across services. You build the artifact once in CI, prove it in dev, then point staging at that same artifact and prove it again before moving the prod alias or tag to it. Because you never rebuild between environments, what you tested is exactly what runs in production. The promotion itself is a single API call, fast to execute and just as fast to reverse.

8. Keeping configuration separate

The companion principle is configuration separation. Your code, the artifact, never changes per environment. Configuration carries the differences: which DynamoDB table, which Lambda alias to call, which third-party endpoint. Stage variables and Lambda environment variables work for short, non-sensitive values. Parameter Store holds longer hierarchical configuration, and Secrets Manager handles credentials. Hardcoding environment values in the artifact breaks the build-once-deploy-many promise and forces a rebuild on every change.

9. Let's practice!

Now let's promote a version across environments. Let's practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.