Logo Google Cloud con Eduardo

Google Cloud con Eduardo

Recibe el código de la lección en tu correo
Te enviaremos el enlace directo al archivo (.zip) y te sumaremos a nuestra newsletter de Google Cloud.

Información básica de protección de datos: Responsable: Eduardo Martínez Agrelo. Finalidad: Facilitar el recurso solicitado y enviar comunicaciones periódicas de valor sobre Google Cloud. Legitimación: Consentimiento del interesado (Art. 6.1.a RGPD). Destinatarios: Plataforma Odoo y proveedores de infraestructura técnica (Google Cloud / Firebase). Derechos: Acceso, rectificación y supresión en eduardomartinezagrelo@gmail.com.
✦ Guía Técnica & Arquitectura

GCP Cloud Engineer: Arquitectura de Infraestructura Enterprise, Terraform, IAM y FinOps

El rol de un GCP Cloud Engineer moderno trasciende la consola web de Google Cloud. En entornos de misión crítica, la responsabilidad radica en diseñar Landing Zones escalables, desacoplar redes mediante Shared VPC, blindar identidades con Workload Identity Federation y aplicar ingeniería de costes FinOps automatizada mediante Infraestructura como Código (IaC).

Hitos Clave del Engineering Track

✓ Estructura de Resource Hierarchy y Landing Zone multi-entorno.
✓ Topología de Red Empresarial: Shared VPC, Private Google Access y Cloud NAT.
✓ Zero-Trust IAM con Workload Identity y VPC Service Controls (VPC-SC).
✓ Código Terraform modular para despliegues inmutables de producción.
Google Cloud Platform Terraform HCL GKE Autopilot Shared VPC Workload Identity Cloud Run FinOps & CUDs IAM & VPC-SC

Matriz de Decisión de Cómputo en GCP

Uno de los desafíos recurrentes para el Cloud Engineer es seleccionar el runtime de cómputo óptimo balanceando overhead operativo, latencia de arranque, granularidad de escalado y costes.

Plataforma Modelo Operativo Tiempo de Inicio FinOps & Billing Caso de Uso Óptimo
Cloud Functions (2nd Gen) Serverless / Event-Driven Sub-segundo / Frío ~1-2s Por invocación + vCPU/RAM por 100ms Procesamiento asíncrono de eventos (Pub/Sub, Cloud Storage triggers).
Cloud Run Serverless Container Milisegundos (Warm) Scale-to-zero / Pago exacto por request activa Microservicios HTTP(S), APIs REST/gRPC y pipelines web stateless.
GKE Autopilot Kubernetes Gestionado Minutos (Pod schedule ~10s) Cobro por pod solicitado (CPU, memoria, efímero) Cargas complejas, microservicios interdependientes, StatefulSets y ML Jobs.
Compute Engine (GCE) IaaS (MIGs / Spot) 1 - 3 minutos Por segundo (compromiso mensual CUDs) Sistemas heredados (Legacy), kernels personalizados o bases de datos no soportadas.

Antipatrones y Fugas de Costes en GCP

⚠️ Antipatrón Crítico: Claves de Service Account y Tráfico de Egress Descontrolado

En producción, dos de las vulnerabilidades y sobrecostes más habituales provienen de:

  • Uso de claves JSON estáticas descargadas: Facilitan la fuga involuntaria a repositorios públicos o logs. La remediación obligatoria es Workload Identity Federation y Service Account impersonation temporal.
  • Egress de Red hacia APIs Públicas de Google: Instancias privadas que salen a internet a través de un Cloud NAT para escribir en Google Cloud Storage o BigQuery pagan tarifas elevadas de procesamiento NAT y salida. La solución arquitectónica es habilitar Private Google Access en cada subred, enrutando el tráfico de manera interna por el backbone de Google sin coste de NAT.

Implementación de Producción: VPC Segura y GKE con Terraform

El siguiente manifiesto en Terraform ilustra el patrón enterprise para aprovisionar una red con subredes privadas, Private Google Access activado, rangos secundarios para Pods/Servicios de Kubernetes y un clúster GKE Autopilot con Workload Identity habilitado de forma nativa.

main.tf (Enterprise GCP Landing Pattern) HCL / Terraform >= 1.5.0
# -----------------------------------------------------------------------------
# Google Cloud Platform - Production Secure VPC & GKE Autopilot
# Arquitectura: Eduardo Martínez Agrelo (AI & Data Architect)
# -----------------------------------------------------------------------------

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.20.0"
    }
  }
}

variable "project_id" {
  type        = string
  description = "GCP Project ID"
}

variable "region" {
  type        = string
  default     = "europe-west1"
}

# 1. Custom VPC Network (Custom Subnet Mode)
resource "google_compute_network" "custom_vpc" {
  name                    = "vpc-enterprise-prod"
  auto_create_subnetworks = false
  routing_mode            = "GLOBAL"
}

# 2. Subred Privada con Rangos Secundarios para GKE y Private Google Access
resource "google_compute_subnetwork" "prod_k8s_subnet" {
  name                     = "snet-k8s-prod-${var.region}"
  ip_cidr_range            = "10.100.0.0/20"
  region                   = var.region
  network                  = google_compute_network.custom_vpc.id
  private_ip_google_access = true # Evita costes de Cloud NAT hacia APIs de Google

  secondary_ip_range {
    range_name    = "pods-range"
    ip_cidr_range = "172.16.0.0/16"
  }

  secondary_ip_range {
    range_name    = "services-range"
    ip_cidr_range = "172.17.0.0/20"
  }
}

# 3. GKE Autopilot Cluster con Hardening y Workload Identity
resource "google_container_cluster" "autopilot_cluster" {
  name     = "gke-enterprise-prod"
  location = var.region

  enable_autopilot = true
  network          = google_compute_network.custom_vpc.name
  subnetwork       = google_compute_subnetwork.prod_k8s_subnet.name

  ip_allocation_policy {
    cluster_secondary_range_name  = "pods-range"
    services_secondary_range_name = "services-range"
  }

  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false # Endpoint público restringido con Authorized Networks
    master_ipv4_cidr_block  = "172.16.255.0/28"
  }

  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "198.51.100.0/24"
      display_name = "Corporate VPN Gateway"
    }
  }

  # Configuración FinOps & Release Channel
  release_channel {
    channel = "REGULAR"
  }

  deletion_protection = true
}

output "gke_endpoint" {
  description = "GKE Master Endpoint"
  value       = google_container_cluster.autopilot_cluster.endpoint
}

Patrones de Diseño de Nivel Architect en GCP

Para garantizar la robustez operativa de infraestructuras a gran escala, un Cloud Engineer debe implementar los siguientes pilares de diseño:

1. Resource Hierarchy y Folder Structure

Organizar los recursos en una jerarquía estricta: Organization → Folders (Core, Workloads, Sandbox) → Projects. Esto permite heredar políticas organizacionales (Organization Policies) de forma determinista, como restringir la creación de IPs públicas o forzar el uso de regiones específicas.

2. Centralized Network Hub (Shared VPC & Cloud Interconnect)

Desacoplar la responsabilidad de la infraestructura de redes mediante una Shared VPC en un proyecto host controlado por el equipo de Cloud Platform. Los equipos de producto despliegan en proyectos de servicio (Service Projects) utilizando las subredes delegadas sin privilegios sobre los cortafuegos o rutas troncales.

3. Gobernanza FinOps Automatizada

Implementar alertas programáticas conectando la exportación de facturación de BigQuery (Billing Export) con Cloud Functions para revocar cuotas o pausar recursos no productivos automáticamente ante anomalías de gasto. Complementar con Committed Use Discounts (CUDs) basados en recursos o gasto flexible.

Framework de Implementación Paso a Paso

  1. Definición del Foundation & Landing Zone: Desplegar la jerarquía de carpetas, vincular cuentas de facturación y aplicar las Organization Policies iniciales mediante Terraform.
  2. Infraestructura de Red Segura: Crear la Shared VPC, habilitar Private Google Access, configurar Cloud DNS privado y desplegar Cloud NAT con IPs estáticas reservadas para auditoría.
  3. Blindaje de Identidad (Zero-Trust IAM): Eliminar claves JSON de Service Accounts, configurar Workload Identity en GKE y enlazar OIDC con los runners de CI/CD (Cloud Build / GitHub Actions).
  4. Observabilidad y Métricas: Configurar Google Cloud Monitoring Workspace, alertas de SLOs/SLAs y exportación de logs de auditoría hacia un bucket de Cloud Storage inmutable con retención Cloud KMS.

Preguntas Frecuentes de Ingeniería GCP

¿Por qué se desaconseja el uso de claves estáticas de Service Accounts (.json) en producción?

Las Service Account Keys estáticas representan un vector de compromiso crítico. En entornos modernos de Google Cloud se utiliza Workload Identity Federation para identidades fuera de GCP y Workload Identity nativo para GKE, eliminando por completo la persistencia y rotación manual de secretos en texto plano.

¿Cuál es la diferencia entre Shared VPC y VPC Network Peering para topologías multi-proyecto?

Shared VPC centraliza la gestión de subredes, firewalls y enrutamiento en un único proyecto Host gestionado por el equipo central de plataforma, permitiendo a los proyectos de servicio consumir recursos de red sin gestionarlos. En cambio, VPC Peering conecta redes independientes de forma descentralizada, no soporta transitividad y presenta mayor sobrecarga de gobernanza a gran escala.

¿Cómo mitigar costes ocultos por Network Egress y Cloud NAT en arquitecturas distribuidas?

Habilitando Private Google Access en las subredes privadas para que el consumo de servicios como Cloud Storage y BigQuery se enrute internamente por el backbone de Google sin tarificar por Cloud NAT, y alineando las cargas de trabajo en zonas de disponibilidad coincidentes para evitar costes de Egress inter-zona innecesarios.

Sobre el Autor: Eduardo Martínez Agrelo
AI & Data Architect

Especialista en diseño de arquitecturas cloud nativas, plataformas de datos escalables y sistemas de inteligencia artificial en producción. Con foco en la excelencia técnica, seguridad zero-trust y optimización de costes para infraestructuras enterprise.