Eine Golden AMI ist ein vorkonfiguriertes, gehärtetes und validiertes Amazon Machine Image, das als einzige Vorlage für den Start identischer EC2-Instanzen dient. Statt jedes Mal einen leeren Server zu starten und Abhängigkeiten von Hand zu installieren, backen Sie alles einmal —gepatchtes Betriebssystem, Agenten, Runtime, Konfiguration und Sicherheitskontrollen— und verwenden es bei jedem Deployment wieder.
Dieser Ansatz ist die Grundlage unveränderlicher Infrastruktur: Sie patchen keine laufenden Server, sondern bauen ein neues Image und ersetzen die Instanzen. Das Ergebnis: weniger Konfigurationsdrift, schnellere Starts beim Autoscaling und Deployments, die sich prüfen und zurückrollen lassen.
Golden AMI gegenüber Bootstrapping beim Start
Es gibt zwei Philosophien. Beim Bootstrapping konfiguriert sich die Instanz beim Start (user-data, Ansible Pull, cloud-init). Das ist flexibel, aber langsam und fragil: Fällt ein Paket-Repository aus, scheitert Ihr Autoscaling. Im Golden-AMI-Modell (Baking) passiert die schwere Arbeit einmalig in der Pipeline; der Start ist nahezu sofort und deterministisch. Die meisten reifen Teams kombinieren beides: Sie backen das Stabile und überlassen dem Start nur die Konfiguration, die je Umgebung variiert.
Warum Packer
Packer von HashiCorp ist das De-facto-Standardwerkzeug, um Maschinen-Images automatisiert und cloudübergreifend aus einer einzigen Vorlage zu bauen. Sie definieren das Image als Code (HCL2); Packer startet eine temporäre Instanz, wendet Ihre Provisioner an, erstellt das AMI und zerstört die temporären Ressourcen. Dieselbe Vorlage kann Images für AWS, Azure und GCP erzeugen – ideal, wenn Sie in mehreren Clouds veröffentlichen.
- Reproduzierbar: Das Image ist in einer in Git versionierten Datei beschrieben.
- Multicloud: ein Ablauf für AMI, Azure Managed Image und GCP Custom Image.
- Integrierbar: passt in CI/CD (GitHub Actions, GitLab CI, CodePipeline).
- Prüfbar: Jeder Build wird protokolliert, mit Manifest und Artefakten.
Anatomie einer Packer-Vorlage (HCL2)
Eine moderne Vorlage ist in Blöcke gegliedert. Der Block source definiert den Builder
(z. B. amazon-ebs), das Basis-AMI, den Instanztyp und die Region. Der Block build
verkettet die Provisioner, die Software installieren und konfigurieren. Die
Post-Processors erzeugen Artefakte wie ein JSON-Manifest mit der ID des entstandenen
AMI.
Minimales kommentiertes Beispiel
source "amazon-ebs" "app" — geht von einem offiziellen Basis-AMI aus, das dynamisch mit
data "amazon-ami" über Eigentümer und Namensmuster gesucht wird, damit keine ID
festgenagelt wird, die verfällt.
provisioner "shell" — führt Installations- und Aktualisierungsskripte aus (dnf update -y, Runtime, CloudWatch-Agent, SSM-Agent).
provisioner "ansible" — wenn Sie bereits Ansible-Rollen haben, nutzen Sie sie erneut,
um das Image idempotent zu konfigurieren.
post-processor "manifest" — schreibt manifest.json mit der artifact_id, die Ihre
Pipeline liest, um zu wissen, welches AMI entstanden ist.
Die Pipeline Schritt für Schritt
Das ist der Ablauf, den wir empfehlen, um eine Golden AMI sicher und wiederholbar vom Commit in die Produktion zu bringen:
| Schritt | Was passiert | Typisches Werkzeug |
|---|---|---|
| 1. Commit | Sie ändern Vorlage oder Skripte und pushen nach Git | Git / PR-Review |
| 2. Validate | packer fmt + packer validate prüfen die Syntax | Packer, CI |
| 3. Build | Packer startet eine temporäre Instanz und wendet Provisioner an | Packer |
| 4. Harden | CIS Benchmark anwenden und Zugangsdaten bereinigen | Ansible / CIS |
| 5. Scan | Schwachstellen- und Secret-Scan | Trivy, Inspector |
| 6. Test | Eine Instanz wird gestartet und validiert | InSpec / Goss |
| 7. Tag & Version | Das AMI wird getaggt (Version, Commit, Datum) | AWS CLI |
| 8. Distribute | Es wird geteilt oder in andere Regionen/Konten kopiert | AWS RAM / copy |
| 9. Deploy | Das AMI wird im Launch Template referenziert | Terraform / ASG |
Referenzablauf einer Golden-AMI-Pipeline in neun Stufen.
Bewährte Praktiken, die den Unterschied machen
- Nageln Sie nie ein Basis-AMI per ID fest: Suchen Sie es dynamisch über Eigentümer und Namen, um stets die neuesten Patches zu erben.
- Versionieren Sie das Image mit klarem Schema (z. B.
app-2026.07.1) und speichern Sie den Git-Commit in den AMI-Tags. - Vor dem Versiegeln aufräumen: Logs, Shell-Historien, temporäre SSH-Schlüssel und Paket-Caches löschen, damit keine Secrets durchsickern.
- Immer scannen: Trivy oder Amazon Inspector einbinden, um keine bekannten CVEs zu veröffentlichen.
- Snapshots verschlüsseln – mit eigenem KMS-Schlüssel von der ersten Minute an.
- Ablauf automatisieren: alte Versionen als veraltet markieren und löschen, um Kosten zu kontrollieren.
Packer oder EC2 Image Builder: was wählen?
Wer ausschließlich in AWS arbeitet und native Integration mit Inspector, verwaltete CIS-Komponenten und keinerlei zu pflegende Infrastruktur schätzt, fährt mit EC2 Image Builder solide und ohne Lizenzkosten. Wer aus einer Vorlage für mehrere Clouds bauen muss oder bereits ein HashiCorp-Ökosystem (Terraform, Vault) hat, bekommt mit Packer mehr Portabilität. Beides schließt sich nicht aus: Viele Teams nutzen Packer für die Multicloud-Logik und Image Builder für interne AWS-Pipelines.
Häufig gestellte Fragen
Wie oft sollte ich die Golden AMI neu bauen?
Mindestens mit jedem Patch-Zyklus des Betriebssystems (monatlich ist meist ein guter Rhythmus) und immer dann, wenn ein kritisches CVE für Ihren Stack erscheint. Eine automatisierte Pipeline erlaubt Neubauten auf Zuruf in Minuten.
Kann ich dieselbe Packer-Vorlage für AWS und Azure nutzen?
Ja. Packer unterstützt mehrere Builder in einem Build. Sie teilen sich die Provisioner und ändern nur den Source-Block je Cloud – so entstehen AMI, Managed Image und Custom Image parallel.
Golden AMI oder Container?
Es ist kein Entweder-oder. Golden AMIs sind ideal für die Host-Schicht und für nicht containerisierte Lasten; Container laufen obendrauf. Tatsächlich ist eine gehärtete Golden AMI eine ausgezeichnete Basis für Ihre Kubernetes-Knoten.
Bei imaxe.cloud bauen und pflegen wir gehärtete, aktuelle Basis-Images, damit Ihre Pipeline von einem verlässlichen Fundament aus startet.
