Bajada
AWS llevó a disponibilidad general una función de la consola que permite ocultar servicios y regiones para cada cuenta. Aunque no reemplaza controles de IAM o SCP, el cambio mejora la gobernanza operativa en entornos multi-cuenta, reduce errores humanos en equipos grandes y aporta una capa práctica para estandarizar experiencia, auditoría y operación diaria.
Introducción
En organizaciones que operan AWS a escala, la complejidad no suele venir solo de la infraestructura, sino de la experiencia diaria con la consola: cientos de servicios visibles, múltiples regiones habilitadas y equipos con distintos niveles de madurez. En ese contexto, los errores operativos por navegación, selección de región equivocada o ejecución en cuentas no previstas son más frecuentes de lo que admiten los playbooks.
Por eso, la disponibilidad general de las nuevas opciones de Visible services y Visible Regions en AWS Management Console merece atención para perfiles de plataforma, SRE y seguridad. No se trata de un “feature cosmético”: bien implementado, puede reducir fricción operacional, ordenar el trabajo de equipos distribuidos y mejorar la consistencia entre cuentas de desarrollo, pruebas y producción.
Qué ocurrió
El 27 de marzo de 2026, AWS anunció GA para dos configuraciones de consola a nivel cuenta dentro de Unified Settings: control de visibilidad de servicios y control de visibilidad de regiones. Además, confirmó que estas opciones pueden gestionarse desde consola y también por vía programática mediante la API de User Experience Customization (UXC), CLI, SDKs, CDK y CloudFormation.
La implicancia inmediata es que los administradores de cuentas ahora pueden definir una “vista operativa” más acotada para sus usuarios autorizados: mostrar solo lo relevante para ese entorno y ocultar lo que no forma parte del alcance operativo normal de la cuenta. Esto está disponible en regiones comerciales de AWS y sin costo adicional por la función de visibilidad.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto principal es de gobernanza operacional. En modelos multi-cuenta (por ejemplo, landing zones con cuentas separadas por dominio o entorno), muchos incidentes menores nacen de una interfaz demasiado amplia: recursos creados en regiones no deseadas, despliegues en servicios no aprobados o búsquedas de consola que inducen rutas incorrectas. Al reducir la superficie visible, se baja la probabilidad de esos errores.
Para equipos DevOps, esto ayuda a reforzar estándares internos. Una cuenta de CI/CD puede exponer solo los servicios involucrados en pipelines y artefactos; una cuenta de observabilidad puede priorizar CloudWatch, X-Ray o servicios de logging; y una cuenta orientada a datos puede centrarse en su stack autorizado. La consola se vuelve más coherente con el propósito de cada cuenta.
En seguridad, conviene remarcar algo clave documentado por AWS: ocultar servicios o regiones en consola no equivale a bloquear acceso real por API. Es decir, no reemplaza IAM, SCP en AWS Organizations ni controles de red. El valor real está en combinar esta capacidad de UX con políticas duras de autorización. En términos prácticos: menos errores visuales y menor ruido operativo, pero manteniendo el enforcement en capas de control tradicionales.
Detalles técnicos
UXC incorpora tres ejes de configuración: color de cuenta, visibilidad de servicios y visibilidad de regiones. Para los dos últimos, el comportamiento por defecto sigue siendo “todo visible” cuando no existe configuración explícita. También se puede resetear al valor por defecto estableciendo null en los campos correspondientes.
Desde la API, las operaciones quedan registradas como eventos de control en CloudTrail bajo el servicio uxc.amazonaws.com, lo que permite auditoría de cambios y trazabilidad de quién aplicó ajustes de visibilidad, cuándo y desde qué origen. Esto es útil en escenarios con cambios frecuentes de equipos o con requisitos de compliance interno.
Un aspecto relevante para platform engineering es la capacidad programática. Al poder definir la visibilidad como código (vía CLI/SDK/CDK/CloudFormation), se puede versionar la experiencia de consola por tipo de cuenta, aplicar revisiones por pull request y reducir drift entre entornos. Esto alinea bien con estrategias de “account vending” y baselines repetibles.
También hay un ángulo de productividad: equipos nuevos o tercerizados pueden arrancar con una consola más enfocada, lo que reduce onboarding y evita exploraciones innecesarias en servicios no permitidos. En operaciones 24×7, la simplificación de interfaz puede acortar tiempos de reacción durante incidentes, sobre todo cuando hay runbooks basados en consola.
Qué deberían hacer los administradores o equipos técnicos
1. Definir perfiles de visibilidad por tipo de cuenta (dev, test, prod, seguridad, datos) y documentar qué servicios/regiones deben mostrarse en cada caso.
2. No confundir UX con control de acceso: mantener IAM/SCP como capa obligatoria de enforcement y usar UXC como complemento operativo.
3. Automatizar UXC como código para evitar configuraciones manuales divergentes entre cuentas y regiones.
4. Habilitar auditoría explícita en CloudTrail para cambios de UXC y agregar alertas cuando se amplíe visibilidad en cuentas sensibles.
5. Probar impacto en workflows reales (despliegues, incident response, soporte) antes de escalar la configuración a toda la organización.
6. Alinear con gobernanza organizacional: si usan Control Tower o marcos internos de plataforma, incorporar UXC en los estándares de cuenta base.
Conclusión
La novedad de AWS Management Console no es un reemplazo de seguridad, pero sí una mejora concreta para operación diaria en entornos complejos. Al permitir una vista más intencional por cuenta, reduce ruido, baja errores humanos y facilita que cada equipo trabaje con un contexto más claro.
Para quienes administran infraestructura a escala, la oportunidad está en integrarla correctamente: UXC para experiencia y consistencia; IAM/SCP para control efectivo; CloudTrail para trazabilidad. Esa combinación aporta valor técnico real y medible en productividad, gobernanza y resiliencia operativa.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/03/account-customizations-console/
- https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/uxc.html
- https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/log-using-cloudtrail.html