Cómo conectar la red local de una empresa externa a Private API Gateway mediante AWS Direct Connect

📅 2026-08-08
📍 AWS Direct Connect × Private API Gateway
⏱️ Unos 35 minutos de lectura

Arquitectura general | Rutas DNS y HTTPS | AWS Direct Connect | Route 53 Resolver | Private API Gateway | Seguridad y diagnóstico

Es importante tener en cuenta aquí: esta no es una "cadena de proxy en serie" por la que pasa todo el tráfico en secuencia.

En realidad, se divide en dos procesos independientes:

  1. Ruta de resolución de DNS : Responsable de resolver el nombre de dominio privado en la IP privada del extremo de la VPC.
  2. Ruta de acceso HTTPS : después de que el cliente obtiene la IP privada, accede directamente al punto final de la interfaz VPC a través de Direct Connect y luego lo transfiere a Private API Gateway a través de AWS PrivateLink.

2. Estructura general

Los ejemplos siguientes utilizan la región de Tokio, ap-northeast-1.


red externa de la empresa
172.20.0.0/16
│
├─Cliente empresarial
│ curl / Java / Cartero / Sistema empresarial
│
├─ DNS externo de empresa
│ Reenvío 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
      │ o
      └─ 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

Route 53 Resolver Inbound Endpoint recibe solicitudes de DNS de la red local, mientras que Private Hosted Zone guarda registros de nombres de dominio privados; Interface VPC Endpoint es el punto de entrada real para los flujos de datos HTTPS en API Gateway.

3. ¿Cómo fluye una solicitud completa?

Supongamos que un sistema externo de la empresa solicita:


https://api.partner.example.com/v1/orders

1. Proceso de resolución de DNS

El cliente primero solicita a la empresa externa su DNS interno:


¿Cuál es la IP de api.partner.example.com?

Reenvío condicional configurado en DNS corporativo externo:


partner.example.com
    → 10.20.10.10
    → 10.20.20.10

Estas dos IP son las IP del punto final entrante del solucionador de Route 53 en la VPC de AWS.

La solicitud de DNS va:


DNS externo de empresa
→ Direct Connect
→ Transit Gateway/VGW
→ Resolver Inbound Endpoint
→ Route 53 VPC Resolver
→ Private Hosted Zone

Existe en la zona privada alojada:


api.partner.example.com
    A Alias
    → vpce-xxxxxxxx.execute-api.ap-northeast-1.vpce.amazonaws.com

Lo que finalmente se devuelve no es la IP pública del API Gateway, sino la IP privada del Interface VPC Endpoint ENI, por ejemplo:


10.20.11.45
10.20.21.82

La IP del punto de enlace entrante es en sí misma una IP privada de VPC, por lo que la red local debe enrutarse a la VPC a través de Direct Connect o VPN. AWS requiere que cada punto final de resolución esté configurado con al menos dos IP y se recomienda colocarlas en diferentes zonas de disponibilidad.

2. Proceso de acceso HTTPS

Una vez finalizado el DNS, el cliente establece TCP 443 en la IP privada del punto final de VPC resuelta:


cliente
→ Direct Connect
→ TGW/VGW
→ VPC Endpoint ENI:443
→ AWS PrivateLink
→ API Gateway Private Custom Domain
→ API Mapping
→ Private REST API

Aquí Route 53 Resolver no participa en el reenvío HTTPS de . Sólo es responsable de la resolución DNS anterior.

Solo se puede acceder a Private API Gateway a través del punto final de VPC de interfaz de API Gateway, y la política de recursos de API también debe permitir la VPC o el punto final de VPC especificado.

4. ¿Por qué existe cada servicio?

1. AWS Direct Connect

función

Direct Connect proporciona una conexión de línea privada entre la red corporativa externa y AWS.

Es principalmente responsable de:

  • Enrute el segmento de red privada de una empresa externa a una VPC de AWS.
  • Liberar el segmento de red de AWS VPC a empresas externas.
  • Aloja solicitudes de DNS.
  • Aloja solicitudes de API HTTPS.
  • Evite el tráfico empresarial que pasa por la Internet pública.
  • Proporciona ancho de banda y latencia relativamente estables.

De qué Direct Connect no es responsable

Direct Connect en sí no es responsable de:

  • Resolución DNS.
  • Autenticación API.
  • Autorización API.
  • Certificado TLS.
  • Enrutamiento de puerta de enlace API.
  • Cifre automáticamente todos los enlaces.

Direct Connect es un "circuito privado", pero no puede equipararse simplemente a un "circuito cifrado de extremo a extremo". Cuando se requiere cifrado de enlace, considere MACsec cuando sea compatible o superponga VPN/IPsec de sitio a sitio en Direct Connect. El modo must_encrypt de MACsec detiene la transmisión si no se puede establecer el cifrado; should_encrypt puede recurrir a una comunicación no cifrada en caso de error.

2. Route 53 Resolver Inbound Endpoint

función

Habilite los servidores DNS propios de empresas externas para consultar DNS dentro de la VPC de AWS.

Sin él, el DNS local de la empresa externa no se puede consultar directamente:

  • Route 53 Private Hosted Zone。
  • Nombre DNS privado interno de VPC.
  • Registros privados relacionados con el endpoint de la VPC.

Después de crear el punto final de entrada, se creará una ENI en la subred especificada y se asignará una IP privada fija. El DNS de la empresa externa reenvía las solicitudes de los nombres de dominio correspondientes a estas IP.

¿Por qué no puedo solicitar directamente el DNS VPC+2 de la VPC?

Las direcciones DNS comunes en VPC son similares:


VPC CIDR：10.20.0.0/16
VPC Resolver：10.20.0.2

Pero la red externa no debería utilizar directamente 10.20.0.2 como un servidor DNS normal. El punto de entrada estándar para redes híbridas es el Resolver Inbound Endpoint.

3. Route 53 Private Hosted Zone

función

Guarde nombres de dominio privados y registros correspondientes, por ejemplo:


Private Hosted Zone:
partner.example.com

Record:
api.partner.example.com
    A Alias
    → execute-api Interface VPC Endpoint

La zona alojada privada solo tiene efecto para la VPC asociada y las consultas ingresadas a través del punto final de entrada de resolución correspondiente. No es necesario exponer la dirección API real al DNS público.

4. Interface VPC Endpoint

Nombre del servicio:


com.amazonaws.ap-northeast-1.execute-api

función

Interface VPC Endpoint es la entrada privada de Private API Gateway dentro de VPC.

Crea una ENI en cada subred de Zona de Disponibilidad seleccionada:


AZ-a：10.20.11.45
AZ-c：10.20.21.82

Las solicitudes HTTPS de empresas externas eventualmente llegan a estos ENI y luego ingresan a API Gateway a través de AWS PrivateLink.

El punto final de la interfaz admite:

  • Security Group。
  • VPC Endpoint Policy。
  • Múltiples zonas de disponibilidad.
  • Nombre DNS privado.
  • IPv4, IPv6 o dual stack, según servicio y configuración.

AWS recomienda que Interface Endpoint seleccione varias subredes para mejorar la disponibilidad.

5. API Gateway Private Custom Domain

Por ejemplo:


api.partner.example.com

Resuelve dos problemas:

Dirección de llamada amigable

No es necesario utilizar:


https://a1b2c3d4-vpce123.execute-api.ap-northeast-1.amazonaws.com/prod

En su lugar utilice:


https://api.partner.example.com/v1

certificado TLS

API Gateway se basa en TLS SNI:


api.partner.example.com

Seleccione el certificado ACM correspondiente.

Debe crearse entre el dominio privado personalizado y el punto final de la VPC:


Domain Name Access Association

De lo contrario, incluso si el DNS apunta al punto final, API Gateway no permitirá que el punto final utilice este nombre de dominio privado.

6. Private API Gateway

Private API Gateway es la entrada final a la API.

Puede seguir integrando:

  • Lambda。
  • Servicios de AWS.
  • Servidor HTTP.
  • Conéctese a ALB/NLB y a servicios intra-VPC a través de VPC Link.

API privada no significa que "cualquiera a través de la línea dedicada puede llamarla". También existen al menos las siguientes capas de autorización:


VPC Endpoint Security Group
VPC Endpoint Policy
Private Domain Resource Policy
Private API Resource Policy
Autenticación a nivel de método API
Certificación empresarial backend

La política de recursos de la API privada puede restringir las fuentes a través de aws:SourceVpce o aws:SourceVpc. AWS recomienda especificar explícitamente una VPC o un punto final de VPC en lugar de permitir todos los orígenes.

5. Dirección recomendada y planificación de recursos

A continuación se ofrece un ejemplo específico.

Proyecto Ejemplo
AWS Region ap-northeast-1
AWS VPC 10.20.0.0/16
Segmento de red externa de la empresa 172.20.0.0/16
Subred A del punto final del solucionador 10.20.10.0/24
Subred C del punto final del solucionador 10.20.20.0/24
Resolver IP A 10.20.10.10
Resolver IP C 10.20.20.10
ejecutar-api Subred de punto final A 10.20.11.0/24
ejecutar-api Subred de punto final C 10.20.21.0/24
Nombre de dominio privado api.partner.example.com
Private Hosted Zone partner.example.com
API Stage prod
Base Path v1

Se recomienda separar el punto final del resolver y el punto final de la interfaz en una subred dedicada para facilitar:

  • Configure NACL de forma independiente.
  • Registros de flujo separados.
  • Identificar costos.
  • Control independiente de enrutamiento y grupos de seguridad.
  • Sustitución o ampliación posterior.

6. Fase uno: configuración de conexión directa

Escenario A: solo una VPC

Puede utilizar:


Direct Connect
→ Private VIF
→ Direct Connect Gateway
→ Virtual Private Gateway
→ VPC

Private VIF se utiliza principalmente para acceder a VPC a través de IP privada. Al crear, debe configurar parámetros como VLAN, cliente BGP ASN, BGP Peer IP y MTU.

Opción B: múltiples VPC o centro de red compartido

Recomendado:


Direct Connect
→ Transit VIF
→ Direct Connect Gateway
→ Transit Gateway
→ Shared Services VPC

Este es un diseño más común en entornos empresariales porque puede ir seguido de:

  • DNS VPC。
  • API VPC。
  • VPC empresarial.
  • Comprobación de seguridad VPC.

Acceso unificado a Transit Gateway.

Transit VIF se utiliza para conectarse a Transit Gateway asociado con Direct Connect Gateway; Los prefijos permitidos de Direct Connect Gateway afectan los prefijos del lado de AWS publicados en la red local.

Pasos de configuración de Conexión Directa

1. Establecer una conexión física o alojada

Puede ser:

  • Dedicated Connection。
  • Conexión alojada proporcionada por socios.

Los entornos de producción formal empresarial deberían evitar tener un solo enlace. El modelo de alta disponibilidad de AWS recomienda el uso de conexiones redundantes desde diferentes dispositivos y diferentes ubicaciones de Direct Connect, y puede usar Resiliency Toolkit para probar la conmutación por error de BGP.

2. Cree una puerta de enlace de Direct Connect

Por ejemplo:


Name: dxgw-partner-api
Amazon side ASN: 64520

3. Crear puerta de enlace de tránsito

Por ejemplo:


TGW ASN: 64530

Adjunte la VPC donde se encuentra la API al TGW.

4. Asociar DX Gateway y TGW

Es necesario configurar los prefijos permitidos, por ejemplo:


10.20.0.0/16

No publiques al azar:


0.0.0.0/0
10.0.0.0/8

A menos que se trate de un diseño web examinado explícitamente.

5. Crear VIF de tránsito

Los parámetros clave incluyen:


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
Clave BGP MD5: generada o especificada automáticamente
MTU: 1500 o 8500

6. Configurar el enrutador local

Publicar localmente en AWS:


172.20.0.0/16

Lanzamientos de AWS a nivel local:


10.20.0.0/16

7. Configurar la tabla de enrutamiento TGW

El lado de AWS requiere al menos:


172.20.0.0/16
    → Dirección de asociación Direct Connect Gateway/TGW

La tabla de rutas de subred API VPC requiere:


172.20.0.0/16
    → Transit Gateway

El enrutador corporativo externo requiere:


10.20.0.0/16
    → Direct Connect

Errores más comunes de Direct Connect

La ruta solo está configurada en una dirección.

Por ejemplo:


Las empresas externas pueden acudir al 20.10.11.45
Pero AWS no sabe cómo volver a 172.20.0.0/16

El resultado suele ser un tiempo de espera de conexión TCP.

Superposición de CIDR

Por ejemplo:


Empresa externa: 10.20.0.0/16
AWS VPC：10.20.0.0/16

Esta situación no puede solucionarse mediante el enrutamiento ordinario. Generalmente requiere:

  • Vuelva a planificar la dirección.
  • NAT。
  • Agente intermediario.
  • Arquitectura basada en servicios PrivateLink.

MTU inconsistente

El VIF privado puede usar 1500 o 9001, el VIF de tránsito puede usar 1500 u 8500. Antes de habilitar Jumbo Frame, asegúrese de que el enrutador del cliente, el operador, el enlace DX, el TGW y el equipo intermedio lo admitan. De lo contrario, las solicitudes pequeñas pueden ser normales y las solicitudes grandes pueden bloquearse.

7. Fase 2: Crear el punto final de entrada del solucionador de ruta 53

1. Crea un grupo de seguridad

Por ejemplo:


sg-r53-inbound

Reglas de entrada:


UDP 53
Fuente: Servidor DNS externo de la empresa IP/32

TCP 53
Fuente: Servidor DNS externo de la empresa IP/32

Por ejemplo:


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

No abra simplemente UDP 53. TCP se puede utilizar en las siguientes situaciones:

  • La respuesta de DNS es demasiado grande.
  • DNSSEC。
  • Vuelva a intentarlo después del truncamiento de UDP.
  • Comportamiento de algunos productos DNS internos.

AWS requiere explícitamente que el grupo de seguridad Inbound Endpoint permita TCP y UDP 53.

2. Crear un punto final de entrada

Ruta de la consola:


Route 53
→ Resolver
→ Inbound endpoints
→ Create inbound endpoint

Configuraciones recomendadas:


Name: r53-inbound-partner-api
VPC: vpc-api-shared
Endpoint category: Default
Protocol: Do53
Security Group: sg-r53-inbound

Configure dos AZ:


AZ-a
Subnet: subnet-dns-a
IP: 10.20.10.10

AZ-c
Subnet: subnet-dns-c
IP: 10.20.20.10

AWS requiere un mínimo de dos IP y recomienda estar en diferentes zonas de disponibilidad; Estas IP permanecen sin cambios durante la vida del Endpoint.

3. Reenvío condicional de configuración DNS de empresa externa

Ejemplo de DNS de Windows:


Conditional Forwarder:
partner.example.com

Master Servers:
10.20.10.10
10.20.20.10

Ejemplo de ENLACE:


zone "partner.example.com" {
    type forward;
    forward only;
    forwarders {
        10.20.10.10;
        10.20.20.10;
    };
};

Se recomienda reenviar sólo el nombre de dominio preciso:


partner.example.com

No configure innecesariamente:


.
com
example.com

De lo contrario, es posible que se reenvíe a AWS una gran cantidad de consultas de DNS irrelevantes.

4. Verificar el enlace DNS

Pruebe la IP de AWS Resolver directamente:


dig @10.20.10.10 api.partner.example.com

Luego pase la prueba DNS normal de la empresa externa:


dig api.partner.example.com

En la etapa inicial, cuando no se ha creado la Zona Alojada Privada, se puede devolver NXDOMAIN, lo que al menos demuestra que la solicitud ha llegado al Resolver.

8. Fase 3: Crear el punto final de la VPC de la interfaz de ejecución-api

1. Cree un grupo de seguridad de punto final

Por ejemplo:


sg-vpce-execute-api

Reglas de entrada:


TCP 443
Source: 172.20.0.0/16

Cuando es más estricto, sólo se permite el segmento de red del sistema empresarial:


TCP 443
Source: 172.20.10.0/24

No cometa el error de pensar que con solo permitir VPC CIDR es suficiente. La persona que llama se encuentra en una red externa de la empresa. La fuente vista por VPC Endpoint suele ser la IP privada original de la empresa externa, por lo que se debe permitir el segmento de red correspondiente.

AWS requiere que el grupo de seguridad de punto final ejecutar-api permita el tráfico HTTPS 443.

2. Crear punto final

Ruta de la consola:


VPC
→ Endpoints
→ Create endpoint

Seleccione:


Service category: AWS services
Service:
com.amazonaws.ap-northeast-1.execute-api

Type:
Interface

Configuración:


VPC: vpc-api-shared
Subnets:
  subnet-endpoint-a
  subnet-endpoint-c

Security Group:
  sg-vpce-execute-api

Private DNS:
  Enabled

Se recomienda seleccionar al menos dos zonas de disponibilidad. Solo se puede seleccionar una subred para cada AZ seleccionada y AWS creará una ENI de punto final en cada subred.

Ejemplo de AWS CLI:


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 del cambio de DNS privado

Después de activar el DNS privado de ejecución de API:


*.execute-api.ap-northeast-1.amazonaws.com

Dentro de esta VPC, el punto final de la VPC se resolverá primero.

Es más conveniente llamar al nombre de dominio predeterminado de la API privada, pero también tiene efectos secundarios:

  • Al acceder a la URL execute-api predeterminada de API Gateway pública en una VPC, es posible que se resuelva en un punto de conexión privado.
  • Por lo tanto, es posible que no se pueda acceder a la API pública a través del nombre de dominio predeterminado.
  • Lo mejor es utilizar su propio dominio regional personalizado para la API de la red pública.

La documentación de AWS recuerda claramente que después de habilitar el DNS privado del punto final de ejecución de API, el acceso a la API pública a través del punto final predeterminado en la VPC puede verse afectado.

9. Fase 4: crear una API REST privada

1. Crear API

Consola:


API Gateway
→ Create API
→ REST API
→ Build

Seleccione:


Endpoint type: Private
IP address type: Dualstack
VPC Endpoint IDs: vpce-xxxxxxxx

En este contexto, Private API Gateway se refiere a un endpoint privado de una API REST. Al crearlo, puede asociarse directamente con el endpoint de VPC de execute-api. Después de la asociación, API Gateway genera nombres DNS de invocación vinculados al ID de la API y al ID del endpoint.

Ejemplo 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. Crear recursos y métodos

Por ejemplo:


/
└── orders
    ├── GET
    └── POST

O:


/health
/orders
/orders/{orderId}

Después de configurar Lambda u otra integración, implemente en:


Stage: prod

3. API Resource Policy

Se recomienda permitir únicamente el punto final 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"
        }
      }
    }
  ]
}

El significado de esta forma de escribir es:

  1. En principio se permiten las llamadas.
  2. Pero siempre que el punto final de origen no sea el punto final especificado, se rechazará explícitamente.

AWS proporciona ejemplos de políticas de recursos de API privada basadas en aws:SourceVpce e aws:SourceVpc.

Después de modificar la política de recursos, se debe volver a implementar la API.

10. Etapa 5: Certificado y Dominio Personalizado Privado

1. Prepare el certificado ACM

El certificado debe cubrir:


api.partner.example.com

Y el certificado debe estar ubicado en la región donde se encuentra API Gateway, por ejemplo:


ap-northeast-1

Puedes usar:


api.partner.example.com

o en su caso:


*.partner.example.com

El dominio personalizado privado admite certificados comodín, pero no admite el nombre del dominio personalizado comodín; Los nombres de dominio privados siempre usan TLS 1.2.

Problemas importantes con los certificados públicos de ACM

Incluso si el nombre de dominio solo se usa para la intranet, ACM aún necesita verificar la propiedad del nombre de dominio al solicitar un certificado público de ACM.

ACM debe poder detectar los registros de verificación de DNS desde el DNS público. Simplemente colocar el CNAME en la zona privada alojada de Route 53 no puede completar la verificación del certificado público de ACM.

Por lo tanto, un enfoque más seguro es:

  • Utilice un subdominio de nombre de dominio público que realmente sea propiedad de la empresa, como api.partner.example.com.
  • Coloque solo CNAME verificado por ACM en DNS público.
  • El registro A de la API real solo se coloca en la zona privada alojada.
  • El DNS de la red pública no necesita publicar la dirección real de la API.

2. Cree un dominio privado personalizado

Consola:


API Gateway
→ Custom domain names
→ Add domain name

Configuración:


Domain name:
api.partner.example.com

Endpoint type:
Private

Routing mode:
API mappings only

ACM Certificate:
Certificado que cubre api.partner.example.com

Después de la creación, API Gateway configurará inicialmente una política que deniega todo acceso al nombre de dominio y requiere autorización manual para especificar el punto final de la VPC.

Ejemplo 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 dominio privado

El propio dominio privado también debe permitir que se especifique el punto final de la VPC.

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"
        }
      }
    }
  ]
}

Aquí hay un punto muy fácil de pasar por alto:

Para que una solicitud tenga éxito, al menos debe cumplirse lo siguiente:


La política de dominio privado permite
La política de API privada permite
La política de puntos finales de VPC permite
La autenticación a nivel de método permite

AWS requiere explícitamente una API privada y un dominio personalizado privado para configurar las políticas de recursos por separado.

12. Etapa 6: Crear mapeo de API

Por ejemplo, esperanza:


https://api.partner.example.com/v1/orders

Mapas a:


API: partner-private-api
Stage: prod
Base Path: v1

Consola:


API Gateway
→ Custom domain names
→ api.partner.example.com
→ API mappings
→ Configure mappings

Configuraciones:


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

El dominio personalizado privado debe asignarse a una API privada y una etapa específicas mediante la asignación de API o reglas de enrutamiento.

13. Etapa 7: Crear una asociación de acceso al nombre de dominio

Este es el paso que más fácilmente se pasa por alto en la arquitectura del dominio privado personalizado.

Necesidad 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

Seleccione:


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

La asociación puede tardar unos 15 minutos en estar disponible después de su creación, y también puede tardar un poco en crear el dominio privado personalizado o actualizar el certificado.

14. Etapa 8: Configurar la política de endpoints de la VPC

Control de políticas de terminales:

No se recomienda mantener el acceso total durante largos periodos de tiempo.

Por ejemplo, solo se permite especificar Dominio y API:


{
  "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/*"
      ]
    }
  ]
}

También puede utilizar execute-api:viaDomainArn para restringir el acceso únicamente al dominio personalizado privado especificado. AWS ofrece un ejemplo de cómo restringir la política de punto final de VPC por nombre de dominio privado, API y método.

Notas del encabezado de autorización

Endpoint Policy primero evalúa el encabezado Authorization de la solicitud:

  • Sin autorización: Evaluado por un director anónimo.
  • SigV4 correcto: identificado como principal de IAM.
  • Error SigV4: Rechazo directo.
  • Token de portador/JWT: la política de punto final generalmente todavía se evalúa en función del principal anónimo.

Por lo tanto, si la capa empresarial utiliza OAuth/JWT/Lambda Authorizer, no solicite por error un usuario de IAM en Endpoint Policy; de lo contrario, Endpoint Policy podría bloquear las solicitudes legítimas de JWT.

15. Etapa 9: Crear registros de alias y zona alojada privada

1. Crear una zona alojada privada

Recomendado para crear:


partner.example.com

y asociar una VPC que contenga los siguientes recursos:

  • Resolver Inbound Endpoint。
  • execute-api VPC Endpoint。

Al menos la Zona Alojada Privada debe estar asociada con la VPC donde se encuentra el Punto Final de Entrada, para que el Resolver pueda usar la 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. Crear registros de alias

Consola:


Route 53
→ Hosted zones
→ partner.example.com
→ Create record

Configuración:


Record name:
api

Record type:
A

Alias:
On

Route traffic to:
Alias to VPC endpoint

Region:
ap-northeast-1

Endpoint:
vpce-0123456789abcdef0

El destino del alias de Route 53 del dominio personalizado de la API privada debe ser el punto final de la VPC de la interfaz de ejecución-api, no el Lambda, el ID de API o el punto final del solucionador.

Ejemplo de registro 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
        }
      }
    }
  ]
}

Entonces:


aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFG \
  --change-batch file://api-alias.json

Si el Endpoint usa IPv6 o Dualstack, agregue registros AAAA según las necesidades reales.

16. ¿Qué necesita configurar finalmente la empresa externa?

Las empresas externas normalmente sólo necesitan acceso a la siguiente información.

Información de red


Segmento de red de destino de AWS:
10.20.0.0/16

Acuerdo:
DNS UDP/TCP 53
HTTPS TCP 443

información DNS


Dominio de reenvío:
partner.example.com

Destino DNS:
10.20.10.10
10.20.20.10

información API


Base URL:
https://api.partner.example.com/v1

Control de salud:
GET /health

API empresarial:
GET /orders
POST /orders

Información de certificación

Depende del diseño, por ejemplo:

  • OAuth2/JWT。
  • API Gateway Lambda Authorizer。
  • AWS IAM SigV4。
  • Firma HMAC.
  • Cognito Token。
  • Nombre de usuario/contraseña comercial, no se recomienda utilizarlo solo.
  • La clave API solo es adecuada para medición y plan de uso y no debe usarse como única autenticación de seguridad.

Actualmente, la API privada no admite la función TLS mutua de API Gateway, por lo que la autenticación de certificado bidireccional B2B no se puede configurar directamente de acuerdo con el método mTLS de la API regional de la red pública. Puede utilizar IAM SigV4, JWT/Lambda Authorizer, verificación de certificado de capa de aplicación o rediseñar la capa de proxy front-end.

17. Capa de control de seguridad completa

Se recomienda dividir los controles en seis capas.

Capa 1: enrutamiento de Direct Connect

Publique solo los segmentos de red necesarios:


Empresa externa → AWS:
10.20.0.0/16

AWS → Empresa externa:
172.20.10.0/24

Intente no publicar segmentos completos de la red empresarial entre sí.

Segunda capa: grupo de seguridad Resolver Endpoint

Sólo se permiten servidores DNS oficiales de empresas externas:


UDP/TCP 53
172.20.1.10/32
172.20.1.11/32

No permita que todos los clientes consulten el Resolver directamente.

La tercera capa: ejecutar-api Grupo de seguridad de punto final

Solo se permiten segmentos de red de origen del sistema empresarial:


TCP 443
172.20.10.0/24

Capa 4: Política de endpoints de VPC

Sólo permitido:


Especificar dominio privado
Especificar API
Especificar método o etapa

Capa 5: Política de recursos de dominio y API

También pasó:


aws:SourceVpce

Limite el punto final especificado.

Cuando necesite restringir aún más las IP de origen externo, se puede utilizar la política de recursos de API privada:


aws:VpcSourceIp

Debido a que VPC Endpoint puede reescribir la IP de origen de la capa de red, se utiliza aws:VpcSourceIp para determinar la dirección de origen de la solicitud original.

Nivel 6: Certificación a nivel de método y a nivel empresarial

Por ejemplo:


OAuth2 Access Token
JWT Claims
Partner ID
Scope
Permisos de pedido
Frecuencia de llamada
auditoría empresarial

Ser accesible a través de la red no significa que la empresa tenga acceso.

18. Puntos clave a tener en cuenta en el diseño de DNS

1. Split-Horizon DNS

Supongamos que la empresa externa ya se gestiona internamente:


example.com

AWS crea nuevamente:


Private Hosted Zone: example.com

Entonces pueden ocurrir DNS divididos y conflictos de autoridad.

Es más recomendable dividir subdominios dedicados:


aws-api.example.com
partner-api.example.com
private.example.com

Entonces solo reenvíe este subdominio de forma condicional.

2. Error de asociación de zona alojada privada

si:


Punto final de resolución en VPC-A
La zona alojada privada solo está asociada con VPC-B

Es posible que el punto final de entrada no resuelva la zona alojada como se esperaba.

La forma más sencilla es:


Private Hosted Zone
Asocie también la VPC donde se encuentra el Resolver Endpoint
Y la VPC donde se encuentra el punto final de ejecución de API

Es más fácil si ambos están en la misma VPC.

3. No escriba la IP del Resolver en el registro A de la empresa.

Error:


api.partner.example.com
A → 10.20.10.10

10.20.10.10 es un servidor DNS, no un servidor API.

Correcto:


api.partner.example.com
A Alias → execute-api VPC Endpoint

4. TTL y almacenamiento en caché

Después de que cambia el registro de la Zona Alojada Privada, los clientes y DNS corporativos externos pueden continuar usando el caché.

Al realizar la prueba puedes:


dig api.partner.example.com

Observe TTL y limpie:

  • Caché DNS de Windows.
  • Caché de Linux systemd-resolved.
  • Caché DNS de Java JVM.
  • Almacenamiento en caché de DNS empresarial.

19. Diseño de alta disponibilidad

Direct Connect

Para entornos de producción, al menos considere:


DX Connection A
DX Connection B
diferentes dispositivos
Mejor ubicación DX diferente

y preparar:


Site-to-Site VPN Backup

Utilice atributos BGP para controlar el modo activo y en espera.

Resolver Inbound Endpoint

Al menos dos AZ:


10.20.10.10
10.20.20.10

El DNS externo se configura con dos reenviadores al mismo tiempo.

Cada IP de Resolver Endpoint puede manejar una gran cantidad de consultas; La documentación actual de AWS indica que una sola IP puede manejar hasta aproximadamente 10 000 QPS de DNS UDP cuando las condiciones son adecuadas, pero la capacidad real se ve afectada por el tamaño de la consulta, el protocolo, la latencia de respuesta y el seguimiento de la conexión del grupo de seguridad.

Interface VPC Endpoint

Al menos dos AZ:


Endpoint ENI A
Endpoint ENI C

El alias de Route 53 devolverá la dirección del punto final correspondiente.

AWS también recomienda claramente que Private Custom Domain utilice puntos de enlace de VPC en al menos dos zonas de disponibilidad.

API Gateway

API Gateway en sí es un servicio de alojamiento regional y no requiere la implementación de instancias activas y en espera de estilo EC2. Sin embargo, el backend aún debe considerarse por separado:

  • Concurrencia lambda.
  • VPC Link。
  • ALB/NLB tiene múltiples AZ.
  • La base de datos tiene varias AZ.
  • Recuperación ante desastres entre regiones.

20. Monitoreo y registro

Se recomienda habilitar al menos los siguientes elementos.

Direct Connect

Monitorear:


ConnectionState
VirtualInterfaceBpsIngress
VirtualInterfaceBpsEgress
VirtualInterfacePpsIngress
VirtualInterfacePpsEgress
estado BGP

Y ejecute la prueba de conmutación por error de BGP para confirmar que el enlace de respaldo realmente puede hacerse cargo. AWS Resiliency Toolkit admite la verificación de rutas redundantes cerrando temporalmente la sesión BGP.

Route 53 Resolver

Habilitar:


Resolver Query Logging
CloudWatch Resolver Endpoint Metrics

Consultar los registros puede ayudar a confirmar:

  • Si se ha recibido una consulta de nombre de dominio.
  • De qué VPC proviene la consulta.
  • Tipo de consulta.
  • Devolver resultados.

Cabe señalar que las consultas repetidas realizadas por la caché del Resolver generalmente no aparecen en el Registro de consultas como cada consulta independiente.

VPC

Habilitar:


VPC Flow Logs

Aspectos destacados:

  • Resolver Endpoint ENI。
  • execute-api Endpoint ENI。
  • Tráfico relacionado con TGW.
  • ACCEPT/REJECT。
  • IP de origen, IP de destino, puerto.

API Gateway

Habilitar:


Access Logs
Execution Logs
Detailed Metrics
Rayos X de AWS, bajo demanda

Se recomienda que los registros de acceso contengan al menos:


$requestId
$context.identity.sourceIp
$context.domainName
$context.httpMethod
$context.resourcePath
$context.status
$context.responseLength
$context.integrationErrorMessage

21. Secuencia de prueba estándar

No ejecute simplemente curl inicialmente, pruebe por capa.

Paso 1: Verifique BGP y enrutamiento

El enrutador externo confirma que ha aprendido:


10.20.0.0/16

La parte de AWS confirma que ha aprendido:


172.20.0.0/16

Paso 2: Pruebe el punto final del Resolver directamente


dig @10.20.10.10 api.partner.example.com A
dig @10.20.20.10 api.partner.example.com A

Paso 3: Pasar las pruebas formales de DNS realizadas por una empresa externa


dig api.partner.example.com A

Se debe devolver la IP privada del punto final.

Paso 4: Pruebe TCP 443


nc -vz api.partner.example.com 443

O:


telnet api.partner.example.com 443

Paso cinco: verifique el certificado TLS


openssl s_client \
  -connect api.partner.example.com:443 \
  -servername api.partner.example.com

Comprobar:


Subject Alternative Name
Issuer
Validity
TLS version
Certificate chain

Paso 6: Llame al control médico


curl -v https://api.partner.example.com/v1/health

Paso 7: Llamar con autenticación

Ejemplo de JWT:


curl -v \
  -H "Authorization: Bearer ${TOKEN}" \
  https://api.partner.example.com/v1/orders

Los escenarios SigV4 pueden utilizar el SDK, AWS CLI o la biblioteca de firmas correspondiente que admita firmas.

22. Faltas comunes y métodos de juicio.

1. Tiempo de espera de solicitud de DNS

Rendimiento:


tiempo de espera de excavación

Controles prioritarios:


DNS externo a enrutamiento IP de resolución
enrutamiento TGW
Enrutamiento de subred VPC
Resolver SG UDP/TCP 53
cortafuegos externo
NACL

2. DNS devuelve NXDOMAIN

Significa que la red y el servidor DNS pueden estar conectados, pero hay un problema con la capa de registro.

Comprobar:


Nombre de la zona alojada privada
Un registro de alias
La zona alojada está asociada con la VPC
¿Es correcto el FQDN consultado?
¿Existe una zona alojada de conflictos más específica?

3. El nombre de dominio se puede resolver, pero el tiempo de espera de TCP 443 se agota.

Comprobar:


execute-api Endpoint SG
Enrutamiento externo al endpoint ENI
NACL
Enrutamiento de retorno TGW
cortafuegos externo

4. El nombre del certificado TLS no coincide

Por ejemplo el certificado es:


*.example.com

Pero el nombre de dominio es:


api.partner.example.com

*.example.com solo cubre una capa:


api.example.com

Generalmente no está cubierto:


api.partner.example.com

Se debe utilizar:


*.partner.example.com

o certificado exacto:


api.partner.example.com

5. Devolver 403 Prohibido

Consultar orden:


¿Está DISPONIBLE la Asociación de Acceso a Nombres de Dominio?
Domain Resource Policy
API Resource Policy
VPC Endpoint Policy
MétodoAutorización
Firma JWT/IAM
API Key/Usage Plan

6. Devolver el token de autenticación faltante

Razones comunes:


Error de ruta base
Error de mapeo de etapa
error del método HTTP
La ruta de recursos no existe
API no redistribuida

Por ejemplo, Mapeo real:


/v1 → prod

Correcto:


https://api.partner.example.com/v1/orders

Error:


https://api.partner.example.com/prod/orders

7. Se puede acceder a la URL de ejecución de API predeterminada, pero no al dominio personalizado

Puntos clave a comprobar:


certificado ACM
Estado de dominio privado
Domain Resource Policy
Domain Access Association
API Mapping
Route 53 Alias
Host/SNI

8. Se puede acceder dentro de la VPC, pero no por empresas externas.

Generalmente se dice:


La configuración de API Gateway es básicamente correcta
El problema se centra en el enrutamiento DX, Endpoint SG o DNS externo.

9. Las solicitudes pequeñas son normales, pero las solicitudes grandes fallan.

Comprobar:


MTU
PMTUD
ICMP Fragmentation Needed
cortafuegos intermedio
Jumbo Frame

23. Los diez lugares que más fácilmente se pierden

  1. Direct Connect no se cifra automáticamente.
  2. DNS y HTTPS son dos rutas diferentes.
  3. El extremo Resolver debe abrir tanto UDP como TCP 53.
  4. La zona alojada privada debe estar asociada con la VPC donde se encuentra el Resolver.
  5. El objetivo de alias es el extremo de VPC de ejecución de API, no el solucionador.
  6. El grupo de seguridad de endpoint execute-api debe permitir el segmento de red de origen de la empresa externa TCP 443.
  7. La política de dominio privado y la política de API privada son dos políticas.
  8. debe crear una Asociación de Acceso a Nombre de Dominio.
  9. Es necesario volver a implementar después de modificar la asociación o el recurso del punto final de la API.
  10. El registro de verificación de DNS del certificado público ACM debe poder consultarse desde el DNS público y no puede colocarse únicamente en la zona alojada privada.

24. Configuración de producción final recomendada

Se recomienda la siguiente configuración para sistemas B2B formales:


Dos conexiones directas
+ Enlace de respaldo VPN

Transit VIF
+ Direct Connect Gateway
+ Transit Gateway

VPC de servicios compartidos independientes

Punto final entrante de resolución de dos AZ
+ Solo permitir servidores DNS oficiales UDP/TCP 53

Punto final de interfaz de ejecución-api de dos AZ
+ Permitir solo el segmento de red comercial externo TCP 443

Subdominio privado dedicado
api.partner.example.com

Private Custom Domain
+ Certificado ACM
+ Domain Access Association

Private Domain Policy
+ API Resource Policy
+ Endpoint Policy
Todas las restricciones aws:SourceVpce

Autenticación JWT o IAM SigV4
+ API Gateway Access Logs
+ Resolver Query Logs
+ VPC Flow Logs
+ Alerta DX CloudWatch

El enlace final se puede resumir como:


DNS：
DNS externo
→ Direct Connect
→ Resolver Inbound Endpoint
→ Private Hosted Zone
→ Volver a la IP privada del endpoint de VPC

HTTPS：
Sistema empresarial externo
→ Direct Connect
→ execute-api Interface Endpoint
→ Private Custom Domain
→ API Mapping
→ Private REST API
→ Servicios de back-end