2.1.4.3. Mutable vs. Immutable Deployment Patterns
2.1.4.3. Mutable vs. Immutable Deployment Patterns
Loading diagram...
The choice between mutable and immutable determines whether your production servers accumulate drift over time or stay identical to what you tested.
Mutable (in-place): Update existing instances by deploying new code, patching OS, or modifying configuration. Fast for small changes but creates configuration drift — after months of patches, hotfixes, and manual tweaks, production servers become unique snowflakes that are impossible to reproduce. CodeDeploy in-place deployments are mutable.
Immutable (replace): Never modify running instances. Instead, build a new AMI or container image with all changes baked in, launch new instances from it, and terminate the old ones. Every deployment produces identical instances. Blue/Green deployments are inherently immutable.
Immutable infrastructure on AWS:
- Code change → CodeBuild builds new Docker image or triggers EC2 Image Builder
- New image stored in ECR or registered as AMI
- CloudFormation/ASG launches new instances from new image
- Load balancer shifts traffic to new instances
- Old instances terminated
When to use each:
- Mutable: Quick config changes, emergency hotfixes, small teams with simple apps. Accept drift risk.
- Immutable: Production workloads, regulated environments, microservices at scale. Invest in build pipeline.
Exam Trap: Elastic Beanstalk supports both patterns. "Rolling" and "Rolling with additional batch" are mutable (update existing instances). "Immutable" and "Blue/Green" are immutable (launch new instances). The exam may ask you to choose based on constraints like "zero-downtime" (immutable) or "fastest deployment time" (mutable rolling).
