Guía

Centralizar la facturación y la aplicación de políticas mientras se concede autonomía administrativa a las unidades de negocio.

→Utilice un nodo de Organización con Carpetas (Folders) para cada unidad de negocio. Cree proyectos dentro de las carpetas. Vincule todos los proyectos a una única Cuenta de Facturación (Billing Account).

Por qué: Las Carpetas (Folders) proporcionan límites administrativos y herencia de políticas. Una única cuenta de facturación centraliza la gestión de costos y permite descuentos a nivel de organización.

Referencia↗

Notificar a finanzas cuando el gasto del proyecto alcance ciertos porcentajes de un presupuesto.

→En Cloud Billing, cree un Presupuesto (Budget) para el proyecto. Establezca múltiples reglas de umbral de alerta (p. ej., 50%, 90%, 100%) que envíen notificaciones a un tema de Pub/Sub o por correo electrónico.

Por qué: Los Presupuestos (Budgets) son para alertar, no para detener el gasto. Para limitar automáticamente el gasto, una notificación de Pub/Sub debe activar una Cloud Function para deshabilitar la facturación o apagar recursos.

Referencia↗

Analizar los costos detallados de la nube a nivel de recurso y realizar un seguimiento del gasto por centro de costos.

→Habilite la exportación detallada de facturación a un conjunto de datos de BigQuery. Aplique etiquetas (p. ej., `cost-center: "finance"`) a los recursos. Consulte la tabla de BigQuery y agrupe por etiquetas para el análisis.

Por qué: La exportación de facturación a BigQuery proporciona los datos de costos más detallados, incluyendo etiquetas, lo cual es esencial para modelos personalizados de chargeback y showback.

Referencia↗

Aplicar estándares de seguridad y configuración en todos los proyectos de una organización (p. ej., restringir ubicaciones de recursos, requerir acceso uniforme a buckets, deshabilitar IPs públicas).

→Aplique restricciones de Política de Organización (Organization Policy) a nivel de Organización o Carpeta (Folder). Ejemplos: `gcp.resourceLocations` para residencia de datos, `storage.uniformBucketLevelAccess` para seguridad de GCS, `compute.vmExternalIpAccess` para prevenir IPs públicas.

Por qué: Las políticas de organización se heredan y proporcionan control preventivo, bloqueando acciones no conformes antes de que ocurran. Esto es más efectivo que la auditoría reactiva.

Referencia↗

Evitar la eliminación accidental de un proyecto de producción crítico.

→Ponga un gravamen (lien) en el proyecto usando `gcloud alpha resource-manager liens create`.

Por qué: Un gravamen (lien) es una propiedad que bloquea la eliminación de un proyecto. Debe ser eliminado explícitamente por un usuario con el rol `resourcemanager.lienModifier` antes de que el proyecto pueda ser eliminado.

Cambiar eficientemente entre diferentes proyectos y cuentas de usuario al usar la CLI de gcloud.

→Use `gcloud config configurations create` para crear configuraciones con nombre para cada proyecto/cuenta. Cambie entre ellas usando `gcloud config configurations activate [CONFIG_NAME]`.

Por qué: Las configuraciones almacenan ajustes como proyecto, cuenta, región y zona, evitando la necesidad de especificarlos con cada comando.

Ejecutar un microservicio HTTP sin estado, en contenedores, con tráfico variable, minimizando la sobrecarga operativa y el costo.

→Despliegue el contenedor en Cloud Run.

Por qué: Cloud Run es completamente gestionado, escala a cero (eliminando costos en períodos de inactividad) y escala automáticamente en función de las solicitudes entrantes. Es ideal para servicios web sin estado.

Referencia↗

Ejecutar un trabajo de procesamiento por lotes tolerante a fallos y flexible en el tiempo al menor costo posible.

→Use Spot VMs (anteriormente Preemptible VMs) en un Grupo de Instancias Gestionadas (Managed Instance Group).

Por qué: Las Spot VMs ofrecen hasta un 91% de descuento en comparación con los precios bajo demanda. Son adecuadas para cargas de trabajo que pueden detenerse y reiniciarse, como muchos trabajos de procesamiento por lotes.

Implementar una aplicación web que requiera alta disponibilidad (p. ej., 99.9%) y autoescalado.

→Utilice un Grupo de Instancias Gestionadas (MIG) regional con una política de autoescalado, desplegado detrás de un Balanceador de Carga HTTP(S) Externo Global.

Por qué: Un MIG regional distribuye automáticamente las instancias en múltiples zonas para la tolerancia a fallos. El autoescalado ajusta la capacidad para satisfacer la demanda, y el balanceador de carga proporciona un único punto de entrada.

Almacenar datos que se acceden frecuentemente durante 30 días, luego infrecuentemente durante un año, y luego archivados.

→Almacene en un bucket de Cloud Storage de clase Standard. Cree una regla de ciclo de vida para hacer la transición de objetos a Nearline/Coldline después de 30 días y a Archive después de 365 días.

Por qué: Las reglas de ciclo de vida automatizan la optimización de costos moviendo los datos a clases de almacenamiento más baratas en función de la antigüedad u otras condiciones, sin intervención manual.

Referencia↗

Una aplicación distribuida globalmente requiere una base de datos relacional con escalabilidad horizontal y fuerte consistencia.

→Use Cloud Spanner.

Por qué: Cloud Spanner es el único servicio que proporciona una base de datos relacional distribuida globalmente, fuertemente consistente y con soporte SQL. Cloud SQL es regional.

Una aplicación requiere una base de datos PostgreSQL o MySQL gestionada con un SLA de disponibilidad del 99.95% y conmutación por error automática.

→Use Cloud SQL con la configuración de Alta Disponibilidad (HA) habilitada.

Por qué: La configuración HA crea una instancia principal y una instancia en espera en una zona diferente. Los datos se replican sincrónicamente y la conmutación por error es automática.

Diseñar una VPC para una aplicación de 3 capas (web, aplicación, base de datos) donde la capa de base de datos no debe ser accesible desde internet.

→Cree una VPC en modo personalizado con una subred separada para cada capa. Aprovisione las instancias de base de datos solo con direcciones IP privadas en su subred dedicada.

Por qué: Aislar las capas en subredes separadas permite reglas de firewall granulares. Omitir IPs externas en las instancias de base de datos es la forma más directa de prevenir el acceso a internet.

Desplegar una aplicación con estado (p. ej., una base de datos) en GKE que requiera identificadores de red estables y almacenamiento persistente.

→Utilice un StatefulSet con una plantilla PersistentVolumeClaim.

Por qué: Los StatefulSets están diseñados para cargas de trabajo con estado, proporcionando nombres de host estables (p. ej., `pod-0`, `pod-1`) y aprovisionando automáticamente un PersistentVolume único para cada réplica.

Un servicio de Cloud Run sensible a la latencia debe evitar los "arranques en frío" (cold starts) durante los picos de tráfico.

→Despliegue el servicio con la bandera `--min-instances` configurada en 1 o superior.

Por qué: Establecer un número mínimo de instancias mantiene un número especificado de contenedores "calientes" y listos para atender solicitudes, eliminando la latencia asociada con el inicio de un nuevo contenedor.

Ejecutar una función sin servidor automáticamente cada vez que se carga un nuevo archivo a un bucket de Cloud Storage.

→Despliegue una Cloud Function (2ª Gen) con un disparador Eventarc para el evento `google.cloud.storage.object.v1.finalized` en el bucket especificado.

Por qué: Eventarc proporciona una arquitectura unificada y basada en eventos. El disparador de GCS es la forma estándar y gestionada de conectar eventos de almacenamiento a la computación sin servidor sin sondeo.

Desplegar una nueva versión de una aplicación de App Engine para pruebas sin enviar inmediatamente tráfico de producción a ella.

→Despliegue la nueva versión usando `gcloud app deploy --no-promote`.

Por qué: La bandera `--no-promote` crea la nueva versión pero no le redirige tráfico. Luego puede probarla usando su URL específica de la versión y migrar el tráfico manualmente cuando esté listo.

Crear un balanceador de carga HTTP(S) global para una aplicación web ejecutándose en instancias de Compute Engine.

→Cree estos componentes en orden: Grupo de Instancias (con VMs), Verificación de Salud (Health Check), Servicio de Backend (apuntando a IG y HC), Mapa de URL (URL Map), Proxy HTTP(S) de Destino (Target HTTP(S) Proxy), y una Regla de Reenvío Global (Global Forwarding Rule) (con una IP pública).

Por qué: Esta secuencia construye correctamente el balanceador de carga desde el backend (instancias) hasta el frontend (regla de reenvío). Cada componente tiene un propósito específico en el enrutamiento y la verificación de salud.

Un equipo necesita gestionar el estado de Terraform de forma colaborativa, garantizando la seguridad y evitando modificaciones concurrentes.

→Utilice un bucket de Cloud Storage como backend de Terraform. Habilite el versionado de objetos para el historial y la recuperación. El bloqueo de estado es gestionado automáticamente por el backend de GCS.

Por qué: Un backend remoto de GCS es el estándar para la colaboración en equipo en GCP. Proporciona bloqueo para prevenir la corrupción del estado y versionado para capacidades de reversión.

Recibir una notificación cuando la utilización de CPU en cualquier VM de un grupo exceda el 80% durante un período sostenido (p. ej., 5 minutos).

→En Cloud Monitoring, cree una Política de Alerta (Alerting Policy). Establezca la condición en `Métrica: Utilización de CPU > 80%` para `Duración: 5 minutos`. Configure un canal de notificación (p. ej., correo electrónico, PagerDuty).

Por qué: Cloud Monitoring es el servicio nativo para crear alertas basadas en métricas. La condición de duración es crucial para evitar alertas "intermitentes" por picos breves y normales en la utilización.

Retener logs de auditoría específicos durante 7 años por cumplimiento, mientras se mantienen otros logs durante 30 días.

→Cree un sumidero de logs (log sink) con un filtro para los logs de auditoría. Configure el sumidero para exportar a un bucket de Cloud Storage. Aplique una política de retención de 7 años en el bucket.

Por qué: Cloud Logging tiene un período de retención limitado (máximo 400 días para Actividad de Administración). Los sumideros (sinks) son el mecanismo para enrutar logs a almacenamiento a largo plazo y más económico como GCS o para análisis en BigQuery.

Un pod de GKE está en estado `CrashLoopBackOff`. Necesita ver los logs del contenedor justo antes de que fallara.

→Use el comando `kubectl logs [POD_NAME] --previous`.

Por qué: Cuando un contenedor falla y se reinicia, `kubectl logs` muestra los logs del *nuevo* contenedor. La bandera `--previous` es esencial para ver los logs de la instancia terminada y diagnosticar el fallo.

Un grupo de instancias gestionadas debe reemplazar automáticamente las instancias que dejan de responder.

→Configure una verificación de salud (health check) (p. ej., HTTP, TCP) y aplíquela a la política de autorreparación (autohealing) del grupo de instancias gestionadas.

Por qué: El MIG sondea periódicamente las instancias basándose en la verificación de salud. Si una instancia falla verificaciones consecutivas, el MIG la elimina y recrea automáticamente a partir de la plantilla, asegurando la disponibilidad de la aplicación.

Se produjo un evento de corrupción de datos en una base de datos de Cloud SQL. Necesita restaurar la base de datos al estado en que se encontraba 5 minutos antes del evento.

→Asegúrese de que la Recuperación a un Punto en el Tiempo (PITR) esté habilitada en la instancia de antemano. Realice una operación de restauración, especificando la marca de tiempo exacta a la que desea recuperar.

Por qué: PITR se basa en que el registro binario esté habilitado. Permite una recuperación granular a cualquier punto en el tiempo dentro de la ventana de retención, lo cual es crítico para minimizar la pérdida de datos (RPO bajo).

Automatizar copias de seguridad diarias de un disco persistente de Compute Engine y retenerlas durante 14 días.

→Cree una Política de Recursos para instantáneas de disco. Configure un programa diario y una política de retención de 14 días. Adjunte esta política al disco persistente de destino.

Por qué: Los programas de instantáneas son la forma gestionada y de "olvidarse" de automatizar las copias de seguridad de GCE. Esto es más fiable y mantenible que usar tareas cron o scripts personalizados.

Una instancia de Compute Engine necesita leer de un bucket de Cloud Storage y escribir en una tabla de BigQuery. Otorgue los permisos mínimos requeridos.

→Cree una cuenta de servicio personalizada. Otorguele los roles `roles/storage.objectViewer` y `roles/bigquery.dataEditor`. Adjunte esta cuenta de servicio a la instancia.

Por qué: El uso de una cuenta de servicio personalizada con roles específicos y predefinidos evita la naturaleza excesivamente permisiva de la cuenta de servicio predeterminada de Compute Engine, adhiriéndose al principio de privilegio mínimo.

Otorgar a un usuario permisos para administrar instancias de GCE pero no eliminarlas.

→Cree un rol IAM personalizado. Comience con los permisos del rol `roles/compute.instanceAdmin.v1` y elimine el permiso `compute.instances.delete`.

Por qué: Los roles personalizados proporcionan la flexibilidad para otorgar un conjunto preciso de permisos cuando los roles predefinidos son demasiado amplios o demasiado restrictivos para una función de trabajo específica.

Un desarrollador necesita acceder por SSH a una instancia de Compute Engine que no tiene dirección IP externa, según la política de seguridad.

→Otorgue al desarrollador el rol `roles/iap.tunnelResourceAccessor`. Luego podrá conectarse usando `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`.

Por qué: El reenvío TCP de Identity-Aware Proxy (IAP) proporciona un método seguro y basado en la identidad para acceder a instancias internas sin hosts bastión, VPNs o IPs públicas.

Referencia↗

Permitir tráfico SSH entrante (puerto 22) a VMs específicas solo desde el rango de IP de la oficina corporativa.

→Cree una regla de firewall de VPC con `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]`, y `target tags: [p. ej., "allow-ssh"]`. Aplique la etiqueta a las VMs previstas.

Por qué: La combinación de rangos de origen y etiquetas de destino proporciona una forma precisa y escalable de controlar el tráfico. Restringe tanto *quién* puede conectarse como *a qué* puede conectarse.

Evitar que los datos de un proyecto sensible de BigQuery sean copiados o accedidos desde fuera de un límite de red confiable, incluso con credenciales válidas.

→Configure Controles de Servicio de VPC (VPC Service Controls). Cree un perímetro de servicio que incluya el proyecto sensible y restrinja la API de BigQuery.

Por qué: Los Controles de Servicio de VPC crean un "perímetro de datos" virtual que controla el acceso a nivel de API, proporcionando una fuerte defensa contra la exfiltración de datos que las reglas de firewall no pueden.

Proporcionar a una aplicación de terceros acceso de lectura temporal y limitado en el tiempo a un objeto privado específico en un bucket de Cloud Storage.

→Genere una URL firmada para el objeto con un tiempo de expiración corto (p. ej., 15 minutos) usando una cuenta de servicio con permisos de lectura.

Por qué: Las URL firmadas otorgan acceso temporal por objeto sin requerir que el tercero tenga una cuenta de Google o permisos IAM. Es el método más seguro para este caso de uso.

Un pod de GKE necesita acceder de forma segura a las APIs de Google Cloud (p. ej., Pub/Sub) sin almacenar claves de cuenta de servicio como secretos de Kubernetes.

→Habilite Workload Identity en el clúster de GKE. Cree una Cuenta de Servicio de Google (GSA) y una Cuenta de Servicio de Kubernetes (KSA). Vincule la KSA a la GSA usando una política de IAM. Configure el pod para usar la KSA.

Por qué: Workload Identity es la forma recomendada y sin claves para que las aplicaciones de GKE se autentiquen en los servicios de Google Cloud. Mapea las identidades de KSA a las identidades de GSA, lo cual es más seguro que gestionar y rotar archivos de clave.

Referencia↗

Una política de organización requiere que todos los datos en un bucket de Cloud Storage estén cifrados usando una clave de cifrado que la organización controla.

→Cree una clave criptográfica en Cloud KMS. Al crear el bucket de Cloud Storage, especifique esta clave como la Clave de Cifrado Gestionada por el Cliente (CMEK).

Por qué: CMEK le da control sobre la clave utilizada para el cifrado, incluyendo la rotación y revocación, mientras sigue aprovechando la infraestructura de cifrado gestionada por Google.

Permitir a los empleados usar sus credenciales existentes de Active Directory local para acceder a los recursos de Google Cloud.

→Configure Cloud Identity para federar con Active Directory usando SAML 2.0. Los usuarios se autentican con AD, que luego afirma su identidad a Google Cloud para el acceso.

Por qué: La federación permite el Inicio de Sesión Único (SSO) y centraliza la gestión de identidades en el IdP existente (Active Directory), evitando la necesidad de gestionar un conjunto separado de contraseñas en Google Cloud.

Otorgar a un contratista externo acceso temporal a un proyecto, que debería expirar automáticamente después de 30 días.

→Agregue al contratista como miembro de IAM con el rol requerido. Agregue una condición a la vinculación de roles con una marca de tiempo de expiración (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).

Por qué: Las Condiciones de IAM proporcionan control de acceso basado en atributos. Las condiciones basadas en tiempo son perfectas para accesos temporales, ya que revocan automáticamente los permisos sin necesidad de limpieza manual.