Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
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 il tuo 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 di 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 proxy inverso, inoltrando le richieste dal dominio personalizzato all'endpoint Gateway
-
Route 53 A Record: associa il tuo dominio personalizzato alla distribuzione CloudFront
I passaggi seguenti ti guideranno nella configurazione di questi componenti tramite AWS CDK.
Passaggi dell’implementazione
Fase 1: Creare una zona ospitata su Route 53
Innanzitutto, crea una zona ospitata su 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 RETAIN per prevenire l'eliminazione accidentale della zona ospitata durante gli aggiornamenti o l'eliminazione dello stack.
Fase 2: Creare un certificato DNS-validated
Quindi, 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 di Route 53.
Fase 3: Creare una distribuzione CloudFront
Crea una CloudFront distribuzione che funga da proxy inverso 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 esempious-east-1).
Fase 4: Creare un record Route 53 A
Crea un record Route 53 A che indirizzi 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 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 del certificato e la creazione della distribuzione. CloudFront
Testare il dominio personalizzato
Dopo aver implementato 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 si risolva nella distribuzione: CloudFront
dig my.example.com
L'output dovrebbe mostrare che il tuo dominio si risolve nei suoi indirizzi IP. CloudFront
Verifica il certificato SSL
Utilizzalo 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 l'HTTP in streaming:
{ "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. Rivedi il modello CloudFront di 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 il tuo endpoint dai comuni exploit web
-
Geo-restrictions per limitare l'accesso a specifiche aree geografiche
-
Intestazioni personalizzate o richiedi la firma per aggiungere un ulteriore livello di autenticazione
-
- Monitoraggio e registrazione
-
Abilita i log 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 finché i record DNS rimangono al loro posto. 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ò causare il fallimento dell'autenticazione dei client OAuth 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 di 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 da OAuth.
-
Genera una nuova risposta: Lambda @Edge non è in grado di leggere i corpi delle risposte 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 percorso.
/.well-known/oauth-protected-resourceDopo aver implementato questa soluzione, l'endpoint delle risorse protette da 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 di Route 53
-
Verifica che i name server del tuo dominio siano impostati correttamente presso il tuo registrar di domini
-
Attendi del tempo per la propagazione del DNS (fino a 48 ore in alcuni casi)
-
- Problemi con i certificati SSL
-
Se riscontri errori nel certificato 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 includa l'esatto 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 CloudFront distribuzione siano corretti
-
Verifica che l'endpoint del gateway sia accessibile direttamente
-
Esamina i registri di CloudFront distribuzione per eventuali errori
-
Conclusioni
L'impostazione 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, puoi creare una configurazione di dominio personalizzata sicura e affidabile utilizzando CloudFront un proxy inverso.
Per ulteriori informazioni sulle caratteristiche e le funzionalità di Gateway, consulta Amazon Bedrock AgentCore Gateway: Connetti in modo sicuro strumenti e altre risorse al tuo Gateway.