En este post dejaré algunas notas que tomé para poder estudiar para el AWS SASS. Utilizo Evernote para guardar notas pero con el paso del tiempo he decidido retomar el blog ya que es una mejor manera de tener mis notas actualizadas. Actualizaré el post poco a poco. Así pues vamos a ver en este post el tema de S3 en AWS que te ayudará con la SAA, la certificación de Solutions Architect Associate!

Las definiciones de los diferentes servicios las tomo de o bien la documentación de AWS o bien de los comentarios del instructor del curso que hice.

Temas cubiertos:    

• S3

Amazon S3: apuntes y conceptos actualizados a 2026

⚠️ Nota de actualización — octubre de 2026

Este artículo nació a partir de mis apuntes de un curso de AWS. Con el paso de los años, Amazon S3 ha cambiado bastante.

Para conservar el contexto histórico, no he eliminado la información antigua. Cuando un dato ya no es válido, aparece marcado como OBSOLETO, seguido de una explicación de cómo funciona actualmente.

Las definiciones proceden principalmente de la documentación de AWS y de los comentarios del instructor del curso original.

Amazon S3

Amazon Simple Storage Service (Amazon S3) es el servicio de almacenamiento de objetos de AWS.

Conceptos básicos

Número de buckets

⚠️ OBSOLETO — información original:
Una cuenta nueva puede crear por defecto hasta 100 buckets.

Actualización 2026

Actualmente, una cuenta de AWS puede crear por defecto hasta 10.000 buckets de uso general, y esta cuota puede solicitarse que sea ampliada mediante Service Quotas.

Tamaño de los objetos

⚠️ OBSOLETO — información original:
Los archivos pueden tener un tamaño entre 0 bytes y 5 TB.

Actualización 2026

Este límite cambió de forma importante el 2 de diciembre de 2025. Amazon S3 aumentó el tamaño máximo de un objeto de 5 TB a 50 TB. AWS documenta un límite técnico de aproximadamente 48,8 TiB.

Hay que distinguir además el método de subida:

• Una única operación PUT: hasta 5 GB.
• Consola de S3: hasta 160 GB.
• Multipart Upload: hasta 50 TB.

Para objetos grandes se debe utilizar Multipart Upload.

Capacidad

S3 permite almacenar una cantidad prácticamente ilimitada de objetos. Un bucket puede contener cualquier número de objetos.

Buckets, objetos y carpetas

Los objetos se almacenan dentro de buckets.

Aunque la consola representa determinadas claves como si fueran carpetas, S3 es un almacenamiento de objetos y no utiliza un sistema de directorios tradicional. Lo que visualmente parecen carpetas son normalmente prefijos en las claves de los objetos.

Nombres de los buckets

Los nombres de los buckets deben ser únicos.

Actualización 2026

En el espacio de nombres global tradicional de los buckets de uso general, el nombre debe ser único entre las cuentas y regiones pertenecientes a una misma partición de AWS.

AWS documenta actualmente las particiones aws, aws-cn, aws-us-gov y aws-eusc. También existe ahora la posibilidad de utilizar un espacio de nombres regional asociado a la propia cuenta para determinados buckets de uso general.

Respuesta al subir un objeto

⚠️ IMPRECISO — información original:
Cuando subes un archivo a S3 recibes un código HTTP 200.

Una operación PutObject correcta devuelve efectivamente HTTP 200 OK, pero no todas las formas posibles de cargar datos en S3 deben generalizarse como una única operación de subida.

Amazon S3 soporta, entre otras características:

• Versionado.
• Cifrado.
• Gestión del ciclo de vida.
• Replicación.
• Object Lock.
• Notificaciones de eventos.

Seguridad y ACL

⚠️ OBSOLETO COMO RECOMENDACIÓN:
Proteger los datos mediante ACL.

Las ACL siguen existiendo, pero ya no son el mecanismo recomendado para la mayoría de casos.

En los buckets nuevos, S3 utiliza por defecto Bucket owner enforced, lo que deshabilita las ACL. AWS recomienda mantenerlas desactivadas y controlar el acceso mediante políticas IAM, bucket policies, políticas de endpoints y otros mecanismos basados en políticas.

Además, los cuatro ajustes de S3 Block Public Access están habilitados por defecto en buckets nuevos.

Consistencia de datos de Amazon S3

⚠️ OBSOLETO — comportamiento anterior a diciembre de 2020:

• Read-after-write consistency para objetos nuevos.
• Consistencia eventual para sobrescrituras mediante PUT.
• Consistencia eventual para DELETE.
• Los cambios podían tardar cierto tiempo en propagarse.

Actualización 2026

Desde el 1 de diciembre de 2020, Amazon S3 proporciona consistencia fuerte de lectura después de escritura.

Esto se aplica a:

• creación de objetos;
• sobrescritura de objetos;
• borrados;
• operaciones GET;
• operaciones LIST;
• etiquetas;
• ACL;
• metadatos.

Después de que una escritura se complete correctamente, una lectura posterior devuelve inmediatamente el estado más reciente.

Nomenclatura y endpoints

El formato recomendado para acceder a un bucket mediante virtual-hosted style es:

bucket-name.s3.region.amazonaws.com

Por ejemplo:

ruben.s3.eu-west-1.amazonaws.com

Path-style

El formato antiguo es:

s3.eu-west-1.amazonaws.com/ruben/key

⚠️ OBSOLETO — información original:
El formato path-style está deprecado y dejaría de funcionar en septiembre de 2020.

Actualización 2026

AWS anunció inicialmente su retirada, pero el 23 de septiembre de 2020 decidió retrasar la deprecación.

A día de hoy, AWS sigue soportando tanto virtual-hosted style como path-style, aunque indica que este último será eliminado en el futuro. Para nuevos desarrollos debe utilizarse virtual-hosted style.

Regiones

Los buckets se crean en una Región de AWS concreta.

La región afecta a factores como:

• latencia;
• residencia de datos;
• costes;
• cumplimiento normativo.

Una vez creado un bucket, su región no puede cambiarse.

Anatomía de un objeto de S3

S3 es un almacenamiento basado en objetos.

Un objeto puede incluir:

• Key: nombre o identificador del objeto.
• Value: datos almacenados.
• Version ID: identificador utilizado cuando el versionado está activado.
• Metadata: metadatos del objeto.
• Subresources: información adicional asociada al recurso.

En el entorno de S3 también encontraremos mecanismos como:

• bucket policies;
• ACL;
• CORS;
• tags;
• Object Lock;
• Lifecycle.

Replicación de S3

Para utilizar S3 Replication, el versionado debe estar habilitado tanto en el bucket de origen como en los buckets de destino.

⚠️ OBSOLETO — información original:
Las regiones del bucket de origen y destino deben ser diferentes.

Actualización 2026

Ya no es cierto.

S3 admite:

• Cross-Region Replication (CRR): entre regiones diferentes.
• Same-Region Replication (SRR): dentro de la misma región.

⚠️ OBSOLETO — información original:
No se puede replicar a múltiples buckets.

Actualización 2026

Una configuración de replicación puede enviar objetos a uno o varios buckets de destino, incluso combinando diferentes cuentas o regiones.

⚠️ INCOMPLETO — información original:
Los archivos que ya existían en el bucket no se replican automáticamente.

Esto sigue siendo cierto para la replicación en directo.

Sin embargo, actualmente existe S3 Batch Replication, que permite replicar objetos existentes bajo demanda, incluidos objetos creados antes de configurar la replicación y objetos cuya replicación falló anteriormente.

Eliminación y replicación

⚠️ INFORMACIÓN ANTIGUA:
Los delete markers se replican.

Actualmente depende de la configuración.

Por defecto, un delete marker creado en el origen no se replica con las configuraciones modernas. Se puede activar explícitamente Delete Marker Replication.

La eliminación permanente de una versión concreta mediante su versionId no se replica como una eliminación equivalente en el destino.

Replication Time Control

Es posible combinar la replicación de delete markers con determinadas configuraciones modernas de replicación, pero AWS indica actualmente que la replicación de delete markers no está cubierta por el SLA de 15 minutos de S3 Replication Time Control.

Clases de almacenamiento de S3

Nota sobre los precios

⚠️ OBSOLETO COMO REFERENCIA ACTUAL — precios originales del artículo:

• S3 Standard: 0,023 USD.
• S3 Standard-IA: 0,125 USD.
• S3 One Zone-IA: 0,01 USD.
• Glacier: 0,01 USD por GB.

Estos precios se conservan como referencia histórica, pero no deben utilizarse para calcular costes actuales.

Además, el antiguo valor 0,125 para Standard-IA parece contener un error decimal: históricamente esta clase arrancaba en torno a 0,0125 USD/GB-mes en determinadas regiones.

Los precios de S3 dependen de:

• región;
• clase de almacenamiento;
• volumen;
• solicitudes;
• recuperación;
• transferencia;
• replicación;
• otras características utilizadas.

AWS recomienda consultar siempre los precios actuales o utilizar AWS Pricing Calculator.

S3 Standard

S3 Standard está diseñado para datos a los que se accede frecuentemente.

Actualmente está diseñado para:

• 99,999999999 % de durabilidad — once nueves.
• 99,99 % de disponibilidad.
• almacenamiento redundante en al menos tres zonas de disponibilidad.

⚠️ IMPRECISO — información original:
“AWS S3 fue construido para ofrecer 99,99 % de disponibilidad y garantiza 99,9 %”.

Aquí se estaban mezclando dos conceptos.

El 99,99 % corresponde al diseño de disponibilidad de S3 Standard. El SLA contractual de S3 funciona mediante porcentajes mensuales de disponibilidad y créditos de servicio; para S3 Standard, el primer umbral de crédito se aplica cuando la disponibilidad mensual cae por debajo del 99,9 %.

S3 Intelligent-Tiering

S3 Intelligent-Tiering está diseñado para objetos cuyo patrón de acceso es desconocido o cambia con el tiempo.

⚠️ IMPRECISO — información original:
S3 guarda el mismo objeto en diferentes clases, una de acceso frecuente y otra de acceso infrecuente.

No se crean copias del objeto en diferentes clases. El objeto continúa perteneciendo a S3 Intelligent-Tiering y AWS lo mueve entre diferentes niveles de acceso.

Actualmente existen tres niveles automáticos:

• Frequent Access.
• Infrequent Access: después de 30 días consecutivos sin acceso.
• Archive Instant Access: después de 90 días sin acceso.

Además existen dos niveles de archivo opcionales:

• Archive Access: a partir de 90 días sin acceso.
• Deep Archive Access: a partir de 180 días sin acceso.

Los objetos menores de 128 KB no son monitorizados para el tiering automático y permanecen en Frequent Access.

Existe un pequeño coste de monitorización y automatización por objeto elegible, pero no se cobran tarifas de recuperación al mover datos entre los niveles automáticos de Intelligent-Tiering.

S3 Standard-IA

S3 Standard-Infrequent Access está diseñado para información:

• de larga duración;
• a la que se accede poco;
• que necesita acceso con latencia de milisegundos.

Está diseñado para:

• 99,999999999 % de durabilidad;
• 99,9 % de disponibilidad;
• almacenamiento en al menos tres zonas de disponibilidad.

Tiene cargos de recuperación y un tamaño mínimo facturable de 128 KB. La duración mínima facturable continúa siendo de 30 días.

S3 One Zone-IA

S3 One Zone-IA mantiene los datos en una única zona de disponibilidad.

Está pensado para datos que puedan recrearse si se pierde esa zona.

Está diseñado para:

• 99,999999999 % de durabilidad;
• 99,5 % de disponibilidad;
• acceso con latencia de milisegundos.

Reduced Redundancy Storage — RRS

⚠️ CLASE LEGACY / NO RECOMENDADA

La información original indicaba:

• 99,99 % de durabilidad.
• 99,99 % de disponibilidad.
• Uso para datos que pueden recrearse.
• AWS comenzaba a recomendar no utilizar esta clase.

La conclusión sigue siendo válida: AWS recomienda no utilizar RRS.

Curiosamente, la clase sigue apareciendo en la documentación y las API, pero AWS indica expresamente que S3 Standard es actualmente más rentable.

S3 Glacier

⚠️ NOMENCLATURA ANTIGUA:
“S3 Archive Glacier”.

Actualmente las clases principales de archivo son:

• S3 Glacier Instant Retrieval.
• S3 Glacier Flexible Retrieval.
• S3 Glacier Deep Archive.

S3 Glacier Instant Retrieval

Es una opción que no aparecía en los apuntes originales.

Está pensada para datos de archivo a los que se accede ocasionalmente pero que requieren recuperación en milisegundos.

Tiene una duración mínima de almacenamiento de 90 días.

S3 Glacier Flexible Retrieval

Es el equivalente moderno a lo que históricamente se llamaba S3 Glacier.

Los niveles de recuperación siguen siendo:

Expedited

Normalmente entre 1 y 5 minutos.

La capacidad puede depender de la demanda; puede adquirirse capacidad aprovisionada para conseguir mayor predictibilidad.

Standard

Normalmente entre 3 y 5 horas.

Bulk

Normalmente entre 5 y 12 horas.

Actualmente las recuperaciones Bulk de Glacier Flexible Retrieval son gratuitas.

Tiene una duración mínima de almacenamiento de 90 días.

S3 Glacier Deep Archive

Está pensado para información que se conserva durante años y que se consulta menos de una vez al año.

Es actualmente una de las opciones de almacenamiento más económicas de AWS.

Está diseñado para una durabilidad del 99,999999999 %.

Opciones de recuperación:

• Standard: normalmente dentro de unas 12 horas.
• Bulk: normalmente dentro de 48 horas.

Tiene una duración mínima de almacenamiento de 180 días.

S3 Express One Zone

Esta clase no existía cuando se escribieron los apuntes originales.

S3 Express One Zone está diseñada para cargas extremadamente sensibles a la latencia y proporciona acceso consistente en milisegundos de un solo dígito.

Los datos se almacenan dentro de una sola zona de disponibilidad y se utiliza con buckets de directorio.

Costes de Amazon S3

Los principales conceptos que pueden generar costes son:

• almacenamiento por GB;
• solicitudes como GET, PUT o COPY;
• recuperación de datos;
• administración del almacenamiento;
• Inventory;
• Storage Lens;
• etiquetas;
• replicación;
• transferencia de datos;
• Transfer Acceleration;
• determinadas funcionalidades de consulta o transformación.

La transferencia de entrada desde Internet a S3 generalmente no tiene coste de transferencia.

Para tráfico dentro de AWS, las reglas dependen del origen, destino y región.

⚠️ DEMASIADO GENERAL — información original:
Transferir datos entre EC2 y S3, Glacier, DynamoDB, SES, SQS o SimpleDB dentro de la misma región no tiene ningún coste.

Actualización

En el caso de S3, la transferencia de datos dentro de la red de AWS y en la misma región puede no tener coste de transferencia, pero las solicitudes GET, PUT y posibles cargos de recuperación siguen aplicándose. No debe interpretarse como que toda la operación es gratuita.

Multipart Upload

Multipart Upload permite dividir un objeto en múltiples partes y cargarlas independientemente, incluso en paralelo.

Si una parte falla, únicamente es necesario retransmitir esa parte.

⚠️ OBSOLETO — información original:
El tamaño máximo del objeto es 5 TB.

Actualización 2026

Actualmente:

• tamaño máximo de objeto mediante multipart: aproximadamente 50 TB;
• máximo de partes: 10.000;
• tamaño de cada parte: de 5 MiB a 5 GiB;
• la última parte puede ser menor de 5 MiB.

AWS sigue recomendando considerar Multipart Upload a partir de aproximadamente 100 MB.

Cifrado en Amazon S3

El cifrado del lado del servidor protege los datos en reposo.

Cambio fundamental desde 2023

⚠️ OBSOLETO — información original:
Para asegurarse de que todos los objetos están cifrados se debe utilizar una bucket policy que rechace cargas que no indiquen x-amz-server-side-encryption.

Actualización

Desde el 5 de enero de 2023, Amazon S3 cifra automáticamente todos los objetos nuevos mediante SSE-S3 si no se especifica otra configuración.

Este cifrado no puede desactivarse.

Por tanto, una bucket policy ya no es necesaria simplemente para conseguir un nivel básico de cifrado.

Sí puede seguir utilizándose una policy cuando se quiere obligar a utilizar SSE-KMS, una clave KMS concreta u otros requisitos específicos.

SSE-S3

AWS administra las claves.

S3 utiliza AES-256 y el cifrado SSE-S3 no tiene coste adicional.

SSE-KMS

Utiliza AWS Key Management Service.

Permite mayor control sobre:

• políticas de acceso;
• permisos;
• rotación;
• auditoría del uso de las claves.

⚠️ TERMINOLOGÍA ANTIGUA:
La documentación antigua hablaba de “Customer Master Keys” o CMK.

Actualmente AWS utiliza el término KMS key y, cuando corresponde, customer managed key.

DSSE-KMS

Otra opción moderna es Dual-layer Server-Side Encryption with AWS KMS keys (DSSE-KMS), que aplica dos capas independientes de cifrado del lado del servidor.

SSE-C

En SSE-C el cliente proporciona la clave de cifrado a S3 con cada operación necesaria.

Entre los encabezados utilizados se encuentran:

x-amz-server-side-encryption-customer-algorithm

x-amz-server-side-encryption-customer-key

x-amz-server-side-encryption-customer-key-MD5

Versionado de Amazon S3

S3 Versioning permite mantener diferentes versiones de un objeto.

Al eliminar normalmente un objeto de un bucket versionado, S3 crea un delete marker como versión actual, mientras mantiene las versiones anteriores.

El versionado:

• ayuda a recuperar sobrescrituras o eliminaciones accidentales;
• se integra con Lifecycle;
• puede combinarse con MFA Delete;
• una vez activado no puede volver al estado completamente deshabilitado: puede suspenderse.

⚠️ IMPRECISO — información original:
Solo el propietario de un bucket puede eliminar permanentemente una versión.

Actualización

Una versión puede ser eliminada permanentemente por el propietario del bucket o por una identidad IAM que disponga de los permisos correspondientes.

MFA Delete

MFA Delete añade protección adicional para:

• eliminar permanentemente versiones;
• cambiar el estado del versionado.

Cuando MFA Delete está habilitado, AWS establece restricciones especiales y actualmente solo el usuario root puede efectuar determinadas operaciones permanentes, utilizando MFA.

Replicación y versionado

Ambos buckets deben tener versionado.

La replicación puede ser:

• entre regiones;
• dentro de la misma región;
• entre cuentas;
• hacia varios destinos.

Los objetos antiguos no entran automáticamente en la replicación en directo, pero pueden copiarse mediante S3 Batch Replication.

S3 Lifecycle

Lifecycle permite automatizar:

• transiciones entre clases de almacenamiento;
• expiración de objetos;
• eliminación de versiones antiguas;
• limpieza de delete markers;
• limpieza de cargas multipart incompletas.

Con buckets versionados

Cuando expira la versión actual de un objeto versionado, normalmente S3 crea un delete marker y la antigua versión actual pasa a ser una versión no actual.

Para eliminar definitivamente versiones anteriores pueden configurarse reglas de expiración de versiones no actuales.

Cambio importante en 2026

⚠️ OBSOLETO — información original:
Se debe esperar 30 días antes de pasar un objeto de Standard a Standard-IA y después otros 30 días para moverlo a Glacier.

Desde julio de 2026, AWS permite configurar una transición a S3 Standard-IA o S3 One Zone-IA desde el día 0.

Sin embargo, esto no elimina necesariamente los periodos mínimos de facturación.

Standard-IA y One Zone-IA siguen teniendo un mínimo facturable de 30 días; Glacier Flexible Retrieval e Instant Retrieval, 90 días; y Deep Archive, 180 días.

Objetos pequeños y Lifecycle

Otro cambio importante se produjo en septiembre de 2024.

De forma predeterminada, las nuevas configuraciones de Lifecycle ya no realizan transiciones de objetos menores de 128 KB a otras clases de almacenamiento.

Las configuraciones anteriores a septiembre de 2024 pueden conservar el comportamiento antiguo hasta ser modificadas.

S3 Object Lock

S3 Object Lock permite almacenar objetos utilizando un modelo WORM — Write Once, Read Many.

Puede impedir que una versión de un objeto sea modificada o eliminada durante un periodo determinado o indefinidamente.

Object Lock necesita versionado.

Governance Mode

Los usuarios no pueden sobrescribir ni eliminar las versiones protegidas salvo que dispongan de permisos especiales para omitir la retención.

Compliance Mode

Una versión protegida no puede ser sobrescrita ni eliminada mientras dure la retención, incluso por el usuario root.

Periodo de retención

Protege una versión durante un periodo determinado.

S3 almacena la fecha de expiración de la retención en los metadatos de la versión.

Legal Hold

Un Legal Hold protege una versión de objeto sin establecer una fecha concreta de expiración.

Continúa activo hasta que se elimina explícitamente.

El permiso correspondiente es:

s3:PutObjectLegalHold

⚠️ CORRECCIÓN: en los apuntes originales aparecía s3:PutObjectLegalhold.

Actualización

Object Lock puede habilitarse actualmente tanto al crear un bucket como en determinados buckets existentes.

Una vez habilitado Object Lock en el bucket, no puede volver a deshabilitarse.

Glacier Vault Lock

Glacier Vault Lock permite aplicar controles de cumplimiento mediante políticas de bloqueo de un vault de Amazon S3 Glacier.

Una vez finalizado el proceso de bloqueo, la política adquiere un carácter inmutable.

Este concepto continúa vigente.

Hosting de sitios web en S3

S3 puede utilizarse para alojar contenido web estático.

⚠️ INCOMPLETO COMO ARQUITECTURA MODERNA — información original:
El bucket debe llamarse exactamente igual que el dominio o subdominio y Route 53 debe apuntar directamente al website endpoint.

Esto sigue siendo cierto para el patrón clásico en el que Route 53 apunta directamente a un endpoint de sitio web de S3.

Sin embargo, no es la arquitectura que recomendaría actualmente para un sitio público moderno.

Actualización 2026

Los S3 Website Endpoints solo soportan HTTP, no HTTPS.

AWS recomienda utilizar CloudFront cuando se necesita HTTPS y, especialmente, si se quiere mantener Block Public Access habilitado.

Con CloudFront puede utilizarse un bucket privado junto con Origin Access Control (OAC).

Por tanto, para nuevas arquitecturas:

Usuario → HTTPS → CloudFront → OAC → bucket S3 privado

es normalmente preferible a:

Usuario → bucket S3 público configurado como website

Requester Pays

Requester Pays continúa existiendo.

Cuando se habilita:

• el propietario paga el almacenamiento;
• el solicitante paga determinadas solicitudes y la transferencia de descarga.

El solicitante debe aceptar el cargo explícitamente, normalmente mediante x-amz-request-payer.

Una diferencia importante es que Requester Pays no permite acceso anónimo.

Eventos de S3

S3 permite generar eventos cuando se producen acciones en un bucket.

Los apuntes originales enumeraban:

• Amazon SNS.
• Amazon SQS.
• AWS Lambda.

Estos destinos continúan siendo válidos.

Actualización

Actualmente también puede utilizarse Amazon EventBridge.

Los eventos de S3 se entregan con semántica al menos una vez, por lo que una aplicación que los consuma debe estar preparada para gestionar posibles duplicados.

Rendimiento de Amazon S3

Guía antigua

⚠️ OBSOLETO — comportamiento anterior a 2018:

Cuando se superaban aproximadamente 100 solicitudes PUT/DELETE/LIST o 300 GET por segundo podía ser necesario modificar la estructura de las claves.

Se recomendaba evitar nombres de objetos secuenciales y añadir aleatoriedad al principio de las keys para evitar que muchos objetos terminaran en la misma partición.

Esta recomendación quedó obsoleta después de las mejoras de rendimiento de S3 introducidas en 2018.

Rendimiento actual

Amazon S3 escala automáticamente a tasas de solicitudes altas.

AWS documenta al menos:

• 3.500 PUT/COPY/POST/DELETE por segundo y prefijo.
• 5.500 GET/HEAD por segundo y prefijo.

No existe un límite práctico de número de prefijos y es posible paralelizar operaciones entre ellos.

Por ejemplo, diez prefijos utilizados en paralelo podrían escalar teóricamente a unas 55.000 operaciones GET/HEAD por segundo.

Ya no es necesario añadir caracteres aleatorios al comienzo de las claves para conseguir un buen reparto de rendimiento.

CloudFront continúa siendo una excelente opción cuando el objetivo es distribuir contenido a usuarios finales y aprovechar caché y puntos de presencia.

S3 Select y Glacier Select

⚠️ OBSOLETO PARA CLIENTES NUEVOS

S3 Select permite consultar una parte del contenido de un objeto utilizando expresiones SQL, evitando recuperar el objeto completo.

Glacier Select ofrecía un concepto similar para información archivada.

Actualización

Desde el 25 de julio de 2024, Amazon S3 Select y Amazon S3 Glacier Select dejaron de estar disponibles para nuevos clientes.

Los clientes que ya los utilizaban pueden continuar haciéndolo, pero AWS no planea introducir nuevas funcionalidades en estos servicios.

Server Access Logging

Server Access Logging permite registrar las solicitudes realizadas contra un bucket.

⚠️ OBSOLETO PARCIALMENTE — información original:
No hay coste por habilitarlo, pero se cobra almacenamiento y las solicitudes realizadas para entregar los logs.

Actualización 2026

Para entrega directa de Server Access Logs a otro bucket S3:

• habilitar el logging no tiene coste adicional;
• la entrega de los logs no tiene coste;
• se paga el almacenamiento de esos logs;
• pueden existir costes al acceder posteriormente a ellos.

Además, actualmente S3 permite entregar Server Access Logs no solo a otro bucket S3, sino también a Amazon CloudWatch Logs, que proporciona JSON estructurado, consultas, agregación entre cuentas y otras capacidades.

AWS también recomienda valorar CloudTrail para auditar acciones a nivel de bucket y objeto.

Actualizaciones históricas del artículo

2018 — Path-style

⚠️ INFORMACIÓN HISTÓRICA

AWS anunció la retirada del direccionamiento path-style y la transición hacia virtual-hosted style.

La fecha prevista inicialmente para 2020 fue posteriormente aplazada.

En 2026 path-style continúa funcionando, aunque AWS sigue indicando que será retirado en el futuro.

2018 — Rendimiento

AWS eliminó la antigua necesidad de aleatorizar los prefijos para obtener rendimiento.

Los límites de referencia actuales son al menos 3.500 escrituras y 5.500 lecturas por segundo por prefijo, no por bucket completo.

2019 — Same-Region Replication

La llegada de Same-Region Replication (SRR) permitió replicar de forma asíncrona entre buckets de la misma región.

Esta funcionalidad continúa plenamente vigente y convive con Cross-Region Replication.

2020 — Strong Consistency

Desde diciembre de 2020 S3 proporciona consistencia fuerte de lectura después de escritura.

2023 — Cifrado por defecto

Desde enero de 2023 todos los objetos nuevos se cifran automáticamente como mínimo mediante SSE-S3.

2023 — ACL deshabilitadas por defecto

Los buckets nuevos utilizan normalmente Bucket owner enforced, por lo que las ACL están deshabilitadas y AWS recomienda utilizar políticas.

2024 — Lifecycle y objetos pequeños

Desde septiembre de 2024, nuevas configuraciones Lifecycle no realizan por defecto transiciones de objetos menores de 128 KB.

2024 — S3 Select

Desde julio de 2024 S3 Select y Glacier Select ya no aceptan nuevos clientes.

2025 — Objetos de 50 TB

El 2 de diciembre de 2025 el tamaño máximo de los objetos de S3 aumentó de 5 TB a 50 TB.

2026 — Lifecycle hacia Standard-IA

Desde julio de 2026 es posible pasar objetos mediante Lifecycle a Standard-IA y One Zone-IA desde el mismo día de su creación.

Ejemplo de IAM Policy

El artículo original terminaba con una política titulada:

“IAM Policy para listar y leer un bucket”

Sin embargo, la política original era:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::test"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::test/*"]
    }
  ]
}

⚠️ CORRECCIÓN — no es una política únicamente de lectura.

La política permite:

• listar el bucket;
• leer objetos;
• subir objetos;
• eliminar objetos.

Si realmente queremos una política únicamente para listar y leer, debería ser:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::test"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::test/*"
    }
  ]
}

Esta diferencia es especialmente importante si queremos aplicar el principio de mínimo privilegio.

Conclusión

Amazon S3 mantiene muchos de los conceptos fundamentales que tenía cuando escribí originalmente estos apuntes: buckets, objetos, versionado, Lifecycle, cifrado, replicación y distintas clases de almacenamiento.

Sin embargo, algunos comportamientos importantes han cambiado considerablemente:

• S3 ya utiliza consistencia fuerte.
• El cifrado está habilitado por defecto.
• Las ACL están deshabilitadas por defecto en nuevos buckets.
• La replicación puede hacerse dentro de una misma región y hacia múltiples destinos.
• Los objetos existentes pueden replicarse mediante Batch Replication.
• El tamaño máximo de objeto ha pasado de 5 TB a 50 TB.
• Lifecycle ha eliminado antiguas restricciones de transición.
• S3 Select ya no está disponible para nuevos clientes.
• La arquitectura recomendada para webs estáticas es normalmente CloudFront con un bucket privado, en lugar de exponer directamente un S3 Website Endpoint.

Por eso merece la pena conservar los apuntes originales como referencia histórica, pero señalando claramente qué partes describen un Amazon S3 que ya no funciona de la misma manera.