Arquitetura geral | Rotas DNS e HTTPS | AWS Direct Connect | Route 53 Resolver | Private API Gateway | Segurança e diagnóstico
É importante notar aqui: esta não é uma “cadeia de proxy em série” pela qual todo o tráfego passa em sequência.
Na verdade, está dividido em dois processos independentes:
- Caminho de resolução DNS : Responsável pela resolução do nome de domínio privado no IP privado do VPC Endpoint.
- Caminho de acesso HTTPS : depois de o cliente obter o IP privado, acede diretamente ao Interface VPC Endpoint através do Direct Connect e, em seguida, transfere-o para o Private API Gateway através do AWS PrivateLink.
2. Estrutura geral
Os exemplos seguintes utilizam a região de Tóquio, ap-northeast-1.
rede externa da empresa
172.20.0.0/16
│
├─Cliente empresarial
│ curl / Java / Postman / Sistema empresarial
│
├─ DNS externo da empresa
│ Encaminhamento condicional:
│ api.partner.example.com
│ ↓
│ 10.20.10.10
│ 10.20.20.10
│
└─ Router corporativo externo
BGP
│
│ AWS Direct Connect
▼
Direct Connect Location
│
▼
Direct Connect Gateway
│
├─ Private VIF → VGW
│ ou
└─ Transit VIF → Transit Gateway
│
▼
AWS VPC
10.20.0.0/16
│
┌──────────────┴──────────────┐
│ │
▼ ▼
Route 53 Resolver Interface VPC Endpoint
Inbound Endpoint com.amazonaws.ap-northeast-1.execute-api
UDP/TCP 53 TCP 443
10.20.10.10 10.20.11.x
10.20.20.10 10.20.21.x
│ │
▼ │
Route 53 Private Hosted Zone │
partner.example.com │
│ │
api.partner.example.com │
Alias → VPC Endpoint ─────────────┘
│
▼
API Gateway Private Domain
│
Domain Access Association
│
▼
API Mapping / Base Path
│
▼
Private REST API Gateway
│
▼
Lambda / AWS Service / VPC Link
O Route 53 Resolver Inbound Endpoint recebe pedidos de DNS da rede local, enquanto a Private Hosted Zone guarda os registos de nomes de domínio privados; Interface VPC Endpoint é o ponto de entrada real para os fluxos de dados HTTPS no API Gateway.
3.º Como flui uma solicitação completa?
Suponha que um sistema externo da empresa solicita:
https://api.partner.example.com/v1/orders
1. Processo de resolução de DNS
O cliente solicita primeiro à empresa externa o seu DNS interno:
Qual é o IP de api.partner.example.com?
Encaminhamento condicional configurado no DNS empresarial externo:
partner.example.com
→ 10.20.10.10
→ 10.20.20.10
Estes dois IPs são os IPs de endpoint de entrada do Route 53 Resolver na AWS VPC.
A solicitação de DNS vai:
DNS externo da empresa
→ Direct Connect
→ Transit Gateway/VGW
→ Resolver Inbound Endpoint
→ Route 53 VPC Resolver
→ Private Hosted Zone
Existe na zona alojada privada:
api.partner.example.com
A Alias
→ vpce-xxxxxxxx.execute-api.ap-northeast-1.vpce.amazonaws.com
O que é finalmente devolvido não é o IP público do API Gateway, mas sim o IP privado da Interface VPC Endpoint ENI, por exemplo:
10.20.11.45
10.20.21.82
O IP do endpoint de entrada é um IP privado da VPC, pelo que a rede local deve ser encaminhada para a VPC através do Direct Connect ou VPN. A AWS exige que cada endpoint do Resolver seja configurado com pelo menos dois IPs e é recomendado colocá-los em zonas de disponibilidade diferentes.
2. Processo de acesso HTTPS
Após o término do DNS, o cliente estabelece o TCP 443 para o IP privado do VPC Endpoint resolvido:
cliente
→ Direct Connect
→ TGW/VGW
→ VPC Endpoint ENI:443
→ AWS PrivateLink
→ API Gateway Private Custom Domain
→ API Mapping
→ Private REST API
Aqui, o Route 53 Resolver não participa no encaminhamento HTTPS de . É apenas responsável pela resolução DNS anterior.
O API Gateway privado só pode ser acedido através do VPC Endpoint de interface do API Gateway, e a política de recursos da API também deve permitir o VPC ou o VPC Endpoint especificado.
4.º Por que razão existe cada serviço?
1. AWS Direct Connect
função
O Direct Connect fornece uma ligação de linha privada entre a rede empresarial externa e a AWS.
É principalmente responsável por:
- Encaminhar o segmento de rede privada de uma empresa externa para uma AWS VPC.
- Liberte o segmento de rede AWS VPC para empresas externas.
- Aloja solicitações de DNS.
- Hospeda pedidos de API HTTPS.
- Evite o tráfego comercial que passa pela Internet pública.
- Fornece largura de banda e latência relativamente estáveis.
Pelo que a Direct Connect não é responsável
A Direct Connect em si não é responsável por:
- Resolução DNS.
- Autenticação API.
- Autorização API.
- Certificado TLS.
- Encaminhamento do API Gateway.
- Encripte automaticamente todos os links.
O Direct Connect é um “circuito privado”, mas não pode ser simplesmente equiparado a um “circuito encriptado de ponta a ponta”. Quando for necessária a encriptação de ligação, considere o MACsec quando houver suporte ou sobreponha VPN/IPsec site a site no Direct Connect. O modo must_encrypt do MACsec interrompe a transmissão se a encriptação não puder ser estabelecida; should_encrypt pode recorrer à comunicação não encriptada em caso de falha.
2. Route 53 Resolver Inbound Endpoint
função
Permita que os próprios servidores DNS de empresas externas consultem o DNS na AWS VPC.
Sem ele, o DNS local da empresa externa não pode ser consultado diretamente:
- Route 53 Private Hosted Zone。
- Nome DNS privado interno da VPC.
- Registos privados relacionados com o VPC Endpoint.
Após a criação do Inbound Endpoint, será criada uma ENI na sub-rede especificada e será atribuído um IP privado fixo. O DNS da empresa externa encaminha os pedidos de nomes de domínio correspondentes para estes IPs.
Porque é que não posso perguntar diretamente ao DNS VPC+2 da VPC?
Os endereços DNS comuns na VPC são semelhantes:
VPC CIDR：10.20.0.0/16
VPC Resolver：10.20.0.2
Mas a rede externa não deve utilizar o 10.20.0.2 directamente como um servidor DNS normal. O ponto de entrada padrão para redes híbridas é o Resolver Inbound Endpoint.
3. Route 53 Private Hosted Zone
função
Guarde os nomes de domínio privados e os registos correspondentes, por exemplo:
Private Hosted Zone:
partner.example.com
Record:
api.partner.example.com
A Alias
→ execute-api Interface VPC Endpoint
A zona alojada privada só entra em vigor para a VPC associada e consultas inseridas através do endpoint de entrada do resolvedor correspondente. Não há necessidade de expor o endereço API real ao DNS público.
4. Interface VPC Endpoint
Nome do serviço:
com.amazonaws.ap-northeast-1.execute-api
função
Interface VPC Endpoint é a entrada privada do Private API Gateway dentro do VPC.
Cria uma ENI em cada sub-rede da zona de disponibilidade selecionada:
AZ-a：10.20.11.45
AZ-c：10.20.21.82
Os pedidos HTTPS de empresas externas acabam por chegar a estes ENIs e entrar no API Gateway através do AWS PrivateLink.
O ponto final da interface suporta:
- Security Group。
- VPC Endpoint Policy。
- Múltiplas zonas de disponibilidade.
- Nome DNS privado.
- IPv4, IPv6 ou pilha dupla, dependendo do serviço e da configuração.
A AWS recomenda que o Interface Endpoint selecione várias sub-redes para melhorar a disponibilidade.
5. API Gateway Private Custom Domain
Por exemplo:
api.partner.example.com
Resolve dois problemas:
Endereço de chamada amigável
Não há necessidade de utilizar:
https://a1b2c3d4-vpce123.execute-api.ap-northeast-1.amazonaws.com/prod
Em vez disso, utilize:
https://api.partner.example.com/v1
Certificado TLS
O API Gateway é baseado no TLS SNI:
api.partner.example.com
Selecione o certificado ACM correspondente.
Deve ser criado entre o domínio personalizado privado e o VPC Endpoint:
Domain Name Access Association
Caso contrário, mesmo que o DNS aponte para o Endpoint, o API Gateway não permitirá que o Endpoint utilize esse nome de domínio privado.
6. Private API Gateway
Private API Gateway é a entrada final da API.
Pode continuar a integrar:
- Lambda。
- Serviços AWS.
- Back-end HTTP.
- Ligue-se aos serviços ALB/NLB e intra-VPC através do VPC Link.
API privada não significa que "qualquer pessoa através da linha dedicada possa chamá-la". Existem também pelo menos as seguintes camadas de autorização:
VPC Endpoint Security Group
VPC Endpoint Policy
Private Domain Resource Policy
Private API Resource Policy
Autenticação ao nível do método API
Certificação de negócios de back-end
A política de recursos da API privada pode restringir as fontes através de aws:SourceVpce ou aws:SourceVpc. A AWS recomenda especificar explicitamente um VPC ou VPC Endpoint em vez de permitir todas as origens.
5. Endereço recomendado e planeamento de recursos
Um exemplo específico é dado abaixo.
| Projeto | Exemplo |
|---|---|
| AWS Region | ap-northeast-1 |
| AWS VPC | 10.20.0.0/16 |
| Segmento de rede externa da empresa | 172.20.0.0/16 |
| Sub-rede A do endpoint do resolvedor | 10.20.10.0/24 |
| Sub-rede C do endpoint do resolvedor | 10.20.20.0/24 |
| Resolver IP A | 10.20.10.10 |
| Resolver IP C | 10.20.20.10 |
| execute-api Endpoint sub-rede A | 10.20.11.0/24 |
| execute-api Endpoint sub-rede C | 10.20.21.0/24 |
| Nome de domínio privado | api.partner.example.com |
| Private Hosted Zone | partner.example.com |
| API Stage | prod |
| Base Path | v1 |
Recomenda-se separar o Resolver Endpoint e o Interface Endpoint numa sub-rede dedicada para facilitar:
- Configure o NACL de forma independente.
- Registos de fluxo separados.
- Identifique os custos.
- Controlo independente de encaminhamento e grupos de segurança.
- Substituição ou expansão subsequente.
6. Fase Um: Configuração da Ligação Direta
Cenário A: apenas um VPC
Pode usar:
Direct Connect
→ Private VIF
→ Direct Connect Gateway
→ Virtual Private Gateway
→ VPC
O VIF privado é utilizado principalmente para aceder a VPC através de IP privado. Ao criar, precisa de definir parâmetros como VLAN, BGP ASN do cliente, BGP Peer IP e MTU.
Opção B: várias VPCs ou centro de rede partilhado
Recomendado:
Direct Connect
→ Transit VIF
→ Direct Connect Gateway
→ Transit Gateway
→ Shared Services VPC
Este é um design mais comum em ambientes corporativos porque pode ser seguido por:
- DNS VPC。
- API VPC。
- VPC empresarial.
- Verificação de segurança VPC.
Acesso unificado ao Transit Gateway.
O Transit VIF é utilizado para ligar ao Transit Gateway associado ao Direct Connect Gateway; os prefixos permitidos do Direct Connect Gateway afetam os prefixos do lado da AWS publicados na rede local.
Passos de configuração do Direct Connect
1. Estabeleça uma ligação física ou alojada
Pode ser:
- Dedicated Connection。
- Ligação alojada fornecida por parceiros.
Os ambientes formais de produção empresarial devem evitar ter apenas um link. O modelo de alta disponibilidade da AWS recomenda a utilização de ligações redundantes de diferentes dispositivos e diferentes locais do Direct Connect, e pode utilizar o Resiliency Toolkit para testar o failover do BGP.
2. Crie um gateway de ligação direta
Por exemplo:
Name: dxgw-partner-api
Amazon side ASN: 64520
3.º Crie um gateway de trânsito
Por exemplo:
TGW ASN: 64530
Anexe o VPC onde a API está localizada ao TGW.
4.º Associar Gateway DX e TGW
Os prefixos permitidos precisam de ser definidos, por exemplo:
10.20.0.0/16
Não publique aleatoriamente:
0.0.0.0/0
10.0.0.0/8
A não ser que este seja um web design explicitamente avaliado.
5.º Crie trânsito VIF
Os principais parâmetros incluem:
VLAN: 120
Customer ASN: 65010
AWS ASN: de DXGW
Customer Peer IP: 169.254.x.x/30
AWS Peer IP: 169.254.x.x/30
Chave BGP MD5: gerada ou especificada automaticamente
MTU: 1500 ou 8500
6. Configure o router local
Publique localmente na AWS:
172.20.0.0/16
Lançamentos da AWS para locais:
10.20.0.0/16
7.º Configure a tabela de encaminhamento TGW
O lado AWS requer, pelo menos:
172.20.0.0/16
→ Direção da associação Direct Connect Gateway/TGW
A tabela de rotas de sub-rede API VPC requer:
172.20.0.0/16
→ Transit Gateway
O router empresarial externo requer:
10.20.0.0/16
→ Direct Connect
Erros mais comuns do Direct Connect
A rota está configurada apenas num sentido
Por exemplo:
As empresas externas podem ir até 20.10.11.45
Mas a AWS não sabe como voltar ao 172.20.0.0/16
O resultado é normalmente um tempo limite de ligação TCP.
Sobreposição CIDR
Por exemplo:
Empresa externa: 10.20.0.0/16
AWS VPC：10.20.0.0/16
Esta situação não pode ser resolvida por encaminhamento comum. Geralmente requer:
- Planeie novamente o endereço.
- NAT。
- Agente intermediário.
- Arquitetura baseada em serviços PrivateLink.
MTU inconsistente
O VIF privado pode utilizar 1500 ou 9001, o Transit VIF pode utilizar 1500 ou 8500. Antes de ativar o Jumbo Frame, certifique-se de que o router do cliente, o operador, a ligação DX, o TGW e os equipamentos intermédios o suportam. Caso contrário, os pedidos pequenos podem ser normais e os pedidos grandes podem ficar bloqueados.
7. Fase 2: Criar endpoint de entrada do Route 53 Resolver
1. Crie um grupo de segurança
Por exemplo:
sg-r53-inbound
Regras de entrada:
UDP 53
Fonte: Servidor DNS externo da empresa IP/32
TCP 53
Fonte: Servidor DNS externo da empresa IP/32
Por exemplo:
UDP 53 ← 172.20.1.10/32
UDP 53 ← 172.20.1.11/32
TCP 53 ← 172.20.1.10/32
TCP 53 ← 172.20.1.11/32
Não abra apenas o UDP 53. O TCP pode ser utilizado nas seguintes situações:
- A resposta do DNS é demasiado grande.
- DNSSEC。
- Tente novamente após o truncamento do UDP.
- Comportamento de alguns produtos DNS internos.
A AWS exige explicitamente que o grupo de segurança Inbound Endpoint permita o TCP e o UDP 53.
2. Criar endpoint de entrada
Caminho da consola:
Route 53
→ Resolver
→ Inbound endpoints
→ Create inbound endpoint
Configurações recomendadas:
Name: r53-inbound-partner-api
VPC: vpc-api-shared
Endpoint category: Default
Protocol: Do53
Security Group: sg-r53-inbound
Configure duas AZ:
AZ-a
Subnet: subnet-dns-a
IP: 10.20.10.10
AZ-c
Subnet: subnet-dns-c
IP: 10.20.20.10
A AWS exige um mínimo de dois IPs e recomenda estar em zonas de disponibilidade diferentes; estes IPs permanecem inalterados durante a vida útil do Endpoint.
3. Encaminhamento condicional de configuração de DNS de empresa externa
Exemplo de DNS do Windows:
Conditional Forwarder:
partner.example.com
Master Servers:
10.20.10.10
10.20.20.10
Exemplo de BIND:
zone "partner.example.com" {
type forward;
forward only;
forwarders {
10.20.10.10;
10.20.20.10;
};
};
Recomenda-se encaminhar apenas o nome de domínio preciso:
partner.example.com
Não configure desnecessariamente:
.
com
example.com
Caso contrário, um grande número de consultas DNS irrelevantes poderá ser encaminhado para a AWS.
4.º Verifique o link DNS
Teste o IP do AWS Resolver diretamente:
dig @10.20.10.10 api.partner.example.com
Em seguida, passe o teste normal de DNS da empresa externa:
dig api.partner.example.com
Na fase inicial, quando a Zona Alojada Privada não tiver sido criada, poderá ser devolvido NXDOMAIN, o que pelo menos comprova que o pedido chegou ao Resolvedor.
8. Fase 3: Criar VPC Endpoint da interface execute-api
1. Crie um grupo de segurança Endpoint
Por exemplo:
sg-vpce-execute-api
Regras de entrada:
TCP 443
Source: 172.20.0.0/16
Quando é mais rigoroso, apenas o segmento de rede do sistema empresarial é permitido:
TCP 443
Source: 172.20.10.0/24
Não cometa o erro de pensar que apenas permitir o CIDR de VPC é suficiente. O chamador está localizado numa rede externa da empresa. A origem vista pelo VPC Endpoint é geralmente o IP privado original da empresa externa, pelo que o segmento de rede correspondente deve ser permitido.
A AWS exige que o grupo de segurança execute-api Endpoint permita o tráfego HTTPS 443.
2. Criar ponto final
Caminho da consola:
VPC
→ Endpoints
→ Create endpoint
Selecione:
Service category: AWS services
Service:
com.amazonaws.ap-northeast-1.execute-api
Type:
Interface
Configuração:
VPC: vpc-api-shared
Subnets:
subnet-endpoint-a
subnet-endpoint-c
Security Group:
sg-vpce-execute-api
Private DNS:
Enabled
Recomenda-se selecionar pelo menos duas zonas de disponibilidade. Apenas uma sub-rede pode ser selecionada para cada AZ selecionada, e a AWS criará um Endpoint ENI em cada sub-rede.
Exemplo de CLI da AWS:
aws ec2 create-vpc-endpoint \
--region ap-northeast-1 \
--vpc-id vpc-0123456789abcdef0 \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.ap-northeast-1.execute-api \
--subnet-ids subnet-aaa subnet-ccc \
--security-group-ids sg-0123456789abcdef0 \
--private-dns-enabled
3. Impacto da alteração do DNS privado
Depois de ativar o DNS privado execute-api:
*.execute-api.ap-northeast-1.amazonaws.com
Dentro desta VPC, o VPC Endpoint será resolvido em primeiro lugar.
É mais conveniente chamar o nome de domínio padrão da API privada, mas também tem efeitos colaterais:
- Ao aceder ao URL
execute-apipadrão do API Gateway público numa VPC, pode ser resolvido para Private Endpoint. - Por conseguinte, a API pública pode não estar acessível através do nome de domínio padrão.
- É melhor utilizar o seu próprio domínio personalizado regional para a API de rede pública.
A documentação da AWS recorda claramente que após a ativação do DNS privado do endpoint execute-api, o acesso à API pública através do endpoint padrão na VPC pode ser afetado.
9. Fase 4: Criar API REST privada
1. Crie API
Consola:
API Gateway
→ Create API
→ REST API
→ Build
Selecione:
Endpoint type: Private
IP address type: Dualstack
VPC Endpoint IDs: vpce-xxxxxxxx
Gateway de API privado aqui refere-se ao endpoint privado da API REST. Pode associar diretamente o VPC Endpoint execute-api ao criá-lo. Uma vez associado, o API Gateway gera o nome DNS de chamada relacionado com o API ID e o Endpoint ID.
Exemplo de CLI:
aws apigateway create-rest-api \
--region ap-northeast-1 \
--name partner-private-api \
--endpoint-configuration '{
"types":["PRIVATE"],
"ipAddressType":"dualstack",
"vpcEndpointIds":["vpce-0123456789abcdef0"]
}'
2.º Crie recursos e métodos
Por exemplo:
/
└── orders
├── GET
└── POST
Ou:
/health
/orders
/orders/{orderId}
Depois de configurar o Lambda ou outra integração, implemente em:
Stage: prod
3. API Resource Policy
Recomenda-se permitir apenas o Endpoint especificado:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*"
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0123456789abcdef0"
}
}
}
]
}
O significado desta forma de escrever é:
- Em princípio, as chamadas são permitidas.
- Mas, desde que o Endpoint de origem não seja o Endpoint especificado, será explicitamente rejeitado.
A AWS fornece exemplos de políticas de recursos de API privadas baseadas em aws:SourceVpce e aws:SourceVpc.
Depois de modificar a política de recursos, a API terá de ser reimplementada.
10.º Passo: Certificado e Domínio Privado Personalizado
1.º Prepare o certificado ACM
O certificado deve abranger:
api.partner.example.com
E o certificado deve estar localizado na região onde se encontra o API Gateway, por exemplo:
ap-northeast-1
Pode usar:
api.partner.example.com
ou quando adequado:
*.partner.example.com
O domínio personalizado privado suporta certificados curinga, mas não o próprio nome de domínio personalizado curinga; os nomes de domínio privados utilizam sempre o TLS 1.2.
Problemas importantes com os certificados públicos ACM
Mesmo que o nome de domínio seja utilizado apenas para a intranet, o ACM ainda terá de verificar a propriedade do nome de domínio ao solicitar um certificado público do ACM.
Os registos de verificação DNS devem ser detetáveis pelo ACM a partir do DNS público. A simples colocação do CNAME na zona alojada privada do Route 53 não pode concluir a verificação do certificado público do ACM.
Assim, uma abordagem mais segura é:
- Utilize um subdomínio de nome de domínio público que seja realmente propriedade da empresa, como por exemplo
api.partner.example.com. - Coloque apenas CNAME verificado pelo ACM no DNS público.
- O registo A da API real é colocado apenas na zona alojada privada.
- O DNS da rede pública não tem de publicar o endereço real da API.
2.º Crie um domínio privado personalizado
Consola:
API Gateway
→ Custom domain names
→ Add domain name
Configuração:
Domain name:
api.partner.example.com
Endpoint type:
Private
Routing mode:
API mappings only
ACM Certificate:
Certificado que cobre api.partner.example.com
Após a criação, o API Gateway irá configurar inicialmente uma política que nega todo o acesso ao nome de domínio e requer autorização manual para especificar o VPC Endpoint.
Exemplo de CLI:
aws apigateway create-domain-name \
--region ap-northeast-1 \
--domain-name api.partner.example.com \
--certificate-arn arn:aws:acm:ap-northeast-1:111122223333:certificate/xxxxxxxx \
--security-policy TLS_1_2 \
--endpoint-configuration '{"types":["PRIVATE"]}' \
--policy file://domain-policy.json
11. Política de Recursos de Domínio Privado
O próprio domínio privado também deve permitir que o VPC Endpoint seja especificado.
domain-policy.json：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*"
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0123456789abcdef0"
}
}
}
]
}
Eis um ponto muito fácil de ignorar:
Para que um pedido seja bem-sucedido, pelo menos o seguinte deve ser verdadeiro:
A Política de Domínio Privado permite
A política de API privada permite
A política VPC Endpoint permite
A autenticação ao nível de método permite
A AWS exige explicitamente API privada e domínio personalizado privado para configurar políticas de recursos separadamente.
12.º Passo: Criar mapeamento de API
Por exemplo, a esperança:
https://api.partner.example.com/v1/orders
Mapas para:
API: partner-private-api
Stage: prod
Base Path: v1
Consola:
API Gateway
→ Custom domain names
→ api.partner.example.com
→ API mappings
→ Configure mappings
Configurações:
API: partner-private-api
Stage: prod
Path: v1
CLI：
aws apigateway create-base-path-mapping \
--region ap-northeast-1 \
--domain-name api.partner.example.com \
--domain-name-id abcd1234 \
--rest-api-id a1b2c3d4 \
--stage prod \
--base-path v1
O domínio personalizado privado deve ser mapeado para API privada e estágio específico através de mapeamento de API ou regras de encaminhamento.
13.º Passo: Criar associação de acesso a nomes de domínio
Esta é a etapa mais facilmente perdida na arquitetura do Domínio Personalizado Privado.
Precisa de construir:
Private Custom Domain
↕
execute-api VPC Endpoint
Consola:
API Gateway
→ Custom domain names
→ api.partner.example.com
→ Resource sharing
→ Domain name access associations
→ Create
Selecione:
Domain ARN:
arn:aws:apigateway:ap-northeast-1:111122223333:
/domainnames/api.partner.example.com+domain-id
VPC Endpoint:
vpce-0123456789abcdef0
CLI：
aws apigateway create-domain-name-access-association \
--region ap-northeast-1 \
--domain-name-arn \
arn:aws:apigateway:ap-northeast-1:111122223333:/domainnames/api.partner.example.com+abcd1234 \
--access-association-source vpce-0123456789abcdef0 \
--access-association-source-type VPCE
Pode demorar cerca de 15 minutos para que a adesão fique disponível após a sua criação, e também pode demorar um pouco para a criação do próprio Domínio Privado Personalizado ou para a atualização do certificado.
14.º Estágio: Configurar a política VPC Endpoint
Controlo de política de endpoint:
Não é recomendado manter o Acesso Total durante longos períodos de tempo.
Por exemplo, apenas o Domínio e a API podem ser especificados:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": [
"arn:aws:execute-api:ap-northeast-1:111122223333:/domainnames/api.partner.example.com+abcd1234",
"arn:aws:execute-api:ap-northeast-1:111122223333:a1b2c3d4/*"
]
}
]
}
Também pode utilizar execute-api:viaDomainArn para restringir o acesso apenas ao domínio personalizado privado especificado. A AWS dá um exemplo de restrição da política de endpoint VPC por nome de domínio privado, API e método.
Notas de cabeçalho de autorização
A Endpoint Policy avalia primeiro o cabeçalho Authorization do pedido:
- Sem autorização: Avaliado pelo realizador anónimo.
- SigV4 correto: identificado como o principal do IAM.
- Erro SigV4: Rejeição direta.
- Bearer Token/JWT: a política de endpoint é geralmente ainda avaliada com base no principal anónimo.
Assim, se a camada de negócio utilizar o autorizador OAuth/JWT/Lambda, não solicite por engano um utilizador IAM na política de endpoint, caso contrário, os pedidos JWT legítimos poderão ser bloqueados pela política de endpoint.
15.º Passo: Criar zona alojada privada e registos de alias
1. Crie uma zona alojada privada
Recomendado para criar:
partner.example.com
e associe uma VPC contendo os seguintes recursos:
- Resolver Inbound Endpoint。
- execute-api VPC Endpoint。
Pelo menos a zona alojada privada deve estar associada à VPC onde se encontra o endpoint de entrada, para que o resolvedor possa utilizar a zona alojada para responder a consultas externas.
CLI：
aws route53 create-hosted-zone \
--name partner.example.com \
--caller-reference "$(date +%s)" \
--hosted-zone-config Comment="Partner private API",PrivateZone=true \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-0123456789abcdef0
2. Crie registos de Alias
Consola:
Route 53
→ Hosted zones
→ partner.example.com
→ Create record
Configuração:
Record name:
api
Record type:
A
Alias:
On
Route traffic to:
Alias to VPC endpoint
Region:
ap-northeast-1
Endpoint:
vpce-0123456789abcdef0
O destino do alias do Route 53 do domínio personalizado da API privada deve ser o VPC Endpoint da interface execute-api, e não o Lambda, o ID da API ou o Resolver Endpoint.
Exemplo de registo CLI:
{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.partner.example.com",
"Type": "A",
"AliasTarget": {
"DNSName": "vpce-0123456789abcdef0.execute-api.ap-northeast-1.vpce.amazonaws.com",
"HostedZoneId": "VPC_ENDPOINT_HOSTED_ZONE_ID",
"EvaluateTargetHealth": false
}
}
}
]
}
Então:
aws route53 change-resource-record-sets \
--hosted-zone-id Z0123456789ABCDEFG \
--change-batch file://api-alias.json
Caso o Endpoint utilize IPv6 ou Dualstack, adicione registos AAAA de acordo com a necessidade real.
16.º O que é que a empresa externa precisa de configurar?
As empresas externas normalmente apenas necessitam de acesso às seguintes informações.
Informações de rede
Segmento de rede de destino da AWS:
10.20.0.0/16
Acordo:
DNS UDP/TCP 53
HTTPS TCP 443
Informações DNS
Domínio de encaminhamento:
partner.example.com
DNS alvo:
10.20.10.10
10.20.20.10
Informações da API
Base URL:
https://api.partner.example.com/v1
Verificação de saúde:
GET /health
API de negócio:
GET /orders
POST /orders
Informações de certificação
Depende do design, por exemplo:
- OAuth2/JWT。
- API Gateway Lambda Authorizer。
- AWS IAM SigV4。
- Assinatura HMAC.
- Cognito Token。
- Nome de utilizador/palavra-passe comercial, não recomendado para utilização isoladamente.
- A chave API é apenas adequada para medição e plano de utilização e não deve ser utilizada como a única autenticação de segurança.
A API privada não suporta atualmente a função TLS mútua do API Gateway, pelo que a autenticação de certificado bidirecional B2B não pode ser configurada diretamente de acordo com o método mTLS da API regional da rede pública. Pode utilizar o IAM SigV4, JWT/Lambda Authorizer, verificação de certificados da camada de aplicação ou redesenhar a camada de proxy front-end.
17. Camada completa de controlo de segurança
Recomenda-se dividir os controlos em seis camadas.
Camada 1: Encaminhamento Direct Connect
Publique apenas os segmentos de rede necessários:
Empresa externa → AWS:
10.20.0.0/16
AWS → Empresa externa:
172.20.10.0/24
Tente não publicar segmentos inteiros da rede empresarial entre si.
Segunda camada: grupo de segurança do Resolver Endpoint
Apenas os servidores DNS oficiais de empresas externas são permitidos:
UDP/TCP 53
172.20.1.10/32
172.20.1.11/32
Não permita que todos os clientes consultem o Resolvedor diretamente.
A terceira camada: grupo de segurança execute-api Endpoint
Apenas os segmentos de rede de origem do sistema comercial são permitidos:
TCP 443
172.20.10.0/24
Camada 4: Política VPC Endpoint
Permitido apenas:
Especifique o domínio privado
Especifique a API
Especifique o método ou o estágio
Camada 5: Política de domínio e recursos de API
Também passou:
aws:SourceVpce
Limite o endpoint especificado.
Quando necessitar de restringir ainda mais os IPs de origem externos, a política de recursos da API privada pode ser utilizada:
aws:VpcSourceIp
Uma vez que o VPC Endpoint pode reescrever o IP de origem da camada de rede, o aws:VpcSourceIp é utilizado para determinar o endereço de origem do pedido original.
Nível 6: Certificação ao nível do método e ao nível do negócio
Por exemplo:
OAuth2 Access Token
JWT Claims
Partner ID
Scope
Permissões de encomenda
Frequência de chamada
auditoria empresarial
Estar acessível através da rede não significa que a empresa tenha acesso.
18. Pontos-chave a ter em conta no design do DNS
1. Split-Horizon DNS
Suponha que a empresa externa já é gerida internamente:
example.com
A AWS cria novamente:
Private Hosted Zone: example.com
Depois podem ocorrer conflitos de autoridade e DNS divididos.
É mais recomendado dividir os subdomínios dedicados:
aws-api.example.com
partner-api.example.com
private.example.com
Em seguida, reencaminhe apenas condicionalmente este subdomínio.
2. Erro de associação de zona alojada privada
se:
Endpoint do resolvedor em VPC-A
A zona alojada privada está associada apenas ao VPC-B
O endpoint de entrada pode não resolver a zona alojada como esperado.
A forma mais simples é:
Private Hosted Zone
Associe também a VPC onde se encontra o Resolver Endpoint
E o VPC onde se encontra o endpoint execute-api
É mais fácil se ambos estiverem na mesma VPC.
3. Não grave o IP do Resolver no registo A da empresa
Erro:
api.partner.example.com
A → 10.20.10.10
10.20.10.10 é um servidor DNS, não um servidor API.
Correto:
api.partner.example.com
A Alias → execute-api VPC Endpoint
4. TTL e cache
Assim que o registo da zona alojada privada for alterado, o DNS empresarial externo e os clientes poderão continuar a utilizar a cache.
Ao testar pode:
dig api.partner.example.com
Observe o TTL e limpe:
- Cache DNS do Windows.
- Cache Linux
systemd-resolved. - Cache DNS JVM Java.
- Cache DNS empresarial.
19. Projeto de alta disponibilidade
Direct Connect
Para ambientes de produção, considere, pelo menos:
DX Connection A
DX Connection B
dispositivos diferentes
Melhor localização DX diferente
e prepare:
Site-to-Site VPN Backup
Utilize os atributos BGP para controlar os ativos e em espera.
Resolver Inbound Endpoint
Pelo menos duas AZ:
10.20.10.10
10.20.20.10
O DNS externo é configurado com dois encaminhadores ao mesmo tempo.
Cada IP do Resolver Endpoint pode lidar com um grande número de consultas; A documentação atual da AWS refere que um único IP pode lidar com aproximadamente 10.000 UDP DNS QPS quando as condições são adequadas, mas a capacidade real é afetada pelo tamanho da consulta, protocolo, latência de resposta e rastreio de ligação do grupo de segurança.
Interface VPC Endpoint
Pelo menos duas AZ:
Endpoint ENI A
Endpoint ENI C
O Route 53 Alias irá devolver o endereço do endpoint correspondente.
A AWS também recomenda claramente que o domínio personalizado privado utilize VPC Endpoints em pelo menos duas zonas de disponibilidade.
API Gateway
O API Gateway em si é um serviço de alojamento regional e não requer a implementação de instâncias ativas e em espera no estilo EC2. No entanto, o back-end ainda precisa de ser considerado separadamente:
- Simultaneidade lambda.
- VPC Link。
- A ALB/NLB tem múltiplas AZs.
- A base de dados possui várias AZs.
- Recuperação de catástrofes entre regiões.
20. Monitorização e registo
Recomenda-se ativar pelo menos os seguintes itens.
Direct Connect
Monitorizar:
ConnectionState
VirtualInterfaceBpsIngress
VirtualInterfaceBpsEgress
VirtualInterfacePpsIngress
VirtualInterfacePpsEgress
Estado do BGP
E execute o teste de failover BGP para confirmar se a ligação de cópia de segurança pode realmente assumir o controlo. O AWS Resiliency Toolkit suporta a verificação de rotas redundantes fechando temporariamente a sessão BGP.
Route 53 Resolver
Ativar:
Resolver Query Logging
CloudWatch Resolver Endpoint Metrics
Consultar os registos pode ajudar a confirmar:
- Se foi recebida uma consulta de nome de domínio.
- De que VPC vem a consulta.
- Tipo de consulta.
- Retornar resultados.
É de notar que as consultas repetidas atingidas pela cache do Resolver geralmente não aparecem no registo de consultas como cada consulta independente.
VPC
Ativar:
VPC Flow Logs
Destaques:
- Resolver Endpoint ENI。
- execute-api Endpoint ENI。
- Tráfego relacionado com o TGW.
- ACCEPT/REJECT。
- IP de origem, IP de destino, porta.
API Gateway
Ativar:
Access Logs
Execution Logs
Detailed Metrics
AWS X-Ray, on-demand
Recomenda-se que os registos de acesso contenham, pelo menos:
$requestId
$context.identity.sourceIp
$context.domainName
$context.httpMethod
$context.resourcePath
$context.status
$context.responseLength
$context.integrationErrorMessage
21. Sequência de teste padrão
Não execute apenas curl inicialmente, teste por camada.
Passo 1: Verifique o BGP e o encaminhamento
O router externo confirma que aprendeu:
10.20.0.0/16
O lado da AWS confirma que aprendeu:
172.20.0.0/16
Passo 2: testar o endpoint do resolvedor diretamente
dig @10.20.10.10 api.partner.example.com A
dig @10.20.20.10 api.partner.example.com A
Passo 3: passar no teste formal de DNS por uma empresa externa
dig api.partner.example.com A
O IP privado do Endpoint deve ser devolvido.
Passo 4: teste TCP 443
nc -vz api.partner.example.com 443
Ou:
telnet api.partner.example.com 443
Passo cinco: verifique o certificado TLS
openssl s_client \
-connect api.partner.example.com:443 \
-servername api.partner.example.com
Verifique:
Subject Alternative Name
Issuer
Validity
TLS version
Certificate chain
Passo 6: ligar para o exame de saúde
curl -v https://api.partner.example.com/v1/health
Passo 7: ligar com autenticação
Exemplo JWT:
curl -v \
-H "Authorization: Bearer ${TOKEN}" \
https://api.partner.example.com/v1/orders
Os cenários SigV4 podem utilizar o SDK, a AWS CLI ou a biblioteca de subscrições correspondente que suporta as subscrições.
22. Falhas comuns e métodos de julgamento
1. Tempo limite de pedido DNS
Desempenho:
tempo limite de escavação
Verificações prioritárias:
DNS externo para encaminhamento IP do Resolver
Encaminhamento TGW
Encaminhamento de sub-rede VPC
Resolver SG UDP/TCP 53
firewall externo
NACL
2. DNS retorna NXDOMAIN
Isto significa que a rede e o servidor DNS podem estar ligados, mas existe um problema com a camada de registo.
Verifique:
Nome da zona alojada privada
Um registo Alias
A zona alojada está associada à VPC
O FQDN consultado está correto?
Existe uma zona alojada de conflito mais específico
3. O nome de domínio pode ser resolvido, mas o TCP 443 atinge o tempo limite.
Verifique:
execute-api Endpoint SG
Encaminhamento externo para Endpoint ENI
NACL
Encaminhamento de backhaul TGW
firewall externo
4. Incompatibilidade de nome do certificado TLS
Por exemplo, o certificado é:
*.example.com
Mas o nome de domínio é:
api.partner.example.com
*.example.com cobre apenas uma camada:
api.example.com
Geralmente não coberto:
api.partner.example.com
Deve ser utilizado:
*.partner.example.com
ou certificado exato:
api.partner.example.com
5.º Retorno 403 Proibido
Verifique o pedido:
A associação de acesso a nomes de domínio está DISPONÍVEL?
Domain Resource Policy
API Resource Policy
VPC Endpoint Policy
Autorização de método
Assinatura JWT/IAM
API Key/Usage Plan
6.º Retornar token de autenticação em falta
Razões comuns:
Erro no caminho base
Erro de mapeamento de estágio
Erro no método HTTP
O caminho do recurso não existe
API não reimplantada
Por exemplo, mapeamento real:
/v1 → prod
Correto:
https://api.partner.example.com/v1/orders
Erro:
https://api.partner.example.com/prod/orders
7. O URL execute-api padrão pode ser acedido, mas o domínio personalizado não pode
Pontos-chave a verificar:
Certificado ACM
Estatuto de domínio privado
Domain Resource Policy
Domain Access Association
API Mapping
Route 53 Alias
Host/SNI
8.º Pode ser acedido dentro da VPC, mas não por empresas externas.
Geralmente afirmado:
A configuração do API Gateway está basicamente correta
O problema está focado no encaminhamento DX, Endpoint SG ou DNS externo
9.As solicitações pequenas são normais, mas as solicitações grandes falham.
Verifique:
MTU
PMTUD
ICMP Fragmentation Needed
firewall intermédio
Jumbo Frame
23. Os dez lugares mais facilmente perdidos
- Direct Connect não é encriptado automaticamente.
- DNS e HTTPS são dois caminhos diferentes.
- O endpoint Resolver deve abrir UDP e TCP 53.
- A zona alojada Private deve estar associada à VPC onde se encontra o resolvedor.
- O destino Alias é o VPC Endpoint execute-api, e não o Resolver.
- O grupo de segurança execute-api Endpoint deve permitir o segmento de rede de origem da empresa externa TCP 443.
- Política de Domínio Privado e Política de API Privada são duas políticas.
- deve criar uma associação de acesso a nomes de domínio.
- necessita de ser reimplantado após modificar a associação ou o recurso do Endpoint da API.
- O registo de verificação DNS do certificado público ACM deve poder ser consultado no DNS público e não pode ser colocado apenas na zona alojada privada.
24. Configuração de produção final recomendada
A seguinte configuração é recomendada para sistemas B2B formais:
Duas ligações diretas
+ Ligação de backup VPN
Transit VIF
+ Direct Connect Gateway
+ Transit Gateway
VPC autónoma de serviços partilhados
Endpoint de entrada do resolvedor de duas AZ
+ Permitir apenas servidores DNS oficiais UDP/TCP 53
Ponto final da interface execute-api de duas AZ
+ Permitir apenas segmento de rede comercial externa TCP 443
Subdomínio privado dedicado
api.partner.example.com
Private Custom Domain
+ Certificado ACM
+ Domain Access Association
Private Domain Policy
+ API Resource Policy
+ Endpoint Policy
Todas as restrições aws:SourceVpce
Autenticação JWT ou IAM SigV4
+ API Gateway Access Logs
+ Resolver Query Logs
+ VPC Flow Logs
+ Alerta DX CloudWatch
O link final pode ser resumido como:
DNS：
DNS externo
→ Direct Connect
→ Resolver Inbound Endpoint
→ Private Hosted Zone
→ Regressar ao IP privado do VPC Endpoint
HTTPS：
Sistema de negócio externo
→ Direct Connect
→ execute-api Interface Endpoint
→ Private Custom Domain
→ API Mapping
→ Private REST API
→ Serviços de back-end