In-place and blue/green deployments
1. In-place and blue/green deployments
Welcome back! Last video you wrote an appspec.yml; now let's use it to release safely. This video is all about choosing how your new version actually reaches production. Let's get started.2. The 2 AM outage
A team pushes an all-at-once update to their checkout fleet at 2 AM. The new version has a regression. Within seconds, every server runs broken code, and every customer hits errors. Rolling back means another full deploy. By the time it finishes, customers have been seeing errors for nearly an hour. The fix? Don't update every instance at once. You'll learn in-place deployments that update in batches, blue/green deployments that swap fleets safely, and the trade-offs that decide which one you reach for.3. Why deployment strategy matters
A bad release can take your service down for every customer at once. The all-at-once approach is the fastest but the riskiest; if the new version is broken, every user feels it. Gradual rollouts are slower but safer because only some users are exposed before you confirm the deployment is healthy. Picking the right strategy is really about controlling blast radius. CodeDeploy supports two main shapes: in-place and blue/green.4. In-place deployments
In-place deployments update the same instances that already serve traffic. CodeDeploy stops the app on a batch, swaps the files, starts the app, and waits for the health check to pass before moving to the next batch. You can configure batch size with deployment configurations like CodeDeployDefault.HalfAtATime or OneAtATime. The advantage is cost: you reuse your existing fleet. The trade-off is risk; some instances are running the new version while others are still on the old.5. Blue/green deployments
Blue/green flips the model. Your blue fleet keeps serving production on the old version while you stand up a fresh green fleet running the new one. CodeDeploy uses a load balancer to shift traffic from blue to green once green is ready. The old fleet doesn't get updated; it stays around briefly so you can roll back instantly by re-pointing the load balancer. After a wait period, the blue fleet is terminated, or kept running, depending on your deployment-group setting.6. Lambda and ECS are blue/green by design
On Lambda and ECS, blue/green is built into the platform. For Lambda, CodeDeploy shifts a function alias from the old version to the new one, no infrastructure to duplicate. For ECS, CodeDeploy creates a replacement task set in the same ECS service, then shifts the load balancer's target group to it. You don't manage two fleets manually. You still choose a deployment configuration that controls how fast traffic shifts: all at once, in steps, or with canary slices.7. Choosing in-place vs. blue/green
Use in-place when you're patching a stable app and budget is tight. Use blue/green when you need zero downtime or instant rollback. Take that checkout-api fleet: 6 EC2 instances behind a load balancer, customers hitting it 24/7. A deploy that drops traffic loses sales, so blue/green is the right call. With a single legacy server, blue/green isn't an option; you can't run two copies. On Lambda or ECS, blue/green is essentially free because the platform handles the duplication.8. Rollback in CodeDeploy
Rollback in CodeDeploy means redeploying the last successful revision. You can configure it to trigger automatically when the deployment itself fails, or when a CloudWatch alarm crosses a threshold during deployment. For in-place deployments, rollback is another full redeploy of the old code, so it takes time. For blue/green, rollback just flips the load balancer back to the old fleet, which happens in seconds. That speed is one of the strongest reasons to choose blue/green for critical workloads.9. Let's practice!
Time to match deployment strategies to the job. Time to practice!Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.