Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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.
Eficiencia de costos: El uso de la salida de VPC directa no tiene cargos adicionales 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.

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: Solo puedes configurar hasta 100 instancias por versión de App Engine para usar la salida de VPC directa.
Registros de flujo de VPC: No muestra la versión del servicio de App Engine en los registros. El nombre del servicio se muestra en el campo AppEngineServiceDetails.

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 escale de 100 instancias a cero, mientras que version 2 escala 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

Antes de comenzar

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.
Habilita la API de Compute Engine y la API de Cloud Build:

Habilita las API
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 a tu cuenta de servicio de implementación:

Rol Agente de servicio de App Engine: De forma predeterminada, el agente de servicio de App Engine tiene el rol 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) en la cuenta de servicio del Agente de servicio de App Engine. Las subredes con IPv6 externa también requieren el rol de administrador de IP pública 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

Para habilitar un servicio de App Engine nuevo o existente que se conecte directamente a tu red de VPC, sigue estos pasos:

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 usará 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 usará el mismo nombre que la red.
- Opcional: NETWORK_TAGS: Es una lista de etiquetas de red que se asocian 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-ranges-only (predeterminado): Solo el tráfico a las 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.
Ejecuta el siguiente comando para implementar en App Engine:
```
gcloud beta app deploy
```

Desconecta un servicio

Para desconectar tu servicio de la red de VPC, haz lo siguiente:

Quita la sección vpc_access de tu archivo app.yaml.
Vuelve a implementar tu servicio:
```
gcloud beta app deploy
```

Prácticas recomendadas para la administración de IP

Es necesario administrar tus direcciones IP, ya que cada instancia de tu servicio consume una dirección IP de tu subred. Usa las siguientes estrategias para administrar tus direcciones IP:

Rango de IP recomendado: Para obtener la mejor compatibilidad, te recomendamos que comiences con el rango RFC 6598 (100.64.0.0/10).
Rangos de IP alternativos: Si ya usas el rango de IP recomendado de 100.64.0.0/10, puedes usar rangos que no sean RFC 1918, como la clase E (240.0.0.0/4) en tu subred.
Tamaño de la subred: Asegúrate de que el rango de direcciones IPv4 de tu subred sea /26 o más grande para proporcionar suficientes direcciones para el escalamiento.
Aprovisiona IPs en exceso: Te recomendamos que aprovisiones en exceso la cantidad de IPs disponibles en tu subred para evitar que se agoten. Al igual que con los servicios de Cloud Run, por lo general, debes usar cuatro veces más IPs (2 veces para el estado estable y 2 veces más durante la implementación) que la cantidad de instancias en ejecución para facilitar el escalamiento y las actualizaciones sin problemas.

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 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 de 1 a 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 en tu cuenta de servicio de implementación. Si encuentras errores de permisos durante la implementación, asegúrate de otorgar los siguientes roles adicionales a la cuenta de servicio:
- 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:

Tu cuenta de servicio de implementación solo tiene permisos para reservar direcciones (create, createInternal) y no tiene permisos para liberar direcciones (delete, deleteInternal).
Se borró tu cuenta de servicio 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:

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.

Si tu consulta muestra resultados, asegúrate de que la cuenta de servicio de implementación contenga el rol de agente de servicio de App Engine (roles/appengine.serviceAgent). Si no puedes usar este rol, asegúrate de otorgar otros roles y permisos necesarios en tu cuenta de servicio de implementación.
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.