[{"data":1,"prerenderedAt":404},["ShallowReactive",2],{"blog-es-que-revisaria-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada":3},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"date":10,"slug":11,"author":12,"image":13,"tags":14,"language":20,"format":21,"body":22,"_type":398,"_id":399,"_source":400,"_file":401,"_stem":402,"_extension":403},"/es/blog/2026-06-18-que-revisaria-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada","blog",false,"","Qué revisaría en las primeras 48 horas al entrar en una cuenta AWS heredada","Un enfoque senior y seguro para priorizar IAM, costes, exposición pública, backups, Terraform, observabilidad y dependencias de producción.","2026-06-18","que-revisaria-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada","Alejandro Rodríguez","/og-image.png",[15,16,17,18,19],"aws","audit","security","terraform","reliability","es","audit-lesson",{"type":23,"children":24,"toc":385},"root",[25,34,40,45,50,55,62,67,72,77,82,87,93,98,103,108,113,119,124,129,134,139,144,150,155,160,165,170,175,181,186,191,196,201,206,212,217,222,227,232,237,243,248,253,258,263,268,274,279,284,289,294,299,305,310,315,340,345,350,356,361,366,371],{"type":26,"tag":27,"props":28,"children":30},"element","h1",{"id":29},"qué-revisar-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada",[31],{"type":32,"value":33},"text","Qué revisar en las primeras 48 horas al entrar en una cuenta AWS heredada",{"type":26,"tag":35,"props":36,"children":37},"p",{},[38],{"type":32,"value":39},"Entrar en una cuenta AWS heredada no es el momento de demostrar velocidad tocando producción.",{"type":26,"tag":35,"props":41,"children":42},{},[43],{"type":32,"value":44},"Una cuenta puede estar funcionando, desplegando cada semana y sosteniendo clientes, pero seguir teniendo zonas oscuras: accesos antiguos, costes que nadie termina de explicar, buckets o endpoints expuestos sin contexto, backups que existen solo sobre el papel, Terraform parcial, alarmas ruidosas y dependencias que viven en la cabeza de una persona.",{"type":26,"tag":35,"props":46,"children":47},{},[48],{"type":32,"value":49},"Las primeras 48 horas no sirven para rehacer la plataforma. Sirven para entender qué sostiene producción, qué riesgos son visibles y qué decisiones no deberían tomarse.",{"type":26,"tag":35,"props":51,"children":52},{},[53],{"type":32,"value":54},"Ese matiz importa. Un enfoque senior no empieza cerrando puertos, borrando usuarios o reescribiendo Terraform. Empieza separando señales reales de ruido operativo.",{"type":26,"tag":56,"props":57,"children":59},"h2",{"id":58},"primero-qué-es-producción-y-quién-depende-de-qué",[60],{"type":32,"value":61},"Primero: qué es producción y quién depende de qué",{"type":26,"tag":35,"props":63,"children":64},{},[65],{"type":32,"value":66},"Antes de mirar IAM, costes o Terraform, conviene responder una pregunta básica: ¿qué partes de esta cuenta sostienen el negocio ahora mismo?",{"type":26,"tag":35,"props":68,"children":69},{},[70],{"type":32,"value":71},"En una cuenta heredada puede haber varias regiones, entornos mezclados, recursos antiguos, nombres poco claros y servicios que parecen críticos aunque ya no lo sean. También puede ocurrir lo contrario: un recurso con nombre provisional puede estar en mitad del flujo principal de producción.",{"type":26,"tag":35,"props":73,"children":74},{},[75],{"type":32,"value":76},"Lo primero es identificar cuentas, regiones, aplicaciones, bases de datos, colas, jobs, pipelines y puntos de entrada públicos con impacto real. No hace falta tener un diagrama perfecto, pero sí un mapa suficiente para no confundir limpieza con riesgo.",{"type":26,"tag":35,"props":78,"children":79},{},[80],{"type":32,"value":81},"Importa el ownership: quién despliega, quién responde incidentes, quién aprueba cambios, quién entiende la base de datos principal y quién sabe qué no conviene tocar al final de la semana.",{"type":26,"tag":35,"props":83,"children":84},{},[85],{"type":32,"value":86},"Sin ese contexto, cualquier hallazgo técnico parece más simple de lo que es.",{"type":26,"tag":56,"props":88,"children":90},{"id":89},"iam-y-accesos-revisar-señales-no-hacer-una-purga",[91],{"type":32,"value":92},"IAM y accesos: revisar señales, no hacer una purga",{"type":26,"tag":35,"props":94,"children":95},{},[96],{"type":32,"value":97},"IAM suele ser una de las primeras zonas que conviene mirar, pero también una de las que peor tolera cambios impulsivos.",{"type":26,"tag":35,"props":99,"children":100},{},[101],{"type":32,"value":102},"Una revisión inicial debería buscar señales de riesgo: usuarios humanos antiguos, accesos sin owner claro, permisos muy amplios, roles difíciles de explicar, credenciales de larga vida, uso irregular de MFA o políticas que han crecido por acumulación.",{"type":26,"tag":35,"props":104,"children":105},{},[106],{"type":32,"value":107},"El objetivo en las primeras 48 horas no es dejar IAM perfecto. Es entender cómo entran las personas, cómo entran los sistemas, qué accesos sostienen despliegues o integraciones y dónde hay dudas que merecen investigación.",{"type":26,"tag":35,"props":109,"children":110},{},[111],{"type":32,"value":112},"Revocar permisos sin saber qué flujo los usa puede romper producción, CI/CD o una dependencia externa. Por eso la salida razonable no es una limpieza masiva, sino una lista priorizada: riesgos evidentes que requieren atención, accesos que necesitan owner y zonas donde hace falta más contexto antes de tocar.",{"type":26,"tag":56,"props":114,"children":116},{"id":115},"exposición-pública-qué-está-abierto-y-por-qué",[117],{"type":32,"value":118},"Exposición pública: qué está abierto y por qué",{"type":26,"tag":35,"props":120,"children":121},{},[122],{"type":32,"value":123},"La exposición pública no es mala por definición. Una aplicación web, una API o un load balancer existen precisamente para recibir tráfico.",{"type":26,"tag":35,"props":125,"children":126},{},[127],{"type":32,"value":128},"La pregunta útil es otra: qué está expuesto, si esa exposición es intencional, quién la mantiene y qué impacto tendría equivocarse.",{"type":26,"tag":35,"props":130,"children":131},{},[132],{"type":32,"value":133},"En una primera revisión conviene mirar superficies como load balancers, security groups, buckets, endpoints, DNS, certificados y servicios que aceptan tráfico desde Internet. No para aplicar recetas genéricas, sino para clasificar.",{"type":26,"tag":35,"props":135,"children":136},{},[137],{"type":32,"value":138},"Hay exposiciones esperadas, exposiciones toleradas por una decisión histórica y exposiciones accidentales. Meterlas todas en el mismo saco lleva a malas decisiones: o se ignora demasiado, o se cambia demasiado rápido.",{"type":26,"tag":35,"props":140,"children":141},{},[142],{"type":32,"value":143},"Una señal típica de cuenta heredada es que nadie sabe explicar por qué una regla, bucket o endpoint existe como existe. Eso no implica tocarlo en caliente. Implica asignarle contexto, impacto y prioridad.",{"type":26,"tag":56,"props":145,"children":147},{"id":146},"costes-entender-la-factura-sin-convertirlo-en-finops",[148],{"type":32,"value":149},"Costes: entender la factura sin convertirlo en FinOps",{"type":26,"tag":35,"props":151,"children":152},{},[153],{"type":32,"value":154},"Los costes también cuentan una historia de arquitectura.",{"type":26,"tag":35,"props":156,"children":157},{},[158],{"type":32,"value":159},"En las primeras 48 horas no hace falta montar un programa FinOps completo ni prometer ahorros. El objetivo es más básico: entender qué servicios explican la factura, qué ha cambiado recientemente y si hay anomalías que merecen investigación.",{"type":26,"tag":35,"props":161,"children":162},{},[163],{"type":32,"value":164},"A veces el gasto viene de crecimiento legítimo. Otras veces aparece por recursos sobredimensionados, logs retenidos sin criterio, snapshots olvidados, tráfico entre zonas, NAT Gateway, entornos que nadie usa o decisiones de arquitectura que tenían sentido en otro momento.",{"type":26,"tag":35,"props":166,"children":167},{},[168],{"type":32,"value":169},"Lo importante es no convertir la revisión de costes en una caza de culpables. La pregunta senior es: ¿qué parte del gasto está alineada con producción y qué parte sigue siendo incertidumbre?",{"type":26,"tag":35,"props":171,"children":172},{},[173],{"type":32,"value":174},"Si nadie puede explicar los principales bloques de coste sin depender de una persona concreta, ya hay un hallazgo útil. No necesariamente urgente, pero sí relevante para el roadmap.",{"type":26,"tag":56,"props":176,"children":178},{"id":177},"backups-y-recuperación-no-asumir-confianza-porque-hay-producción",[179],{"type":32,"value":180},"Backups y recuperación: no asumir confianza porque hay producción",{"type":26,"tag":35,"props":182,"children":183},{},[184],{"type":32,"value":185},"Que una cuenta esté en producción no significa que tenga una estrategia de recuperación fiable.",{"type":26,"tag":35,"props":187,"children":188},{},[189],{"type":32,"value":190},"Puede haber backups configurados y aun así no existir claridad sobre qué cubren, qué retención tienen, quién los revisa, qué sistemas quedan fuera o cuándo se probó por última vez una restauración.",{"type":26,"tag":35,"props":192,"children":193},{},[194],{"type":32,"value":195},"En una cuenta heredada, esta revisión debería hacerse con cuidado. No se trata de inventar RTOs o RPOs en dos días, ni de afirmar que todo está mal porque no hay un documento formal. Se trata de saber qué sistemas son críticos y qué nivel de confianza existe si algo falla.",{"type":26,"tag":35,"props":197,"children":198},{},[199],{"type":32,"value":200},"Bases de datos, volúmenes, buckets, repositorios, secrets, configuraciones, estados de Terraform y dependencias externas pueden requerir tratamientos distintos. La señal preocupante no es solo la ausencia de backup; también lo es la ausencia de alguien que sepa explicar cómo se recuperaría algo importante.",{"type":26,"tag":35,"props":202,"children":203},{},[204],{"type":32,"value":205},"Una pregunta práctica: si mañana hubiera que restaurar el componente más crítico, ¿el equipo sabría qué hacer sin improvisar bajo presión?",{"type":26,"tag":56,"props":207,"children":209},{"id":208},"terraform-state-e-infraestructura-real-comparar-mapa-y-territorio",[210],{"type":32,"value":211},"Terraform, state e infraestructura real: comparar mapa y territorio",{"type":26,"tag":35,"props":213,"children":214},{},[215],{"type":32,"value":216},"Terraform puede ser una gran ayuda para entender una cuenta AWS heredada, pero no siempre describe toda la realidad.",{"type":26,"tag":35,"props":218,"children":219},{},[220],{"type":32,"value":221},"Puede haber infraestructura gestionada por Terraform, recursos creados a mano, cambios urgentes aplicados fuera del flujo normal, módulos antiguos, state remoto con ownership poco claro o entornos que no siguen el mismo patrón.",{"type":26,"tag":35,"props":223,"children":224},{},[225],{"type":32,"value":226},"La revisión inicial debería responder tres cosas: qué está realmente bajo infraestructura como código, qué queda fuera y qué riesgo tiene cambiarlo.",{"type":26,"tag":35,"props":228,"children":229},{},[230],{"type":32,"value":231},"No hace falta convertir esta parte en una reestructuración de Terraform. En las primeras 48 horas basta con detectar si el state está protegido razonablemente, si hay separación de entornos, si los cambios pasan por revisión, si los planes son comprensibles y si existe drift relevante entre lo declarado y lo desplegado.",{"type":26,"tag":35,"props":233,"children":234},{},[235],{"type":32,"value":236},"La clave es no confundir “hay Terraform” con “la infraestructura es segura de cambiar”. Terraform es parte del mapa. La cuenta real es el territorio.",{"type":26,"tag":56,"props":238,"children":240},{"id":239},"observabilidad-saber-si-verías-venir-un-problema",[241],{"type":32,"value":242},"Observabilidad: saber si verías venir un problema",{"type":26,"tag":35,"props":244,"children":245},{},[246],{"type":32,"value":247},"Muchas cuentas heredadas tienen herramientas de observabilidad. Menos tienen señales útiles.",{"type":26,"tag":35,"props":249,"children":250},{},[251],{"type":32,"value":252},"Puede haber dashboards, logs, métricas, alarmas, CloudWatch, CloudTrail o AWS Config, y aun así el equipo no saber responder preguntas básicas cuando algo va mal: qué servicio está afectado, desde cuándo, qué despliegue pudo influir, si hay impacto en clientes o quién debe actuar.",{"type":26,"tag":35,"props":254,"children":255},{},[256],{"type":32,"value":257},"La revisión de observabilidad no debería empezar preguntando cuántos paneles existen. Debería empezar preguntando qué decisiones permite tomar la información disponible.",{"type":26,"tag":35,"props":259,"children":260},{},[261],{"type":32,"value":262},"Una alarma que nadie atiende es ruido. Un dashboard que solo entiende una persona es dependencia. Un log que existe pero no ayuda a investigar también es deuda operativa.",{"type":26,"tag":35,"props":264,"children":265},{},[266],{"type":32,"value":267},"En las primeras 48 horas, el objetivo es identificar si el equipo podría detectar una degradación, entender su impacto y relacionarla con cambios recientes. Si no, la plataforma puede estar operando con más confianza aparente que real.",{"type":26,"tag":56,"props":269,"children":271},{"id":270},"dependencias-de-producción-lo-que-no-aparece-en-el-diagrama",[272],{"type":32,"value":273},"Dependencias de producción: lo que no aparece en el diagrama",{"type":26,"tag":35,"props":275,"children":276},{},[277],{"type":32,"value":278},"Las cuentas heredadas rara vez fallan solo por lo evidente.",{"type":26,"tag":35,"props":280,"children":281},{},[282],{"type":32,"value":283},"También hay certificados, dominios, integraciones de terceros, pipelines, jobs nocturnos, colas, webhooks, secrets, usuarios de servicio, repositorios, imágenes, runners, herramientas externas y procesos manuales que sostienen partes críticas del sistema.",{"type":26,"tag":35,"props":285,"children":286},{},[287],{"type":32,"value":288},"Muchas de estas dependencias no aparecen en el primer diagrama. A veces ni siquiera están documentadas. Se descubren preguntando qué pasa si se cae un proveedor, si caduca un certificado, si falla un job, si cambia una credencial o si la persona que conoce el flujo no está disponible.",{"type":26,"tag":35,"props":290,"children":291},{},[292],{"type":32,"value":293},"Aquí la documentación mínima tiene mucho valor. No manuales eternos, sino ownership, impacto, señales de fallo y pasos básicos de operación.",{"type":26,"tag":35,"props":295,"children":296},{},[297],{"type":32,"value":298},"Una cuenta AWS heredada no se entiende solo mirando AWS. Se entiende mirando el sistema completo que hace que producción funcione.",{"type":26,"tag":56,"props":300,"children":302},{"id":301},"cómo-priorizar-después-de-las-48-horas",[303],{"type":32,"value":304},"Cómo priorizar después de las 48 horas",{"type":26,"tag":35,"props":306,"children":307},{},[308],{"type":32,"value":309},"El resultado de una buena revisión inicial no debería ser una lista infinita de problemas.",{"type":26,"tag":35,"props":311,"children":312},{},[313],{"type":32,"value":314},"Debería ser una clasificación clara:",{"type":26,"tag":316,"props":317,"children":318},"ul",{},[319,325,330,335],{"type":26,"tag":320,"props":321,"children":322},"li",{},[323],{"type":32,"value":324},"Riesgos inmediatos que requieren atención cuidadosa.",{"type":26,"tag":320,"props":326,"children":327},{},[328],{"type":32,"value":329},"Temas que necesitan investigación antes de tocar nada.",{"type":26,"tag":320,"props":331,"children":332},{},[333],{"type":32,"value":334},"Deuda técnica planificable.",{"type":26,"tag":320,"props":336,"children":337},{},[338],{"type":32,"value":339},"Mejoras futuras que no bloquean producción.",{"type":26,"tag":35,"props":341,"children":342},{},[343],{"type":32,"value":344},"Esta clasificación evita dos errores habituales: ignorar señales importantes porque “todo funciona”, o intentar arreglarlo todo a la vez y generar más riesgo del que se reduce.",{"type":26,"tag":35,"props":346,"children":347},{},[348],{"type":32,"value":349},"Una cuenta heredada necesita criterio, no heroicidad. A veces la mejor decisión durante las primeras 48 horas es no cambiar nada todavía, pero salir con un mapa mucho más claro de qué merece acción y en qué orden.",{"type":26,"tag":56,"props":351,"children":353},{"id":352},"cerrar-incertidumbre-antes-de-acelerar-cambios",[354],{"type":32,"value":355},"Cerrar incertidumbre antes de acelerar cambios",{"type":26,"tag":35,"props":357,"children":358},{},[359],{"type":32,"value":360},"Heredar una cuenta AWS no debería convertirse en una auditoría teatral ni en una carrera por demostrar control.",{"type":26,"tag":35,"props":362,"children":363},{},[364],{"type":32,"value":365},"La prioridad es entender qué sostiene producción, dónde hay exposición real, qué accesos existen, qué costes merecen atención, qué backups generan confianza, cuánto coincide Terraform con la realidad, qué señales de observabilidad sirven y qué dependencias no estaban visibles.",{"type":26,"tag":35,"props":367,"children":368},{},[369],{"type":32,"value":370},"Con eso, el equipo puede decidir mejor: qué tocar ahora, qué estudiar, qué convertir en roadmap y qué dejar tranquilo.",{"type":26,"tag":35,"props":372,"children":373},{},[374,376,383],{"type":32,"value":375},"Si has heredado una cuenta AWS y necesitas separar riesgos reales de ruido operativo, AstralDeploy puede ayudarte con una ",{"type":26,"tag":377,"props":378,"children":380},"a",{"href":379},"/servicios/cloud-reliability",[381],{"type":32,"value":382},"revisión de fiabilidad cloud en AWS",{"type":32,"value":384}," orientada a entender producción, priorizar hallazgos y avanzar sin romper lo que ya sostiene el negocio.",{"title":7,"searchDepth":386,"depth":386,"links":387},2,[388,389,390,391,392,393,394,395,396,397],{"id":58,"depth":386,"text":61},{"id":89,"depth":386,"text":92},{"id":115,"depth":386,"text":118},{"id":146,"depth":386,"text":149},{"id":177,"depth":386,"text":180},{"id":208,"depth":386,"text":211},{"id":239,"depth":386,"text":242},{"id":270,"depth":386,"text":273},{"id":301,"depth":386,"text":304},{"id":352,"depth":386,"text":355},"markdown","content:es:blog:2026-06-18-que-revisaria-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada.md","content","es/blog/2026-06-18-que-revisaria-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada.md","es/blog/2026-06-18-que-revisaria-en-las-primeras-48-horas-al-entrar-en-una-cuenta-aws-heredada","md",1781784848359]