La guía completa de AWS Config: sistematizar el seguimiento de cambios de configuración y el cumplimiento continuo (con comparaciones con GCP Cloud Asset Inventory / Azure Policy + Resource Graph)

Primero lo esencial: AWS Config es la base para manejar tanto la “evidencia de cambios” como el “cumplimiento continuo”

AWS Config es un servicio orientado a gobernanza que registra las configuraciones (ajustes) de recursos de AWS, rastrea cambios y evalúa el cumplimiento mediante reglas. Lo que realmente importa en operaciones reales es poder explicar—durante incidentes o auditorías—“cuándo, qué ajuste, cambió y cómo”, y poder convertir “detectar deriva del estado deseado y restaurarlo” de un procedimiento manual en un mecanismo. :contentReference[oaicite:0]{index=0}

El mismo dolor existe en GCP y Azure. En GCP, Cloud Asset Inventory indica explícitamente que puede usarse para rastrear cambios de recursos para auditorías y gestión de deriva, y que puedes recibir notificaciones de cambios mediante Pub/Sub. :contentReference[oaicite:1]{index=1}
En Azure, se organiza de modo que Azure Policy puede imponer, evaluar y remediar estándares organizacionales a escala, mientras que Resource Graph soporta exploración de activos e inventario en la nube. :contentReference[oaicite:2]{index=2}

Este artículo se centra en AWS Config y, desde una perspectiva “sobre el terreno”, hilvana una sola historia de diseño: “¿qué debemos registrar?”, “¿cómo evaluamos?” y “¿cómo agregamos en entornos multi-cuenta?”

A quién ayuda (en concreto)

Primero, a equipos de SRE / operaciones. En incidentes relacionados con configuración, lo más difícil no es “encontrar al culpable”, sino “establecer los hechos”. Con AWS Config, el historial de configuración y las relaciones entre recursos (dependencias) ayudan a delimitar impacto y acotar causas relacionadas con cambios más rápido. :contentReference[oaicite:3]{index=3}

Luego, a equipos de seguridad / TI corporativa. En auditorías y requisitos de clientes, “tenemos reglas” y “cumplimos continuamente” no son lo mismo. AWS Config soporta evaluación por reglas y ofrece “conformance packs” que agrupan reglas y remediación, facilitando distribuir chequeos de cumplimiento continuo. :contentReference[oaicite:4]{index=4}

Y por último, a administradores cloud que operan múltiples cuentas. AWS Config ofrece un Aggregator para ver de forma centralizada datos de AWS Config a través de múltiples cuentas, múltiples regiones y AWS Organizations. :contentReference[oaicite:5]{index=5}
Si estás cansado de “revisar cada cuenta por separado”, esto apunta a construir una vista centralizada.

1. Qué es AWS Config: un servicio que trata “registro (evidencia)” y “evaluación (cumplimiento)” en la misma UI y lenguaje

La esencia de AWS Config es que puede manejar simultáneamente:

• Registrar continuamente cambios de configuración y conservarlos como historial (evidencia)
• Evaluar contra reglas y detectar no cumplimiento (cumplimiento continuo)

Las descripciones oficiales indican que AWS Config rastrea cambios en la configuración de recursos, entrega periódicamente información de configuración actualizada a un bucket de S3 especificado, envía archivos de historial a intervalos regulares (p. ej., cada 6 horas) y puede entregar snapshots de configuración (una foto completa). :contentReference[oaicite:6]{index=6}

El punto clave: Config se parece más a “registrar y evaluar” que a “monitorear”. En vez de detección segundo a segundo como el monitoreo por métricas, se enfoca en cambios de “estado” (configuración) y si ese estado cumple reglas. Por eso es especialmente fuerte para prevención post-incidente, respuesta a auditorías y estandarización continua.

2. La primera decisión de diseño: qué registrar (alcance) determina el 90% del éxito operativo

Cuando equipos introducen AWS Config, la primera pregunta común es: “¿Debemos registrar todo?” La respuesta práctica suele ser: define objetivos primero y despliega el alcance por fases, en lugar de registrar todo sin condiciones desde el día uno.

Oficialmente, Config crea archivos de historial de configuración por tipo de recurso e incluye detalles sobre recursos que cambiaron. Eso significa que cuanto más amplio sea el alcance, más datos emites y más pesadas se vuelven las operaciones de almacenamiento/búsqueda/retención. :contentReference[oaicite:7]{index=7}

Además, la documentación japonesa señala explícitamente que registrar AWS::Config::ResourceCompliance (para conservar resultados pasados de cumplimiento) no es requerido para evaluaciones de cumplimiento actuales y puede excluirse si no es necesario. Esto es muy práctico: puedes ajustar la “profundidad del historial” según requisitos. :contentReference[oaicite:8]{index=8}

Un despliegue por fases recomendado (el menos polémico en equipos reales) se ve así:

1. Empezar por “áreas de alto dolor” (red, permisos, exposición pública) para registro/evaluación
2. Añadir “áreas propensas a accidentes de costo” (recursos sin uso, tags faltantes, abandono)
3. Finalmente, añadir “áreas con auditoría estricta” (emparejadas con retención y presentación de evidencia)

Esta secuencia hace visible el beneficio temprano mientras controla la carga operativa.

3. Reglas y conformance packs: de “reglas individuales” a “operaciones empaquetadas”

AWS Config evalúa mediante Config Rules (administradas/personalizadas), y los conformance packs permiten distribuir múltiples reglas y acciones de remediación juntas. La documentación oficial describe un conformance pack como “una colección de reglas de Config y acciones de remediación” que puede desplegarse en cuentas/regiones o en toda una Organization. :contentReference[oaicite:9]{index=9}

Un consejo operativo importante es no añadir reglas “a lo loco”. Si sigues agregando reglas sueltas sin plan, suele pasar:

• Nadie sabe para qué sirve una regla
• El manejo de excepciones depende de personas
• El no cumplimiento crece tanto que nadie lo mira

Plantillas de ejemplo muestran que los conformance packs se pueden agrupar por propósito—“seguridad”, “operaciones”, “optimización de costos”, etc. :contentReference[oaicite:10]{index=10}
En otras palabras, puedes operar conjuntos de reglas como “paquetes por propósito”, lo que facilita alineación del equipo.

Ejemplos de paquetes (conceptual)

• Paquete base de seguridad: mínimos indispensables (exposición pública, cifrado, logging, etc.)
• Paquete estándar de operaciones: etiquetado, backups por defecto, expectativas de monitoreo, etc.
• Paquete de higiene de costos: detección temprana de recursos sin uso/abandonados/sobredimensionados

Este enfoque “a nivel de paquete” también mapea bien a GCP/Azure (policy sets y estándares organizacionales), como veremos luego.

4. Agregación multi-cuenta: usa Aggregator para tener “un solo lugar donde mirar”

Como AWS suele adoptar por defecto estructuras multi-cuenta, es común querer una vista centralizada de Config. La documentación oficial explica que los aggregators pueden recopilar datos de configuración y cumplimiento de AWS Config desde múltiples cuentas y regiones, o desde todas las cuentas habilitadas bajo Organizations. :contentReference[oaicite:11]{index=11}

Una vez que esto está, los beneficios operativos se notan de inmediato:

• Ver qué cuentas están fuera de cumplimiento de un vistazo
• Operar como “mecanismo de restauración”, no como “culpar a un equipo”
• Explicar en auditorías que la organización realiza evaluación continua

En resumen, el valor de Config crece mucho en entornos multi-cuenta donde la estandarización es el objetivo.

5. Seguimiento de cambios: Config brilla cuando debes explicar “¿desde cuándo está mal?”

El momento más “me salvó” de AWS Config suele ser durante respuesta a incidentes o investigaciones cuando preguntan: “¿Desde cuándo este ajuste está así?” Config puede entregar archivos de historial y snapshots a S3 y preservarlos como historial. :contentReference[oaicite:12]{index=12}

También se describe que puedes almacenar y ver una línea temporal de cambios de estado de cumplimiento para conformance packs. Esto significa que puedes rastrear no solo “está fuera de cumplimiento ahora”, sino también “cuándo se volvió no conforme”, lo cual es evidencia operativa muy valiosa. :contentReference[oaicite:13]{index=13}

El punto de diseño aquí no es solo “guardar historial o no”, sino también:

• Cuánto tiempo lo retienes
• Quién lo mira y con qué frecuencia
• Cómo gestionas excepciones (desviaciones legítimas)

“Existen logs pero nadie los revisa” se vuelve efectivamente “no existen logs”, así que se recomienda definir una cadencia mínima (p. ej., revisión semanal/mensual del top 10 de no conformidades).

6. Comparación con GCP: Cloud Asset Inventory se centra en “inventario + notificaciones de cambio”

GCP Cloud Asset Inventory se organiza alrededor de casos como filtrado de metadatos, trazas de auditoría vía seguimiento de cambios, gestión de deriva de cumplimiento y auditorías de seguridad/costo. :contentReference[oaicite:14]{index=14}
Para historial de activos, declara explícitamente que puedes recuperar hasta 35 días de historial de creación/actualización/eliminación. :contentReference[oaicite:15]{index=15}

También describe oficialmente que puedes recibir “notificaciones de cambio en tiempo real” vía Pub/Sub creando y suscribiéndote a feeds. :contentReference[oaicite:16]{index=16}

Así que, en GCP, un patrón estándar común es:

• Usar Asset Inventory para inventario (estado actual) e historial (cambios recientes)
• Usar notificaciones (Pub/Sub) como disparador para construir detección → respuesta automatizada (o ticketing)

Una diferencia clara vs AWS Config es que AWS puede poner “evaluación por reglas y cumplimiento” en el centro con Config, mientras que en GCP “visibilidad de activos y detección de cambios” se resuelve fuerte con Asset Inventory, y el enforcement/remediación suele construirse combinando otros mecanismos (Org Policy, automatización). No es “cuál es mejor”, sino una diferencia de filosofía de diseño y fronteras de servicio.

7. Comparación con Azure: Policy maneja “evaluación + remediación”, Resource Graph maneja “exploración multi-entorno”

Azure Policy se describe como un mecanismo para imponer estándares organizacionales y evaluar cumplimiento a escala, ofreciendo vistas agregadas vía dashboards de cumplimiento y contemplando remediación masiva de recursos existentes así como remediación automática para recursos nuevos. :contentReference[oaicite:17]{index=17}

Para “tareas de remediación” que corrigen recursos no conformes, explica explícitamente ejecutar operaciones de remediación (por IDs especificados) para asignaciones deployIfNotExists y modify. :contentReference[oaicite:18]{index=18}

Mientras tanto, Resource Graph se organiza como un servicio para explorar el inventario cloud y gestionarlo más eficazmente. :contentReference[oaicite:19]{index=19}
En otras palabras, Azure divide claramente:

• Policy: evaluar si se cumplen estándares + mecanismo de restauración
• Resource Graph: inventario/exploración transversal (consulta)

Mapeo con AWS Config: la “evaluación (reglas / conformance packs)” de Config se parece a Policy, y el “inventario/historial” de Config se acerca a Resource Graph / gestión de activos. Para alinear gobernanza multi-cloud, discutirlo con este mapeo suele sincronizar entendimiento entre equipos.

8. Plantilla práctica de adopción: qué decidir en las primeras dos semanas

Para evitar “habilitamos AWS Config pero solo está ahí”, estos puntos se vuelven mucho más fáciles si se alinean temprano:

1. Prioridad de objetivos
   ¿Es para auditorías, investigación de incidentes o estandarización (cumplimiento continuo)? Los objetivos cambian alcance de registro y selección de reglas. :contentReference[oaicite:20]{index=20}

2. Alcance de registro (tipos de recurso objetivo)
   ¿Empiezas con todo o con dominios críticos? Decídelo junto con la profundidad de historial (p. ej., si retener historial de cumplimiento pasado). :contentReference[oaicite:21]{index=21}

3. Unidad de operación de reglas
   ¿Creces con reglas individuales o agrupas por propósito con conformance packs? A largo plazo, los packs tienden a colapsar menos. :contentReference[oaicite:22]{index=22}

4. Enfoque de agregación multi-cuenta
   ¿Agregarás centralmente con un Aggregator, y qué cuenta “posee” la vista agregada? :contentReference[oaicite:23]{index=23}

5. Política de almacenamiento y retención
   Como Config entrega historial a S3, define retención y lifecycle/archivo como reglas operativas. También se especifica que Config no modifica políticas de lifecycle de S3. :contentReference[oaicite:24]{index=24}

6. Construir una “rutina de revisión”
   Define quién revisa qué semanal/mensualmente (revisión de no conformidad, revisión de excepciones). Sin esto, la no conformidad se acumula y el sistema se vuelve ceremonial.

Resumen: AWS Config se vuelve “confianza del equipo” a medida que madura la estandarización

AWS Config es un servicio central de gobernanza que registra cambios de configuración, preserva historial y evalúa cumplimiento mediante reglas. Con bloques como entrega a S3 de historial y snapshots, empaquetado de reglas y remediaciones mediante conformance packs, y agregación multi-cuenta con aggregators, es muy adecuado para pasar de “procedimientos” a “mecanismos”. :contentReference[oaicite:25]{index=25}

GCP Cloud Asset Inventory es fuerte en inventario + seguimiento de cambios y notificaciones Pub/Sub, mientras Azure muestra una división clara: Policy para evaluación/remediación y Resource Graph para exploración multi-entorno. :contentReference[oaicite:26]{index=26}

Un “primer paso” robusto es: “empezar registrando + evaluando dominios críticos, agrupar por propósito con conformance packs y crear una vista agregada central con Aggregator”. Empieza pequeño y no te apresures—pero define con cuidado la “rutina de revisión” desde el principio. Con AWS Config, ese cuidado se traduce directamente en fortaleza para respuesta a incidentes y preparación de auditorías.

Enlaces de referencia (priorizando fuentes oficiales / primarias)

• What is AWS Config? (Official) :contentReference[oaicite:27]{index=27}

• How AWS Config works (history files / snapshot delivery) :contentReference[oaicite:28]{index=28}

• AWS Config Conformance Packs :contentReference[oaicite:29]{index=29}

• Conformance pack sample templates :contentReference[oaicite:30]{index=30}

• AWS Config multi-account / multi-region aggregation (Aggregator) :contentReference[oaicite:31]{index=31}

• GCP Cloud Asset Inventory overview :contentReference[oaicite:32]{index=32}

• GCP real-time asset change notifications (Pub/Sub feeds) :contentReference[oaicite:33]{index=33}

• GCP asset history retrieval (up to 35 days) :contentReference[oaicite:34]{index=34}

• Azure Policy overview (compliance evaluation and remediation) :contentReference[oaicite:35]{index=35}

• Azure Policy remediation for non-compliant resources :contentReference[oaicite:36]{index=36}

• Azure Resource Graph documentation (inventory exploration) :contentReference[oaicite:37]{index=37}