Amazon DVA-C02: Amazon API Gateway und Anwendungsintegration — Lernleitfaden
Teil des AWS Developer Associate DVA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Entwerfen von APIs mit API Gateway (REST, HTTP, WebSocket) und Integrationen
Das Design beginnt mit der Wahl des richtigen API-Typs: REST APIs (API Gateway REST) bieten feingranulare Funktionen auf Stage-Ebene wie Caching pro Stage und anspruchsvolle Mapping-Templates; HTTP APIs (API Gateway v2) bieten geringere Latenz und niedrigere Kosten für gängige Proxy-Muster und native JWT/OIDC-Authorizer; WebSocket APIs bieten persistente Client-Server-Kanäle mit Route Keys ($connect, $disconnect, $default) und erfordern die API Gateway Management API (PostToConnection), um Nachrichten zu senden. Architekturen für Integrationen sollten AWS_PROXY/Lambda-Proxy für einfache Anfrage/Antwort-Muster bevorzugen (verwenden Sie
undefined
oder für v2
undefined
auf
undefined
) und HTTP oder VPC Link für private HTTP-Backends wählen. Für Backends mit hohem Durchsatz verwenden Sie NLB + VPC Link. Mock-Integrationen (
undefined
) und Integrationsantwort-Templates ermöglichen es Frontend-Teams, ohne ein fertiges Backend zu beginnen. Wenn Sie APIs mit CloudFront versehen, verwenden Sie regionale API-Endpunkte als Origins und setzen Sie die Origin Protocol Policy auf „HTTPS-only“; Edge-optimierte REST APIs befinden sich bereits hinter CloudFront. Häufige Fallstricke sind nicht übereinstimmende Versionen des Payload-Formats zwischen API und Lambda (v1.0 vs. 2.0), das Vergessen, apigateway.amazonaws.com die Berechtigung zum Aufrufen von Lambda zu erteilen (fügen Sie die Berechtigung mit
undefined
hinzu) und CORS-Fehlkonfigurationen, die Browser blockieren.
Sicherheits- und Autorisierungsmuster (Cognito, IAM, Custom Authorizers)
Sicherheitsmuster sollten auf Client-Typen und Zugriffsmodelle abgestimmt sein: Verwenden Sie Amazon Cognito User Pools oder einen externen OIDC-Provider und binden Sie diese als JWT-Authorizer für HTTP APIs ein (
undefined
in apigatewayv2 mit
undefined
auf
undefined
gesetzt), oder verwenden Sie REST API Cognito Authorizers für sitzungsbasierten Benutzerzugriff. Für Service-zu-Service- oder Admin-APIs ist die IAM-Autorisierung (SigV4) und eng gefasste IAM-Ressourcenrichtlinien auf Stages und Methoden zu bevorzugen. Lambda (Custom) Authorizers bieten maximale Flexibilität zur Implementierung maßgeschneiderter Authentifizierungsregeln, aber denken Sie daran, dass sie Latenz und Fehlermodi hinzufügen – cachen Sie Authorizer-Antworten mit einer TTL, um Cold Starts zu reduzieren und Fehler zu vermeiden, die einen 500er-Status an Clients zurückgeben. Schützen Sie sich vor Missbrauch mit Nutzungsplänen und API-Schlüsseln (
undefined
und
undefined
) in Kombination mit Drosselungsquoten. Stellen Sie korrekte IAM-Berechtigungen sicher: Erteilen Sie API Gateway die Berechtigung, Lambda aufzurufen (
undefined
) und beschränken Sie die Lambda-Ausführungsrollen auf das Least-Privilege-Prinzip. Typische Fallstricke für Entwickler sind das Vergessen, die Token-Extraktion für JWT-Authorizer zu aktivieren, Authorizer-Timeouts, die die gesamte API-Latenz beeinträchtigen, und die Weiterleitung von Headern/Cookies durch CloudFront, was unbeabsichtigt Caches umgehen oder Benutzerdaten preisgeben kann.
Stage-Management, Versionierung, Caching und Canary-Deployments
Behandeln Sie Stages als unabhängige Laufzeitumgebungen: Deployments sind Snapshots (
undefined
oder
undefined
), und Stages werden diesen Snapshots zugeordnet. Verwenden Sie Stage-Variablen oder, vorzugsweise, Lambda-Aliase, um den Traffic zwischen Versionen zu leiten; schalten Sie Aliase atomar um (
undefined
) oder verwenden Sie die Canary-Einstellungen der API Gateway Stage für ein schrittweises Rollout. Für REST APIs aktivieren Sie das Caching auf der Stage-Ebene (
undefined
mit Patch-Operationen, um
undefined
und
undefined
zu setzen) und steuern Sie die TTL- und Cache-Schlüssel-Parameter in den Methodeneinstellungen; HTTP APIs haben derzeit kein integriertes Caching, verwenden Sie daher CloudFront oder Caches auf Anwendungsebene. Leeren Sie den Cache bei einem Deployment oder wenn sich die zugrunde liegenden Daten ändern; sich ausschließlich auf die TTL zu verlassen, kann zur Rückgabe veralteter Daten führen. Muster für die Versionierung: Verwenden Sie semantische API-Versionierung im Pfad (/v1/…) oder verlassen Sie sich auf gestagte Deployments für Blue/Green-Flows. Häufige Fallstricke sind die Annahme, dass Stage-Variablen sicher sind (sie sind für Entwickler mit Konsolenzugriff sichtbar), die Fehlkonfiguration von Cache-Schlüsseln (Vergessen, den Authorization-Header oder Query-Parameter einzubeziehen) und die fehlende Koordination von Schemaänderungen mit der Client-Kompatibilität.
Leistung, Beobachtbarkeit und Diagnose
Instrumentieren Sie APIs End-to-End: Aktivieren Sie Ausführungsprotokolle und Zugriffsprotokolle auf API Gateway und erzeugen Sie strukturierte JSON-Daten ($context-Variablen) in CloudWatch Logs; aktivieren Sie X-Ray auf API Gateway und Lambda (setzen Sie tracingEnabled in der Bereitstellung/Stage oder verwenden Sie das SDK: PutFunctionConcurrency/UpdateFunctionConfiguration mit TracingConfig), um Traces zu korrelieren. Überwachen Sie API-Gateway-Metriken (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) und Lambda-Metriken (Duration, Throttles, ConcurrentExecutions) in CloudWatch; verwenden Sie Metrik-Mathematik, um zu identifizieren, wo sich Latenz ansammelt. Bei WebSocket verfolgen Sie die Anzahl der Verbindungen und Spitzen bei API Gateway 5XX-Fehlern. Zu den Schritten zur Fehlerbehebung gehören der Vergleich von IntegrationLatency mit Latency, um festzustellen, ob das Backend oder das Gateway den Overhead verursacht, die Detailanalyse von X-Ray-Segmenten auf Kaltstarts oder VPC-ENIs und die Überprüfung von CloudWatch Logs auf Fehler in Mapping-Vorlagen. Verwenden Sie DLQs und Ziele für asynchrone Lambda-Fehler und legen Sie reservierte Nebenläufigkeit oder bereitgestellte Nebenläufigkeit für kritische Funktionen fest. Fallstricke für Entwickler: Protokollierung sensibler PII in Traces (am Ursprung zensieren oder das X-Ray-Sampling für diese Abläufe deaktivieren), fehlende Anbieterzertifikate für benutzerdefinierte Domains (regionales ACM vs. us-east-1 für Edge) und das Verlassen auf die standardmäßige Konto-Drosselung ohne Nutzungspläne für öffentliche APIs.
Praktisches Problem: Anwendungsfallszenario
Szenario: BrightCart betreibt ein regionales E-Commerce-Frontend auf einer Single-Page-Application, die in S3/CloudFront gehostet wird, und stellt eine Checkout-API über API Gateway (regionale HTTP-API) bereit, die Lambda-Funktionen in einer VPC aufruft und Bestellungen in DynamoDB schreibt. Die Umgebung verwendet eine CI/CD-Pipeline, die Lambda-Versionen auf Produktions-Aliase bereitstellt und /checkout auf einer Produktions-Stage verfügbar macht.
Herausforderung: Nach einem kürzlichen Feature-Rollout ist die Latenz der Produktions-API gestiegen, und einige Checkout-Anfragen geben zeitweise 502/504-Fehler zurück; Entwickler benötigen einen sicheren Rollback-Mechanismus und sofortige Diagnosemöglichkeiten.
Empfohlener Ansatz:
- Erstellen Sie einen Deployment-Rollback, indem Sie die Produktions-API-Stage auf das vorherige Deployment verweisen lassen: Verwenden Sie
undefined
und dann
undefined
.
2. Verschieben Sie den Traffic sicher mithilfe von Lambda-Aliasen: Aktualisieren Sie den prod-Lambda-Alias auf die vorherige Version mit
undefined
und überprüfen Sie das Verhalten. 3. Aktivieren und sammeln Sie Diagnosedaten: Aktivieren Sie das X-Ray-Tracing für die API und Lambda (
undefined
und
undefined
) und schalten Sie detaillierte Zugriffsprotokolle (
undefined
,
undefined
) in CloudWatch Logs ein.
4. Analysieren Sie Metriken und Traces: Vergleichen Sie API Gateway IntegrationLatency mit Latency in CloudWatch, untersuchen Sie X-Ray-Segmente, um Kaltstarts von VPC-ENIs zu identifizieren, und prüfen Sie auf Lambda-Drosselungen oder bedingte Schreibvorgänge in DynamoDB; wenn die Latenz der VPC-ENIs die Ursache ist, ziehen Sie bereitgestellte Nebenläufigkeit (
undefined
) oder einen Wechsel zu Lambda mit VPC-Endpunkt-Optimierungen in Betracht.
Begründung: Atomare Stage-Redeploys und das Umschalten von Lambda-Aliasen ermöglichen einen schnellen, risikoarmen Rollback ohne Code-Änderungen. Die Aktivierung von X-Ray und strukturierten Zugriffsprotokollen ermöglicht es Entwicklern, genau zu bestimmen, ob API Gateway, Lambda-Kaltstarts, das VPC-Netzwerk oder nachgelagerte DynamoDB-Aufrufe die Fehler verursachen, und leitet die richtige Gegenmaßnahme ein (bereitgestellte Nebenläufigkeit, erhöhter Durchsatz oder Konfigurationskorrekturen).
← Serverless und AWS Lambda · Alle Domänen · Amazon DynamoDB und NoSQL-Design →
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 →