Skip to content

PATTERN Cited by 1 source

Layered AMI pipeline

Pattern

A layered AMI pipeline separates machine image construction into a platform-owned base layer and team-owned service layers, connected by an event-driven rebuild trigger. When the base image is updated, downstream service images automatically rebuild on the new foundation.

Structure

Base image build (platform team)
    ├── Validate (launch temporary instance, run tests)
    ├── Publish (update SSM parameter / registry)
    └── Notify (EventBridge / webhook / pub-sub)
Service image builds (service teams) × N
    ├── Inherit updated base
    ├── Layer service-specific software + config
    ├── Validate
    └── Publish for deployment

Mechanism

  1. Platform team publishes a new golden base image (e.g., via AWS Image Builder).
  2. Image passes automated validation tests before distribution.
  3. A signal (EventBridge event, SSM Parameter update) propagates to downstream service pipelines.
  4. Each service pipeline rebuilds its image on the new base, runs its own tests, and produces a deployable artifact.
  5. Service teams deploy the updated image through their normal rollout pipeline.

Benefits

  • Separation of concerns: Platform teams own the foundation; service teams own their layer.
  • Automatic propagation: Security patches and platform improvements flow downstream without manual intervention.
  • Independent cadence: Each layer can evolve at its own pace; service teams are not blocked by the base image cadence.
  • Validated at every layer: Both base and service images pass tests before any fleet instance runs them.

Slack's implementation

Slack's slack-zero + service image architecture is the canonical wiki instance. AWS Image Builder produces slack-zero, publishes an SSM parameter, and fires an EventBridge event → Lambda → downstream service pipelines rebuild automatically (Source: sources/2026-07-14-slack-shipyard-next-generation-ec2-platform).

Seen in

Last updated · 585 distilled / 1,765 read