Golden Image

A golden image is a deliberately built, tested, versioned machine image from which servers are created. It provides a common starting artifact. Teams can update it and replace hosts, while separately controlling launch configuration, required state, and changes made after boot. The same build-and-replace principle applies to container images, but the deployment unit differs: a container image starts application processes rather than a whole machine. Replacing a container does not replace its host, and persistent volumes need their own lifecycle and compatibility plan.

Note the name collision, since both terms appear in platform conversations. A golden path is a recommended route for developers through the platform; a golden image is an artifact servers boot from. Related in spirit, different things.

Compare replacement with in-place patching

In-place patching can be managed through centralized orchestration, configuration convergence, and verification. Replacement concentrates testing on a new artifact but introduces rollout and state-transfer requirements. The useful comparison is the process each workload can support.

	Patch in place	Rebuild from an image
What gets tested	Patches on representative current host states, then service checks during rollout	The image and launch configuration, then service checks during rollout
Hosts over time	Consistency depends on patch coverage, configuration control, and verification	A common baseline, with approved boot configuration and later changes still needing control
Rollback	A supported reversal or tested restore, with state compatibility checked	A previous compatible image. External schemas, migrated data, and consumers do not revert with the host
Prerequisite	Inventory, tests, orchestration, restart planning, and a recovery procedure	An owned pipeline and a tested plan for replacement, interrupted work, and required state

Choose replacement when the application and its state can tolerate that transition. Stateful services may qualify through replication, reattachment, or restoration; the label stateful alone does not decide. Agree on the behavior with the application owners before automating it.

What a pipeline does

AWS Image Builder automates image creation, validation, testing, and distribution. Its workflow illustrates the separation between building an artifact and deciding whether it is ready to use.

1. Define a recipe. Record the base image and components in version control and preserve the resolved inputs used for each build. A recipe supports repeatability, but floating inputs or unrecorded manual steps can still change the result.
2. Build and validate. Apply the customizations and check the resulting configuration. Validation should detect relevant missing or incorrect changes rather than assuming that a successful build command proves the artifact is correct.
3. Test the result. Launch from the produced image and exercise the selected behavior, including the supported launch configuration and dependencies.
4. Gate image distribution. Image Builder requires the configured tests to succeed before distribution. Fleet rollout is a separate decision: validate mixed-version behavior, preserve necessary capacity and state, drain work, and expand in stages while service metrics remain healthy. Define stop and recovery conditions; passing an image test alone does not establish safe production replacement.

Hardening can be built into the recipe, including managed components for supported standards. That establishes a tested starting baseline. Verify that launch configuration and subsequent changes preserve the required controls, and rebuild or remediate when the baseline itself needs updating.

What goes in, and what must not

The image should contain what is identical everywhere: the operating system and its patches, the baseline configuration, the agents, the runtime the applications need.

Keep secrets, environment-specific settings, and persistent state outside the shared image for different reasons:

• Secrets. A credential copied into images can still be revoked or changed at its issuer, but existing copies and consumers do not update automatically. Revocation can therefore break workloads using the old value. Fetch secrets with a least-privileged runtime identity, and design refresh, restart, or short-lived credentials to handle their lifecycle. Test consumer updates and old-credential retirement; not every service offers the same rotation mechanism. Image access is also a least privilege concern because launchers can inherit its contents.
• Environment-specific configuration. Pass supported differences at launch so the same artifact can be promoted between environments. Test the production configuration and dependencies too. If a separate image is necessary, validate that artifact rather than treating another environment’s test as sufficient.
• State. Anything that must survive replacement has to live elsewhere, since replacement is the whole point.

Keep image lineage understandable and record resolved base versions. Layering is manageable when inputs and changes are traceable; repeatedly modifying yesterday’s output without that record makes diagnosis harder. Rebuild from a maintained base and verify the result against the intended configuration.

A good image nobody has to use

An approved image has little operational value if workloads routinely launch other artifacts. Identify those launch paths and the reasons teams avoid the supported option before deciding how to enforce it.

AWS documents policies that limit launches to approved AMIs. Verify the scope of that enforcement and pair it with a convenient catalog and a documented exception path. Approval also needs an expiration and maintenance policy for older image versions.

Set rebuild and review triggers based on support dates, vulnerabilities, and changes to dependencies. Decide how long old images may remain launchable, including any time-limited rollback need. A regular schedule supports maintenance but does not replace urgent updates or service checks.

Where replacement cannot preserve required state, availability, or licensing conditions, use an owned in-place maintenance process. Revisit whether those constraints can change. How that decision fits with support dates, drift, and standardization is worked through in The Server That Outlived Its Support Window.

References

• AWS, What is EC2 Image Builder?
• AWS Builders’ Library — Automating safe, hands-off deployments
• AWS — Rotate AWS Secrets Manager secrets