AWS elimina el bucketsquatting en S3: así funciona

¿Qué es el bucketsquatting y por qué debería importarte como founder?

Si tu startup usa Amazon S3 para almacenar datos, logs, assets o artefactos de despliegue —y casi todas lo hacen—, hay una vulnerabilidad que ha acechado el ecosistema cloud durante más de una década: el bucketsquatting, también conocido como bucketsniping.

El problema es sencillo pero devastador: los nombres de los buckets de S3 son globalmente únicos en toda la plataforma de AWS. Si una organización elimina un bucket, ese nombre queda libre para que cualquier atacante lo registre antes de que nadie lo note. Si el atacante conoce (o puede predecir) el nombre que usaba ese bucket, puede reclamarlo, configurarlo con políticas permisivas y quedar posicionado para interceptar datos, ejecutar código malicioso o interrumpir servicios que aún apuntan a ese nombre.

Este escenario no es teórico. Investigadores de seguridad como Ian Mckay (del blog onecloudplease.com) llevan casi una década documentando cómo convenciones de nombres predecibles —del tipo myapp-us-east-1— facilitan estos ataques. Incluso los propios equipos internos de AWS han sido víctimas de esta práctica, según el mismo investigador.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El nuevo namespace de AWS: la solución que el ecosistema esperaba

El 12 de marzo de 2026, Amazon Web Services anunció oficialmente los Account Regional Namespaces para Amazon S3, disponibles de inmediato en 37 regiones de AWS, incluyendo AWS China y AWS GovCloud (US), sin costo adicional.

La mecánica es elegante: en lugar de competir por un nombre en un espacio global, ahora puedes crear buckets bajo un namespace reservado exclusivamente para tu cuenta y región. El patrón de nomenclatura es el siguiente:

myprefix-<accountid>-<region>-an

Por ejemplo, si tu Account ID de AWS es 123456789012, tu prefijo es myapp y quieres crear un bucket en us-west-2, el nombre sería:

myapp-123456789012-us-west-2-an

El sufijo -an hace referencia a account namespace. Una vez adoptado este patrón, ninguna otra cuenta de AWS puede crear un bucket con ese mismo nombre. Si alguien lo intenta, AWS devuelve el error InvalidBucketNamespace. La misma respuesta se recibe si el propietario legítimo intenta crear un bucket donde la región del nombre no coincide con la región real del bucket.

¿Cómo se crea un bucket con namespace?

La integración es directa desde las herramientas que ya usas. Puedes hacerlo mediante:

Consola de AWS: seleccionando la opción de namespace al crear el bucket.
API REST de S3: añadiendo el parámetro BucketNamespace: 'account-regional' en la llamada CreateBucket.
AWS CLI y SDKs: con el mismo parámetro disponible en todos los lenguajes.
AWS CloudFormation: usando la propiedad BucketNamePrefix, que añade automáticamente el sufijo -an.

Con boto3 (Python), el flujo sería tan simple como resolver dinámicamente el account_id y la region para construir el nombre y luego llamar a create_bucket con el nuevo parámetro.

Enforcement a nivel organizacional: el nuevo condition key

Uno de los aspectos más poderosos de esta actualización para equipos con múltiples cuentas de AWS es la posibilidad de exigir el uso del namespace a nivel de organización. AWS ha introducido una nueva condition key llamada s3:x-amz-bucket-namespace, que puede aplicarse en las Service Control Policies (SCPs) de AWS Organizations.

Esto significa que un administrador de seguridad puede crear una política que bloquee la creación de cualquier bucket que no siga el patrón de namespace, garantizando protección consistente en toda la organización sin depender de que cada equipo lo implemente manualmente.

Para startups que escalan rápido y suman desarrolladores constantemente, esto es un cambio de paradigma: la seguridad pasa de ser una responsabilidad individual a una restricción estructural imposible de ignorar.

¿Protege los buckets existentes?

Aquí conviene ser honesto: no de forma retroactiva. Los buckets ya creados con nombres tradicionales no quedan automáticamente protegidos por este mecanismo. Tampoco los templates de CloudFormation, Terraform o CDK que ya tengas en producción con patrones de región como sufijo o prefijo.

Si quieres proteger tu infraestructura existente, la ruta es crear nuevos buckets bajo el namespace y migrar los datos. No es trivial, pero es el precio de adoptar una arquitectura verdaderamente segura. Dicho esto, para todos los proyectos nuevos o pipelines CI/CD que arranques a partir de hoy, adoptar el patrón -an debería ser el estándar por defecto.

¿Cómo están Google Cloud y Azure frente a este problema?

Vale la pena contextualizar esta solución dentro del panorama más amplio del cloud:

Google Cloud Storage: ya contaba con una solución parcial basada en verificación de dominio. Los buckets con formato de nombre de dominio (ej. myapp.com) solo pueden crearse si el propietario demuestra que controla ese dominio. Sin embargo, los buckets con nombres arbitrarios siguen siendo vulnerables al bucketsquatting.
Azure Blob Storage: el modelo de Storage Accounts —donde los datos se acceden mediante una URL que combina nombre de cuenta y contenedor— reduce considerablemente este riesgo de forma estructural. La exposición es menor por diseño.

AWS S3, con su espacio de nombres completamente global y su enorme adopción en el ecosistema startup, era el más expuesto. Esta actualización lo pone en una posición mucho más sólida.

Ataques reales que este namespace previene

Para dimensionar el impacto, vale recordar algunos casos documentados:

Bucket Monopoly (Aqua Security, 2024): investigadores demostraron que fallos en al menos seis servicios de AWS permitían a atacantes ejecutar código remoto, robar datos o incluso tomar control completo de cuentas mediante el registro de buckets con nombres predecibles usados por servicios internos como AWS Athena o AWS Config.
AWS CDK: el propio kit de desarrollo cloud de AWS generaba nombres de buckets predecibles por defecto, lo que permitía a adversarios posicionarse antes de que los equipos desplegaran su infraestructura.
Shadow Resources: organizaciones que eliminaban buckets de ambientes temporales (staging, pruebas) sin saber que esos nombres seguían siendo referenciados por pipelines productivos.

Todos estos vectores se neutralizan cuando los nombres de bucket están atados a un namespace de cuenta irrepetible.

Lo que debes hacer hoy en tu startup

La acción concreta es clara y urgente para cualquier equipo técnico:

Adopta el patrón -an en todos los buckets nuevos, desde hoy. Actualiza tus templates de IaC (Terraform, CDK, CloudFormation) para generar nombres que incluyan accountid y region con el sufijo -an.
Implementa una SCP con s3:x-amz-bucket-namespace si manejas múltiples cuentas bajo AWS Organizations. Esto garantiza que ningún equipo pueda crear buckets fuera del namespace protegido.
Audita tus buckets existentes: identifica cuáles usan nombres predecibles y evalúa si vale la pena migrarlos al nuevo namespace según el nivel de criticidad de los datos.
Revisa tus templates y pipelines: cualquier script que genere nombres de bucket con patrones como app-us-east-1 debe actualizarse para usar el nuevo formato.
Habilita AWS Config o GuardDuty para detectar accesos inesperados a buckets mientras realizas la migración.

Conclusión

El bucketsquatting en AWS S3 fue durante una década un riesgo silencioso que afectó a startups, empresas y hasta a los propios servicios internos de Amazon. La introducción de los Account Regional Namespaces el pasado 12 de marzo de 2026 es la solución estructural que el ecosistema esperaba: un mecanismo simple, sin costo adicional y con soporte nativo en todas las herramientas de AWS.

No protege el pasado, pero cierra la puerta de forma definitiva para todo lo que construyas de aquí en adelante. Para cualquier founder o CTO que valore la seguridad de su infraestructura cloud, adoptar este patrón no es opcional: es la nueva línea base.

Descubre cómo otros founders implementan estas soluciones de seguridad cloud y comparte tus propias experiencias con AWS en nuestra comunidad gratuita de Ecosistema Startup.

Unirme a la comunidad