Conectar AWS y Google Cloud

Antes de replicar datos o mover tráfico entre proveedores necesitas tres cosas: un camino de red privado y redundante, direcciones y nombres que funcionen igual de los dos lados, e identidades que se reconozcan sin llaves guardadas en archivos. Esta lección arma esa base. Los conceptos de red de Google Cloud están en redes en Google Cloud; los de AWS, en conectar redes.

Las piezas de cada lado

Los nombres cambian, pero las funciones se corresponden casi una a una. La diferencia más visible: en Google Cloud la VPC es global y el Cloud Router es regional; en AWS la VPC es regional y el punto de reunión suele ser un Transit Gateway.

Criterio	En Google Cloud	En AWS
Extremo de la VPN	HA VPN gateway, con dos interfaces y una IP pública en cada una	Site-to-Site VPN connection, con dos túneles por conexión, sobre un Transit Gateway o un virtual private gateway
Quién representa al otro lado	External VPN gateway, con las cuatro IP de los túneles de AWS	Customer gateway, uno por cada interfaz del gateway de Google
Rutas dinámicas	Cloud Router (BGP), regional	BGP en cada túnel; ECMP entre túneles solo con Transit Gateway
Enlace dedicado	Cloud Interconnect: Dedicated, Partner y Cross-Cloud Interconnect	AWS Direct Connect y AWS Interconnect – multicloud
Reenvío de DNS	Cloud DNS: zonas de reenvío y política de servidor entrante	Route 53 Resolver: endpoints de salida y de entrada con reglas de reenvío
Confiar en identidades externas	Workload Identity Federation	Proveedores OIDC en IAM y IAM Roles Anywhere

HA VPN contra Site-to-Site VPN: la topología de cuatro túneles

Es el punto de partida en casi todos los proyectos: se arma en una tarde, va cifrada con IPsec y no exige contratos físicos. La guía oficial de Google para conectar con AWS define una topología concreta:

1. 1

   Un HA VPN gateway en Google Cloud

   Tiene dos interfaces (0 y 1), cada una con su IP pública. Si configuras una sola interfaz activa, el gateway no tiene SLA.
2. 2

   Dos customer gateways y dos conexiones en AWS

   Un customer gateway por cada IP de Google y una Site-to-Site VPN connection por cada uno. Cada conexión trae dos túneles: cuatro en total.
3. 3

   Cuatro túneles con BGP

   Cada túnel lleva una sesión BGP con el Cloud Router. La guía dice que cuatro es el mínimo para el SLA de 99,99 % del lado de Google. Ese SLA cubre solo la parte de Google; AWS tiene el suyo.
4. 4

   IKEv2 y un solo juego de algoritmos

   Los juegos por defecto de AWS generan mensajes IKE grandes que se fragmentan, y Cloud VPN no acepta IKE fragmentado. Fija una sola combinación de cifrado, integridad y grupo Diffie-Hellman por fase.
5. 5

   Transit Gateway mejor que virtual private gateway

   Con Transit Gateway y ECMP el tráfico se reparte entre los túneles activos. Con un virtual private gateway solo un túnel lleva tráfico a la vez.

# Google Cloud: gateway HA VPN (dos interfaces) y Cloud Router con BGP
gcloud compute vpn-gateways create gw-aws \
  --network=core --region=southamerica-east1 --stack-type=IPV4_ONLY

gcloud compute routers create cr-aws \
  --network=core --region=southamerica-east1 --asn=65534 \
  --advertisement-mode=custom --set-advertisement-groups=all_subnets \
  --set-advertisement-ranges=35.199.192.0/19   # rango de Cloud DNS, para el DNS de vuelta

# Gateway externo con las cuatro IP públicas de los túneles de AWS
gcloud compute external-vpn-gateways create aws-peer \
  --interfaces 0=IP_AWS_T1,1=IP_AWS_T2,2=IP_AWS_T3,3=IP_AWS_T4

# Un túnel por IP de AWS: la interfaz 0 va a 0 y 1; la interfaz 1 va a 2 y 3
gcloud compute vpn-tunnels create t0 --region=southamerica-east1 \
  --vpn-gateway=gw-aws --interface=0 \
  --peer-external-gateway=aws-peer --peer-external-gateway-interface=0 \
  --router=cr-aws --ike-version=2 --shared-secret=SECRETO_T0

# AWS: un customer gateway por interfaz de Google y una conexión VPN por cada uno
aws ec2 create-customer-gateway --type ipsec.1 --bgp-asn 65534 --ip-address IP_GCP_INTERFAZ_0
aws ec2 create-customer-gateway --type ipsec.1 --bgp-asn 65534 --ip-address IP_GCP_INTERFAZ_1
aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-0aaa --transit-gateway-id tgw-0bbb

El techo de ancho de banda llega rápido. Cada túnel de HA VPN soporta 250 000 paquetes por segundo, entre 1 y 3 Gbps según el tamaño de paquete. Un túnel estándar de Site-to-Site VPN llega hasta 1,25 Gbps, y uno de gran ancho de banda hasta 5 Gbps. Para más capacidad agregas túneles, pero el viaje sigue pasando por internet: la latencia varía con el «clima» de la red.

Interconnect: la vía férrea privada

Cuando la replicación o el tráfico entre servicios crecen, pasas a un enlace dedicado. Hay tres caminos:

• Cross-Cloud Interconnect: Google tiende y administra la conexión física entre su red y la de AWS en una instalación donde ambos están presentes. Tú compras los puertos de Direct Connect en AWS (en grupos LAG con LACP), descargas la carta de autorización indicando «Google-Cloud» como proveedor y se la entregas a Google. Del lado de AWS creas un Direct Connect gateway y una interfaz virtual privada por cada LAG. Para AWS hay puertos de 10, 100 y 400 Gbps. El 99,99 % exige dos pares de conexiones en dos áreas metropolitanas, o un diseño de una región con los adjuntos en dominios de disponibilidad distintos. Tarda semanas.
• AWS Interconnect – multicloud (Partner Cross-Cloud Interconnect for AWS en Google): un producto administrado en conjunto por los dos proveedores, disponible desde abril de 2026. Lo pides desde cualquiera de las dos consolas con una clave de activación y queda listo en minutos, sin puertos ni BGP que configurar. En AWS se ancla a un Direct Connect gateway; en Google, al Cloud Router. La redundancia viene incluida (cuatro conexiones en al menos dos edificios) y el tramo entre los equipos de ambos va cifrado con MACsec. Solo existe en algunos pares de regiones: revisa si los tuyos están.
• Partner Interconnect más Direct Connect por un socio: si ya tienes presencia en una instalación de colocación o contratas a un proveedor de red que llega a las dos nubes, el socio une ambos extremos. Tú administras más piezas y dos contratos con el socio.

Google agrupa estas piezas bajo el nombre Cross-Cloud Network: una arquitectura de referencia con una VPC de tránsito, Network Connectivity Center y Private Service Connect para que varias nubes se comporten como una sola red. Es una forma de organizar el diseño, no un producto que se enciende.

Criterio	HA VPN + Site-to-Site VPN	Cross-Cloud Interconnect	AWS Interconnect – multicloud	Partner Interconnect + Direct Connect
Ancho de banda	1 a 3 Gbps por túnel en Google; 1,25 o 5 Gbps por túnel en AWS	10, 100 o 400 Gbps por puerto	De 1 a 100 Gbps, ajustable sin reaprovisionar	Lo que venda el socio
Latencia	Variable: va por internet	Estable	Estable	Estable, con un salto más
Tiempo para tenerlo	Horas	Semanas	Minutos, en los pares de regiones disponibles	Días o semanas
Quién opera lo físico	Nadie: es lógico	Google, hasta la red de AWS	AWS y Google juntos	El socio
Cifrado	IPsec incluido	MACsec opcional o HA VPN encima	MACsec entre equipos, por defecto	Agrega HA VPN encima
Cuándo conviene	Empezar, poco volumen o camino de respaldo	Volumen alto y estable, con equipo de red	Volumen alto sin operar hardware	Ya tienes colocación o un socio de red

Un plan de direcciones para las dos nubes

Si un rango se repite en las dos nubes, el enrutamiento no tiene arreglo limpio: terminas con NAT entre redes privadas y nombres que resuelven a la IP equivocada. Reparte el espacio antes de crear la primera subred, con el mismo cuidado que en direcciones IP y CIDR. Un ejemplo:

DNS entre nubes

Las cargas de cada nube tienen que resolver los nombres privados de la otra. El patrón es el mismo de DNS híbrido, con Google Cloud en el lugar del centro de datos:

1. 1

   De Google Cloud hacia AWS

   Creas un endpoint de entrada de Route 53 Resolver en la VPC de AWS. En Cloud DNS creas una zona de reenvío privada, por ejemplo aws.interno., que apunta a las IP de ese endpoint.
2. 2

   De AWS hacia Google Cloud

   Creas una política de servidor entrante en la VPC de Google: te da direcciones internas que aceptan consultas. En AWS, un endpoint de salida de Resolver y una regla de reenvío para gcp.interno. hacia esas direcciones.
3. 3

   La ruta de vuelta

   Cloud DNS envía las consultas reenviadas desde 35.199.192.0/19 y la respuesta tiene que volver por el mismo túnel o adjunto. Con BGP, lo anuncias en el Cloud Router como ruta personalizada.
4. 4

   Firewall en los dos lados

   Abre TCP y UDP 53 en los security groups de los endpoints de Resolver y en las reglas de firewall de Google.

Identidad entre nubes sin llaves de larga duración

El atajo peligroso es crear una llave JSON de service account en Google y guardarla en AWS, o una access key de IAM y guardarla en Google. Son secretos que se filtran, no rotan solos y nadie recuerda dónde están. Las dos nubes ofrecen federación:

• De AWS hacia Google Cloud: Workload Identity Federation. La carga en AWS firma una petición GetCallerIdentity de STS con sus credenciales temporales; Google la verifica con AWS y entrega un token de corta vida. No cambias nada en la cuenta de AWS. Mapeas atributos (por ejemplo, el rol que asumió la sesión) y limitas con una condición quién puede entrar. Google recomienda dar permisos directos al principal federado y usar la suplantación de una service account solo donde una API lo exija.
• De Google Cloud hacia AWS: la carga pide al servidor de metadatos un ID token firmado por Google para su service account y llama a AssumeRoleWithWebIdentity. La política de confianza del rol acepta a accounts.google.com como proveedor y exige el identificador único de esa service account. Si la carga no puede obtener tokens de Google, IAM Roles Anywhere entrega credenciales temporales a cambio de un certificado X.509 de tu propia autoridad.
• La opción más nueva: la federación saliente de IAM permite que un rol de AWS obtenga un JWT firmado con GetWebIdentityToken, que un servicio externo verifica contra el emisor de tu cuenta. Google puede confiar en él como proveedor OIDC. No sirve para entrar a AWS.

# Google Cloud: un pool y un proveedor que confían en una cuenta de AWS
gcloud iam workload-identity-pools create aws-prod --location=global

gcloud iam workload-identity-pools providers create-aws cuenta-prod \
  --location=global --workload-identity-pool=aws-prod --account-id=111122223333 \
  --attribute-mapping="google.subject=assertion.arn,attribute.aws_role=assertion.arn.extract('assumed-role/{role}/')" \
  --attribute-condition="assertion.arn.startsWith('arn:aws:sts::111122223333:assumed-role/replicador/')"

# Acceso directo al recurso para las sesiones de ese rol (sin service account)
gcloud storage buckets add-iam-policy-binding gs://respaldos-dr \
  --role=roles/storage.objectCreator \
  --member="principalSet://iam.googleapis.com/projects/NUMERO_PROYECTO/locations/global/workloadIdentityPools/aws-prod/attribute.aws_role/replicador"

# Archivo de configuración para las librerías de Google: no contiene ningún secreto
gcloud iam workload-identity-pools create-cred-config \
  projects/NUMERO_PROYECTO/locations/global/workloadIdentityPools/aws-prod/providers/cuenta-prod \
  --aws --enable-imdsv2 --output-file=gcp-cred.json

Cifrar y vigilar los enlaces

La VPN ya va cifrada. Un interconnect, no necesariamente: el tráfico viaja por un enlace privado, pero en claro a nivel de red. Tienes tres capas posibles: MACsec en el enlace (opcional en Cross-Cloud Interconnect, incluido entre los equipos de AWS Interconnect – multicloud), HA VPN sobre el interconnect si una norma exige IPsec, y TLS de punta a punta en cada conexión de aplicación y de base de datos. La última no es opcional: cifra aunque el camino sea privado.

Vigila el enlace como un componente crítico. En Google, el estado de cada sesión BGP del Cloud Router y el tráfico por túnel en Cloud Monitoring. En AWS, la métrica TunnelState de cada túnel en CloudWatch y, con AWS Interconnect, el Network Synthetic Monitor incluido que mide latencia y pérdida. Alarma sobre sesiones BGP caídas y sobre rutas aprendidas que desaparecen, no solo sobre túneles abajo: un túnel arriba sin rutas no lleva nada.

Con la red y la identidad listas, sigue con replicar datos entre nubes. La jerarquía de proyectos y el IAM de Google se repasan en de AWS a Google Cloud.