Configurando nomes de domínio personalizados para endpoints do Gateway
Por padrão, os endpoints do Gateway são fornecidos com um nome AWS de domínio gerenciado no formato. <gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com Para ambientes de produção ou para criar uma experiência mais fácil de usar, talvez você queira usar um nome de domínio personalizado para o endpoint do gateway. Esta seção orienta você na configuração de um nome de domínio personalizado usando a Amazon CloudFront como proxy reverso.
Pré-requisitos
Antes de começar, verifique se você tem:
-
Um endpoint de gateway em funcionamento
-
Delegação de DNS (se seu domínio do Route 53 precisar ser acessível publicamente)
-
AWS CDK instalado e configurado (se seguir a abordagem CDK)
-
Permissões apropriadas do IAM para criar e gerenciar CloudFront distribuições, zonas hospedadas do Route 53 e certificados ACM
Visão geral da solução
A solução envolve os componentes abaixo:
-
Zona hospedada do Route 53: gerencia registros DNS para seu domínio personalizado
-
Certificado ACM: fornece SSL/TLS criptografia para seu domínio personalizado
-
CloudFront Distribuição: atua como um proxy reverso, encaminhando solicitações do seu domínio personalizado para o endpoint do Gateway
-
Route 53 A Record: mapeia seu domínio personalizado para a CloudFront distribuição
As etapas a seguir guiarão você na configuração desses componentes usando o AWS CDK.
Etapas de implementação
Etapa 1: criar uma zona hospedada do Route 53
Primeiro, crie uma zona hospedada do Route 53 para seu domínio 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 uma política de remoção RETAIN para evitar a exclusão acidental da zona hospedada durante as atualizações ou a exclusão da pilha.
Etapa 2: criar um DNS-validated certificado
Em seguida, crie um SSL/TLS certificado para seu domínio personalizado usando o AWS Certificate Manager (ACM) com validação 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);
A validação de DNS cria automaticamente os registros de validação necessários na sua zona hospedada do Route 53.
Etapa 3: criar uma CloudFront distribuição
Crie uma CloudFront distribuição para atuar como um proxy reverso para seu endpoint do 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
Configure cachePolicy: CachePolicy.CACHING_DISABLED para garantir que CloudFront não armazene em cache as respostas do seu endpoint do Gateway, o que é importante para interações dinâmicas de API.
<mymcpserver>Substitua por seu ID de gateway e <region> por sua AWS região (por exemplo,us-east-1).
Etapa 4: criar um registro do Route 53 A
Crie um registro do Route 53 A que direcione seu domínio personalizado para a CloudFront distribuição:
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 });
Isso cria um registro de alias que mapeia seu domínio personalizado para a CloudFront distribuição.
Etapa 5: implantar sua infraestrutura
Implante sua pilha de CDK para criar os recursos:
cdk deploy
O processo de implantação pode levar algum tempo, especialmente para a validação do certificado e a criação da CloudFront distribuição.
Testando seu domínio personalizado
Depois de implantar sua infraestrutura, verifique se seu domínio personalizado está configurado corretamente:
Verifique a resolução do DNS
Use o dig comando para verificar se seu domínio personalizado está resolvido para a CloudFront distribuição:
dig my.example.com
A saída deve mostrar que seu domínio resolve para CloudFront endereços IP.
Verifique o certificado SSL
Use curl para verificar se o certificado SSL está configurado corretamente:
curl -v https://my.example.com
A saída deve mostrar um handshake SSL bem-sucedido sem erros de certificado.
Configurando clientes MCP
Depois que seu domínio personalizado for configurado e verificado, você poderá configurar seus clientes MCP para usá-lo:
Configuração do cursor
Para Cursor, atualize seu arquivo de configuração:
{ "mcpServers": { "my-mcp-server": { "url": "https://my.example.com" } } }
Outros clientes MCP
Para clientes MCP que não oferecem suporte nativo a HTTP simplificável:
{ "mcpServers": { "my-mcp-server": { "command": "/path/to/uvx", "args": [ "mcp-proxy", "--transport", "streamablehttp", "https://my.example.com" ] } } }
Considerações adicionais
- Implicações de custo
-
O uso CloudFront como proxy reverso gera custos adicionais para transferência de dados e tratamento de solicitações. Analise o modelo de CloudFront preços para entender as implicações de custo para seu caso de uso específico.
- Considerações de segurança
-
Considere a implementação de medidas de segurança adicionais, como:
-
Regras do WAF para proteger seu endpoint contra explorações comuns na web
-
Geo-restrictions para limitar o acesso a regiões geográficas específicas
-
Cabeçalhos personalizados ou assinatura de solicitações para adicionar uma camada extra de autenticação
-
- Monitoramento e registro
-
Ative os registros de CloudFront acesso e configure CloudWatch alarmes para monitorar a integridade e o desempenho da configuração de seu domínio personalizado.
- Renovação do certificado
-
Os certificados ACM emitidos por meio da validação de DNS são renovados automaticamente, desde que os registros DNS permaneçam no local. Certifique-se de não excluir os registros de validação.
- Endpoint de recursos protegidos por OAuth com domínios personalizados
-
Por padrão, o
/.well-known/oauth-protected-resourceendpoint retorna uma URL de recurso que contém o domínio do gateway em vez do seu domínio personalizado. Isso pode fazer com que os clientes OAuth falhem na autenticação ao usar domínios personalizados.Para resolver esse problema, você pode implementar uma função Lambda @Edge que intercepta a resposta de descoberta do OAuth e gera uma nova resposta com a URL de domínio personalizada correta. Aqui está a abordagem:
-
Use o Lambda @Edge com o tipo de evento ORIGIN_RESPONSE: crie uma função que seja acionada nas respostas de origem para interceptar a resposta do endpoint do recurso protegido por OAuth.
-
Gere uma nova resposta: o Lambda @Edge não consegue ler os corpos das respostas de origem. Portanto, em vez de modificar a resposta existente, gere uma resposta JSON completamente nova com o domínio personalizado.
-
Associar ao CloudFront comportamento: configure a função Lambda @Edge para acionar especificamente para o padrão do
/.well-known/oauth-protected-resourcecaminho.Depois de implementar essa solução, o endpoint de recursos protegidos por OAuth retornará o domínio personalizado correto:
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
Embora o Lambda @Edge forneça uma solução para esse problema, a implementação de domínios personalizados para o AgentCore Gateway sem suporte integrado exige complexidade adicional que pode não ser ideal para todos os clientes. Considere essa abordagem como uma solução alternativa até que o suporte nativo para descoberta de OAuth com domínios personalizados esteja disponível.
-
Solução de problemas
- Problemas de resolução de DNS
-
Se seu domínio personalizado não for resolvido corretamente:
-
Verifique se o registro A está configurado corretamente na sua zona hospedada do Route 53
-
Verifique se os servidores de nomes do seu domínio estão configurados corretamente no registrador do seu domínio
-
Aguarde tempo para a propagação do DNS (até 48 horas em alguns casos)
-
- Problemas com o certificado SSL
-
Se você encontrar erros no certificado SSL:
-
Verifique se o certificado foi emitido e está ativo no console do ACM
-
Verifique se o certificado está associado corretamente à sua CloudFront distribuição
-
Certifique-se de que o certificado cubra o nome de domínio exato que você está usando
-
- Problemas de conectividade do gateway
-
Se seu domínio personalizado não se conectar ao seu gateway:
-
Verifique se o domínio e o caminho de origem em sua CloudFront distribuição estão corretos
-
Verifique se o endpoint do gateway está acessível diretamente
-
Revise os registros de CloudFront distribuição em busca de erros
-
Conclusão
A configuração de um nome de domínio personalizado para seu endpoint do Gateway aprimora a aparência profissional do seu aplicativo e fornece flexibilidade no gerenciamento de seus endpoints de API. Seguindo as etapas descritas neste guia, você pode criar uma configuração de domínio personalizada segura e confiável usando CloudFront como proxy reverso.
Para obter mais informações sobre os recursos e capacidades do Gateway, consulte Amazon Bedrock AgentCore Gateway: conecte ferramentas e outros recursos com segurança ao seu Gateway.