Compute
Intermediate 12 min read Compute

Images and Provisioning

Immutable OS images and boot-time automation

Machine images (AMI, Azure image, Compute Engine image) define what boots. Pipeline-built images plus user-data/cloud-init turn VM launching into a repeatable, scriptable operation.

AMIimagecloud-inituser-dataprovisioningHashiCorp Packer
Prerequisites: Compute Families and Sizing
Before we start

What you will learn

  • Explain image vs live-config provisioning
  • Build an image with Packer or a provider builder
  • Use cloud-init and user-data to configure at boot
In 60 seconds

An image is a frozen bootable disk (OS + packages + config). Provisioning with images means boot identical, pre-baked machines, then hand runtime drift-bearing config to cloud-init at first boot.

Introduction

What is this?

AWS AMIs are regional images captured from a source or built with Packer; Azure uses image definitions in a shared image gallery (SIG); GCP uses compute images and image families. Boot automation: user-data scripts, cloud-init (write_files, packages, users, runcmd), and instance templating (Launch Templates, VM image + config, instance templates). Images are immutable — never patch a running one, build a new version.

Motivation

Why do you need it?

  • Baking packages into images cuts boot from 15 min to < 2 min.
  • Reproducible images kill the 'works on that one box' class of bugs.
  • Golden images are the substrate for autoscaling: scale-out boots identical workers.
  • Provisioning logs (cloud-init) turn boot mysteries into debuggable steps.
Think about it

Mental model

Imagine

A frozen dinner vs cooking from scratch each time

Think of

Images vs live provisioning

Bake the meal (image) ahead with all ingredients standardized; at service time pop it in the oven (boot) with the table setting configured by the host (user-data).

Mechanics

How it works

  • Packer builds an image: launch a base, run provisioners, snapshot the disk, register the AMI/image.
  • Image families let you always reference the latest: ami-family, image family 'ubuntu-2204-lts'.
  • At boot, the metadata service injects user-data; cloud-init runs it (write files, install packages, run commands).
  • Launch templates/templates pin image, size, disks, SG, key, and user-data in one reusable definition.
  • New image versions are promoted through environments, then the ASG/MIG rolls instances gradually.

Image build to fleet roll.

Base image
Packer build
Golden image
Launch template
Fleet roll
Hands-on

Examples

Boot-time configuration with cloud-init

Boot-time configuration with cloud-init
#user-data
#cloud-config
packages:
  - nginx
write_files:
  - path: /etc/site/index.html
    content: "hello from boot config"
runcmd:
  - systemctl enable --now nginx
  - curl -sf http://169.254.169.254/latest/meta-data/tags > /tmp/tags.txt

cloud-init applies packages, files and commands on first boot, so a bare AMI becomes a configured server in seconds.

Real world

In production

  • A payment platform builds a hardened golden AMI with CIS-hardened OS, agents and app binary each release.
  • Azure shared image gallery distributes standard images across subscriptions and regions with replication.
  • GCP MIGs roll image updates from a versioned template with canary and rolling replacement.
Guidelines

Best practices

  • Keep images minimal and patch a day-old base to trim window for fresh CVEs.
  • Version images semantically; tag the AMI id in the release manifest.
  • Store user-data in Version Control, not in the console, and log cloud-init output.
  • Scan images (ECR/Artifact Registry/SIG scanning) before they reach production fleets.
Watch out

Common mistakes

  • Patching running instances forever instead of rebuilding images.
  • Committing OS drift: image from last year, packages updated haphazardly.
  • Forgetting cloud-init only runs once on first boot — pre-bake the config.
  • Regional image mismatch: an AMI copied to another region with the old ID breaks launch.
Root cause analysis

Common issues

Error
App missing after boot
Root cause

Package installed by cloud-init failed or never ran

Fix

Inspect cloud-init-output.log; ensure the package manager cache is reachable at boot.

Error
Image copy across regions missing
Root cause

Region-scoped images not replicated

Fix

Copy AMI or add Azure SIG replicas / GCP cross-region snapshots.

When things break

Debugging tips

  • Tail /var/log/cloud-init-output.log for first-boot failures.
  • Check immutability: after the first boot, config changes should come from a new image.
  • If an instance 'loses' its config, verify user-data was attached and cloud-init completed.
  • Compare MD5 of launched image vs your golden image; a mismatch means the wrong image launched.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

cloud-init runs on first boot of a fresh instance only.

Go deeper

Official documentation

AWS — Amazon Machine Images
docs
Azure — Shared image gallery
docs
cloud-init — Documentation
docs