Amazon S3: clases de almacenamiento, cifrado, lifecycle y recuperación

1. S3 no es simplemente “un bucket”

Amazon S3, o Simple Storage Service, es uno de los servicios más usados de AWS. Sirve para almacenar objetos: documentos, imágenes, vídeos, logs, backups, ficheros estáticos, datasets, exportaciones, informes y muchísimas cosas más.

Cuando empiezas, lo ves como algo sencillo: creo un bucket, subo un archivo y lo descargo cuando quiera. Y sí, esa es la base. Pero diseñar bien S3 implica tomar decisiones importantes sobre seguridad, coste, acceso, retención y recuperación.

S3 se usa mucho para:

• Contenido estático de webs.
• Backups y copias de seguridad.
• Data lakes.
• Logs de aplicaciones y servicios.
• Documentos de usuarios.
• Imágenes y vídeos.
• Archivos de analítica.
• Intercambio de ficheros entre sistemas.
• Almacenamiento de larga duración.

2. Bucket, objeto y key: los básicos que no hay que saltarse

En S3 hay tres conceptos básicos que debes tener claros: bucket, objeto y key.

Concepto	Qué significa	Ejemplo
Bucket	Contenedor donde guardas objetos	bornforcloud-contenidos
Objeto	Archivo guardado en S3 junto con sus metadatos	guia-clf-c02.pdf
Key	Nombre/ruta lógica del objeto dentro del bucket	cursos/aws/clf-c02/modulo1.pdf

Aunque en la consola parezca que hay carpetas, S3 realmente trabaja con claves de objetos. Una ruta como cursos/aws/imagen.png es la key del objeto. La consola lo muestra como carpetas para que sea más cómodo visualmente.

Esto es importante cuando diseñas nombres, prefijos, lifecycle, permisos o analítica de almacenamiento.

3. Durabilidad y disponibilidad no son lo mismo

S3 es famoso por su alta durabilidad. AWS suele destacar que S3 está diseñado para una durabilidad de 11 nueves. Pero cuidado: durabilidad y disponibilidad no son exactamente lo mismo.

Concepto	Qué significa	Ejemplo sencillo
Durabilidad	Probabilidad de no perder el objeto almacenado	Que el archivo no desaparezca ni se corrompa
Disponibilidad	Probabilidad de poder acceder al objeto cuando lo necesitas	Que puedas leerlo en ese momento

Para CLF-C02, quédate con la idea de que S3 está diseñado para almacenar objetos de forma muy durable y que replica datos internamente dentro de una región, salvo clases específicas como One Zone-IA, que tienen otro enfoque.

4. Clases de almacenamiento: no todos los datos se usan igual

No todos los archivos tienen el mismo uso. Algunos se consultan todos los días. Otros se guardan “por si acaso”. Otros son backups antiguos que casi nunca se recuperan.

Por eso S3 tiene distintas clases de almacenamiento. La idea es pagar de forma más ajustada según el patrón de acceso.

Clase	Cuándo usarla	Idea rápida	Error habitual
S3 Standard	Datos de acceso frecuente	Alta disponibilidad y baja latencia	Dejar datos fríos aquí durante años
S3 Standard-IA	Datos de acceso infrecuente pero recuperación rápida	Menos coste de almacenamiento, coste por recuperación	Usarlo para datos que se consultan mucho
S3 One Zone-IA	Datos infrecuentes y recreables	Almacenado en una sola AZ	Usarlo para datos críticos no recreables
S3 Glacier Instant Retrieval	Archivo con acceso inmediato	Datos archivados pero recuperables rápidamente	No revisar el patrón real de acceso
S3 Glacier Flexible Retrieval	Archivo con recuperación no inmediata	Bueno para archivo a menor coste	Elegirlo si necesitas acceso urgente
S3 Glacier Deep Archive	Archivo a muy largo plazo	Muy bajo coste para datos casi nunca consultados	Usarlo para datos que podrías necesitar pronto
S3 Intelligent-Tiering	Patrón de acceso variable o desconocido	Mueve datos entre niveles automáticamente	No entender cargos de monitorización

5. S3 Standard: la opción general para acceso frecuente

S3 Standard suele ser la clase por defecto para datos que se consultan con frecuencia o donde necesitas baja latencia.

Ejemplos:

• Imágenes usadas por una web.
• Ficheros descargados habitualmente por usuarios.
• Contenido estático activo.
• Datos de aplicaciones con acceso frecuente.
• Archivos que no sabes todavía si serán calientes o fríos.

El error típico es dejarlo todo en Standard para siempre. Funciona, sí, pero quizá estás pagando más de lo necesario si muchos objetos dejan de consultarse con el tiempo.

6. Standard-IA y One Zone-IA: acceso infrecuente

IA significa Infrequent Access. Son clases pensadas para datos que no se consultan a menudo, pero que cuando se necesitan deben recuperarse rápido.

S3 Standard-IA mantiene resiliencia multi-AZ y puede encajar para datos menos usados pero importantes.

S3 One Zone-IA almacena datos en una sola Availability Zone, por lo que puede ser más barato, pero tiene más riesgo si esa zona tiene un problema. Por eso se suele usar para datos recreables o no críticos.

Ejemplos donde podría encajar IA:

• Backups recientes que rara vez se restauran.
• Documentos antiguos pero todavía accesibles.
• Archivos de proyectos cerrados que podrían consultarse ocasionalmente.

La clave es no mirar solo el coste por GB. También debes mirar costes de acceso y recuperación.

7. Glacier: archivo y retención a largo plazo

Las clases Glacier están orientadas a archivado. Es decir, datos que quieres conservar, pero que no necesitas consultar habitualmente.

Ejemplos:

• Copias históricas.
• Registros por cumplimiento legal.
• Archivos financieros antiguos.
• Datos que deben guardarse muchos años.
• Backups de largo plazo.

Lo importante es entender que algunas clases Glacier no están pensadas para acceso inmediato. Pueden tener tiempos de recuperación más largos.

Por eso, si una aplicación necesita abrir el archivo al instante, no deberías elegir una clase fría solo porque es más barata por GB.

8. Intelligent-Tiering: cuando no sabes el patrón de acceso

S3 Intelligent-Tiering es útil cuando no tienes claro si los objetos se van a consultar mucho o poco.

Esta clase puede mover automáticamente objetos entre niveles según el patrón de acceso, ayudando a optimizar coste sin que tengas que crear reglas tan manuales.

Puede encajar bien cuando:

• No sabes si el contenido será consultado.
• El patrón de acceso cambia con el tiempo.
• Hay muchos objetos con comportamiento variable.
• No quieres gestionar transiciones manuales desde el primer día.

Eso sí, conviene entender que puede haber cargos de monitorización y automatización. Para objetos muy pequeños o patrones muy claros, quizá una regla lifecycle sencilla sea suficiente.

9. Lifecycle: automatizar la evolución del dato

Las reglas de lifecycle permiten automatizar qué ocurre con los objetos con el paso del tiempo.

Por ejemplo:

• Después de 30 días, mover logs a Standard-IA.
• Después de 90 días, mover backups a Glacier.
• Después de 365 días, eliminar versiones antiguas.
• Después de 7 años, expirar datos que ya no deben conservarse.

Esto es muy potente porque muchos datos pierden valor operativo con el tiempo.

Un log de ayer puede ser importante para investigar una incidencia. Un log de hace tres años quizá solo se conserva por cumplimiento o auditoría.

10. Versioning: recuperar versiones anteriores

S3 Versioning permite conservar varias versiones de un mismo objeto.

Si alguien sobrescribe un archivo por error, puedes recuperar una versión anterior. Si alguien borra un objeto, en muchos casos se crea un marcador de borrado y las versiones previas siguen existiendo.

Esto ayuda mucho frente a errores humanos, cambios accidentales o ciertas situaciones de recuperación.

Ejemplos:

• Un usuario sube una versión incorrecta de un documento.
• Una aplicación sobrescribe un fichero válido con uno corrupto.
• Alguien borra un objeto importante por error.

Pero ojo: versioning también puede aumentar el coste, porque las versiones antiguas ocupan almacenamiento. Por eso suele combinarse con reglas lifecycle para limpiar versiones no actuales después de cierto tiempo.

11. Object Lock: proteger frente a borrado o modificación

S3 Object Lock permite aplicar retención WORM: Write Once, Read Many. En español: escribir una vez, leer muchas.

Esto significa que un objeto puede quedar protegido frente a borrado o modificación durante un periodo definido.

Puede ser útil para:

• Cumplimiento normativo.
• Protección frente a borrado malicioso.
• Retención legal.
• Backups inmutables.
• Escenarios donde necesitas demostrar que los datos no han sido alterados.

Object Lock puede trabajar con modos de retención y legal holds. Para CLF-C02 no necesitas conocer todos los detalles, pero sí entender que sirve para proteger objetos frente a eliminación o modificación durante un tiempo.

12. Cifrado en S3: proteger datos en reposo

En S3 puedes cifrar datos en reposo. Es decir, proteger los objetos almacenados.

Hay varias opciones habituales:

Tipo de cifrado	Idea rápida	Cuándo puede encajar
SSE-S3	Cifrado gestionado por S3 con claves gestionadas por AWS	Opción sencilla para muchos casos
SSE-KMS	Cifrado usando AWS KMS	Cuando necesitas más control, auditoría o gestión de claves
SSE-C	El cliente proporciona las claves	Casos muy concretos con control externo de claves

Para nivel base, lo importante es entender que S3 puede cifrar objetos y que AWS KMS permite mayor control sobre claves, permisos y auditoría.

En muchos entornos reales, SSE-KMS se usa cuando hay requisitos de cumplimiento, separación de permisos o trazabilidad sobre uso de claves.

13. Seguridad y acceso público: cuidado con exponer buckets

Uno de los errores clásicos en S3 es dejar datos expuestos públicamente sin querer.

Por eso AWS ofrece S3 Block Public Access, que permite bloquear acceso público a nivel de cuenta o bucket.

Como regla general, un bucket no debería ser público salvo que tengas un caso muy claro y controlado.

Buenas prácticas básicas:

• Activa bloqueo de acceso público salvo necesidad explícita.
• Usa IAM para controlar identidades.
• Usa bucket policies con cuidado.
• No abras acceso anónimo sin revisar impacto.
• Revisa accesos cross-account.
• Usa CloudTrail y logs cuando aplique.
• Aplica mínimo privilegio.
• Usa condiciones en políticas cuando tenga sentido.

14. IAM Policy vs Bucket Policy

En S3 puedes controlar acceso de varias formas. Dos de las más importantes son IAM policies y bucket policies.

Tipo de política	Dónde se aplica	Ejemplo
IAM Policy	Usuario, grupo o rol IAM	Un rol puede leer objetos de un bucket concreto
Bucket Policy	Directamente en el bucket	Permitir acceso a una cuenta concreta o forzar HTTPS

Ejemplo:

Una aplicación en EC2 necesita leer imágenes desde un bucket. Lo normal sería asignar un rol IAM a la instancia con permiso de lectura sobre ese bucket.

Otro ejemplo:

Quieres obligar a que todo acceso al bucket sea mediante HTTPS. Puedes usar una bucket policy con condiciones para denegar tráfico no seguro.

15. Replicación: copiar objetos a otra región o cuenta

S3 puede replicar objetos automáticamente a otro bucket. Ese bucket puede estar en otra región o incluso en otra cuenta AWS.

Esto puede ser útil para:

• Recuperación ante desastre.
• Copias entre regiones.
• Separación de datos en otra cuenta.
• Requisitos de cumplimiento.
• Baja latencia para usuarios de otra zona geográfica.

Hay dos conceptos habituales:

Tipo	Qué significa	Uso típico
CRR	Cross-Region Replication	Replicar a otra región
SRR	Same-Region Replication	Replicar en la misma región, por ejemplo a otra cuenta

Importante: replicación no sustituye a una estrategia completa de backup y recuperación. Es una herramienta más. Si replicas un borrado o una corrupción según configuración, podrías propagar el problema. Hay que diseñarlo con cuidado.

16. Recuperación: versioning, Object Lock, backup y pruebas

Cuando hablamos de recuperación en S3, no basta con decir “S3 es durable”. También hay que pensar en errores humanos, borrados accidentales, sobrescrituras, ransomware o configuraciones incorrectas.

Herramientas útiles:

• Versioning: permite recuperar versiones anteriores.
• Object Lock: protege objetos frente a borrado o modificación durante retención.
• Lifecycle: gestiona versiones antiguas y retención.
• Replicación: copia objetos a otra región o cuenta.
• AWS Backup: puede formar parte de estrategias centralizadas de protección.
• CloudTrail: ayuda a investigar quién hizo cambios.

Y algo muy importante: hay que probar la recuperación.

17. S3 para web estática: mejor con CloudFront

S3 se puede usar para alojar contenido estático: HTML, CSS, JavaScript, imágenes o ficheros descargables.

Pero en arquitecturas reales suele combinarse con Amazon CloudFront, que es la CDN de AWS.

Ventajas de usar CloudFront delante de S3:

• Mejor rendimiento para usuarios distribuidos.
• Caché en ubicaciones edge.
• HTTPS gestionado con certificados.
• Menos exposición directa del bucket.
• Más control de distribución y acceso.

Un error típico es hacer público el bucket directamente sin necesidad. Muchas veces puedes mantener el bucket privado y servir el contenido mediante CloudFront.

18. S3 como base de un data lake

S3 se usa muchísimo como capa de almacenamiento para data lakes.

Un data lake es un repositorio donde guardas grandes volúmenes de datos, normalmente para analítica, machine learning, reporting o procesamiento posterior.

En este caso, S3 no debe convertirse en un cajón desastre.

Conviene cuidar:

• Estructura de prefijos.
• Formato de datos.
• Particionado.
• Catálogo de datos.
• Permisos por dominio o equipo.
• Cifrado.
• Lifecycle.
• Clasificación de datos.
• Coste de almacenamiento y consultas.

Ejemplo de mala práctica:

Subir ficheros sin estructura, sin dueño, sin formato común y sin saber quién puede leer qué.

Ejemplo mejor:

Organizar por dominio, fecha, origen y sensibilidad, con permisos claros y lifecycle definido.

19. S3 para logs: útil, pero con gobierno

Muchos servicios pueden enviar logs a S3. Esto es muy útil para auditoría, análisis e investigación.

Pero los logs crecen rápido. Si no aplicas lifecycle, puedes acabar pagando por años de datos que nadie consulta.

Buenas prácticas para logs en S3:

• Separar logs por cuenta, entorno o servicio.
• Activar cifrado.
• Proteger contra borrado cuando aplique.
• Definir retención.
• Mover logs antiguos a clases más frías.
• Controlar quién puede leerlos.
• Evitar que los mismos equipos que generan logs puedan borrarlos sin control.

20. Optimización de coste en S3

S3 puede ser muy económico, pero también puede crecer mucho si no lo gobiernas.

El coste no depende solo de los GB almacenados. También pueden influir:

• Clase de almacenamiento.
• Número de requests.
• Recuperaciones desde clases frías.
• Transferencia de datos.
• Replicación.
• Versiones antiguas.
• Objetos incompletos de cargas multipart.
• Uso de KMS.
• Monitorización de Intelligent-Tiering.

Errores típicos:

• Guardar todo en Standard para siempre.
  Puede ser innecesariamente caro si los datos dejan de consultarse.
• No limpiar versiones antiguas.
  Versioning protege, pero también puede multiplicar almacenamiento.
• Mover datos a Glacier sin entender recuperación.
  Ahorras almacenamiento, pero quizá tardas más o pagas más al recuperar.
• No eliminar cargas multipart incompletas.
  Pueden quedarse consumiendo almacenamiento.
• No etiquetar buckets ni objetos.
  Luego cuesta saber quién es dueño del coste.
• No revisar requests y transferencia.
  A veces el problema no son los GB, sino el acceso.

21. Gobierno: el detalle que marca la diferencia

Cuando hay pocos buckets, todo parece manejable. Cuando hay decenas o cientos, necesitas estándares.

Un buen gobierno de S3 debería definir:

• Nombres de buckets.
• Etiquetas obligatorias.
• Propietario del dato.
• Clasificación de sensibilidad.
• Cifrado por defecto.
• Bloqueo de acceso público.
• Lifecycle mínimo.
• Retención de logs.
• Permisos cross-account.
• Revisión periódica de acceso.

Una buena pregunta para cada bucket sería:

¿Para qué existe, quién es el dueño, qué datos contiene, quién puede acceder, cuánto tiempo deben conservarse y cuánto cuesta?

Si nadie sabe responder eso, el bucket está mal gobernado.

22. Errores típicos con Amazon S3

Estos errores son bastante comunes:

• Pensar que S3 es solo una carpeta en la nube.
  S3 es almacenamiento de objetos con muchas opciones de seguridad, coste y gobierno.
• Hacer público un bucket sin necesidad.
  Para contenido estático, muchas veces es mejor usar CloudFront delante.
• No activar versioning en datos importantes.
  Sin versioning, recuperar sobrescrituras o borrados puede ser más difícil.
• Activar versioning pero no limpiar versiones antiguas.
  Proteges datos, pero puedes disparar el coste.
• No usar lifecycle.
  Los datos antiguos se quedan en clases caras sin motivo.
• Elegir Glacier para datos que necesitas rápido.
  No todas las clases frías tienen recuperación inmediata.
• No cifrar o no controlar claves.
  El cifrado debe alinearse con requisitos de seguridad.
• No revisar permisos cross-account.
  Puedes estar compartiendo datos más de lo previsto.
• No probar restauración.
  Diseñar recuperación no es lo mismo que demostrar que recuperas.
• No etiquetar ni clasificar datos.
  Sin etiquetas ni propietarios, el gobierno se vuelve complicado.

23. Casos de uso típicos bien diseñados

Vamos a verlo por escenarios.

Caso	Controles clave	Error habitual
Web estática	CloudFront, bucket privado, HTTPS, caché	Exponer el bucket directamente sin necesidad
Backups	Versioning, Object Lock, cifrado, lifecycle	No probar restauración
Data lake	Prefijos, catálogo, permisos, formatos, lifecycle	Convertir S3 en un cajón desastre
Logs	Retención, cifrado, protección contra borrado	Guardar logs infinitamente en Standard
Documentos de usuarios	IAM, bucket policies, cifrado, clasificación	Permisos demasiado abiertos
Archivo legal	Glacier, Object Lock, retención definida	No considerar tiempos de recuperación

24. Cómo puede aparecer S3 en el examen CLF-C02

En CLF-C02, S3 aparece muchísimo porque es un servicio muy básico y muy usado.

Pueden preguntarte por:

• Qué servicio usar para almacenamiento de objetos.
• Qué clase usar para datos de acceso frecuente.
• Qué clase usar para archivo a largo plazo.
• Qué función permite recuperar versiones anteriores.
• Qué opción protege frente a borrado o modificación durante retención.
• Qué usar para mover objetos automáticamente a clases más baratas.
• Qué servicio usar para cifrado con claves gestionadas.
• Qué hacer para evitar acceso público accidental.
• Qué servicio usar delante de S3 para distribución global de contenido.

Asociaciones rápidas para memorizar

Necesidad en la pregunta	Servicio o característica
Almacenamiento de objetos	Amazon S3
Contenido de acceso frecuente	S3 Standard
Acceso infrecuente con recuperación rápida	S3 Standard-IA
Archivo de largo plazo	S3 Glacier / Glacier Deep Archive
Patrón de acceso desconocido	S3 Intelligent-Tiering
Recuperar versiones anteriores	S3 Versioning
Retención inmutable / WORM	S3 Object Lock
Mover objetos automáticamente entre clases	S3 Lifecycle
Replicar objetos a otra región	S3 Cross-Region Replication
Distribuir contenido globalmente	Amazon CloudFront
Cifrado con control de claves	AWS KMS / SSE-KMS

25. Checklist para diseñar un bucket S3 correctamente

Antes de dar por bueno un diseño con S3, revisa esto:

• ¿El bucket tiene un propósito claro?
  No crees buckets “genéricos” donde acaba todo mezclado.
• ¿Está bloqueado el acceso público?
  Salvo que tengas un caso explícito, debería estar bloqueado.
• ¿Los datos importantes tienen versioning?
  Ayuda a recuperar sobrescrituras o borrados accidentales.
• ¿Hay lifecycle para objetos antiguos?
  Evita pagar indefinidamente por datos fríos en clases caras.
• ¿Se ha elegido bien la clase de almacenamiento?
  No todo debe estar en Standard ni todo debe ir a Glacier.
• ¿El cifrado cumple los requisitos?
  SSE-S3 puede bastar en muchos casos; SSE-KMS da más control.
• ¿Se revisan permisos IAM y bucket policies?
  Evita accesos demasiado amplios o cross-account sin control.
• ¿Hay estrategia de recuperación?
  Versioning, Object Lock, replicación o backup según criticidad.
• ¿Se han probado restauraciones?
  No basta con configurar protección; hay que comprobar que funciona.
• ¿El bucket tiene etiquetas y propietario?
  Ayuda a controlar coste, gobierno y responsabilidad.

26. Resumen para quedarte con lo importante

Si estás preparando CLF-C02, quédate con estas ideas:

• S3 es almacenamiento de objetos, no almacenamiento de bloques.
• Un bucket contiene objetos identificados por keys.
• S3 Standard es para acceso frecuente.
• Standard-IA es para acceso infrecuente con recuperación rápida.
• Glacier y Deep Archive son para archivado y largo plazo.
• Intelligent-Tiering ayuda cuando el patrón de acceso es variable o desconocido.
• Lifecycle automatiza transiciones y expiraciones.
• Versioning ayuda a recuperar versiones anteriores.
• Object Lock permite retención inmutable tipo WORM.
• Block Public Access ayuda a evitar exposiciones accidentales.
• SSE-S3 y SSE-KMS son opciones de cifrado en reposo.
• CloudFront suele ser buena opción para distribuir contenido estático desde S3.

Conclusión

Amazon S3 es uno de los servicios más sencillos para empezar en AWS, pero también uno de los más importantes para diseñar bien.

No basta con crear un bucket y subir archivos. Hay que pensar en clases de almacenamiento, lifecycle, cifrado, acceso público, versioning, Object Lock, replicación, recuperación y coste.

Para alumnos de AWS Certified Cloud Practitioner CLF-C02, S3 es un servicio que conviene dominar muy bien a nivel conceptual. Aparece en almacenamiento, seguridad, costes, recuperación, contenido estático, backups y analítica.

Una buena arquitectura con S3 no es la que guarda todo sin pensar. Es la que entiende qué datos tiene, quién puede acceder, cuánto tiempo se conservan, cómo se protegen y cuánto cuesta mantenerlos.