Introducción
Si tu organización opera más de 1.000 buckets S3 por cuenta — algo cada vez más común en arquitecturas multi-tenant, landing zones de AWS Organizations o plataformas de datos con un bucket por dataset — probablemente ya enfrentaste el problema silencioso de AWS Backup: los buckets que superaban el tope simplemente quedaban fuera del plan de protección, sin error visible, sin alerta en CloudWatch. La cuota se manifestaba como un gap de cobertura que solo se detectaba en el peor momento: durante una prueba de restauración o un incidente real.
AWS eliminó ese tope en septiembre de 2026. AWS Backup for Amazon S3 ahora soporta el respaldo y la restauración de todos los general purpose buckets de una cuenta, sin importar cuántos existan, siempre que respeten la cuota de buckets configurada para esa cuenta en Amazon S3. No es un parche cosmético: es un cambio en la arquitectura interna del servicio que impacta directamente en cómo los equipos de infraestructura diseñan políticas de backup a escala.
Qué ocurrió
Hasta esta actualización, AWS Backup para S3 imponía un límite duro de 1.000 buckets por cuenta por región. Ese número coincidía con la cuota predeterminada de S3, pero en la práctica generaba un problema operativo concreto: si un equipo de plataforma solicitaba y obtenía un incremento de cuota de buckets (por ejemplo, subiendo de 1.000 a 5.000 mediante un service quota request en el Service Quotas console), AWS Backup no escalaría con esa cuota. Los buckets adicionales quedaban sin protección, y la única forma de cubrirlos era crear cuentas secundarias dedicadas al backup o implementar scripts ad-hoc con aws s3api y aws backup combinados, lo cual rompía la consistencia de los planes de backup centralizados.
Con el lanzamiento de septiembre 2026, AWS alineó el límite de AWS Backup for S3 con la cuota dinámica de S3 de la cuenta. Si tu cuenta tiene una cuota de 5.000 buckets por región, AWS Backup puede proteger los 5.000. Si la cuota es 10.000, cubre los 10.000. El servicio deja de tener un techo propio y pasa a respetar el techo que el propio S3 impone a la cuenta. La disponibilidad abarca todas las regiones comerciales de AWS y las regiones GovCloud (US).
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos que administran landing zones con AWS Organizations, el impacto inmediato es la simplificación de la gobernanza. Antes, una cuenta de datos con 3.000 buckets (uno por cliente, por ejemplo) requería dividir la estrategia: los primeros 1.000 en un backup plan nativo de AWS Backup, los restantes en una cuenta espejo o en un pipeline custom con aws s3 sync hacia una cuenta de archive. Eso multiplicaba la complejidad de auditoría, los costos de almacenamiento intermedio y, sobre todo, los tiempos de recuperación (RTO) porque la restauración cruzaba cuentas.
Desde la perspectiva de seguridad, este cambio elimina un vector de riesgo operativo: la falsa sensación de cobertura. Un equipo que configuraba un backup plan con S3:ListAllMyBuckets y esperaba que el servicio protegiera todo, sin saber que los buckets 1.001 en adelante quedaban descubiertos, ahora tiene garantía de cobertura total. Esto es relevante para marcos de cumplimiento como SOC 2, ISO 27001 o la norma NIS2, donde la evidencia de backup de todos los activos de datos es un control obligatorio.
En entornos de multi-región, la eliminación del tope también reduce la necesidad de particionar cuentas por volumen de buckets. Organizaciones que antes creaban cuentas AWS secundarias exclusivamente para distribuir buckets y así «caben» dentro del límite de 1.000 de AWS Backup, ahora pueden consolidar la arquitectura en menos cuentas, reduciendo la superficie de gestión de IAM, CloudTrail y SCPs.
Detalles técnicos
El cambio afecta específicamente a AWS Backup for Amazon S3, que opera a través de backup vaults y backup plans. El componente interno que imponía el tope era el scheduler de backup jobs: al enumerar buckets elegibles para un backup rule, el servicio cortaba la lista en 1.000 entradas. El nuevo comportamiento delega la enumeración a la cuota de S3 de la cuenta (s3-buckets-per-region en Service Quotas).
Para cuentas que usan las managed policies de AWS Backup (AWSBackupServiceRolePolicyForBackup, AWSBackupServiceRolePolicyForS3Backup), no se requiere ninguna acción. Las políticas ya incluyen permisos de s3:ListBucket, s3:GetObjectVersion y s3:PutObject que escalan con el número de buckets.
Para cuentas con custom IAM policies, el punto crítico está en los recursos listados. Una política que restringía s3:ListBucket a un ARN pattern como arn:aws:s3:::bucket-prefix-* puede necesitar expansión si la nomenclatura de buckets no sigue un patrón uniforme. El siguiente snippet muestra cómo validar que tu custom policy no limita implícitamente la cobertura:
# Verificar la cuota actual de buckets S3 por región
aws service-quotas get-service-quota \
–service-code s3 \
–quota-code L-8F05D82E \
–region us-east-1 \
–query «Quota.Value» \
–output text
# Listar buckets actuales y contar
aws s3api list-buckets –query ‘Buckets[?starts_with(Name, `prod-`)].Name’ | jq ‘length’
# Verificar que el backup plan cubre la cantidad esperada
aws backup list-backup-jobs \
–by-resource-type S3 \
–by-state COMPLETED \
–query ‘length(@)’
Los backup jobs para S3 siguen usando la arquitectura de snapshot-based backup del vault. La restauración (aws backup start-restore-job –recovery-point-arn … –resource-type S3) no cambia su comportamiento: la diferencia está en la fase de enumeración y scheduling, no en el mecanismo de copia de objetos.
Qué deberían hacer los administradores y equipos técnicos
Primero, auditá la cuota real de buckets por región en cada cuenta de tu organización. Si alguna cuenta opera cerca o por encima de 1.000 buckets, verificá que AWS Backup efectivamente cubra la totalidad. Podés cruzar la lista de buckets con los recovery points existentes:
# Contar buckets en la cuenta actual
TOTAL=$(aws s3api list-buckets –query ‘length(Buckets)’ –output text)
# Contar recovery points de S3 en el vault principal
COVERED=$(aws backup list-recovery-points-by-resource-type \
–resource-type S3 \
–max-results 1000 \
–query ‘length(NextToken)’ –output text 2>/dev/null || echo «0»)
echo «Buckets: $TOTAL | Recovery points registrados: $COVERED»
Segundo, si usás custom IAM policies para el rol de servicio de AWS Backup, revisá que no haya restricciones por nombre de bucket o prefijo que excluyan buckets nuevos. Las managed policies de AWS (AWSBackupServiceRolePolicyForBackup) no tienen este problema; las custom policies sí pueden tenerlo si fueron escritas en 2022-2023 para un entorno de menos de 1.000 buckets.
Tercero, actualizá tus runbooks de DR. Si algún procedimiento de recuperación asumía que los buckets «número 1.001+» se restauraban desde una cuenta espejo o un pipeline alternativo, eliminá esa dependencia. El RTO de restauración ahora es uniforme para todos los buckets de la cuenta.
Cuarto, si gestionás SCPs (Service Control Policies) en una Organization, confirmá que no exista una restricción de backup:StartBackupJob o s3:ListBucket que, combinada con la eliminación del tope, ahora permita a una cuenta de workload crear backup jobs sobre miles de buckets sin supervisión. Considerá agregar una SCP que limite la frecuencia o el volumen de backup jobs si tu modelo de costos lo requiere.
Conclusión
La eliminación del tope de 1.000 buckets en AWS Backup for S3 no es un feature menor. Para organizaciones con arquitecturas de datos a escala — plataformas de ML con un bucket por modelo, SaaS multi-tenant, data lakes con miles de datasets — este cambio elimina una workaround permanente que vivía en runbooks internos y scripts de cron. La cobertura ahora es proporcional a la cuota de S3, lo cual es lo que cualquier administrador esperaría desde el día uno. El trabajo pendiente es de auditoría: verificar que las políticas IAM, los SCPs y los runbooks de DR reflejen la nueva realidad de cobertura total, y no sigan operando con supuestos del tope anterior.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/09/aws-backup-more-than-1000-s3-buckets/