GCP: VPC compartida frente a VPC Peering entre proyectos: ¿principales diferencias?

GCP: VPC compartida frente a VPC Peering entre proyectos: ¿principales diferencias?

Estoy probando varias funciones de GCP y me encontré con la pregunta del título. Después de un poco de experimentación,pensarlo siguiente debería ser válido:

  • 2 VPC emparejadas no pueden compartir los mismos rangos de subred, mientras que VPC comparteescompartiendo las mismas subredes: si queremos que las instancias se comuniquen y ajustamos las reglas del firewall (FW),¿Hace esto alguna diferencia práctica?
  • La VPC compartida crea una relación jerárquica donde un extremoesel administrador de la red y las reglas de FW y, por lo tanto, puede dictar todas las capacidades de los proyectos de servicio y puede revocar acciones, esto también significa que la parte host debe tener acceso a los proyectos de servicio para permitirles elegirlos y permitirles usar las VPC del proyecto host. De todos modos, el emparejamiento de VPC requiere un cierto nivel de acceso a los proyectos si uno quiere emparejarlos, pero los 2 proyectos están a la par (ambos extremos deben permitir el emparejamiento):esta es una diferencia administrativa/de autenticación
  • La VPC compartida permite una configuración de FW simplificada ya que solo tiene un punto central para configurar sus reglas de FW: tiene el mismo conjunto de subredes compartidas; mientras que el peering (al igual que las VPN) requiere configurar reglas en ambos extremos:esto es una simplificación de la gestión
  • VPC compartidapoderagota sus recursos (rangos IPv4) más rápido, pero esto significa que tienes un montón de instancias conectadas...
  • El emparejamiento de VPC puede realizar transferencias (en cadena) hasta 1 nivel: tengo 1 conexión de VPC A a VPC B y una de VPC B a VPC C. VPC A y C puedennocomunicarse pero la VPC B puede comunicarse con ambos. Por el contrario, en un escenario compartido, un proyecto solo puede ser un host o un servicio al mismo tiempo, pero puedo crear un escenario con varios proyectos que comparten la misma subred y se comunican entre sí de forma transitiva...esta es probablemente la diferencia más relevante que he visto

digamos que tenemosnortediferentes proyectos connortediferentes administradores,siTodas las partes están de acuerdo en tener algún tipo de conexión de red entre instancias. ¿Hay otras ventajas o desventajas de elegir el peering en lugar del compartido?

Editar

  • tal vez esta sea la diferencia realmente más grande: si un proyecto de servicio usa una VPC compartida y luego desea eliminarla, primero debe crear una nueva VPC (o usar la predeterminada del proyecto de servicio), reasignar una nueva NIC a todas las instancias que actualmente usan la VPC compartida. deje que esta nueva NIC use la VPC propia del proyecto, rehaga las reglas de FW y verifique la conectividad correcta de todas las instancias antes de desconectarlas de la VPC compartida.
  • adicionalmente se puede utilizar el peering de VPCdentro del mismo proyectopara aumentar el aislamiento entre cargas de trabajo pero permitiendo que pocas máquinas virtuales seleccionadas se comuniquen.

Editar 2

  • A partir de ahora (2021-01), la VPC compartida se puede utilizar en una segunda NIC, pero es una función beta.
  • Además, no se pueden agregar más de 25 peering a una red, por lo tanto, es bastante común permitir que el proyecto se comunique a través de VPC compartida en los llamados diseños hub-and-spoke.
  • Acabo de descubrir que el peering de VPC se puede aplicar incluso entre diferentesorganizaciones!

Editar 3

Si bien no es una arquitectura de red estrictamente, Google ahora ofrece también acceso a servicios privados: una forma de proxy de servicios externos (incluidos aquellos en otros proyectos/VPC) a través de unaproxy en su VPC

Gracias

Respuesta1

Me gustaría agregar algo a sus excelentes hallazgos:

Respecto a compartir el mismo rango de subred, debemos tener en cuenta que ambas VPC deben pertenecer a la misma Organización. Y también quería decir que VCP compartido (XPVC) permite compartir recursos con más de un proyecto. En lugar de peering de VPC que solo permite compartir recursos entre dos proyectos.

Estoy de acuerdo con su punto de que usar XVPC es más fácil de administrar los recursos, en lugar de VPC porque cada VPC tiene sus propios recursos.

Entonces, como conclusión, la principal diferencia entre usar peering XVPC o VPC, dependerá de tus necesidades y tu experiencia en el manejo de recursos o de cuánto quieras ser práctico.

Respuesta2

Peering: El peering permite la conectividad de direcciones IP internas a través de dos redes de Nube Privada Virtual (VPC) independientemente de si pertenecen al mismo proyecto o a la misma organización. está limitado a 25 por proyecto y la transitividad no es posible.

Uso compartido de VPC: la VPC compartida permite a una organización conectar recursos de múltiples proyectos a una red común de Nube Privada Virtual (VPC), para que puedan comunicarse entre sí de forma segura y eficiente utilizando IP internas de esa red. Cuando utiliza VPC compartida, designa un proyecto como proyecto anfitrión y le adjunta uno o más proyectos de servicio. Las redes de VPC en el proyecto anfitrión se denominan redes de VPC compartidas. Los recursos elegibles de proyectos de servicio pueden usar subredes en la red VPC compartida.

información relacionada