Try the new version before everyone uses it — CodeDeploy and ECS

Your goal

Plan a container release that shifts traffic to a tested replacement.

Why this matters

A shop wants to release a new app version with a clear way back. You will prepare a replacement task set, test it, and decide how traffic and data changes affect rollback.

Words you will use

Blue and green refer to current and replacement environments. A task set runs app copies. Traffic shifting moves requests between versions. Rollback returns to a working version.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Prepare both versions

The current ECS app serves customers. The new version needs somewhere to run before it receives normal production traffic.

What should the deployment prepare?

A replacement task set alongside the current version.

An ECS blue/green deployment prepares replacement tasks and uses the configured traffic routing. Ensure the service, load balancer, and deployment setup support the intended strategy and that capacity is available.

The new version can be evaluated before taking over traffic.

Current tasks + replacement tasks → staged release

2. Use evidence to shift traffic

Replacement tasks have started, but the team has not checked whether checkout works. A running process alone is weak release evidence.

What should guide the shift?

Health checks, meaningful tests, and monitored release criteria.

Check the behavior visitors depend on, then shift traffic using the chosen deployment configuration. Monitor errors and other meaningful signals during the change. A healthy process can still contain a broken feature.

Traffic moves based on relevant checks and monitoring.

Replacement checks → traffic shift → watch release signals

3. Keep rollback realistic

The new version changes stored data in a way the old version cannot read. Sending traffic back might not restore a working app.

What should be planned?

Compatible data changes and a tested rollback or recovery path.

Traffic rollback does not automatically reverse schema or data changes. Plan compatibility between versions and test recovery for stateful changes. Keep a clear decision point for stopping or reversing the release.

The release plan accounts for both app traffic and persistent data.

Compatible data change + tested recovery → safer rollback

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.