¿Es realmente una carpeta la «/» de S3? - La verdad del espacio de nombres plano y el mecanismo de los prefijos
Partiendo del hecho de que en S3 no existe el concepto de carpeta y de que la «/» de la clave de objeto es simplemente parte de una cadena, se explican el mecanismo de búsqueda por prefijo, el truco con el que la consola hace que parezca que hay carpetas y las prácticas recomendadas para el diseño de claves.
En S3 no existen las carpetas
El modelo de datos de S3 es un espacio de nombres plano formado solo por dos niveles: buckets y objetos. No existe una jerarquía de directorios como la de un sistema de archivos. La clave de objeto images/2024/photo.jpg no es «photo.jpg dentro de la carpeta 2024 dentro de la carpeta images», sino «un único objeto llamado images/2024/photo.jpg». La «/» es parte del nombre de la clave y es esencialmente distinta del carácter separador de rutas de un sistema de archivos. Hay una forma sencilla de comprobar este hecho. Si se ejecuta aws s3api list-objects-v2 --bucket my-bucket en la AWS CLI, todos los objetos se devuelven como una lista plana. El concepto de carpeta no aparece en absoluto. En cambio, si se ejecuta aws s3 ls s3://my-bucket/, el resultado se muestra como si hubiera una estructura de carpetas. Esto se debe simplemente a que el comando s3 (comando de alto nivel) usa «/» como delimitador y muestra los prefijos comunes como si fueran carpetas.
El truco con el que la consola hace que parezca que hay carpetas
En la pantalla de S3 de la AWS Management Console se muestran iconos de carpeta y también hay un botón para crear carpetas. Sin embargo, cuando se usa «Crear carpeta» en la consola, en realidad se crea un objeto de cero bytes cuyo nombre termina en «/» (por ejemplo, images/). Este objeto no es más que un marcador para que la consola lo muestre como carpeta. Aunque se elimine el marcador de carpeta, los objetos que tienen ese prefijo no se ven afectados. Aunque se elimine el objeto images/, images/photo.jpg sigue existiendo. A la inversa, si se sube images/photo.jpg, la consola muestra la carpeta images aunque no exista el marcador images/. La consola especifica «/» en el parámetro Delimiter de la API ListObjectsV2 y muestra los CommonPrefixes (prefijos comunes) como carpetas. Si no se comprende este mecanismo, desconciertan fenómenos como «he eliminado la carpeta, pero los archivos de dentro no desaparecen» o «se muestra una carpeta que no he creado».
La relación entre los prefijos y el rendimiento
(A fecha de agosto de 2026) Los prefijos de S3 influyen directamente en el rendimiento. En 2018, S3 mejoró considerablemente su rendimiento y pasó a poder procesar, por cada prefijo particionado, al menos 3,500 solicitudes PUT/COPY/POST/DELETE o 5,500 solicitudes GET/HEAD por segundo. Aquí, el «prefijo» es una cadena de cualquier longitud que empieza al principio de la clave de objeto y puede llegar hasta 1,024 bytes, el límite del nombre de la clave. No es una unidad de tramos separados por «/», ni la parte anterior a la última «/». La clave images/2024/01/photo.jpg tiene como prefijos no solo images/ e images/2024/, sino también cadenas que terminan a mitad de un tramo entre delimitadores, como images/2024/01/p. S3 crea automáticamente los límites de las particiones en cualquier posición de la cadena del prefijo según la tasa de solicitudes sostenida. Como no hay límite en el número de prefijos de un bucket, si se distribuyen las claves, el rendimiento de lectura y escritura se puede escalar horizontalmente. No obstante, no es una simple multiplicación. En las cargas de trabajo que mezclan PUT y GET, la capacidad de procesamiento por partición se reparte según la proporción; por ejemplo, con una composición de un 30% de PUT/POST/DELETE y un 70% de GET, baja a unas 1,050 y 3,850 por segundo. Además, la adición automática de particiones requiere unos 20 minutos después de que la carga por encima del límite se haya mantenido entre 30 y 60 minutos, por lo que durante ese tiempo las solicitudes reciben un 503 (Slow Down). Cuando se pueden prever los picos de antemano, resulta fiable pedir a AWS Support que prepare las particiones del prefijo. Antes de 2018, como el particionado de S3 se basaba en los primeros caracteres de la clave, existía la práctica recomendada de añadir un hash aleatorio al principio de la clave (por ejemplo, a1b2c3/images/photo.jpg). Hoy no es necesario idear patrones de nomenclatura de claves únicos, y S3 optimiza las particiones automáticamente.
Prácticas recomendadas para el diseño de claves de objeto
El diseño de las claves de objeto influye mucho en la eficiencia operativa de S3. En primer lugar, se trata de unificar las reglas de nomenclatura de las claves. Las claves basadas en fechas (logs/2024/01/15/access.log) son adecuadas para gestionar datos de series temporales. Las reglas de ciclo de vida de S3 permiten acotar los objetos de destino no solo por prefijo, sino también por etiquetas de objeto, por tamaño de objeto (mínimo / máximo) y por combinaciones de estos. Sin embargo, si se incluye la fecha en el prefijo, basta con especificar el prefijo. Así, se pueden trasladar automáticamente los datos antiguos a S3 Glacier Flexible Retrieval o S3 Glacier Deep Archive, o eliminar los que han superado su periodo de retención. En segundo lugar, se trata de evitar los caracteres especiales en las claves. En las claves de objeto de S3 se puede usar cualquier carácter UTF-8, pero las claves que contienen espacios, japonés o símbolos especiales pueden causar problemas de codificación de URL. Lo seguro es limitarse a caracteres alfanuméricos, guiones, guiones bajos y barras. En tercer lugar, se trata de tener presente la longitud de las claves. La longitud máxima de una clave de objeto es de 1,024 bytes. Si se usan claves largas para imitar una estructura de carpetas profunda, se acercan a este límite. Además, como la respuesta de ListObjectsV2 incluye los nombres de las claves, las claves largas aumentan el tamaño de la respuesta y consumen ancho de banda de red.
Aprovechamiento del espacio de nombres plano y opciones para filtrar el contenido
El espacio de nombres plano de S3 resulta extraño a los desarrolladores acostumbrados al concepto de los sistemas de archivos tradicionales, pero tiene grandes ventajas en el procesamiento de datos a gran escala. En un espacio de nombres plano no es necesario gestionar metadatos de directorios, por lo que el rendimiento no se degrada aunque se almacenen miles de millones de objetos. En un sistema de archivos, cuantos más archivos contiene un directorio, más aumenta el coste de enumerarlos, y el tiempo de espera varía mucho según el tipo de sistema de archivos y el estado de la caché. En S3, por mucho que aumente el número de objetos, ListObjectsV2 devuelve los resultados en una unidad fija de hasta 1,000 elementos por respuesta, y se puede extraer solo el rango necesario especificando el prefijo y el delimitador. Cuando se quería filtrar el contenido de los objetos en el lado de S3, antes se usaba S3 Select, que ejecuta consultas SQL sobre CSV o JSON. Sin embargo, S3 Select no se ofrece a clientes nuevos, y solo los usuarios existentes pueden seguir usándolo como hasta ahora (a fecha de agosto de 2026). Si se diseña a partir de ahora, la opción actual es la combinación de Amazon Athena, que ejecuta SQL sobre los datos de S3, y AWS Glue, que se encarga de la gestión de esquemas y del ETL. S3 Object Lambda, que procesa las respuestas GET con funciones propias, también se puede usar para el mismo fin. No obstante, al igual que S3 Select, dejó de ofrecerse a clientes nuevos el 7 de noviembre de 2025, por lo que es una opción para los usuarios existentes. En cualquiera de estas configuraciones, que se pueda o no limitar la lectura a los prefijos necesarios determina el volumen de escaneo y el coste, por lo que un diseño de claves que parta del espacio de nombres plano tiene un efecto directo.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.