Salida de VPC directa

La salida de VPC directa proporciona una solución de redes de alto rendimiento para que tu servicio de App Engine envíe tráfico a una red de nube privada virtual (VPC). La salida de VPC directa permite que las cargas de trabajo accedan sin problemas a los recursos de la red de VPC y elimina la necesidad de configurar conectores de Acceso a VPC sin servidores.

Ventajas clave

• Administración simplificada: Elimina la sobrecarga operativa de administrar instancias de conector, tipos de máquinas y parámetros de configuración de escalamiento. App Engine controla las configuraciones directamente en el archivo app.yaml de tu servicio.
• Rentabilidad: El uso de la salida de VPC directa no tiene un cargo adicional y no tienes que pagar cargos mensuales fijos por las VMs de conector.
• Rendimiento y confiabilidad mejorados: Como elimina la necesidad de usar un conector, la salida de VPC directa ofrece una conexión más rápida y confiable a los recursos de tu red de VPC. Se escala con la misma rapidez que tu servicio de App Engine y evita las interrupciones de conexión que podrían ocurrir con los conectores durante el mantenimiento.

• Seguridad detallada: Puedes aplicar etiquetas de red directamente a tus versiones del servicio de App Engine, lo que habilita reglas de firewall y políticas de red precisas y específicas del servicio.

• Admite registros de flujo de VPC: Puedes habilitar los registros de flujo de VPC en tu subred para registrar el tráfico de salida de tu servicio de App Engine.

• Admite Cloud NAT: Puedes configurar una puerta de enlace de Cloud NAT en tu subred para proporcionar servicios de NAT, como NAT pública o NAT privada, para el tráfico saliente de tu servicio de App Engine.

Limitaciones

• Consumo de direcciones IP: El uso de direcciones IP de tu servicio escala directamente con la cantidad de instancias en ejecución, y tu capacidad de escalamiento está limitada por la cantidad de direcciones IP disponibles en la subred que elegiste.

• Eventos de mantenimiento: Es posible que tu servicio experimente interrupciones breves de la conexión durante los eventos de mantenimiento de la infraestructura de red. Te recomendamos que uses bibliotecas cliente para controlar los restablecimientos ocasionales de la conexión.

• Inicios en frío: Los tiempos de inicio en frío iniciales dependen de la región y del caso de uso específico. En casos excepcionales, los inicios en frío pueden durar hasta un minuto.

• Entrada de VPC directa: App Engine no admite la entrada de VPC directa.

• Cantidad de instancias: De forma predeterminada, solo puedes configurar hasta 100 instancias por versión de App Engine para usar la salida de VPC directa. Puedes solicitar un aumento de cuota para este límite si tu carga de trabajo requiere más instancias.

  Nota: A partir de marzo de 2025, para las aplicaciones nuevas, si no configuraste max_instances en tu archivo app.yaml, App Engine establece este campo en 20. En el caso de las aplicaciones creadas antes de marzo de 2025, App Engine establece este campo en tu cuota de instancias de VPC directa, que es 100 de forma predeterminada.

• Registros de flujo de VPC: No muestra la versión de tu servicio de App Engine en los registros. El nombre del servicio se muestra en el campo AppEngineServiceDetails.

• Disponibilidad regional: La salida de VPC directa solo está disponible por invitación en ciertas regiones. Para solicitar acceso en estas regiones, comunícate con el equipo de asistencia.

Asignación de direcciones IP

Para colocar tu servicio de App Engine en una red de VPC, especifica una red de VPC, una subred o ambas. Si solo especificas una red, la subred usará el mismo nombre que la red. App Engine asigna direcciones IP desde tu subred.

Las direcciones IP son efímeras, por lo que no debes crear políticas basadas en IPs individuales. Si necesitas crear una política basada en IPs, como en reglas de firewall, debes usar el rango de direcciones IP de toda la subred.

Para cambiar la red o subred que usa tu servicio, implementa una versión nueva que use los valores de red y subred nuevos.

Aumenta o reduce la escala verticalmente

Para un escalamiento vertical más rápido durante un aumento de tráfico, App Engine reserva direcciones IP en bloques de 16 (máscara de subred 28) a la vez. Para asegurarte de tener suficientes direcciones IPv4 disponibles para usar en App Engine, el rango de direcciones IPv4 de tu subred debe ser /26 o mayor.

Para obtener eficiencia de la asignación de IP y facilidad de administración, coloca varios recursos en la misma subred. Si el espacio de dirección IPv4 es limitado, consulta Rangos de IPv4 compatibles para obtener más opciones.

Para borrar la subred, primero debes borrar o volver a implementar el servicio de App Engine para dejar de usar la subred y, luego, esperar entre 1 y 2 horas.

Consumo de direcciones IP para servicios

En estado estable, App Engine usa 2 veces (2X) más direcciones IP que la cantidad de instancias. Cuando una versión se reduce, App Engine conserva sus direcciones IP durante un máximo de 20 minutos. En total, reserva al menos el doble de la cantidad de direcciones IP, más un margen para tener en cuenta las actualizaciones de versión.

Por ejemplo, si actualizas las versiones para que version 1 reduzca la escala verticalmente de 100 instancias a cero, mientras que version 2 aumenta la escala verticalmente de cero a 100, App Engine conserva las direcciones IP de version 1 durante un máximo de 20 minutos después de reducir la escala verticalmente. Durante el período de retención de 20 minutos, debes reservar al menos 400 direcciones IP ((100 + 100) * 2).

Rangos de IPv4 compatibles

App Engine admite los siguientes rangos IPv4 para tu subred:

• RFC 1918
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
• RFC 6598
  • 100.64.0.0/10
• Clase E
  • 240.0.0.0/4

Nota: Prueba configuraciones que no sean RFC 1918 para identificar posibles problemas de compatibilidad con recursos o hardware que no sean deGoogle Cloud . Obtén más información para crear subredes con rangos de IP que no sean RFC 1918.

Antes de comenzar

1. Asegúrate de tener una red de VPC y una subred existentes en tu proyecto. Si aún no tienes una VPC, sigue las instrucciones para crear una en Crea una red de VPC.

2. Habilita la API de Compute Engine y la API de Cloud Build:

   Habilita las API

3. Para usar la salida de VPC directa, asegúrate de ejecutar la versión más reciente de Google Cloud CLI:

   gcloud components update

Roles obligatorios

Asegúrate de que App Engine tenga acceso a la red de VPC otorgando los siguientes roles al agente de servicio de App Engine:

• Rol de agente de servicio de App Engine: De forma predeterminada, el agente de servicio de App Engine tiene el rol de agente de servicio de App Engine (roles/appengine.serviceAgent) que contiene los permisos necesarios.

• Permisos personalizados: Para obtener un control más detallado, otorga al agente de servicio de App Engine los siguientes permisos adicionales en el proyecto:

  • compute.networks.get
  • compute.subnetworks.get
  • compute.subnetworks.use en el proyecto host o en la subred específica
  • compute.addresses.get
  • compute.addresses.list
  • compute.addresses.create
  • compute.addresses.delete
  • compute.addresses.createInternal
  • compute.addresses.deleteInternal
  • compute.regionOperations.get

• Rol Usuario de red de Compute: Si no usas el rol predeterminado Agente de servicio de App Engine o los permisos personalizados, otorga el rol Usuario de red de Compute (roles/compute.networkUser) al agente de servicio de App Engine. Las subredes con IPv6 externa también requieren el rol de administrador de IP públicas de Compute (roles/compute.publicIpAdmin).

  Por ejemplo, para otorgar el rol de usuario de red de Compute, ejecuta el siguiente comando:

  gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service." \
  --role "roles/compute.networkUser"

  Reemplaza lo siguiente:

  • PROJECT_ID: el ID de tu proyecto.
  • PROJECT_NUMBER: Es el número de proyecto en el que implementas tu servicio de App Engine.

Configura un servicio de App Engine con la salida de VPC directa

Puedes configurar la salida de VPC directa para un servicio de App Engine con YAML o Terraform. Para habilitar o desconectar la salida de VPC directa, implementa una versión nueva y migra el tráfico a ella. También puedes borrar primero la versión implementada, en lugar de reemplazar un ID de versión existente.

YAML

1. Agrega el siguiente parámetro de configuración vpc_access a tu archivo app.yaml:

   vpc_access:
   network_interface:
    network: NETWORK
    subnet: SUBNET
    tags:
        - NETWORK_TAGS
   vpc_egress: EGRESS_SETTING

   Reemplaza lo siguiente:

   • NETWORK: Es el nombre de la red existente a la que se conectan las instancias de tu aplicación, por ejemplo, default. Especifica una red de VPC, una subred o ambas. Si solo especificas una red, la subred usa el mismo nombre que la red.

   • SUBNET: Es el nombre de la subred existente a la que se conectan las instancias de tu aplicación, por ejemplo, default. Especifica una red de VPC, una subred o ambas. Si solo especificas una red, la subred usa el mismo nombre que la red.

   • Opcional: NETWORK_TAGS enumera las etiquetas de red que se asociarán con las instancias de tu servicio de App Engine para usarlas en las reglas de firewall y las políticas de enrutamiento.

   • Opcional: EGRESS_SETTING controla cómo se enruta el tráfico saliente. Este campo admite los siguientes parámetros de configuración:

     • all-traffic: Todas las solicitudes salientes se enrutan a través de la red de VPC.
     • private-ranges-only (predeterminado): Solo el tráfico a direcciones IP internas se enruta a través de la red de VPC. El tráfico de Internet usa la ruta predeterminada de App Engine.

2. Ejecuta el siguiente comando para implementar en App Engine:

   gcloud app deploy

Terraform

Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform.

1. Agrega el siguiente bloque vpc_access a un recurso google_app_engine_standard_app_version en tu configuración de Terraform:

   vpc_access {
   vpc_egress = "EGRESS_SETTING"
   network_interfaces {
    network    = "NETWORK"
    subnetwork = "SUBNET"
    tags       = ["TAG_1", "TAG_2"]
   }
   }

   Reemplaza lo siguiente:

   • NETWORK: Es el nombre de la red de VPC existente a la que se conectan las instancias de tu aplicación, por ejemplo, default. Especifica una red de VPC, una subred o ambas. Si solo especificas una red, la subred usa el mismo nombre que la red. También puedes hacer referencia a un nombre de recurso de google_compute_network (por ejemplo, google_compute_network.custom.name).
   • SUBNET: Es el nombre de la subred existente a la que se conectan las instancias de tu aplicación, por ejemplo, default. Especifica una red de VPC, una subred o ambas. Si solo especificas una red, la subred usa el mismo nombre que la red. También puedes hacer referencia a un nombre de recurso de google_compute_subnetwork (por ejemplo, google_compute_subnetwork.custom.name).
   • Opcional: TAG_1, TAG_2 enumera las etiquetas de red que se asociarán con las instancias de tu servicio de App Engine para usarlas en reglas de firewall y políticas de enrutamiento.
   • Opcional: EGRESS_SETTING controla cómo se enruta el tráfico saliente. Este campo admite los siguientes parámetros de configuración:
   • ALL_TRAFFIC: Todas las solicitudes salientes se enrutan a través de la red de VPC.
   • PRIVATE_IP_RANGES (predeterminado): Solo el tráfico a direcciones IP internas se enruta a través de la red de VPC. El tráfico de Internet usa la ruta predeterminada de App Engine.

2. Si la versión ya se implementó sin la salida de VPC directa, actualiza el campo version_id a un valor nuevo. No puedes habilitar la salida de VPC directa en una versión existente.

3. Aplica la configuración:

   terraform apply

Desconecta un servicio

Para desconectar tu servicio de la red de VPC, usa YAML o Terraform:

YAML

1. Quita la sección vpc_access del archivo app.yaml.

2. Vuelve a implementar tu servicio:

   gcloud app deploy

Terraform

1. Quita el bloque vpc_access del recurso google_app_engine_standard_app_version en tu configuración de Terraform.

2. Actualiza el campo version_id a un valor nuevo. No puedes inhabilitar la salida de VPC directa en una versión existente.

3. Aplica la configuración:

   terraform apply

Aísla el tráfico de Internet saliente

De forma predeterminada, cuando vpc_egress se establece en private-ranges-only, App Engine envía tráfico de Internet saliente a través de un grupo regional de direcciones IP dinámicas compartidas entre las cargas de trabajo sin servidores. No uses este grupo compartido predeterminado para cargas de trabajo que dependan de la reputación de IP o que generen un tráfico de sondeo de gran volumen.

En su lugar, configura vpc_egress: all-traffic y enruta el tráfico saliente a través de Cloud NAT con direcciones IP salientes estáticas dedicadas en estos casos:

• Tu servicio se conecta a extremos externos sensibles a la reputación, como puertas de enlace de pago, bases de datos alojadas o APIs de socios detrás de firewalls de aplicaciones web (WAF) de terceros. Las direcciones IP estáticas dedicadas evitan que el tráfico ruidoso de otros usuarios del grupo compartido active bloqueos de WAF externos o errores HTTP 403.
• Tu servicio ejecuta análisis de red autorizados, enumeración de puertos, huellas digitales de host, sondeo de vulnerabilidades, extracción de datos web o pruebas de carga. Ejecutar estas cargas de trabajo en el grupo de IP compartido predeterminado degrada la reputación de la IP, puede interrumpir el servicio para otros clientes, lo que infringe la Política de Uso Aceptable deGoogle Cloud , y puede hacer que Google limite o suspenda tu carga de trabajo.

Cuando ejecutes análisis autorizados o cargas de trabajo de alta conexión a través de Cloud NAT, asigna suficientes direcciones IP estáticas y configura la reserva de puertos para evitar el agotamiento de puertos.

Solucionar problemas

En esta sección, se describen los errores comunes que puedes encontrar cuando implementas tu servicio de App Engine con la salida de VPC directa.

No se puede borrar la subred

Para borrar una subred, primero debes borrar o volver a implementar todos los recursos que la usen. Si App Engine usa una subred, desconecta el servicio de App Engine de la red de VPC o muévelo a una subred diferente antes de borrar la subred.

Después de borrar o mover el servicio de App Engine, espera entre 1 y 2 horas para que App Engine libere las direcciones IP antes de borrar la subred.

Fallas de Deployment

Si la implementación falla, Google Cloud CLI muestra mensajes de error que indican la causa raíz. Estos son algunos problemas comunes:

• Metadatos de VPC incorrectos, como un nombre de red o subred mal escrito en tu archivo app.yaml. Para corregir posibles errores, revisa la configuración de VPC en tu archivo app.yaml.

• Permisos de IAM insuficientes. Asegúrate de otorgar los permisos necesarios al agente de servicio de App Engine. Si encuentras errores de permisos durante la implementación, asegúrate de otorgar los siguientes roles adicionales a tu cuenta de servicio de implementación:

  • Cuenta de servicio de Cloud Build (roles/cloudbuild.builds.builder)
  • Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator)

Agotamiento de direcciones IP

Si tu subred se queda sin direcciones IP disponibles, App Engine no puede iniciar instancias nuevas y registra un error. Para resolver este problema, expande el rango de IP de tu subred o mueve tu servicio a una subred más grande.

Filtraciones de direcciones IP

Las filtraciones de direcciones IP pueden provocar el agotamiento de estas direcciones. Es poco probable que se produzcan filtraciones de direcciones IP durante las operaciones estándar, pero pueden ocurrir por los siguientes motivos:

• El agente de servicio de App Engine solo tiene permisos para reservar direcciones (create, createInternal) y no tiene permisos para liberar direcciones (delete, deleteInternal).
• Se borró el agente de servicio de App Engine mientras estaban activas otras reservas de direcciones de Google Cloud .
• La cuenta de Facturación de Cloud se quitó y, luego, se volvió a habilitar en el proyecto mientras las reservas de direcciones sin servidores estaban activas.
• Tu proyecto de Google Cloud se borró y, luego, se restableció mientras aún existían las reservas de direcciones sin servidores.

Para resolver el problema, sigue estos pasos:

1. Consulta los siguientes registros en el Explorador de registros para identificar las direcciones filtradas:

   protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*"
   protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses"
   protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*"
   severity>=WARNING
   

   Si esta consulta no devuelve resultados, no hay filtraciones de direcciones IP y no se requiere ninguna otra acción.

2. Si tu consulta devuelve resultados, asegúrate de que el agente de servicio de App Engine tenga el rol de agente de servicio de App Engine (roles/appengine.serviceAgent). Si no puedes usar este rol, asegúrate de otorgar los otros roles y permisos necesarios al agente de servicio de App Engine.

3. Borra de forma manual las direcciones IP filtradas con la consola de Google Cloud o Google Cloud CLI:

   Console

   1. Ve a la página Direcciones IP en la consola de Google Cloud :

      Ir a Direcciones IP

   2. Selecciona las direcciones IP filtradas que identificaste en el paso anterior ejecutando la consulta.

   3. Haz clic en Liberar dirección estática para quitar las direcciones filtradas.

   gcloud

   Ejecuta el comando gcloud compute addresses delete:

   gcloud compute addresses delete ADDRESS_NAME --region=REGION

   Reemplaza lo siguiente:

   • ADDRESS_NAME: Es el nombre de la dirección IP filtrada.
   • REGION: Es la región de la dirección IP filtrada.