Skip to main content

Configuration management

Configuration management means a machine can be rebuilt to a known state without a person remembering what was done to it. This standard covers how we achieve that for containers, EC2 instances and serverless functions.

The standard. Automated software inventory, OS patching, system image creation and configuration for Windows and Linux workloads.

Configuration items​

Everything that can change and affects behaviour is a configuration item, and is recorded:

  • Docker images — repository, tag, digest, base image, build arguments.
  • Packer templates — source AMI, provisioners, software versions, patch level.
  • Lambda functions — runtime version, dependencies, environment variables, memory and timeout settings.
  • Infrastructure variables — account, region, instance types, scaling bounds.

Each item has a defined desired state and a named owner.

Containers​

Build. Images are built from a reviewed Dockerfile in a pipeline, not on a developer workstation. Multi-stage builds keep the runtime image minimal.

Pin. Base images are referenced by digest, not by a floating tag. latest is not a version.

Inventory. The pipeline records, per build:

docker image inspect "$IMAGE" \
  --format '{{.Id}} {{.Config.Image}} {{json .Config.Env}}'

along with a software bill of materials generated by the scanner (for example syft), stored as a build artefact.

Patch. The base image is rebuilt on a schedule. A pipeline that only rebuilds on application change leaves base-image vulnerabilities in production indefinitely.

Desired state. The deployment manifest — task definition, or Kubernetes manifest — is the single source of truth for runtime configuration. Manual task definition edits are prohibited; they are detected and reverted by the deployment pipeline.

EC2 and AMIs​

Golden images are built with Packer, not configured by hand after launch.

source "amazon-ebs" "base" {
  ami_name      = "app-base-{{timestamp}}"
  instance_type = "t3.micro"
  region        = var.region
  source_ami_filter {
    filters = {
      name                = "al2023-ami-*-x86_64"
      virtualization-type = "hvm"
    }
    owners      = ["amazon"]
    most_recent = true
  }
  ssh_username = "ec2-user"
}

build {
  sources = ["source.amazon-ebs.base"]
  provisioner "shell" {
    inline = [
      "sudo dnf update -y",
      "sudo dnf install -y amazon-cloudwatch-agent",
    ]
  }
}

Rules.

  • Images are versioned by timestamp or build number, never overwritten.
  • OS patches are applied during the build, so an instance never launches unpatched.
  • The AMI ID is published as a pipeline output and consumed by Terraform — never typed into a console.
  • Instance refresh replaces running instances with the new image rather than patching in place.
  • Build logs and the software manifest are retained as artefacts.

See AMI pipeline with Packer.

Serverless​

Runtime versions are pinned in the infrastructure definition and upgraded deliberately; an automatic major-version bump is a breaking change.

Dependencies are locked (package-lock.json, poetry.lock, requirements.txt with hashes) and scanned in the pipeline.

Configuration — environment variables, memory, timeout, concurrency — is defined in IaC, not set in the console.

Registry. A record of every function's runtime, dependencies and configuration is generated from the deployed state, so inventory is a query rather than an audit.

Patch management​

WorkloadPatch mechanismCadence
ContainersRebuild base image, redeployWeekly for base images; immediately for critical CVEs
EC2Rebuild AMI, instance refreshMonthly; immediately for critical CVEs
LambdaRuntime and dependency update, redeployPer runtime support window; dependency scan on every build
Managed servicesAWS-managedMonitored via AWS Health and Security Hub

Emergency patching has a defined path: the base image or dependency is updated, the pipeline rebuilds, and the change is deployed through the normal release process — faster, but not bypassing it.

Inventory​

A weekly job collects:

  • Running container image digests per environment.
  • EC2 instance AMI IDs and patch level.
  • Lambda runtime versions and dependency manifests.
  • Resources that differ from the Terraform state.

Discrepancies are reported and routed to the owning team. Inventory that is only collected and never compared is not configuration management.