Google ACE: Gestión de costos, rendimiento y optimización de la capacidad — Guía de estudio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Forma parte de la Google Associate Cloud Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La gestión de costos y la optimización del rendimiento/capacidad en Google Cloud requieren visibilidad continua, decisiones de dimensionamiento correcto y una gobernanza que alinee la utilización de recursos con los objetivos de negocio. Una práctica eficaz combina controles financieros (presupuestos, asignación), palancas técnicas (autoescalado, reservas, políticas de ciclo de vida), decisiones de arquitectura (localidad de datos, replicación) y retroalimentación operacional (telemetría, pruebas de carga). Esta sección detalla las herramientas clave, las compensaciones y los modos de fallo en cómputo, almacenamiento, procesamiento de datos, redes, bases de datos, cuotas e ingeniería de rendimiento.

Visibilidad de costos, presupuestos y asignación

Informes y exportaciones de facturación:
- Utilice los Cloud Billing Reports para desgloses rápidos de tendencias y SKU; habilite la exportación de datos de Cloud Billing a BigQuery para obtener datos detallados y consultables de costos y uso. Esto permite realizar pronósticos diarios/mensuales, detección de anomalías y acumulados multiproyecto con SQL estándar.
- La exportación de la tabla de precios ayuda a conciliar los precios de lista con los costos y créditos de los SKU.
- Modos de fallo: Usar solo las vistas de la consola limita la granularidad; no exportar a BigQuery bloquea el modelado histórico y la asignación precisa de costos (showback/chargeback).
Presupuestos y alertas:
- Cree presupuestos con alcance a cuentas de facturación, proyectos, carpetas, servicios o filtros de etiquetas (labels/tags); configure alertas de umbral (p. ej., 50/90/100 %) sobre el costo real y previsto. Considere los canales de notificación a través de Pub/Sub para activar acciones automatizadas (p. ej., pausar entornos de no producción).
- Compensación: Los apagados automáticos agresivos reducen el gasto, pero pueden perjudicar la fiabilidad si se aplican a rutas de producción.
Etiquetas (labels y tags) para la asignación:
- Aplique etiquetas de recursos (labels) y etiquetas de Resource Manager (tags) de forma consistente (env, app, owner, cost-center). Las etiquetas (tags) son compatibles con las políticas de organización y aparecen en los filtros de facturación para una asignación robusta.
- Gobernanza: Aplique políticas de etiquetas (labels/tags) utilizando Organization Policy, plantillas de despliegue y verificaciones de CI/CD.
- Modos de fallo: Claves inconsistentes o etiquetas faltantes rompen los modelos de asignación; las etiquetas heredadas no se aplican a todos los tipos de recursos si las herramientas son inconsistentes.
Modelos de asignación de costos:
- Los modelos de showback/chargeback suelen utilizar una jerarquía: proyecto → servicio/SKU → etiqueta (label/tag). Los costos de plataforma compartida (p. ej., balanceadores de carga, egreso de VPC) se pueden asignar según factores como solicitudes, GB transferidos o CPU-horas medidos a través de registros/métricas.
- Compensación: Los modelos simples (división equitativa) son fáciles de ejecutar, pero pueden asignar precios incorrectos a los usuarios intensivos; los modelos granulares requieren telemetría fiable y más sobrecarga.

Ejemplo corto (ejecución de prueba en BigQuery para estimación de costos):

undefined

Eficiencia de cómputo y optimización del ciclo de vida

Dimensionamiento correcto y tipos de máquina personalizados:
- Utilice la API/consola de Recommender para dimensionar correctamente las VM basándose en los percentiles de uso de CPU/memoria. Prefiera tipos de máquina personalizados para necesidades estables que no se ajustan a los tipos predefinidos (p. ej., 2 vCPU/10 GB de RAM) para evitar pagar por capacidad no utilizada.
- Modos de fallo: Reducir el tamaño de servicios sensibles a la latencia o con picos de carga puede causar estrangulamiento (throttling). Valide con pruebas de carga y deje un margen de capacidad.
Committed Use Discounts (CUDs):
- Adquiera CUDs basados en recursos (vCPU, memoria, GPU) a nivel regional por plazos de 1 o 3 años a través de la consola o la CLI. Ideal para una capacidad base estable; superponga el autoescalado para los picos de carga.
- Compensaciones: Los compromisos reducen el precio unitario, pero son inflexibles. Comprometerse en exceso bloquea el gasto; comprometerse por debajo anula los descuentos.
Spot VMs:
- Utilice Spot VMs para cargas de trabajo tolerantes a fallos e interrumpibles (procesos por lotes, CI, niveles sin estado). Implemente puntos de control (checkpointing) y manejo de interrupciones (preemption) (aviso de 30 segundos a través de metadatos/Pub/Sub).
- Modos de fallo: La capacidad puede desaparecer en cualquier momento; nunca coloque servicios con estado o críticos para el quórum únicamente en Spot.
Autoescalado, programación y ciclo de vida:
- Los grupos de instancias administrados (MIGs) con autoescalado (basado en CPU, balanceador de carga o métricas personalizadas de Cloud Monitoring) gestionan la carga variable. Ajuste los controles de enfriamiento (cool-down) y de reducción de escala (scale-in) para evitar oscilaciones; alinee el retraso inicial de la verificación de estado con la preparación de la aplicación.
- Programación: Detenga o suspenda las VM de desarrollo/pruebas fuera del horario laboral; utilice Instance Schedules o automatización con Cloud Scheduler y Cloud Functions para minimizar el costo por inactividad.
- Ciclo de vida y mantenimiento: Habilite el reinicio automático y la migración por mantenimiento del host para alta disponibilidad; tenga en cuenta que la migración en vivo (live migration) puede no aplicarse con GPU o SSD locales.
- Limpieza de recursos inactivos: Recupere discos persistentes no adjuntos, instantáneas obsoletas y direcciones IP estáticas no utilizadas usando Recommender.
- Modos de fallo: Retrasos cortos en la verificación de estado o la falta de señales de preparación causan sobreaprovisionamiento; una reducción de escala demasiado agresiva interrumpe conexiones; deshabilitar la autoreparación (autohealing) oculta los nodos que fallan.

Ejemplos cortos:

undefined

Economía del almacenamiento y el procesamiento de datos

Clases de almacenamiento y ciclo de vida de Cloud Storage:
- Elige las clases según el patrón de acceso: Standard (datos de acceso frecuente o hot), Nearline (mínimo ≥30 días), Coldline (mínimo ≥90 días), Archive (mínimo ≥365 días). Aplica reglas de ciclo de vida para bajar de nivel (tier down) y eliminar según un cronograma.
- Compensaciones en la recuperación: Las clases de menor costo imponen tarifas de recuperación por GB y cargos por duración mínima de almacenamiento; las lecturas frecuentes en Coldline/Archive eliminan los ahorros. Planifica los flujos de trabajo de restauración para los costos pico de lectura.
- Gobernanza: Usa políticas de retención y bloqueos de objetos (object holds) para el cumplimiento normativo (compliance); habilita el pago por solicitante (requester-pays) para conjuntos de datos compartidos y así evitar sorpresas en la facturación entre equipos.
Ejemplo de política de ciclo de vida (bajar de nivel y luego eliminar):
- Define acciones SetStorageClass y Delete basadas en la antigüedad (Age) para automatizar las transiciones y la limpieza de datos obsoletos.
Controles de costos en BigQuery:
- Las consultas bajo demanda (on-demand) cobran por bytes procesados; minimiza el costo con la poda de particiones (partition pruning) y la clusterización. Particiona por columna de fecha o de ingesta; clusteriza hasta cuatro columnas con alta cardinalidad/selectividad.
- Usa ejecuciones de prueba (dry runs) para estimar el costo, vistas materializadas para agregaciones frecuentes (hot), y decoradores de tabla para acotar las ventanas de tiempo.
- Las reservas (slots) proporcionan un rendimiento y un gasto predecibles; usa asignaciones por proyecto/carpeta y considera los compromisos flexibles (flex commitments) para picos cortos.
- Modos de fallo: Los escaneos sin particionar, SELECT * en tablas anchas o una clusterización mal ordenada generan una cantidad masiva de bytes escaneados; las tablas intermedias efímeras pueden disparar el almacenamiento si no se les aplica una caducidad.

Ejemplo corto (fragmento JSON de ciclo de vida de Cloud Storage):

{ “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

Redes, bases de datos y escalado consciente de las cuotas

Salida de red (egress) e impacto en la arquitectura:
- La salida de datos (egress) a internet, entre regiones y a través de IP externas incurre en cargos; el tráfico dentro de la misma región sobre IP internas es generalmente gratuito. Elige el Nivel de Red Premium (Premium Network Tier) para el rendimiento o el Estándar (Standard) para cargas de trabajo sensibles al costo con requisitos de latencia/jitter más flexibles.
- Balanceadores de carga: Los de L7 HTTP(S) y L4 TCP/UDP tienen cargos por procesamiento de datos y por reglas de reenvío; los balanceadores de carga interregionales pueden añadir costos de salida (egress) entre regiones. Consolidar los balanceadores de carga ahorra costos fijos, pero puede aumentar el radio de impacto (blast radius).
- Optimización: Mantén el tráfico dentro de la región; usa buckets y servicios regionales; evita el hairpinning a través de IP externas. Almacena en caché los activos estáticos en el borde de la red (edge) para reducir la salida de datos (egress) del origen.
- Modos de fallo: Usar accidentalmente IP externas entre servicios en la misma VPC genera una salida de datos (egress) innecesaria; la replicación multirregional duplica la salida de datos para las rutas de escritura.
Dimensionamiento de bases de datos, réplicas y disponibilidad:
- Cloud SQL: Dimensiona vCPU/RAM para la carga del percentil 95; habilita el redimensionamiento automático del almacenamiento; usa réplicas de lectura para escalar horizontalmente las lecturas (scale-out); la alta disponibilidad (HA) duplica el costo de cómputo pero reduce el RTO de conmutación por error (failover). El agrupamiento de conexiones (connection pooling) evita la sobrecarga excesiva por conexiones.
- Spanner: La capacidad se aprovisiona como nodos o unidades de procesamiento; las configuraciones multirregionales mejoran la disponibilidad y la latencia de lectura, pero aumentan el costo y la latencia de escritura; planifica cuidadosamente las divisiones (splits) y los puntos calientes (hotspots).
- Bigtable: El número de nodos determina el rendimiento (throughput); el autoescalador ayuda a seguir el tráfico; la replicación multiclúster añade disponibilidad y costo; diseña el esquema para una distribución uniforme de claves.
- Compensaciones: Las réplicas mejoran el rendimiento de lectura y la disponibilidad, pero aumentan la amplificación de escritura y la salida de datos (egress); la consistencia fuerte y las escrituras multirregionales añaden latencia.
Cuotas, límites de tasa y contrapresión (backpressure):
- Comprende las cuotas por API y la concurrencia por servicio. Implementa un retroceso exponencial con fluctuación (exponential backoff with jitter) para los errores 429/5xx. Aplica la nivelación de carga basada en colas con trabajos de Pub/Sub y Dataflow o Cloud Run.
- Ajustes de concurrencia: En Cloud Run, una mayor concurrencia reduce el costo pero arriesga la latencia de cola (tail latency); ajusta la asignación de CPU bajo petición para un rendimiento estable.
- Contrapresión (Backpressure): Usa el control de flujo en los suscriptores de Pub/Sub, interruptores de circuito (circuit breakers) y control de admisión para prevenir fallos en cascada.
- Modos de fallo: Ignorar las cuotas conduce a una limitación repentina (throttling); el autoescalado puede amplificar la carga en los sistemas dependientes (downstreams) si no hay contrapresión, causando reintentos y aumentando el costo.

Gobernanza de la Medición y Optimización del Rendimiento

Medición y pruebas de carga:
- Establecer SLI/SLO (Indicadores/Objetivos de Nivel de Servicio) para latencia, tasa de errores y saturación. Usar paneles de Cloud Monitoring, verificaciones de tiempo de actividad y alertas. Instrumentar el rastreo (Cloud Trace) y el perfilado (Cloud Profiler) para localizar rutas críticas y contención de bloqueos.
- Realizar pruebas de carga con modelos de tráfico realistas, cardinalidad de datos y tiempos de reflexión. Validar los parámetros del escalador automático, el calentamiento y las puertas de preparación (readiness gates). Incluir escenarios de conmutación por error y de caos para observar el margen de capacidad y el tiempo de recuperación.
- Diagnóstico de cuellos de botella: Usar el método USE (Utilización, Saturación, Errores) en CPU, memoria, disco, red y dependencias descendentes; correlacionar con logs y trazas.
Gobernanza que equilibra costo, seguridad y fiabilidad:
- Barreras de protección de FinOps: Etiquetas obligatorias; presupuestos con alertas de previsión; exportaciones de facturación centralizadas y cadencias de revisión de costos. Integrar los hallazgos de Recommender (IP/discos inactivos, ajuste de tamaño) en el backlog con SLA por propietario.
- Seguridad: Preferir la conectividad privada (sin IP externas), VPC Service Controls para riesgos de exfiltración de datos; reconocer que las rutas privadas pueden alterar los patrones de egreso y los costos. Cifrar en reposo y en tránsito; incluir el uso de KMS en los modelos de costos.
- Fiabilidad: Reservar capacidad base mediante CUD o reservas de BigQuery; mantener un margen para ráfagas para cumplir los SLO; realizar game days (simulacros) periódicos. Documentar cuándo el uso de instancias Spot o el escalado automático agresivo es inaceptable para las rutas críticas.
- Gestión de cambios: Tratar los parámetros que afectan al costo (límites del escalador automático, reservas de BigQuery, topología de LB) como código, con planes de revisión y reversión.

Escenario de Problema Práctico

Contoso Media opera una plataforma multirregional de análisis de video que experimenta costos crecientes e incumplimientos ocasionales del SLO de latencia durante los picos de tráfico. La dirección desea una reducción de costos del 20% sin comprometer un SLO de latencia p95 de 300 ms para la API y un SLA de 2 horas para la finalización del lote nocturno.

Establecer bases de referencia de costo y rendimiento

Acción: Habilitar la exportación de Cloud Billing a BigQuery y crear paneles que correlacionen los costos de SKU con los SLI de Cloud Monitoring (latencia, CPU, bytes de egreso). Ejecutar bq dry runs en las 20 consultas principales para estimar los bytes escaneados.
Justificación: Las bases de referencia identifican los servicios de alto impacto y mapean el gasto a los impulsores de rendimiento, permitiendo una optimización dirigida.

Forzar el etiquetado de asignación y los presupuestos

Acción: Requerir etiquetas (env, service, owner, cost-center) a través de plantillas de despliegue; establecer presupuestos por entorno con alertas de previsión a un tema de Pub/Sub de FinOps.
Justificación: Los datos de asignación completos y las alertas proactivas permiten una rápida asignación de responsabilidad y acciones correctivas antes de que se excedan los costos.

Ajustar el tamaño (rightsizing) y comprometer el cómputo base

Acción: Aplicar el ajuste de tamaño de VM de Recommender a los servicios estables; convertir la capacidad de estado estable a CUD regionales de 1 año; mantener un búfer del 20–30% en el máximo del escalador automático para los picos.
Justificación: El ajuste de tamaño y los compromisos reducen el costo unitario en cargas predecibles, preservando al mismo tiempo el margen para cumplir los SLO.

Optimizar el escalado automático y la preparación

Acción: Para los MIG, cambiar las señales de escalado automático a métricas basadas en solicitudes o personalizadas de QPS/latencia, establecer el período de enfriamiento (cool-down) en 120–180 segundos y alinear el retraso inicial de la verificación de estado con el calentamiento de la aplicación. Habilitar los controles de reducción de escala (scale-in) para evitar una reducción rápida.
Justificación: Las señales conscientes de la carga de trabajo y la estabilización evitan la agitación (thrashing) y el sobreaprovisionamiento que inflan los costos y perjudican la latencia.

Reducir el egreso de red y la sobrecarga del balanceador de carga

Acción: Eliminar la comunicación por IP externa entre servicios; asegurar que todo el tráfico este-oeste utilice balanceo de carga interno; coubicar los servicios con mucha comunicación dentro de las regiones; almacenar en caché los activos estáticos en el borde de la red (edge).
Justificación: Las rutas internas eliminan el egreso innecesario y reducen el procesamiento de L7, mejorando la latencia y el costo.

Ciclo de vida del almacenamiento y archivado

Acción: Aplicar reglas de ciclo de vida de Cloud Storage para mover artefactos fríos a Coldline a los 90 días y eliminarlos a los 365 días; establecer la opción de pago por solicitante (requester-pays) en los buckets compartidos; revisar las implicaciones de la duración mínima de almacenamiento para los datos de acceso poco frecuente.
Justificación: La organización por niveles (tiering) y la retención reducen los costos de almacenamiento y recuperación, manteniendo intacto el cumplimiento normativo.

Ajuste de consultas y capacidad de BigQuery

Acción: Particionar las tablas de hechos grandes por fecha, agruparlas en clústeres por columnas de alta selectividad; reemplazar SELECT * con proyecciones de columnas; introducir vistas materializadas para las principales agregaciones; comprar una pequeña reserva para las ventanas de ETL pico y usar flex slots durante los picos de los lotes.
Justificación: El particionamiento/clustering reduce los bytes escaneados; las reservas de capacidad estabilizan el rendimiento y el costo para las cargas de trabajo críticas.

Escala de base de datos y réplicas

Acción: Para los servicios de Cloud SQL con mucha lectura, agregar réplicas de lectura; ajustar el pool de conexiones; configurar el redimensionamiento automático del almacenamiento; probar la conmutación por error para validar el RTO/RPO. Para Bigtable, habilitar el escalador automático y abordar los puntos calientes (hotspots) en las claves.
Justificación: Las réplicas descargan las lecturas y protegen las rutas de escritura; el escalado automático mantiene el rendimiento (throughput) alineado con la demanda sin sobreaprovisionamiento manual.

Cuotas, concurrencia y contrapresión (backpressure)

Acción: Implementar retroceso exponencial (exponential backoff) con fluctuación (jitter); configurar el control de flujo del suscriptor de Pub/Sub; establecer la concurrencia de Cloud Run para equilibrar el rendimiento (throughput) y la latencia; agregar interruptores de circuito (circuit breakers) en los límites de las dependencias descendentes.
Justificación: Una contrapresión (backpressure) adecuada previene fallos en cascada y reintentos descontrolados que degradan los SLO e inflan los costos.

Validación y gobernanza continuas

Acción: Ejecutar pruebas de carga mensuales y simulacros de caos; hacer seguimiento de los SLO/presupuestos de error; integrar los hallazgos de Recommender y las anomalías de costos en la planificación del sprint con propietarios y fechas de entrega.
Justificación: La validación iterativa asegura que los ahorros persistan y que los SLO se mantengan en verde a medida que las cargas de trabajo evolucionan.

← Fiabilidad · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →