View a markdown version of this page

Configuración de nombres de dominio personalizados para los puntos finales de Gateway - Amazon Bedrock AgentCore

Configuración de nombres de dominio personalizados para los puntos finales de Gateway

De forma predeterminada, los puntos de enlace de Gateway se proporcionan con un nombre de dominio AWS administrado en este formato. <gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com Para los entornos de producción o para crear una experiencia más fácil de usar, es posible que desee utilizar un nombre de dominio personalizado para el punto de enlace de su puerta de enlace. Esta sección lo guía a través de la configuración de un nombre de dominio personalizado utilizando Amazon CloudFront como proxy inverso.

Requisitos previos

Antes de comenzar, asegúrese de que dispone de lo siguiente:

  • Un punto final de Gateway que funcione

  • Delegación de DNS (si su dominio de Route 53 debe ser accesible públicamente)

  • AWS CDK instalado y configurado (si sigue el enfoque de CDK)

  • Permisos de IAM adecuados para crear y administrar CloudFront distribuciones, zonas alojadas de Route 53 y certificados ACM

Información general de la solución

La solución implica los siguientes componentes:

  • Route 53 Hosted Zone: administra los registros de DNS de su dominio personalizado

  • Certificado ACM: proporciona SSL/TLS cifrado para su dominio personalizado

  • CloudFront Distribución: actúa como un proxy inverso y reenvía las solicitudes de su dominio personalizado al punto final de Gateway

  • Route 53 A Record: asigna tu dominio personalizado a la CloudFront distribución

Los siguientes pasos le guiarán en la configuración de estos componentes mediante AWS CDK.

Pasos para la implementación

Paso 1: Crear una zona alojada en Route 53

En primer lugar, cree una zona alojada de Route 53 para su dominio personalizado:

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

Aplicamos una política de eliminación RETAIN para evitar la eliminación accidental de la zona alojada durante la eliminación o actualización de la pila.

Paso 2: Crea un DNS-validated certificado

A continuación, cree un SSL/TLS certificado para su dominio personalizado mediante AWS Certificate Manager (ACM) con validación de 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 validación de DNS crea automáticamente los registros de validación necesarios en la zona alojada de Route 53.

Paso 3: Crear una CloudFront distribución

Cree una CloudFront distribución que actúe como proxy inverso para su punto final de 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

Configúrelo cachePolicy: CachePolicy.CACHING_DISABLED para garantizar que CloudFront no almacene en caché las respuestas de su punto final de Gateway, lo cual es importante para las interacciones dinámicas de la API.

<mymcpserver>Sustitúyalo por el ID de tu puerta <region> de enlace y por tu AWS región (p. ej.,us-east-1).

Paso 4: Crear un registro de Route 53 A

Cree un registro de Route 53 A que dirija su dominio personalizado a la CloudFront distribución:

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 });

Esto crea un registro de alias que asigna tu dominio personalizado a la CloudFront distribución.

Paso 5: Implemente su infraestructura

Implemente su pila de CDK para crear los recursos:

cdk deploy

El proceso de implementación puede llevar algún tiempo, especialmente para la validación del certificado y la creación de la CloudFront distribución.

Probar tu dominio personalizado

Tras implementar la infraestructura, compruebe que el dominio personalizado esté configurado correctamente:

Verifica la resolución del DNS

Usa el dig comando para comprobar que tu dominio personalizado se resuelve en la CloudFront distribución:

dig my.example.com

El resultado debería mostrar que tu dominio se resuelve en las direcciones IP. CloudFront

Verifica el certificado SSL

curlÚselo para comprobar que el certificado SSL está configurado correctamente:

curl -v https://my.example.com

El resultado debería mostrar un protocolo de enlace SSL correcto sin errores de certificado.

Configuración de clientes MCP

Una vez que haya configurado y verificado su dominio personalizado, puede configurar sus clientes MCP para que lo usen:

Configuración del cursor

Para Cursor, actualice el archivo de configuración:

{ "mcpServers": { "my-mcp-server": { "url": "https://my.example.com" } } }

Otros clientes MCP

Para los clientes MCP que no admiten HTTP transmisible de forma nativa:

{ "mcpServers": { "my-mcp-server": { "command": "/path/to/uvx", "args": [ "mcp-proxy", "--transport", "streamablehttp", "https://my.example.com" ] } } }

Consideraciones adicionales

Implicaciones de costos

Su uso CloudFront como proxy inverso conlleva costes adicionales en cuanto a la transferencia de datos y la gestión de las solicitudes. Revise el modelo CloudFront de precios para comprender las implicaciones de costo para su caso de uso específico.

Consideraciones de seguridad

Considere la posibilidad de implementar medidas de seguridad adicionales, tales como:

  • Reglas de WAF para proteger su terminal de los ataques web más comunes

  • Geo-restrictions para limitar el acceso a regiones geográficas específicas

  • Personalice los encabezados o solicite la firma para añadir una capa adicional de autenticación

Monitoreo y registro

Habilite los registros de CloudFront acceso y configure CloudWatch las alarmas para supervisar el estado y el rendimiento de la configuración de su dominio personalizado.

Renovación de certificados

Los certificados ACM emitidos mediante la validación del DNS se renuevan automáticamente mientras los registros DNS permanezcan en su lugar. Asegúrese de no eliminar los registros de validación.

Punto final de recursos protegido por OAuth con dominios personalizados

De forma predeterminada, el /.well-known/oauth-protected-resource punto final devuelve una URL de recurso que contiene el dominio de la puerta de enlace en lugar del dominio personalizado. Esto puede provocar que los clientes de OAuth no se autentiquen al usar dominios personalizados.

Para resolver este problema, puedes implementar una función Lambda @Edge que intercepte la respuesta de detección de OAuth y genere una nueva respuesta con la URL de dominio personalizada correcta. Este es el enfoque:

  • Utilice Lambda @Edge con el tipo de evento ORIGIN_RESPONSE: cree una función que se active en las respuestas de origen para interceptar la respuesta del punto final del recurso protegido por OAuth.

  • Generar una nueva respuesta: Lambda @Edge no puede leer los cuerpos de respuesta de origen, por lo que, en lugar de modificar la respuesta existente, genere una respuesta JSON completamente nueva con el dominio personalizado.

  • Asociar con el CloudFront comportamiento: configure la función Lambda @Edge para que se active específicamente para el patrón de /.well-known/oauth-protected-resource ruta.

    Tras implementar esta solución, el punto final del recurso protegido por OAuth devolverá el dominio personalizado correcto:

    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

    Si bien Lambda @Edge ofrece una solución para este problema, la implementación de dominios personalizados para AgentCore Gateway sin soporte integrado requiere una complejidad adicional que puede no ser óptima para todos los clientes. Considere este enfoque como una solución alternativa hasta que esté disponible el soporte nativo para la detección de OAuth con dominios personalizados.

Resolución de problemas

Problemas de resolución de DNS

Si tu dominio personalizado no se resuelve correctamente:

  • Compruebe que el registro A esté configurado correctamente en la zona alojada de Route 53

  • Compruebe que los servidores de nombres de su dominio estén configurados correctamente en su registrador de dominios

  • Deja pasar un tiempo para que el DNS se propague (hasta 48 horas en algunos casos)

Problemas con el certificado SSL

Si encuentra errores en el certificado SSL:

  • Compruebe que el certificado esté emitido y activo en la consola ACM

  • Compruebe que el certificado esté correctamente asociado a su distribución CloudFront

  • Asegúrese de que el certificado cubra el nombre de dominio exacto que está utilizando

Problemas de conectividad con la pasarela

Si tu dominio personalizado no se conecta a tu puerta de enlace:

  • Comprueba que el dominio y la ruta de origen de tu CloudFront distribución sean correctos

  • Compruebe que se pueda acceder directamente al punto final de la puerta de enlace

  • Revise los registros CloudFront de distribución para ver si hay algún error

Conclusión

La configuración de un nombre de dominio personalizado para el punto de conexión de Gateway mejora el aspecto profesional de la aplicación y proporciona flexibilidad a la hora de gestionar los puntos de enlace de la API. Si sigue los pasos descritos en esta guía, puede crear una configuración de dominio personalizada segura y fiable utilizando CloudFront un proxy inverso.

Para obtener más información sobre las funciones y capacidades de Gateway, consulte Amazon Bedrock AgentCore Gateway: conecte herramientas y otros recursos de forma segura a su puerta de enlace.