Guía de Nomenclatura y Segmentación de Red en la Nube

Como Arquitecto de Soluciones Cloud, el propósito de este documento es establecer un conjunto de estándares y mejores prácticas para la nomenclatura de recursos y la arquitectura de red. Una base bien definida es crucial para la seguridad, escalabilidad, gestión de costos y eficiencia operativa.

1. Estándares de Nomenclatura de Recursos

Una nomenclatura coherente es fundamental para identificar rápidamente el propósito, entorno y criticidad de un recurso.

Fórmula General:

La estructura base que utilizaremos es: [entorno]-[aplicacion/servicio]-[rol/recurso]-[identificador]

• [entorno]: Ambiente del ciclo de vida (ej: prod, staging, dev, qa).
• [aplicacion/servicio]: Nombre del proyecto, aplicación o microservicio (ej: webapp, auth-api, data-pipeline).
• [rol/recurso]: El tipo específico de recurso o su función (ej: vm, eks, lb, bucket, nat).
• [identificador]: Un número secuencial o descriptor único (ej: 01, 02, primary, failover).

Ejemplos por Tipo de Recurso

Máquinas Virtuales (VMs)

• Estructura: [entorno]-[aplicacion]-[rol]-[os]-[identificador]
• Ejemplo 1: prod-webapp-frontend-linux-01
• Ejemplo 2: dev-reporting-worker-win-01

Clústeres de Kubernetes (EKS, GKE, AKS)

Clúster Principal:

• Estructura: [entorno]-[region]-[nombre-cluster]-eks
• Ejemplo 1: prod-us-east-1-main-cluster-eks
• Ejemplo 2: staging-eu-west-1-apps-cluster-gke

Grupos de Nodos:

• Estructura: [entorno]-[nombre-cluster]-[rol-nodos]-[identificador]
• Ejemplo 1: prod-main-cluster-app-nodes-01
• Ejemplo 2: prod-main-cluster-data-nodes-spot-01

Balanceadores de Carga

• Estructura: [entorno]-[aplicacion]-[visibilidad]-lb

Públicos:

• prod-webapp-public-lb
• staging-api-public-lb

Internos:

• prod-services-internal-lb
• dev-database-internal-lb

NAT Gateways

• Estructura: [entorno]-[vpc-nombre]-[az]-nat
• Ejemplo 1: prod-main-vpc-us-east-1a-nat
• Ejemplo 2: dev-main-vpc-us-east-1b-nat

Buckets de Almacenamiento

• Estructura: [organizacion]-[entorno]-[proposito]-[identificador-unico]
• Ejemplo 1: mycompany-prod-access-logs-2025
• Ejemplo 2: mycompany-prod-webapp-media-uploads
• Ejemplo 3: mycompany-dr-database-backups-iad

Cloud Functions

• Estructura: [entorno]-[aplicacion]-[trigger/proposito]-func
• Ejemplo 1: prod-users-api-post-confirmation-func
• Ejemplo 2: staging-images-s3-thumbnail-generator-func

2. Estrategia de Segmentación de Red en VPC

Una segmentación de red robusta es la primera línea de defensa. Adoptaremos una arquitectura de VPC multi-zona de disponibilidad (AZ) con capas de subredes.

Diseño de la VPC

• CIDR Principal: 10.0.0.0/16

Estructura de Subredes

• Subredes Públicas:

  • Propósito: Balanceadores Públicos, NATs, Bastions
  • CIDR Ejemplo: 10.0.1.0/24, 10.0.2.0/24

• Subredes Privadas de Aplicación:

  • Propósito: VMs, Kubernetes Nodes
  • CIDR Ejemplo: 10.0.10.0/24, 10.0.20.0/24

• Subredes Privadas de Base de Datos:

  • Propósito: RDS, Cloud SQL
  • CIDR Ejemplo: 10.0.11.0/24, 10.0.21.0/24

Segmentos de VPC para Clústeres Kubernetes con Peering

Para escenarios que requieren múltiples clústeres Kubernetes aislados entre sí pero con capacidad de comunicación controlada mediante VPC Peering, se definen 10 segmentos de VPC con rangos CIDR no superpuestos, dentro del espacio privado RFC 1918 (10.0.0.0/8), facilitando escalabilidad y evitando conflictos.

Cada VPC puede albergar un clúster Kubernetes completo (control plane + nodos) o compartirse según las políticas organizacionales. El peering entre ellas debe configurarse explícitamente, y la propagación de rutas debe controlarse.

Tabla de Segmentos VPC

VPC ID	Nombre sugerido	Rango CIDR	Región	Propósito
vpc-01	k8s-prod-cluster-01	10.10.0.0/16	us-central1	Clúster Kubernetes productivo principal
vpc-02	k8s-prod-cluster-02	10.20.0.0/16	us-central1	Clúster de servicios backend
vpc-03	k8s-prod-cluster-data	10.30.0.0/16	us-central1	Clúster dedicado a procesamiento de datos
vpc-04	k8s-prod-cluster-internal	10.40.0.0/16	us-central1	Clúster de microservicios internos
vpc-05	k8s-prod-cluster-frontend	10.50.0.0/16	us-central1	Clúster para componentes frontend
vpc-06	k8s-staging-cluster-01	10.60.0.0/16	us-central1	Ambiente de staging
vpc-07	k8s-dev-cluster-01	10.70.0.0/16	us-central1	Desarrollo general
vpc-08	k8s-dr-cluster	10.80.0.0/16	us-central1	Clúster para recuperación ante desastres
vpc-09	k8s-ai-ml-cluster	10.90.0.0/16	us-central1	Workloads de IA / ML
vpc-10	k8s-observabilidad-cluster	10.100.0.0/16	us-central1	Observabilidad (Prometheus, Grafana, etc)

🛡️ Recomendación: Cada VPC debe tener sus propias subredes públicas y privadas, y los peering deben usar route filters para limitar el tráfico según políticas internas.

Ejemplo de Peering

Para conectar vpc-01 y vpc-02:

• Se crea una conexión de peering entre ambas VPCs.
• Se actualizan las tablas de rutas para que:
  • vpc-01 permita tráfico hacia 10.20.0.0/16
  • vpc-02 permita tráfico hacia 10.10.0.0/16
• Se definen reglas de firewall (seguridad) para permitir solo los puertos y protocolos requeridos (por ejemplo, TCP 443 para comunicación de servicios internos).

Distribución de Recursos

• VMs: en Subredes Privadas de Aplicación
• Kubernetes Nodes: en Subredes Privadas de Aplicación
• Load Balancers: públicos en Subredes Públicas, internos en Subredes Privadas
• NAT Gateways: uno por AZ en Subred Pública
• Buckets y Cloud Functions: usar VPC Connectors y VPC Endpoints

Reglas de Firewall (Ejemplos)

• sg-public-lb: Entrada TCP/443, TCP/80 desde Internet
• sg-frontend-vms: Entrada TCP/8080 desde sg-public-lb
• sg-backend-vms: Entrada TCP/9000 desde sg-frontend-vms
• sg-database: Entrada TCP/5432 desde sg-backend-vms

Regla de Oro: Subredes privadas no deben permitir tráfico entrante desde internet.

3. Matriz de Roles y Responsabilidades

Rol	Diseño Arquitectura	Despliegue	Mantenimiento	Seguridad
Arquitecto Cloud	✅	🔍	✅	✅
Ingeniero DevOps	👥	✅	✅	✅
Ingeniero Seguridad	✅	🔍	✅	✅
Desarrollador	🧩	✅	🐞	🔒

4. Diagrama de Arquitectura de Red (ASCII)