Resumen

Cuando trabajas con infraestructura en la nube, no solo importa la capacidad de procesamiento o la memoria. La red es un recurso igual de crítico, y en Google Cloud Platform toda la infraestructura de red está virtualizada. Google define su red como una software-defined network [0:18], lo que significa que cada componente de red es una entidad lógica controlada por software, sin necesidad de que alguien conecte cables físicamente para habilitar tus servicios.

¿Cómo está organizada la infraestructura global de Google Cloud?

Google Cloud se estructura a partir de regiones, que son ubicaciones geográficas donde existen centros de datos. Cada región puede contener múltiples zonas (o data centers) [2:00]. Por ejemplo, la región de Los Ángeles, identificada como US West 2, cuenta con tres zonas disponibles. Esto explica la diferencia entre recursos regionales (distribuidos en todas las zonas de una región) y recursos zonales (ubicados en un solo data center).

Todas estas regiones están interconectadas mediante la red privada de Google, compuesta por cables submarinos y terrestres de los cuales Google es dueño total o parcial a través de consorcios [2:30]. Esto le garantiza capacidad y prioridad de ancho de banda.

¿Qué son los puntos de presencia y por qué importan?

Además de las regiones, existen puntos de presencia [3:15]. Estos no son centros de datos completos, sino infraestructura de Google que conecta a los usuarios y enruta el tráfico hacia la red privada, reduciendo la latencia. Un ejemplo práctico: si estás en Perú o Ecuador, puede resultarte más rápido salir por cables submarinos hacia Panamá, llegar a Florida y desde ahí incorporarte a la red de Google, en lugar de conectarte directamente a una región en Brasil [3:40].

  • Identifica dónde están tus usuarios antes de elegir una región.
  • Busca cercanía lógica, no necesariamente física.
  • Aprovecha los puntos de presencia para reducir latencia.

¿Qué es una VPC y qué tipos existen?

El concepto central de la red en Google Cloud es la VPC (Virtual Private Cloud) [4:30]. Es tu propia red virtual dentro del contexto de un proyecto. De forma predeterminada puedes tener hasta cinco VPC por proyecto, aunque es posible solicitar una ampliación.

La VPC permite agrupar y aislar recursos de manera lógica. Puedes tener máquinas virtuales en VPC distintas que no se comuniquen entre sí, lo cual es fundamental para la seguridad y la organización de tu arquitectura.

Existen tres tipos de VPC [5:20]:

  • Default: se crea automáticamente con cada proyecto nuevo, incluye recursos aprovisionados en todas las regiones y reglas de firewall predeterminadas. No se recomienda para producción porque puede ser demasiado permisiva o restrictiva.
  • Auto: similar a la default, aprovisiona recursos en todas las regiones, pero te permite decidir sobre las reglas de firewall.
  • Custom: no tiene valores predeterminados [6:40]. Tú defines cada subred, los rangos de red, las regiones y todas las reglas de firewall. Es la opción recomendada para producción.

¿Por qué evitar la red default en producción?

La red default viene con reglas de firewall preconfiguradas que podrían exponer tus recursos más de lo deseado [5:50]. Funciona bien para hacer pruebas iniciales y familiarizarte con el entorno, pero para cargas de trabajo reales necesitas control total sobre la seguridad y la visibilidad de tus servicios.

¿Cómo funcionan las reglas de firewall en una VPC?

Las reglas de firewall son un conjunto de instrucciones para autorizar o rechazar tráfico entrante o saliente [7:10]. Existen dentro del contexto de cada VPC, y se pueden aplicar a todas las máquinas virtuales o de forma específica usando network tags o cuentas de servicio.

Al crear una regla desde línea de comandos, defines varios parámetros [7:50]:

  • Red: sobre cuál VPC se aplica.
  • Prioridad: cuando hay reglas contradictorias, la prioridad determina cuál prevalece.
  • Dirección: tráfico entrante (ingress) o saliente (egress).
  • Acción: permitir o rechazar.
  • Protocolo y puerto: por ejemplo, TCP en el puerto 443 para comunicaciones seguras.

Un caso típico: un front end expuesto a Internet y un back end aislado en subredes distintas [8:50]. Para que se comuniquen, defines una regla de firewall que permita tráfico TCP por el puerto 443, manteniendo el back end protegido del acceso externo.

Si quieres dominar estos conceptos, el siguiente paso es ponerlos en práctica creando tus propias VPC y configurando reglas de firewall. ¿Qué tipo de arquitectura estás diseñando y qué retos de red has encontrado?