Arquitectura GCP para Empresas: Guía de Referencia

Resource Hierarchy: la base de todo lo demás

El error más frecuente en empresas que empiezan en GCP: crear proyectos directamente bajo la organización sin planificar la jerarquía. Esto hace imposible aplicar políticas consistentes a múltiples equipos, gestionar billing por unidad de negocio, y delegar acceso sin comprometer seguridad.

Organización: empresa.com
├── Folder: produccion/
│   ├── Proyecto: prod-networking       # VPC Shared, Cloud DNS, NAT
│   ├── Proyecto: prod-data             # BigQuery, Cloud SQL
│   └── Proyecto: prod-apps            # GKE, Cloud Run, APIs
├── Folder: no-produccion/
│   ├── Proyecto: staging-apps
│   └── Proyecto: dev-sandbox
└── Folder: shared-services/
    ├── Proyecto: monitoring            # Cloud Monitoring centralizado
    └── Proyecto: security             # Security Command Center, KMS

La separación en proyectos distintos por función (networking, data, apps) crea límites naturales de blast radius. Un incidente de IAM en el proyecto de apps no compromete las claves KMS en security. El billing por folder permite reportar costos por unidad de negocio sin necesidad de tags manuales.

VPC Shared: el patrón de red correcto para empresas

Con VPC Shared, un proyecto host centraliza la red (subnets, firewall rules, Cloud NAT, VPC peering con on-premises) y los proyectos de servicio consumen esa red sin necesidad de gestionar recursos de red propios. Esto elimina la proliferación de VPCs aisladas, simplifica la conectividad y centraliza la auditoría de tráfico.

# Terraform — habilitar Shared VPC en el proyecto host
resource "google_compute_shared_vpc_host_project" "host" {
  project = var.host_project_id
}

resource "google_compute_shared_vpc_service_project" "apps" {
  host_project    = google_compute_shared_vpc_host_project.host.project
  service_project = var.apps_project_id
}

# Subnet con Private Google Access para que las VMs alcancen APIs de Google sin IP pública
resource "google_compute_subnetwork" "apps_subnet" {
  name                     = "apps-subnet"
  ip_cidr_range            = "10.10.0.0/24"
  region                   = "us-central1"
  network                  = google_compute_network.shared_vpc.id
  private_ip_google_access = true
}

GKE Autopilot vs. Standard: la decisión correcta por caso de uso

GKE Autopilot gestiona el plano de datos automáticamente — Google aprovisiona y escala los nodos, aplica parches de seguridad y optimiza el packing de pods. El precio es por CPU/memoria/almacenamiento consumido por los pods, no por nodos. GKE Standard da control completo sobre los node pools pero requiere gestión operacional del plano de datos.

• Autopilot: recomendado para la mayoría de workloads empresariales. Elimina la operación de nodos, garantiza conformidad de seguridad automática, y la facturación granular por pod reduce el waste.
• Standard: necesario cuando tienes requerimientos de hardware específicos (GPUs, local SSDs), necesitas DaemonSets personalizados, o tienes workloads con profiles de recursos muy variables que Autopilot no puede optimizar.
• En la práctica: la mayoría de las empresas deberían empezar con Autopilot y migrar a Standard solo si encuentran limitaciones concretas.

Workload Identity: sin credenciales en el código

El anti-patrón más peligroso en GCP: crear service account keys JSON y distribuirlas como variables de entorno o secretos. Si esa key se filtra, el acceso comprometido no tiene expiración automática. Workload Identity permite que pods de GKE accedan a APIs de GCP con la identidad de un service account, sin credenciales estáticas.

# Kubernetes ServiceAccount con Workload Identity binding
apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-service
  namespace: production
  annotations:
    iam.gke.io/gcp-service-account: api-service@prod-apps.iam.gserviceaccount.com

# Vincular el KSA con el GSA
gcloud iam service-accounts add-iam-policy-binding \
  api-service@prod-apps.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:prod-apps.svc.id.goog[production/api-service]"

Cloud Run para APIs sin gestión de cluster

Para APIs HTTP stateless, Cloud Run es frecuentemente mejor que GKE. Sin gestión de nodos, sin preocupación por pod scheduling, con scale-to-zero automático y pricing por request. El tradeoff: menos control sobre el ambiente de ejecución y cold starts en servicios con tráfico esporádico.

# Cloud Run service con VPC connector y sin tráfico público directo
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: payment-api
  annotations:
    run.googleapis.com/ingress: internal-and-cloud-load-balancing
    run.googleapis.com/vpc-access-connector: projects/prod-networking/locations/us-central1/connectors/vpc-connector
    run.googleapis.com/vpc-access-egress: private-ranges-only
spec:
  template:
    spec:
      serviceAccountName: api-service@prod-apps.iam.gserviceaccount.com
      containers:
      - image: us-central1-docker.pkg.dev/prod-apps/api/payment-api:latest
        resources:
          limits:
            cpu: "2"
            memory: "1Gi"

Seguridad de red: VPC Service Controls

VPC Service Controls crea un perímetro de seguridad alrededor de APIs de GCP (BigQuery, Cloud Storage, Cloud SQL) que previene la exfiltración de datos incluso si un service account es comprometido. Las APIs dentro del perímetro solo son accesibles desde redes y proyectos explícitamente autorizados.

Para empresas que manejan datos regulados (PCI-DSS, HIPAA, datos financieros), VPC Service Controls no es opcional — es el control que previene que una brecha de IAM se convierta en una brecha de datos.