Amazon DVA-C02: Amazon API Gateway e Integrazione di applicazioni — Guida allo studio
Fa parte della AWS Developer Associate DVA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Progettazione di API con API Gateway (REST, HTTP, WebSocket) e integrazioni
La progettazione inizia con la scelta del tipo di API più adatto: le API REST (API Gateway REST) offrono funzionalità granulari a livello di stage, come la cache per stage e template di mappatura sofisticati; le API HTTP (API Gateway v2) forniscono latenza e costi inferiori per i pattern di proxy comuni e authorizer JWT/OIDC nativi; le API WebSocket forniscono canali client-server persistenti con route key ($connect, $disconnect, $default) e richiedono l’API Gateway Management API (PostToConnection) per inviare messaggi. Progetta le integrazioni preferendo AWS_PROXY/Lambda proxy per semplici richieste/risposte (usa aws apigateway put-integration --type AWS_PROXY o per la v2 usa CreateIntegration su ApiGatewayV2Client), e scegli HTTP o VPC Link per backend HTTP privati. Per backend ad alto throughput, usa NLB + VPC Link. Le integrazioni di tipo Mock (put-integration --type MOCK) e i template di risposta dell’integrazione consentono ai team di frontend di iniziare a lavorare senza attendere che il backend sia pronto. Quando si espongono le API tramite CloudFront, usa gli endpoint API regionali come origini e imposta la Origin Protocol Policy su HTTPS-only; le API REST edge-optimized si trovano già dietro CloudFront. Le trappole comuni includono versioni del formato del payload non corrispondenti tra API e Lambda (v1.0 vs 2.0), dimenticare di concedere al principal apigateway.amazonaws.com il permesso di invocare Lambda (aggiungere il permesso con aws lambda add-permission --principal apigateway.amazonaws.com) e configurazioni errate di CORS che bloccano i browser.
Pattern di Sicurezza e Autorizzazione (Cognito, IAM, authorizer personalizzati)
I pattern di sicurezza dovrebbero corrispondere ai tipi di client e ai modelli di accesso: usa i Bacini di utenza di Amazon Cognito o un provider OIDC esterno e collegali come authorizer JWT per le API HTTP (CreateAuthorizer in apigatewayv2 con identitySource impostato su $request.header.Authorization), oppure usa i Cognito Authorizer per API REST per l’accesso degli utenti basato su sessione. Per le API service-to-service o di amministrazione, preferisci l’autorizzazione IAM (SigV4) e policy di risorsa IAM con ambito ristretto su stage e metodi. Gli authorizer Lambda (personalizzati) offrono la massima flessibilità per implementare regole di autenticazione su misura, ma ricorda che aggiungono latenza e possibili punti di fallimento — metti in cache le risposte dell’authorizer con un TTL per ridurre i cold start ed evitare di generare errori che restituiscono un 500 ai client. Proteggiti dagli abusi con i piani di utilizzo e le chiavi API (aws apigateway create-usage-plan e create-api-key) combinati con quote di throttling. Assicurati che i permessi IAM siano corretti: concedi ad API Gateway il permesso di invocare Lambda (aws lambda add-permission) e limita i ruoli di esecuzione di Lambda al principio del privilegio minimo (least privilege). Le sviste comuni per gli sviluppatori includono dimenticare di abilitare l’estrazione del token per gli authorizer JWT, timeout dell’authorizer che impattano la latenza complessiva dell’API e l’inoltro di header/cookie da parte di CloudFront che può inavvertitamente bypassare le cache o causare la fuga di dati utente.
Gestione degli Stage, Versioning, Caching e Deploy Canary
Tratta gli stage come superfici di runtime indipendenti: i deployment sono snapshot (aws apigateway create-deployment o apigatewayv2 create-deployment) e gli stage vengono mappati a tali snapshot. Usa le variabili di stage o, preferibilmente, gli alias di Lambda per instradare il traffico tra le versioni; cambia gli alias in modo atomico (UpdateAlias) o usa le impostazioni canary dello stage di API Gateway per un rilascio graduale. Per le API REST, abilita la cache a livello di stage (aws apigateway update-stage con patch-operations per impostare cacheClusterEnabled e cacheClusterSize) e controlla il TTL e i parametri della chiave di cache nelle impostazioni del metodo; le API HTTP al momento non dispongono di caching integrato, quindi usa CloudFront o cache a livello di applicazione. Invalida la cache durante il deploy o quando i dati sottostanti cambiano; affidarsi esclusivamente al TTL può restituire dati obsoleti (stale data). Pattern di versioning: usa il versioning semantico delle API nel percorso (/v1/…) o affidati a deployment per stage per flussi blue/green. Le trappole comuni includono presumere che le variabili di stage siano sicure (sono visibili agli sviluppatori con accesso alla console), configurare in modo errato le chiavi di cache (dimenticando di includere l’header di autorizzazione o i parametri di query) e non coordinare il deploy delle modifiche allo schema con la compatibilità dei client.
Prestazioni, Osservabilità e Diagnostica
Strumentare le API end-to-end: abilitare i log di esecuzione e i log di accesso su API Gateway e produrre JSON strutturato (variabili $context) verso CloudWatch Logs; abilitare X-Ray su API Gateway e Lambda (impostare tracingEnabled nel deployment/stage o usare l’SDK: PutFunctionConcurrency/UpdateFunctionConfiguration con TracingConfig) per correlare le tracce. Monitorare le metriche di API Gateway (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) e le metriche di Lambda (Duration, Throttles, ConcurrentExecutions) in CloudWatch; utilizzare la metric math per identificare dove si accumula la latenza. Per WebSocket, tracciare il numero di connessioni e i picchi di errori 5XX di API Gateway. I passaggi per la risoluzione dei problemi includono il confronto tra IntegrationLatency e Latency per vedere se il backend o il gateway aggiungono overhead, l’analisi dettagliata dei segmenti di X-Ray per i cold start o le ENI delle VPC e il controllo dei CloudWatch Logs per errori nei template di mappatura. Utilizzare DLQ e destinazioni per i fallimenti asincroni di Lambda e impostare la concorrenza riservata o la concorrenza fornita per le funzioni critiche. Errori comuni degli sviluppatori: registrare PII sensibili nelle tracce (oscurare alla fonte o disabilitare il campionamento di X-Ray per tali flussi), mancanza dei certificati del provider per i domini personalizzati (ACM regionale vs us-east-1 per l’edge) e fare affidamento sul throttling di default dell’account senza piani di utilizzo per le API pubbliche.
Problema Pratico: Scenario d’Uso
Scenario: BrightCart gestisce un frontend di e-commerce regionale su una single-page application ospitata in S3/CloudFront ed espone un’API di checkout tramite API Gateway (API HTTP regionale) che invoca funzioni Lambda in una VPC e scrive gli ordini su DynamoDB. L’ambiente utilizza una pipeline CI/CD che distribuisce le versioni di Lambda su alias di produzione ed espone /checkout su uno stage di produzione.
Sfida: Dopo il rilascio di una nuova funzionalità, la latenza dell’API di produzione è aumentata e alcune richieste di checkout restituiscono errori 502/504 in modo intermittente; gli sviluppatori necessitano di un meccanismo di rollback sicuro e di una diagnostica immediata.
Approccio Raccomandato:
- Creare un rollback del deployment puntando lo stage di produzione dell’API al deployment precedente: usare
aws apigatewayv2 create-deployment --api-id <api> --description "rollback"e poiaws apigatewayv2 update-stage --api-id <api> --stage-name prod --deployment-id <old-deploy-id>. - Spostare il traffico in modo sicuro utilizzando gli alias di Lambda: aggiornare l’alias
proddi Lambda alla versione precedente conaws lambda update-alias --function-name CheckoutFn --name prod --function-version <previous-version>e verificare il comportamento. - Abilitare e raccogliere dati diagnostici: abilitare il tracciamento X-Ray per l’API e Lambda (
aws apigatewayv2 update-stage --tracing-enabled trueeaws lambda update-function-configuration --function-name CheckoutFn --tracing-config Mode=Active) e attivare i log di accesso dettagliati ($context.requestTime,$context.integrationErrorMessage) verso CloudWatch Logs. - Analizzare metriche e tracce: confrontare
IntegrationLatencyeLatencydi API Gateway in CloudWatch, esaminare i segmenti di X-Ray per identificare i cold-start delle ENI della VPC e controllare i throttle di Lambda o le scritture condizionali di DynamoDB; se la latenza delle ENI della VPC è la causa principale, considerare la concorrenza fornita (aws lambda put-provisioned-concurrency-config) o passare a Lambda con ottimizzazioni per gli endpoint VPC.
Motivazione: La ri-distribuzione atomica dello stage e il cambio di alias di Lambda forniscono un rollback rapido e a basso rischio senza modifiche al codice. L’abilitazione di X-Ray e dei log di accesso strutturati consente agli sviluppatori di individuare con precisione se gli errori sono causati da API Gateway, dai cold start di Lambda, dal networking della VPC o dalle chiamate downstream a DynamoDB, guidando verso la mitigazione corretta (concorrenza fornita, aumento del throughput o correzioni di configurazione).
← Serverless e AWS Lambda · Tutti i domini · Amazon DynamoDB e Progettazione NoSQL →
Esercitati su queste domande → · Pratica cronometrata su 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.
Supera l'esame →