Configurazione di nomi di dominio personalizzati per gli endpoint Gateway
Per impostazione predefinita, agli endpoint Gateway viene fornito un nome AWS di dominio gestito nel formato. <gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com Per gli ambienti di produzione o per creare un'esperienza più intuitiva, potresti voler utilizzare un nome di dominio personalizzato per l'endpoint gateway. Questa sezione ti guida nella configurazione di un nome di dominio personalizzato utilizzando Amazon CloudFront come proxy inverso.
Prerequisiti
Prima di iniziare, assicurati di disporre dei seguenti elementi:
-
Un endpoint Gateway funzionante
-
Delega DNS (se il dominio Route 53 deve essere raggiungibile pubblicamente)
-
AWS CDK installato e configurato (se si segue l'approccio CDK)
-
Autorizzazioni IAM appropriate per creare e gestire CloudFront distribuzioni, zone ospitate da Route 53 e certificati ACM
Panoramica della soluzione
La soluzione prevede i seguenti componenti:
-
Route 53 Hosted Zone: gestisce i record DNS per il tuo dominio personalizzato
-
Certificato ACM: fornisce la SSL/TLS crittografia per il tuo dominio personalizzato
-
CloudFront Distribuzione: funge da reverse proxy, inoltrando le richieste dal dominio personalizzato all'endpoint Gateway
-
Route 53 A Record: associa il tuo dominio personalizzato alla CloudFront distribuzione
I seguenti passaggi ti guideranno nella configurazione di questi componenti utilizzando AWS CDK.
Passaggi dell’implementazione
Fase 1: Creare una zona ospitata sulla Route 53
Innanzitutto, crea una zona ospitata Route 53 per il tuo dominio personalizzato:
import { RemovalPolicy } from 'aws-cdk-lib'; import { PublicHostedZone } from 'aws-cdk-lib/aws-route53'; const domainName = 'my.example.com'; const hostedZone = new PublicHostedZone(this, 'HostedZone', { zoneName: domainName, }); this.hostedZone.applyRemovalPolicy(RemovalPolicy.RETAIN);
Nota
Applichiamo una politica di rimozione volta RETAIN a prevenire l'eliminazione accidentale della zona ospitata durante gli aggiornamenti o l'eliminazione dello stack.
Fase 2: Creare un certificato DNS-validated
Successivamente, crea un SSL/TLS certificato per il tuo dominio personalizzato utilizzando AWS Certificate Manager (ACM) con convalida DNS:
import { RemovalPolicy } from 'aws-cdk-lib'; import { Certificate, CertificateValidation } from 'aws-cdk-lib/aws-certificatemanager'; const certificate = new Certificate(this, 'SSLCertificate', { domainName: domainName, // route53 hosted zone domain name from step 1 validation: CertificateValidation.fromDns(hostedZone), // route53 hosted zone from step 1 }); this.certificate.applyRemovalPolicy(RemovalPolicy.RETAIN);
La convalida DNS crea automaticamente i record di convalida necessari nella zona ospitata da Route 53.
Fase 3: Creare una distribuzione CloudFront
Crea una CloudFront distribuzione che funga da reverse proxy per il tuo endpoint Gateway:
import { AllowedMethods, CachePolicy, Distribution, OriginProtocolPolicy, ViewerProtocolPolicy } from 'aws-cdk-lib/aws-cloudfront'; import { HttpOrigin } from 'aws-cdk-lib/aws-cloudfront-origins'; const bedrockAgentCoreGatewayHostName = '<mymcpserver>.gateway.bedrock-agentcore.<region>.amazonaws.com' const bedrockAgentCoreGatewayPath = '/mcp' // can also be left undefined, depending on your requirement const distribution = new Distribution(this, 'Distribution', { defaultBehavior: { origin: new HttpOrigin(bedrockAgentCoreGatewayHostName, { protocolPolicy: OriginProtocolPolicy.HTTPS_ONLY, originPath: bedrockAgentCoreGatewayPath, }), viewerProtocolPolicy: ViewerProtocolPolicy.HTTPS_ONLY, cachePolicy: CachePolicy.CACHING_DISABLED, // important since caching is enabled by default and hence is not suitable for a reverse proxy allowedMethods: AllowedMethods.ALLOW_ALL, }, domainNames: [domainName], // route53 hosted zone domain name from step 1 certificate: certificate, // ssl certificate for the route53 domain from step 2 });
Importante
Imposta cachePolicy: CachePolicy.CACHING_DISABLED per garantire che CloudFront non memorizzi nella cache le risposte dall'endpoint Gateway, il che è importante per le interazioni dinamiche con le API.
Sostituiscilo <mymcpserver> con il tuo ID gateway e <region> con la tua AWS regione (ad es.us-east-1).
Fase 4: Creare un record Route 53 A
Crea un record Route 53 A che indirizza il tuo dominio personalizzato alla CloudFront distribuzione:
import { ARecord, RecordTarget } from 'aws-cdk-lib/aws-route53'; import { CloudFrontTarget } from 'aws-cdk-lib/aws-route53-targets'; const aRecord = new ARecord(this, 'AliasRecord', { zone: hostedZone, // route53 hosted zone from step 1 recordName: domainName, // route53 hosted zone domain name from step 1 target: RecordTarget.fromAlias(new CloudFrontTarget(distribution)), // cloudfront distribution from step 3 });
Questo crea un record di alias che associa il tuo dominio personalizzato alla CloudFront distribuzione.
Fase 5: Implementa la tua infrastruttura
Implementa il tuo stack CDK per creare le risorse:
cdk deploy
Il processo di distribuzione potrebbe richiedere del tempo, in particolare per la convalida dei certificati e la creazione della distribuzione. CloudFront
Verifica del tuo dominio personalizzato
Dopo aver distribuito l'infrastruttura, verifica che il dominio personalizzato sia configurato correttamente:
Verifica la risoluzione DNS
Usa il dig comando per verificare che il tuo dominio personalizzato corrisponda alla distribuzione: CloudFront
dig my.example.com
L'output dovrebbe mostrare che il tuo dominio si risolve negli indirizzi IP. CloudFront
Verifica il certificato SSL
Utilizza curl per verificare che il certificato SSL sia configurato correttamente:
curl -v https://my.example.com
L'output dovrebbe mostrare un handshake SSL riuscito senza errori di certificato.
Configurazione dei client MCP
Una volta impostato e verificato il dominio personalizzato, puoi configurare i tuoi client MCP per utilizzarlo:
Configurazione del cursore
Per Cursor, aggiorna il file di configurazione:
{ "mcpServers": { "my-mcp-server": { "url": "https://my.example.com" } } }
Altri client MCP
Per i client MCP che non supportano nativamente lo streaming HTTP:
{ "mcpServers": { "my-mcp-server": { "command": "/path/to/uvx", "args": [ "mcp-proxy", "--transport", "streamablehttp", "https://my.example.com" ] } } }
Ulteriori considerazioni
- Implicazioni sui costi
-
L'utilizzo CloudFront come proxy inverso comporta costi aggiuntivi per il trasferimento dei dati e la gestione delle richieste. Esamina il modello di CloudFront prezzo per comprendere le implicazioni in termini di costi per il tuo caso d'uso specifico.
- Considerazioni sulla sicurezza
-
Prendi in considerazione l'implementazione di misure di sicurezza aggiuntive come:
-
Regole WAF per proteggere gli endpoint dagli exploit web più comuni
-
Geo-restrictions per limitare l'accesso a aree geografiche specifiche
-
Intestazioni personalizzate o firma delle richieste per aggiungere un ulteriore livello di autenticazione
-
- Monitoraggio e registrazione
-
Abilita i registri di CloudFront accesso e configura gli CloudWatch allarmi per monitorare lo stato e le prestazioni della configurazione personalizzata del dominio.
- Rinnovo del certificato
-
I certificati ACM emessi tramite la convalida DNS vengono rinnovati automaticamente fintanto che i record DNS rimangono validi. Assicurati di non eliminare i record di convalida.
- Endpoint di risorse protetto da OAuth con domini personalizzati
-
Per impostazione predefinita, l'
/.well-known/oauth-protected-resourceendpoint restituisce un URL di risorsa che contiene il dominio gateway anziché il dominio personalizzato. Ciò può far sì che i client OAuth non riescano a eseguire l'autenticazione quando utilizzano domini personalizzati.Per risolvere questo problema, puoi implementare una funzione Lambda @Edge che intercetta la risposta di rilevamento OAuth e genera una nuova risposta con l'URL del dominio personalizzato corretto. Ecco l'approccio:
-
Usa Lambda @Edge con il tipo di evento ORIGIN_RESPONSE: crea una funzione che si attiva sulle risposte di origine per intercettare la risposta dell'endpoint della risorsa protetta OAuth.
-
Genera una nuova risposta: Lambda @Edge non è in grado di leggere i corpi di risposta di origine, quindi invece di modificare la risposta esistente, genera una risposta JSON completamente nuova con il dominio personalizzato.
-
Associa al CloudFront comportamento: configura la funzione Lambda @Edge in modo che si attivi specificamente per il modello di
/.well-known/oauth-protected-resourcepercorso.Dopo aver implementato questa soluzione, l'endpoint di risorse protette OAuth restituirà il dominio personalizzato corretto:
curl https://my-custom-domain.com/.well-known/oauth-protected-resource { "authorization_servers": ["https://my-org.okta.com/oauth2/default"], "resource": "https://my-custom-domain.com/mcp" }Nota
Sebbene Lambda @Edge fornisca una soluzione a questo problema, l'implementazione di domini personalizzati per AgentCore Gateway senza supporto integrato richiede una complessità aggiuntiva che potrebbe non essere ottimale per tutti i clienti. Considerate questo approccio come una soluzione alternativa fino a quando non sarà disponibile il supporto nativo per l'individuazione di OAuth con domini personalizzati.
-
Risoluzione dei problemi
- Problemi di risoluzione DNS
-
Se il tuo dominio personalizzato non si risolve correttamente:
-
Verifica che il record A sia configurato correttamente nella tua zona ospitata da Route 53
-
Verifica che i name server del tuo dominio siano impostati correttamente presso il registrar del dominio
-
Attendi il tempo necessario per la propagazione del DNS (fino a 48 ore in alcuni casi)
-
- Problemi relativi ai certificati SSL
-
Se riscontri errori nei certificati SSL:
-
Verifica che il certificato sia emesso e attivo nella console ACM
-
Verifica che il certificato sia associato correttamente alla tua distribuzione CloudFront
-
Assicurati che il certificato copra esattamente il nome di dominio che stai utilizzando
-
- Problemi di connettività del gateway
-
Se il dominio personalizzato non si connette al gateway:
-
Verifica che il dominio e il percorso di origine nella tua CloudFront distribuzione siano corretti
-
Verifica che l'endpoint del gateway sia accessibile direttamente
-
Esamina i log di CloudFront distribuzione per eventuali errori
-
Conclusioni
La configurazione di un nome di dominio personalizzato per l'endpoint Gateway migliora l'aspetto professionale dell'applicazione e offre flessibilità nella gestione degli endpoint API. Seguendo i passaggi descritti in questa guida, è possibile creare una configurazione di dominio personalizzata sicura e affidabile utilizzando CloudFront come proxy inverso.
Per ulteriori informazioni sulle caratteristiche e funzionalità del gateway, consulta Amazon Bedrock AgentCore Gateway: collega in modo sicuro strumenti e altre risorse al tuo gateway.