Immutable Infrastructure

Immutable infrastructure treats deployed compute resources as replaceable instances of a controlled definition. Instead of logging into production servers to install patches or changing software inside running containers, engineers update the build definition, produce a new image, test it, and replace the affected resources. The objective is consistent, traceable deployments rather than a promise that running systems cannot change.

A typical cloud implementation combines version-controlled infrastructure definitions with automated image builds. A virtual machine image can include a patched operating system, approved packages, logging configuration, endpoint protection, and a management agent. A container image can include a minimal runtime, pinned dependencies, and an application configured to run without root privileges. Build pipelines should scan and test these artifacts, restrict who can publish them, and record their provenance. Secrets and long-lived credentials should not be embedded in either image type; workloads should obtain credentials and configuration through controlled runtime mechanisms.

For example, an EC2 fleet can use a launch template that references an approved AMI. To remediate a vulnerable library, build and validate a replacement AMI, create a new launch template version, and roll the fleet onto that version using an instance refresh. For containers, rebuild the image and update the deployment to a specific image digest. A mutable tag such as latest does not reliably identify the artifact that was tested. Health checks, capacity headroom, and connection draining help replacements occur without unnecessary service interruption.

Hardening belongs in the build process, but some controls must be applied at deployment or runtime. Installing the Systems Manager Agent in an AMI does not by itself make an instance manageable: the instance also needs suitable permissions, connectivity, and a supported agent configuration. Similarly, a hardened container image does not enforce the workload's network policy or runtime privileges. Least-privilege roles, restricted network access, monitoring, and runtime security controls remain necessary.

During a security incident, replacing a compromised resource is a recovery technique, not the entire response. First contain the affected workload using appropriate network controls and remove it from normal traffic. Coordinate with orchestration and automatic replacement processes so that evidence is not inadvertently destroyed. Preserve required disk snapshots, logs, and, where appropriate, volatile evidence before termination. Restrict access to forensic artifacts because they may contain sensitive information.

Recover by deploying a trusted image that addresses the entry point, rotating exposed credentials, and checking for persistence outside the replaced resource. Restore persistent data from a validated recovery point when necessary, and verify that the restored data does not reintroduce malicious content. An image captured from a compromised server is not a trustworthy recovery baseline. Replacing compute alone does not remove an attacker’s access through stolen credentials, altered identity policies, or infected shared storage.

The main trade-offs are build latency, image maintenance, temporary replacement capacity, and the need to separate application state from disposable compute. Emergency in-place patching may sometimes be justified, but it creates an exception that must be incorporated into the next approved image. Infrastructure as code alone does not make a system immutable if deployments still modify existing hosts. Immutable infrastructure also does not replace backups, and rolling back an image may be unsafe when database schemas have changed or the previous image contains a known vulnerability.