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
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.
# -----------------------------------------------------------------------------
# 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
- 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.
- 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.
- 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).
- 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
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.
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.
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.
