Amazon ANS-C01: Automatisierung, IaC und Netzwerkbetrieb — Lernleitfaden
Teil des AWS Advanced Networking Specialty ANS-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Kernkonzept
Infrastructure as Code für das Networking auf AWS wandelt Netzwerktopologie, Sicherheitsrichtlinien und Routing in deklarative Vorlagen und deterministische Lebenszyklus-Operationen um. CloudFormation-Vorlagen (AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup) kodieren den gewünschten Zustand, während CloudFormation-APIs – CreateStack, UpdateStack, DeleteStack, DescribeStacks und Change-Set-Operationen – Änderungen atomar anwenden. Verwenden Sie verschachtelte Stacks und modulare Vorlagen, um Netzwerkdomänen (gemeinsam genutzte Dienste, anwendungsspezifische VPCs pro Konto, Ingress/Egress-Zonen) zu isolieren, und StackSets, um konsistente Netzwerk-Stacks über AWS Organizations hinweg zu verteilen. Drift-Erkennung (DetectStackDrift) und Change Sets bieten Leitplanken, sodass die Automatisierung Out-of-Band-Netzwerkänderungen erkennen und eine manuelle Überprüfung erfordern kann.
Die Automatisierung muss auch die Teile des Netzwerks abdecken, die CloudFormation nicht nativ ausdrücken kann oder die Lifecycle-Hooks erfordern: kontoübergreifende Ressourcenfreigabe, On-Prem-Integrationen und Laufzeitkonfiguration auf Hosts. CloudFormation Custom Resources (unterstützt durch Lambda) oder CloudFormation-Module können APIs wie CreateResourceShare (AWS RAM) aufrufen, um ein Transit Gateway oder Subnetz freizugeben, oder Systems Manager (SSM) SendCommand aufrufen, um Zertifikate oder Routing-Richtlinien in Instanzen zu injizieren. Für Kubernetes in EKS wird der AWS Load Balancer Controller über Helm installiert und durch Service-Annotationen verwaltet. CloudFormation kann die IAM-Rolle, den OIDC-Provider und HelmRelease-Objekte über AWS::EKS::Cluster und Custom Resources bereitstellen, aber die Laufzeit-Zuweisung von Pod-IPs zu NLB-Zielgruppen wird vom Controller gehandhabt.
Wichtige Services und Konfiguration
Es gibt primäre AWS-Services und APIs, die Sie bei der Automatisierung von Netzwerkoperationen wiederholt verwenden werden: CloudFormation (CreateStack, UpdateStack, DetectStackDrift), AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare), AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute), Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes), AWS Lambda (CreateFunction, AddPermission, Invoke), Systems Manager (PutParameter, SendCommand, CreateDocument) und AWS Config (PutEvaluations, StartConfigurationRecorder). Diese Services bilden einen typischen Automatisierungs-Stack für sicheres, auditierbares Networking.
Achten Sie beim Entwerfen von Vorlagen und Automatisierungen auf spezifische Ressourcenattribute und Controller-Annotationen. Wählen Sie für Load Balancer den richtigen Typ und die richtigen Attribute: Ein NLB mit TCP-Listenern behält die Quell-IP bei und unterstützt das Proxy Protocol v2 über CreateLoadBalancer/ModifyTargetGroupAttributes und die Einstellung „proxy_protocol_v2.enabled“ für Zielgruppen; ein ALB (Application Load Balancer) terminiert TLS, fügt X-Forwarded-For-Header für Client-IPs ein und unterstützt gRPC/HTTP2, wenn er mit HTTPS-Listenern konfiguriert ist. Für EKS verwenden Sie Annotationen wie service.beta.kubernetes.io/aws-load-balancer-type: „nlb“ oder die Ingress/Service-Annotationen des AWS Load Balancer Controllers, um TLS-Passthrough gegenüber der Terminierung zu steuern und den Zieltyp für direktes Pod-Targeting auf ip zu setzen. Für die kontoübergreifende Freigabe und Multi-Account-Netzwerke verwenden Sie AWS RAM, um Transit Gateways freizugeben, und CloudFormation StackSets in Kombination mit delegierten Admin-Rollen, um Attachments und Zugriff in den Consumer-Konten zu erstellen.
Designmuster und Kompromisse
Zwei gängige, gegensätzliche Muster sind Hub-and-Spoke mit Transit Gateway und Shared VPC über AWS RAM. Hub-and-Spoke mit einem Transit Gateway zentralisiert Routing, Inspektion und Inter-VPC-Konnektivität; es skaliert, da Attachments und Routing-Tabellen eine Segmentierung ermöglichen, und Sie können das TGW mit RAM freigeben, sodass verschiedene Konten Attachments erstellen können, ohne den vollständigen Besitz zu übertragen. Der Kompromiss liegt in der Routenverteilung und den Limits der Routing-Tabellen: Die Routing-Tabellen und Attachment-Limits des Transit Gateway erfordern Planung und können einzelne Punkte schaffen, an denen Richtlinien durchgesetzt werden müssen (verwenden Sie mehrere Routing-Tabellen und AWS Network Firewall, um den Datenverkehr zu isolieren). Shared VPC (VPC-Freigabe mit AWS RAM) platziert Subnetze in einem Host-Konto und ermöglicht es Consumer-Konten, Ressourcen in diesen Subnetzen zu starten. Dies vereinfacht zentrale Sicherheitskontrollen für die Konnektivität, reduziert jedoch die Autonomie auf Kontoebene und erschwert die Netzwerkisolation pro Geschäftseinheit, da der Besitz von Sicherheitsgruppen und IAM-Grenzen sorgfältig verwaltet werden müssen.
Für Ingress und TLS-Terminierung müssen Sie die Notwendigkeit einer Ende-zu-Ende-Verschlüsselung gegen Skalierbarkeit und die Beibehaltung der Client-IP abwägen. Wenn Sie eine TLS-Terminierung am Load Balancer benötigen (für WAF, Zertifikatszentralisierung und HTTP-Routing), ist ein ALB das richtige Werkzeug; er fügt X-Forwarded-For hinzu, damit das Anwendungs-Logging Client-IPs erfassen kann, und der ALB unterstützt pfad- und hostbasiertes Routing zu mehreren Zielgruppen. Wenn Sie echtes Ende-zu-Ende-TLS oder mTLS benötigen, bei dem der Load Balancer den Datenverkehr nicht entschlüsseln darf, verwenden Sie einen NLB im TCP-Modus, um TLS an die Backend-Endpunkte (Pod oder Instanz) durchzuleiten, und konfigurieren Sie den Zieltyp ip und externalTrafficPolicy: Local auf Kubernetes, um die Quell-IP beizubehalten. Für Tausende von gleichzeitigen, bidirektionalen gRPC-Verbindungen mit mTLS bietet ein NLB, der rohes TLS an Pod-Ports weiterleitet, in Kombination mit Pods, die mTLS terminieren, Skalierbarkeit und echte Ende-zu-Ende-Verschlüsselung, während die Annotationen des AWS Load Balancer Controllers verwendet werden, um die richtigen NLB-Listener und Zielgruppen zu erstellen.
Häufige Fallstricke und Entscheidungskriterien
Ein häufiger Fallstrick ist die Verwechslung des Ortes der TLS-Terminierung mit den Anforderungen an die Client-IP: Ein ALB stellt den X-Forwarded-For-Header bereit, wenn er TLS terminiert, aber er erhält die Quell-IP zum Ziel nicht bei, wie es ein NLB tut. Wenn Sie sowohl ALB-Funktionen (Host-/Pfad-basiertes Routing, WAF) als auch die ursprüngliche Quell-IP am Backend benötigen, sollten Sie erwägen, einen ALB für die HTTP-Terminierung zu verwenden und an Reverse-Proxys oder Sidecars weiterzuleiten, die die Quell-IPs aus dem X-Forwarded-For-Header rekonstruieren. Alternativ können Sie eine Architektur verwenden, bei der ein NLB TLS an Dienste durchleitet, die mTLS durchführen und das HTTP-Routing an In-Cluster-Proxys auslagern. Ein weiterer Fallstrick ist die Fehlkonfiguration von kontoübergreifenden Berechtigungen: Wenn Sie ein Transit Gateway oder eine andere Netzwerkressource mit RAM teilen, stellen Sie sicher, dass Sie eine explizite Ressourcenfreigabe (Resource Share) und die korrekte IAM-Rolle sowie den korrekten RAM-Prinzipal verwenden. Andernfalls führt dies zu undurchsichtigen „Permission Denied“-Fehlern.
Bei der Automatisierung der Compliance sollten Sie private Schlüssel oder CA-Material niemals unverschlüsselt im Klartext speichern. Verwenden Sie SSM Parameter Store SecureString mit einem KMS-Schlüssel, der eine minimale Schlüsselrichtlinie (Key Policy) hat, die nur den Rollen und Prinzipalen Zugriff gewährt, die ihn benötigen. Nutzen Sie verwaltete Regeln von AWS Config (zum Beispiel vpc-flow-logs-enabled, restricted-common-ports, security-group-rule-check). Wo verwaltete Regeln Ihre Kriterien nicht abdecken, implementieren Sie Lambda-gestützte Config-Regeln, die PutEvaluations aufrufen. Die Behebung (Remediation) sollte über SSM Automation-Dokumente oder Systems Manager Run Command automatisiert werden, die von der Config-Remediation-Aktion aufgerufen werden können. Stellen Sie jedoch immer einen Benachrichtigungs- und Genehmigungspfad für risikoreiche Änderungen bereit.
Praktisches Problem: Anwendungsfallszenario
Unternehmen: ApexTelemetrics – Herausforderung: Bereitstellung eines global erreichbaren, auf EKS gehosteten gRPC-Dienstes, der echtes End-to-End Mutual TLS (Client und Server authentifizieren sich mit mTLS) erfordert, Tausende von gleichzeitigen, langlebigen Verbindungen über TCP 443 unterstützt, Pods automatisch skalieren muss und sicherstellt, dass die Verteilung und Rotation von Zertifikaten automatisiert und prüfbar ist.
Vorgehensweise:
- Netzwerk und Load Balancer mit CloudFormation bereitstellen: Erstellen Sie einen NLB über AWS::ElasticLoadBalancingV2::LoadBalancer, der mit einem TCP-Listener auf Port 443 und Zielgruppen (Target Groups) mit targetType „ip“ und Zustandsprüfungen (Health Checks) über TCP konfiguriert ist. Verwenden Sie CloudFormation CreateStack/UpdateStack und modulare, verschachtelte Stacks für VPC, Subnetze und den NLB. Nutzen Sie Annotationen des AWS Load Balancer Controllers auf dem EKS Service (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”, service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”), damit jeder Service die NLB-Zielgruppe direkt für die Pods erstellt.
- TLS-Passthrough und mTLS-Terminierung an den Pods sicherstellen: Konfigurieren Sie den EKS Service so, dass er TCP 443 direkt an die Pod-Ports weiterleitet. Implementieren Sie einen Sidecar- oder Envoy-Proxy in jedem Pod, der die mTLS-Terminierung mit dem Client durchführt und die gegenseitige Authentifizierung erzwingt. Setzen Sie externalTrafficPolicy: Local auf dem Service, damit die Quell-IP bei Bedarf erhalten bleibt, und verwenden Sie Pod-Level-Autoscaling (Horizontal Pod Autoscaler) zusammen mit dem Cluster Autoscaler, um Knoten und Pods gemeinsam zu skalieren.
- Zertifikatslebenszyklus und -verteilung automatisieren: Speichern Sie private Schlüssel von CA- und Serverzertifikaten im SSM Parameter Store als SecureString, verschlüsselt mit einem KMS-Schlüssel. Erstellen Sie eine AWS Lambda-gestützte benutzerdefinierte Ressource (Custom Resource) in CloudFormation, um SSM-Parameter während der Stack-Erstellung anzulegen (CreateFunction mit passender IAM-Rolle, dann CloudFormation Custom Resource zum Aufruf von PutParameter). Verwenden Sie SSM Run Command oder ein unveränderliches DaemonSet, das Secrets über eine an den Pod gebundene IAM-Rolle (via IRSA) aus SSM abruft, um Zertifikate in den Sidecar zu injizieren. Planen Sie für die Rotation Lambda-Funktionen (CreateFunction + EventBridge-Regel), um neue Zertifikate zu generieren, PutParameter auszuführen und SSM oder Kubernetes Jobs für rollierende Neustarts zu verwenden.
- Compliance und Audit: Aktivieren Sie AWS Config-Regeln (verwaltete Regeln wie vpc-flow-logs-enabled und benutzerdefinierte, Lambda-gestützte Regeln, die PutEvaluations verwenden), um zu überprüfen, dass die NLB-Listener TCP sind und kein ALB TLS für diesen Dienst terminiert. Konfigurieren Sie die Config-Remediation so, dass sie bei Erkennung einer Fehlkonfiguration SSM Automation-Dokumente aufruft und die Ergebnisse (Findings) an AWS Security Hub und CloudWatch Events sendet. Begründung seitens AWS: Der NLB im TCP-Modus bietet den echten TLS-Passthrough, der für End-to-End-mTLS erforderlich ist, und skaliert auf Tausende von gleichzeitigen Verbindungen mit einem geringen CPU-Fußabdruck pro Verbindung auf dem Load Balancer. Das Anzielen von Pods über targetType=ip entfernt einen zusätzlichen Hop und sorgt dafür, dass das Autoscaling reaktionsschnell bleibt. Die Speicherung und Rotation von Schlüsseln im durch KMS gesicherten SSM Parameter Store bietet ein zentralisiertes, prüfbares Secrets-Management mit IAM-Kontrollen. Die Verwendung von CloudFormation zusammen mit Lambda Custom Resources und EventBridge stellt sicher, dass der gesamte Lebenszyklus kodifiziert, wiederholbar und beobachtbar ist.
← Netzwerk-Performance und Monitoring · Alle Domänen · Container- und Serverless-Networking →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →