Proteggere Amazon Bedrock AgentCore Runtime con AWS WAF: due pattern di architettura

Quando si espongono agenti di AI generativa costruiti con Amazon Bedrock AgentCore come endpoint API di produzione, spesso serve applicare policy di web application firewall, rate limiting, protezione dalle minacce web comuni e controlli di audit tramite AWS WAF. Il problema è che AWS WAF si integra con Application Load Balancer (ALB), CloudFront e API Gateway: CloudFront è pensato per il caching (inutile per invocazioni real-time e dinamiche), API Gateway aggiunge un proprio layer di autenticazione che crea un problema di doppia autenticazione con SigV4/OAuth di AgentCore. Resta quindi un ALB internet-facing come punto di integrazione, che instrada verso AgentCore tramite un VPC Interface Endpoint sul data plane (com.amazonaws.<region>.bedrock-agentcore).

Il nodo degli health check

Qui emerge la sfida: gli ALB richiedono health check per verificare i target, ma AgentCore Runtime richiede autenticazione (SigV4 o OAuth) su ogni chiamata, health check inclusi. Gli health check standard dell’ALB inviano richieste non autenticate e falliscono. Il post presenta due pattern testati end-to-end con SigV4 e OAuth (JWT Cognito).

Due pattern

Nel Pattern 1, una funzione Lambda fa da proxy tra l’ALB e il VPC Endpoint: offre pieno controllo su trasformazione delle richieste, logging custom e traduzione tra metodi di autenticazione. Per OAuth passa l’header Authorization invariato; per SigV4 deve ri-firmare la richiesta con le credenziali del proprio execution role, perché la firma è legata all’host originale. Costo: circa 50-200 ms di latenza aggiuntiva per richiesta (cold start Lambda) più il costo di invocazione.

Nel Pattern 2, l’ALB punta direttamente agli indirizzi IP delle ENI del VPC Endpoint sulla porta HTTPS 443, senza Lambda. La chiave è un target group di tipo IP con un health check sul path / e matcher HttpCode 200-499: AgentCore risponde 404 su / (non è un path API valido) ma l’ALB accetta l’intervallo 200-499 come healthy, verificando così che il VPC Endpoint risponda senza bisogno di autenticazione. L’ALB passa l’header Authorization in modo trasparente, sia per SigV4 sia per OAuth. Latenza minima, nessun costo di compute aggiuntivo, ma nessuna capacità di trasformazione delle richieste.

Entrambi i pattern richiedono una resource policy per chiudere la backdoor di accesso diretto: senza, chi ha credenziali valide può chiamare l’endpoint pubblico di AgentCore bypassando AWS WAF. La policy consente InvokeAgentRuntime solo dal VPC Endpoint specifico (condizione aws:SourceVpce) e nega le richieste che non ne provengono, con aws:ViaAWSService a false per non bloccare le chiamate interne del servizio. Il risultato è una difesa in profondità su più livelli: AWS WAF, security group dell’ALB, security group del VPC Endpoint, autenticazione AgentCore, resource policy e VPC Endpoint policy opzionale.

• Un ALB internet-facing con AWS WAF che instrada verso un VPC Endpoint è il modo pratico per mettere un WAF davanti ad AgentCore Runtime.
• Il Pattern 2 (ALB diretto al VPC Endpoint) ha meno componenti e minore latenza; il Pattern 1 (proxy Lambda) aggiunge flessibilità quando servono trasformazione delle richieste o traduzione tra metodi di autenticazione.
• Una resource policy basata su aws:SourceVpce è necessaria in entrambi i pattern per impedire l’accesso diretto che bypassa AWS WAF.

Fonte: Securing Amazon Bedrock AgentCore Runtime with AWS WAF — https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-agentcore-runtime-with-aws-waf/