Amazon SAP-C02: Optimización de Costos y Gobernanza — Guía de estudio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Solutions Architect Professional SAP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Visibilidad, asignación e informes de costos

Lograr una verdadera visibilidad de costos comienza con una asignación de costos consistente e impuesta, y con informes de alta fidelidad. Implemente AWS Organizations con una cuenta de pago designada y habilite la facturación consolidada para centralizar las facturas mientras se mantiene la separación de cargos por cuenta. Active el AWS Cost and Usage Report (CUR) con granularidad por hora, entrega en S3 e integración con Amazon Athena para que pueda ejecutar consultas ad hoc y unir los registros de costos con los metadatos de los recursos. Implemente una estrategia de etiquetado estricta: defina un conjunto obligatorio de etiquetas de asignación de costos (entorno, proyecto, propietario, unidad de negocio y centro de costos) y exíjalas en el momento del aprovisionamiento utilizando CloudFormation StackSets, Service Control Policies para limitar los patrones de creación de recursos sin etiquetar, y AWS Config Rules que evalúen y corrijan automáticamente las etiquetas faltantes. Combine Cost Explorer con informes de entidades reservadas y de ajuste de tamaño (rightsizing) para comprender las tendencias de gasto y la capacidad inactiva. Las trampas comunes incluyen una cobertura de etiquetas incompleta que sesga los contracargos (chargebacks), depender únicamente de la Billing Console sin los análisis del CUR, y no capturar los costos de transferencia entre cuentas o entre regiones. Las compensaciones en las decisiones a menudo se reducen a la puntualidad frente a la granularidad: habilitar los CUR por hora y Athena cuesta más en procesamiento, pero produce la atribución precisa necesaria para las decisiones de negocio, mientras que los resúmenes mensuales generales son más baratos operacionalmente, pero ocultan los picos transitorios y los recursos ineficientes.

Precios comprometidos, ajuste de tamaño (rightsizing) y estrategia de compra

Optimizar el gasto comprometido requiere elegir entre Savings Plans, Reserved Instances y precios transitorios como Spot, mientras se utiliza el ajuste de tamaño (rightsizing) para adecuar la capacidad a los perfiles de la carga de trabajo. Comience con los patrones de uso de Cost Explorer y Compute Optimizer para identificar las líneas base de CPU/memoria en estado estable y las oportunidades para cambiar de familia o tamaño de instancia. Prefiera los Compute Savings Plans cuando se necesite flexibilidad en la carga de trabajo entre tipos de instancia y regiones, y utilice EC2 Instance Reservations cuando familias de instancias específicas y ubicaciones en Zonas de Disponibilidad (AZ) justifiquen descuentos más profundos. Aproveche Spot para cargas de trabajo por lotes (batch) y de microservicios tolerantes a fallos, pero evite Spot para servicios con estado (stateful) en una sola AZ que no tengan un sistema robusto de puntos de control (checkpointing). El ajuste de tamaño (rightsizing) debe combinar las recomendaciones automatizadas de Compute Optimizer y Trusted Advisor con una revisión manual para evitar una reducción de tamaño demasiado agresiva que afecte al rendimiento. Esté atento a las trampas, como comprometerse en exceso con RIs de 3 años cuando los pronósticos de negocio son inciertos, infrautilizar los Savings Plans debido a un uso no etiquetado o aislado en una cuenta, y asumir la intercambiabilidad de familias de instancias sin realizar pruebas. Las compensaciones suelen ser el costo frente a la flexibilidad operativa: los descuentos más profundos a largo plazo reducen el costo unitario, pero añaden riesgo empresarial si la demanda cae o la arquitectura cambia; por el contrario, Spot y on-demand ofrecen agilidad a un mayor costo por unidad.

Gobernanza, aplicación de políticas y remediación automatizada

La gobernanza centralizada establece barreras de protección (guardrails) que evitan el gasto descontrolado al tiempo que habilitan a los equipos autónomos. Utilice AWS Control Tower o una línea base de Organizations bien diseñada para aprovisionar cuentas con barreras de protección (guardrails) preconfiguradas y registro centralizado. Aplique Service Control Policies para limitar los servicios de alto costo o las regiones no aprobadas, e implemente AWS Config Rules para detectar configuraciones no conformes, como buckets de S3 públicos, tipos de instancia sobredimensionados o falta de cifrado y etiquetas. Integre AWS Budgets con acciones automatizadas: establezca umbrales de presupuesto que activen notificaciones de SNS y una remediación automatizada a través de Lambda o Systems Manager (por ejemplo, detener/terminar instancias inactivas o reducir la clase de instancia de RDS). Trusted Advisor complementa la gobernanza al exponer comprobaciones de optimización de costos, pero no lo trate como la única señal; las comprobaciones gratuitas de Trusted Advisor son limitadas y los conocimientos detallados requieren un plan de soporte Business o Enterprise. Las trampas comunes incluyen el uso de SCPs de forma demasiado restrictiva, bloqueando cambios operativos legítimos; depender únicamente de notificaciones sin una aplicación automatizada; y conceder privilegios de IAM excesivos que permiten eludir las políticas. Evalúe las decisiones de gobernanza sopesando la autonomía del negocio frente al riesgo: los controles más estrictos evitan los costos descontrolados, pero pueden ralentizar la velocidad y requieren un proceso de excepción bien definido.

Patrones de arquitectura conscientes de los costos y consideraciones sobre la transferencia de datos

Las decisiones de arquitectura influyen profundamente en los costos continuos. Descargue el contenido de alto volumen y la distribución global a Amazon CloudFront para reducir las solicitudes al origen de S3 y los cargos de egreso; use S3 Transfer Acceleration solo cuando los beneficios de latencia justifiquen los mayores costos de transferencia. Para arquitecturas entre zonas de disponibilidad (cross-AZ) y entre regiones (cross-Region), recuerde que la transferencia de datos entre AZ puede tener un costo; diseñe para la localidad del tráfico dentro de una misma AZ (intra-AZ) cuando sea posible, o agregue el tráfico a través de servicios regionales. Para la distribución de archivos grandes, considere Amazon S3 con cargas multiparte (multipart upload) y políticas de ciclo de vida (lifecycle policies), S3 Intelligent-Tiering para accesos impredecibles y EFS One Zone para cargas de trabajo en una única AZ donde las concesiones en resiliencia reducen el costo. Al migrar cargas de trabajo de contenedores, evalúe Fargate frente a ECS/EKS respaldado por EC2: Fargate aumenta la simplicidad operativa y reduce la sobrecarga de gestión del clúster, pero generalmente cuesta más por vCPU/memoria que los grupos de nodos respaldados por instancias Spot de EC2 bien compactados. Las trampas comunes incluyen subestimar la replicación entre regiones, colocar registros de alta rotación (high-churn) en clases de almacenamiento de acceso poco frecuente y asumir que los VPC endpoints son gratuitos; estos ahorran en el egreso de NAT, pero añaden cargos por hora y por GB. Los criterios de decisión deben sopesar la gravedad de los datos (data gravity), los SLA de latencia y las necesidades de durabilidad: elija almacenamiento o cómputo más económico solo donde los requisitos de resiliencia y rendimiento lo permitan.

Problema práctico: Escenario de caso de uso

Escenario: Acme Global Enterprises opera un entorno de AWS maduro con 18 cuentas miembro bajo AWS Organizations, una cuenta de pago centralizada y cargas de trabajo en tres regiones. Tienen una adopción parcial del etiquetado, ejecutan varias flotas de EC2 de larga duración y usan S3 de forma extensiva para datos de analítica.

Desafío: Necesitan reducir su gasto mensual en AWS en un 20 % en un plazo de seis meses, preservando los SLA de rendimiento y permitiendo que los equipos autónomos desplieguen funcionalidades.

Enfoque recomendado:

Habilite el Cost and Usage Report en S3 con granularidad horaria e intégrelo con Amazon Athena; cree informes de instancias reservadas y de optimización de tamaño (rightsizing) en Cost Explorer para los últimos 6 a 12 meses.
Despliegue Compute Optimizer y analice el uso de instancias en estado estable; adquiera una combinación de Compute Savings Plans para una cobertura amplia y RIs convertibles a 1 año para cargas de trabajo predecibles y específicas de una familia de instancias.
Imponga el etiquetado a través de CloudFormation StackSets y reglas de AWS Config con remediación automática para etiquetas faltantes; canalice los informes de costos por etiqueta a los propietarios de las unidades de negocio y cree AWS Budgets con remediación automatizada mediante SNS y Lambda para las infracciones de umbral.
Mueva el contenido estático y distribuido globalmente a Amazon CloudFront, convierta los datos de acceso poco frecuente a S3 Intelligent-Tiering con transiciones de ciclo de vida, e identifique trabajos por lotes (batch jobs) adecuados para Spot con puntos de control (checkpointing) para migrarlos fuera de la capacidad bajo demanda (on-demand).

Justificación: La visibilidad centralizada (CUR + Athena) expone oportunidades concretas de optimización de tamaño (rightsizing) y de compra de instancias reservadas, mientras que las barreras de protección automatizadas (guardrails) (Config, StackSets, Budgets) imponen la asignación de costos y previenen regresiones; la combinación de Savings Plans con RIs selectivas equilibra la profundidad del descuento y la flexibilidad para una reducción de costos fiable sin sacrificar el rendimiento.

← Resiliencia · Todos los dominios · Despliegue →

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