You've embraced immutable infrastructure. Servers are cattle. Every deploy replaces the fleet. But how you build those replacement servers matters enormously. There are two approaches: boot a base OS and run configuration scripts every time (Chef, Ansible, cloud-init), or bake a pre-configured image once and boot that. The Golden Image Pattern is the second approach — build the artifact once, boot it a thousand times.

A golden image is a machine image (AMI, VMDK, container image, OS snapshot) with everything pre-installed: OS patches, runtime, dependencies, agents, security hardening, and often your application code itself. When you scale up, you don't run 300 apt-gets — you just launch instances from the image.

Why this beats configure-on-boot:

• Boot time collapses. A configure-on-boot instance takes 3-8 minutes to become healthy. A golden-image instance takes 30-60 seconds. When autoscaling responds to a traffic spike, that difference decides whether users see errors.
• No dependency on external services at boot. If your package repo, container registry, or config server is down, configure-on-boot fails. Golden images boot regardless.
• Deterministic. The image you tested in staging is byte-for-byte the image that runs in production. No "apt-get pulled a new version this morning" surprises.

Real-world example: Netflix built Aminator specifically for this. Every service deployment produces a baked AMI with the JVM, application JAR, monitoring agents, and configuration all pre-installed. When Netflix scales up during a traffic surge, new instances are serving traffic within roughly 60 seconds. If they used configure-on-boot with their scale, they'd need to over-provision by 20-30% just to absorb bootup latency during scaling events.

The tradeoff: image builds are slower than a config push. Baking an AMI takes 5-15 minutes; running Ansible against a live host takes 30 seconds. This is why teams often layer both: golden images for the base + application, small config injection at boot for environment-specific values (secrets, region, cluster ID).

Rule of thumb for what to bake vs inject: if it changes per environment (dev/staging/prod), inject it at boot via user data or a secrets manager. If it's the same across every instance of this service version, bake it. A good target is 90% baked, 10% injected — anything more injected and you're back to configure-on-boot; anything less and you need a new image for every config tweak.

Watch out for image sprawl. Without hygiene, you'll accumulate hundreds of AMIs at $0.05/GB-month. Set a retention policy: keep last N versions plus anything currently running, garbage-collect the rest weekly.