

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Bonnes pratiques pour optimiser les performances de S3 Express One Zone
<a name="s3-express-optimizing-performance-design-patterns"></a>

Lors du développement d’applications qui chargent et récupèrent les objets depuis Amazon S3 Express One Zone, suivez nos bonnes pratiques pour optimiser les performances. Pour utiliser la classe de stockage S3 Express One Zone, vous devez créer un compartiment de répertoires S3. La classe de stockage S3 Express One Zone n’est pas prise en charge pour une utilisation avec les compartiments S3 à usage général.

Pour accéder aux directives d’optimisation des performances relatives à toutes les autres classes de stockage Amazon S3 et aux compartiments à usage général S3, consultez [Modèles de conception des bonnes pratiques : optimisation des performances d’Amazon S3](optimizing-performance.md).

Pour optimiser les performances et la capacité de mise à l’échelle de la classe de stockage S3 Express One Zone et des compartiments de répertoires pour les charges de travail à grande échelle, il est important de comprendre en quoi les compartiments de répertoires fonctionnent différemment des compartiments à usage général. Nous vous proposons ensuite de bonnes pratiques pour aligner vos applications sur le fonctionnement des compartiments de répertoires.

## Fonctionnement des compartiments de répertoires
<a name="s3-express-how-directory-buckets-work"></a>

La classe de stockage Amazon S3 Express One Zone peut prendre en charge des charges de travail comportant jusqu’à deux millions de transactions GET et jusqu’à 200 000 transactions PUT par seconde (TPS) par compartiment de répertoires. Avec S3 Express One Zone, les données sont stockées dans des compartiments de répertoires S3 situés dans des zones de disponibilité. Les objets des compartiments de répertoires sont accessibles dans un espace de noms hiérarchique, semblable à un système de fichiers, contrairement aux compartiments à usage général S3 qui disposent d’un espace de noms plat. Contrairement aux compartiments à usage général, les compartiments de répertoires organisent les clés de manière hiérarchique dans des répertoires plutôt qu’avec des préfixes. Un préfixe est une chaîne de caractères au début du nom de la clé d’objet. Vous pouvez utiliser des préfixes pour organiser vos données et gérer une architecture plate de stockage d’objets dans des compartiments à usage général. Pour de plus amples informations, veuillez consulter [Organisation des objets à l’aide de préfixes](using-prefixes.md).

Dans les compartiments de répertoires, les objets sont organisés dans un espace de noms hiérarchique en utilisant la barre oblique (`/`) comme seul délimiteur pris en charge. Lorsque vous chargez un objet avec une clé comme `dir1/dir2/file1.txt`, les répertoires `dir1/` et `dir2/` sont automatiquement créés et gérés par Amazon S3. Les répertoires sont créés pendant l’opération `PutObject` ou `CreateMultiPartUpload` et automatiquement supprimés lorsqu’ils sont vidés après l’opération `DeleteObject` ou `AbortMultiPartUpload`. Le nombre d’objets et de sous-répertoires dans un répertoire n’est pas plafonné.

Les répertoires créés lorsque des objets sont chargés dans des compartiments de répertoires peuvent être mis à l’échelle instantanément afin de réduire les risques d’erreur HTTP `503 (Slow Down)`. Cette mise à l’échelle automatique permet à vos applications de mettre en parallèle les demandes de lecture et d’écriture dans et entre les répertoires, selon les besoins. Pour S3 Express One Zone, les répertoires sont conçus pour prendre en charge le nombre maximal de demandes d’un compartiment de répertoires. Il n’est pas nécessaire de randomiser les préfixes de clé pour optimiser les performances, car le système répartit automatiquement les objets pour équilibrer la charge. Les clés ne sont donc pas stockées par ordre lexicographique dans les compartiments de répertoires. En revanche, dans les compartiments à usage général S3, les clés qui sont plus proches lexicographiquement sont plus susceptibles de se trouver sur le même serveur. 

Pour plus d’exemples d’opérations sur des compartiments de répertoires et d’interactions avec les répertoires, consultez [Exemples d’opérations sur des compartiments de répertoires et d’interactions avec les répertoires](#s3-express-directory-bucket-examples).

## Bonnes pratiques
<a name="s3-express-best-practices-section"></a>

Adoptez les bonnes pratiques pour optimiser les performances de votre compartiment de répertoires et mettre à l’échelle vos charges de travail au fil du temps.

### Utiliser des répertoires contenant de nombreuses entrées (objets ou sous-répertoires)
<a name="s3-express-best-practices-use-directories"></a>

Les compartiments de répertoires offrent des performances élevées par défaut pour toutes les charges de travail. Pour optimiser davantage les performances de certaines opérations, la consolidation d’un grand nombre d’entrées (objets ou sous-répertoires) dans des répertoires permet de réduire le temps de latence et d’augmenter le taux de demandes : 
+ Les opérations d’API mutantes, comme `PutObject`, `DeleteObject`, `CreateMultiPartUpload` et `AbortMultiPartUpload`, atteignent des performances optimales lorsqu’elles sont mises en œuvre avec un nombre réduit de répertoires plus denses contenant des milliers d’entrées, plutôt qu’avec un grand nombre de petits répertoires. 
+ Les opérations `ListObjectsV2` sont plus performantes lorsqu’il y a moins de répertoires à parcourir pour remplir une page de résultats.

#### Ne pas utiliser d’entropie dans les préfixes
<a name="s3-express-best-practices-dont-use-entropy"></a>

Dans les opérations Amazon S3, l’entropie fait référence au caractère aléatoire de la dénomination des préfixes qui permet de répartir les charges de travail de manière uniforme sur les partitions de stockage. Cependant, étant donné que les compartiments de répertoires gèrent en interne la répartition de la charge, il n’est pas recommandé de recourir à l’entropie dans les préfixes pour améliorer les performances. En effet, pour les compartiments de répertoires, l’entropie peut ralentir les demandes en ne réutilisant pas les répertoires déjà créés.

Un modèle de clé comme `$HASH/directory/object` pourrait finir par créer de nombreux répertoires intermédiaires. Dans l’exemple suivant, tous les `job-1` sont des répertoires différents puisque leurs parents sont différents. Les répertoires seront rares et les demandes de mutation et de liste seront plus lentes. Dans cet exemple, il existe 12 répertoires intermédiaires qui ont tous une seule entrée.

```
s3://my-bucket/0cc175b9c0f1b6a831c399e269772661/job-1/file1
  
s3://my-bucket/92eb5ffee6ae2fec3ad71c777531578f/job-1/file2
  
s3://my-bucket/4a8a08f09d37b73795649038408b5f33/job-1/file3
  
s3://my-bucket/8277e0910d750195b448797616e091ad/job-1/file4
  
s3://my-bucket/e1671797c52e15f763380b45e841ec32/job-1/file5
  
s3://my-bucket/8fa14cdd754f91cc6554c9e71929cce7/job-1/file6
```

Pour améliorer les performances, nous pouvons supprimer le composant `$HASH` et autoriser `job-1` à devenir un répertoire unique, et améliorer ainsi la densité du répertoire. Dans l’exemple suivant, l’unique répertoire intermédiaire qui comprend six entrées peut améliorer les performances par rapport à l’exemple précédent.

```
s3://my-bucket/job-1/file1
  
s3://my-bucket/job-1/file2
  
s3://my-bucket/job-1/file3
  
s3://my-bucket/job-1/file4
  
s3://my-bucket/job-1/file5
  
s3://my-bucket/job-1/file6
```

Ce gain de performances s’explique par le fait que lorsqu’une clé d’objet est créée et que son nom inclut un répertoire, celui-ci est automatiquement créé pour l’objet. Les chargements d’objets ultérieurs vers ce même répertoire ne nécessitent pas la création du répertoire, ce qui réduit la latence lors des chargements d’objets vers les répertoires existants.

#### Utiliser un séparateur autre que le délimiteur / pour séparer les parties de votre clé si vous n’avez pas besoin de regrouper des objets de manière logique pendant les appels `ListObjectsV2`
<a name="s3-express-best-practices-use-separator"></a>

Étant donné que le délimiteur `/` est traité de manière particulière pour les compartiments de répertoires, il doit être utilisé à bon escient. Même si les compartiments de répertoires ne classent pas les objets par ordre lexicographique, les objets d’un répertoire sont tout de même regroupés dans les sorties `ListObjectsV2`. Si vous n’avez pas besoin de cette fonctionnalité, vous pouvez remplacer `/` par un autre caractère comme séparateur afin de ne pas provoquer la création de répertoires intermédiaires.

Supposons, par exemple, que les clés suivantes adoptent le modèle de préfixe `YYYY/MM/DD/HH/`.

```
s3://my-bucket/2024/04/00/01/file1
  
s3://my-bucket/2024/04/00/02/file2
  
s3://my-bucket/2024/04/00/03/file3
  
s3://my-bucket/2024/04/01/01/file4
  
s3://my-bucket/2024/04/01/02/file5
  
s3://my-bucket/2024/04/01/03/file6
```

Si vous n’avez pas besoin de regrouper les objets par heure ou par jour dans les résultats `ListObjectsV2`, mais que vous avez besoin de les regrouper par mois, le schéma de clé `YYYY/MM/DD-HH-` permet de réduire considérablement le nombre de répertoires et d’améliorer les performances de l’opération `ListObjectsV2`.

```
s3://my-bucket/2024/04/00-01-file1
  
s3://my-bucket/2024/04/00-01-file2
  
s3://my-bucket/2024/04/00-01-file3
  
s3://my-bucket/2024/04/01-02-file4
  
s3://my-bucket/2024/04/01-02-file5
  
s3://my-bucket/2024/04/01-02-file6
```

#### Utiliser des opérations de listes délimitées dans la mesure du possible
<a name="s3-express-best-practices-use-delimited-list"></a>

Une demande `ListObjectsV2` sans `delimiter` effectue une analyse récursive approfondie de tous les répertoires. Une demande `ListObjectsV2` avec un `delimiter` extrait uniquement les entrées du répertoire spécifié par le paramètre `prefix`, ce qui réduit le temps de latence des demandes et augmente le nombre de clés agrégées par seconde. Pour les compartiments de répertoires, utilisez des opérations de listes délimitées dans la mesure du possible. Les listes délimitées permettent de réduire le nombre de visites des répertoires, ce qui se traduit par un nombre accru de clés par seconde et une latence plus faible des demandes.

Par exemple, pour les répertoires et objets suivants de votre compartiment de répertoires :

```
s3://my-bucket/2024/04/12-01-file1
  
s3://my-bucket/2024/04/12-01-file2
  
...
  
s3://my-bucket/2024/05/12-01-file1
  
s3://my-bucket/2024/05/12-01-file2
  
...
  
s3://my-bucket/2024/06/12-01-file1
  
s3://my-bucket/2024/06/12-01-file2
  
...
  
s3://my-bucket/2024/07/12-01-file1
  
s3://my-bucket/2024/07/12-01-file2
  
...
```

Pour de meilleures performances de `ListObjectsV2`, utilisez une liste délimitée pour répertorier vos sous-répertoires et vos objets, si la logique de votre application le permet. Par exemple, vous pouvez exécuter la commande suivante pour l’opération de liste délimitée :

```
aws s3api list-objects-v2 --bucket my-bucket --prefix '2024/' --delimiter '/'
```

La sortie est la liste des sous-répertoires.

```
{
    "CommonPrefixes": [
        {
            "Prefix": "2024/04/"
        },
        {
            "Prefix": "2024/05/"
        },
        {
            "Prefix": "2024/06/"
        },
        {
            "Prefix": "2024/07/"
        }
    ]
}
```

Pour mieux répertorier chaque sous-répertoire, vous pouvez exécuter une commande semblable à l’exemple suivant :

Commande :

```
aws s3api list-objects-v2 --bucket my-bucket --prefix '2024/04' --delimiter '/'
```

Sortie :

```
{
    "Contents": [
        {
            "Key": "2024/04/12-01-file1"
        },
        {
            "Key": "2024/04/12-01-file2"
        }
    ]
}
```

### Regroupement du stockage S3 Express One Zone et de vos ressources de calcul
<a name="s3-express-best-practices-colocate"></a>

Avec S3 Express One Zone, chaque compartiment de répertoires est stocké dans une zone de disponibilité unique que vous sélectionnez lorsque vous créez le compartiment. Vous pouvez commencer par créer un nouveau compartiment de répertoires dans une zone de disponibilité locale pour vos charges de travail ou vos ressources de calcul. Vous pouvez alors commencer immédiatement des opérations de lecture et d’écriture à très faible latence. Les compartiments de répertoire sont un type de compartiments S3 dans lesquels vous pouvez choisir la zone de disponibilité dans un Région AWS afin de réduire le temps de latence entre le calcul et le stockage.

Si vous accédez à des compartiments de répertoires dans différentes zones de disponibilité, vous risquez de constater une légère augmentation de la latence. Pour optimiser les performances, nous vous recommandons d’accéder à un compartiment de répertoires depuis des instances Amazon Elastic Container Service, Amazon Elastic Kubernetes Service et Amazon Elastic Compute Cloud situées dans la même zone de disponibilité, quand cela est possible.

### Utiliser des connexions simultanées pour atteindre un débit élevé avec les objets de plus de 1 Mo
<a name="s3-express-best-practices-concurrent-connections"></a>

Vous pouvez optimiser les performances en adressant plusieurs demandes simultanées aux compartiments de répertoires pour répartir vos demandes sur des connexions distinctes et augmenter au maximum la bande passante accessible. À l’instar des compartiments à usage général, S3 Express One Zone n’impose aucune limite quant au nombre de connexions établies avec votre compartiment de répertoires. Les répertoires individuels peuvent mettre à l’échelle horizontalement et automatiquement les performances quand un grand nombre d’écritures simultanées sont effectuées dans le même répertoire.

Les connexions TCP aux compartiments de répertoires ont une limite supérieure fixe quant au nombre d’octets pouvant être chargés ou téléchargés par seconde. Lorsque les objets deviennent plus volumineux, les temps de requête sont davantage dominés par le streaming des octets que par le traitement des transactions. Pour utiliser plusieurs connexions afin de paralléliser le chargement ou le téléchargement d'objets plus volumineux, vous pouvez réduire end-to-end le temps de latence. Si vous utilisez le kit `Java 2.x` SDK, vous devriez envisager d’utiliser le [gestionnaire de transferts S3](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html), qui tirera parti des améliorations de performances telles que les [opérations d’API de chargement partitionné](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html) et les extractions par plage d’octets pour accéder aux données en parallèle.

### Utiliser des points de terminaison d’un VPC de passerelle
<a name="s3-express-best-practices-vpc-endpoints"></a>

Les points de terminaison de passerelle fournissent une connexion directe entre votre VPC et les compartiments de répertoires, sans nécessiter de passerelle Internet ou d’appareil NAT pour votre VPC. Pour réduire le temps que vos paquets passent sur le réseau, vous devez configurer votre VPC avec un point de terminaison d’un VPC de passerelle pour les compartiments de répertoires. Pour de plus amples informations, veuillez consulter [Mise en réseau des compartiments de répertoires](s3-express-networking.md).

### Utiliser l’authentification de session et réutiliser les jetons de session lorsqu’ils sont valides
<a name="s3-express-best-practices-session-auth"></a>

Les compartiments de répertoires fournissent un mécanisme d’authentification par jeton de session pour réduire la latence lors des opérations d’API sensibles aux performances. Vous pouvez passer un seul appel à `CreateSession` pour obtenir un jeton de session, qui sera ensuite valide pour toutes les demandes pendant les cinq minutes suivantes. Pour réduire au minimum la latence de vos appels d’API, assurez-vous d’acquérir un jeton de session et de le réutiliser pendant toute sa durée de vie avant de l’actualiser.

Si vous l'utilisez AWS SDKs, SDKs gérez automatiquement les actualisations des jetons de session afin d'éviter les interruptions de service à l'expiration d'une session. Nous vous recommandons d'utiliser le AWS SDKs pour lancer et gérer les demandes relatives à l'opération `CreateSession` API.

Pour plus d’informations sur `CreateSession`, consultez [Autorisation des opérations d’API de point de terminaison zonal avec `CreateSession`](s3-express-create-session.md).

### Utiliser un client basé sur le CRT
<a name="s3-express-best-practices-crt"></a>

Le AWS Common Runtime (CRT) est un ensemble de bibliothèques modulaires, performantes et efficaces écrites en C et destinées à servir de base au AWS SDKs. Le CRT offre un débit amélioré, une gestion optimisée des connexions et des temps de démarrage plus rapides. Le CRT est disponible sur tous les réseaux AWS SDKs sauf Go.

[Pour plus d'informations sur la configuration du CRT pour le SDK que vous utilisez, consultez les [bibliothèques AWS Common Runtime (CRT)](https://docs.aws.amazon.com/sdkref/latest/guide/common-runtime.html), Accélérez le [débit d'Amazon S3 avec le AWS Common Runtime, Présentation du](https://aws.amazon.com/blogs//storage/improving-amazon-s3-throughput-for-the-aws-cli-and-boto3-with-the-aws-common-runtime/)[client S3 basé sur CRT et du gestionnaire de transfert S3 dans le SDK pour Java AWS 2.x, Utilisation de S3 pour](https://aws.amazon.com/blogs//developer/introducing-crt-based-s3-client-and-the-s3-transfer-manager-in-the-aws-sdk-for-java-2-x/) les opérations [CrtClient Amazon S3](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/examples-s3-crt.html) et Configuration des clients HTTP basés sur le CRT. AWS](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/http-configuration-crt.html)

### Utilisez la dernière version du AWS SDKs
<a name="s3-express-best-practices-latest-sdks"></a>

Ils AWS SDKs fournissent un support intégré pour de nombreuses directives recommandées pour optimiser les performances d'Amazon S3. Ils SDKs proposent une API plus simple pour tirer parti d'Amazon S3 depuis une application et sont régulièrement mis à jour pour suivre les meilleures pratiques les plus récentes. Par exemple, ils réessayent SDKs automatiquement les demandes après des `503` erreurs HTTP et gèrent les réponses lentes aux connexions.

Si vous utilisez le kit `Java 2.x` SDK, vous devriez envisager d’utiliser le [gestionnaire de transferts S3](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html), qui met automatiquement les connexions à l’échelle horizontalement pour traiter des milliers de demandes par seconde en utilisant des demandes par plage d’octets, le cas échéant. Les demandes par plage d’octets peuvent améliorer les performances, car vous pouvez utiliser des connexions simultanées à S3 pour extraire différentes plages d’octets du même objet. Vous pouvez ainsi parvenir au regroupement de débits le plus élevé, par opposition à une seule demande d’objet entier. Il est donc important d'utiliser la dernière version du AWS SDKs pour obtenir les dernières fonctionnalités d'optimisation des performances.

## Dépannage des performances
<a name="s3-express-performance-troubleshooting"></a>

### Configurez-vous des demandes de nouvelle tentative pour les applications sensibles à la latence ?
<a name="s3-express-performance-troubleshooting-retry"></a>

La classe S3 Express One Zone est spécialement conçue pour fournir des niveaux élevés constants de performances sans réglages supplémentaires. Toutefois, la définition de valeurs de délai d’attente et de nouvelles tentatives agressives contribue également à garantir une latence et des performances constantes. Ils AWS SDKs ont des valeurs de délai d'expiration et de nouvelle tentative configurables que vous pouvez ajuster en fonction des tolérances de votre application spécifique.

### Utilisez-vous des bibliothèques CRT ( AWS Common Runtime) et des types d'instances Amazon EC2 optimaux ?
<a name="s3-express-performance-troubleshooting-crt-ec2"></a>

Les applications qui effectuent un grand nombre d’opérations de lecture et d’écriture ont probablement besoin de plus de mémoire et de capacité de calcul que les autres. Lorsque vous lancez vos instances Amazon Elastic Compute Cloud (Amazon EC2) pour votre charge de travail exigeante en performances, choisissez les types d’instances qui disposent de la quantité de ces ressources dont votre application a besoin. Le stockage hautes performances S3 Express One Zone est idéalement associé à des types d'instances plus grands et plus récents, dotés d'une plus grande quantité de mémoire système et plus puissants, CPUs et GPUs qui peuvent tirer parti d'un stockage plus performant. Nous vous recommandons également d'utiliser les dernières versions de la technologie compatible CRT AWS SDKs, qui permettent de mieux accélérer les requêtes de lecture et d'écriture en parallèle.

### Utilisez-vous une authentification basée sur AWS SDKs les sessions ?
<a name="s3-express-performance-troubleshooting-session-auth"></a>

Avec Amazon S3, vous pouvez également optimiser les performances lorsque vous utilisez des requêtes d'API HTTP REST en suivant les mêmes bonnes pratiques que celles décrites dans le AWS SDKs. Toutefois, compte tenu du mécanisme d'autorisation et d'authentification basé sur les sessions utilisé par S3 Express One Zone, nous vous recommandons vivement d'utiliser le AWS SDKs to manage `CreateSession` et son jeton de session géré. Créez et actualisez AWS SDKs automatiquement les jetons en votre nom à l'aide de l'opération `CreateSession` API. Utilisation d'`CreateSession`économies sur le temps de latence aller-retour par demande vers Gestion des identités et des accès AWS (IAM) pour autoriser chaque demande.

## Exemples d’opérations sur des compartiments de répertoires et d’interactions avec les répertoires
<a name="s3-express-directory-bucket-examples"></a>

Voici trois exemples illustrant le fonctionnement des compartiments de répertoires.

### Exemple 1 : interaction de demandes S3 `PutObject` adressées à un compartiment de répertoires avec les répertoires
<a name="s3-express-directory-bucket-examples-put"></a>

1. Lorsque l’opération `PUT(<bucket>, "documents/reports/quarterly.txt")` est exécutée dans un compartiment vide, le répertoire `documents/` situé à la racine du compartiment est créé, le répertoire `reports/` dans `documents/` est créé, et l’objet `quarterly.txt` dans `reports/`est créé. Pour cette opération, deux répertoires ont été créés en plus de l’objet.  
![\[Schéma illustrant la structure d’un répertoire après l’opération PUT pour documents/reports/quarterly.txt\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-foo-bar-baz.png)

1. Ensuite, lorsqu’une autre opération `PUT(<bucket>, "documents/logs/application.txt")` est exécutée, le répertoire `documents/` existe déjà, le répertoire `logs/` dans `documents/` n’existe pas et est créé, et l’objet `application.txt` dans `logs/` est créé. Pour cette opération, un seul répertoire a été créé en plus de l’objet.  
![\[Schéma illustrant la structure d’un répertoire après l’opération PUT pour documents/logs/application.txt\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-foo-baz-quux.png)

1. Enfin, lorsqu’une opération `PUT(<bucket>, "documents/readme.txt")` est exécutée, le répertoire `documents/` situé à la racine existe déjà et l’objet `readme.txt` est créé. Pour cette opération, aucun répertoire n’est créé.  
![\[Schéma illustrant la structure d’un répertoire après l’opération PUT pour documents/readme.txt\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-foo-bar.png)

### Exemple 2 : interaction de demandes S3 `ListObjectsV2` adressées à un compartiment de répertoires avec les répertoires
<a name="s3-express-directory-bucket-examples-list"></a>

Pour les demandes S3 `ListObjectsV2` sans délimiteur, un compartiment est parcouru en profondeur. Les sorties sont renvoyées dans un ordre cohérent. Cependant, bien qu’il reste identique entre les demandes, cet ordre n’est pas lexicographique. Pour le compartiment et les répertoires créés dans l’exemple précédent :

1. Lorsqu’un `LIST(<bucket>)` est exécuté, le répertoire `documents/` est saisi et le parcours commence.

1. Le sous-répertoire `logs/` est saisi et le parcours commence.

1. L’objet `application.txt` est trouvé dans `logs/`.

1. Il n’existe aucune autre entrée dans `logs/`. L’opération Liste sort de `logs/`, puis entre à nouveau dans `documents/`.

1. Le répertoire `documents/` continue d’être parcouru et l’objet `readme.txt` est trouvé.

1. Le répertoire `documents/` continue d’être parcouru, le sous-répertoire `reports/` est saisi et le parcours commence.

1. L’objet `quarterly.txt` est trouvé dans `reports/`.

1. Il n’existe aucune autre entrée dans `reports/`. L’opération Liste sort de `reports/`, puis entre à nouveau dans `documents/`.

1. Il n’existe aucune autre entrée dans `documents/` et l’opération Liste revient.

Dans cet exemple, `logs/` est classé avant `readme.txt`, et `readme.txt` avant `reports/`.

### Exemple 3 : interaction de demandes S3 `DeleteObject` adressées à un compartiment de répertoires avec les répertoires
<a name="s3-express-directory-bucket-examples-delete"></a>

![\[Schéma illustrant la structure initiale du répertoire avant l’opération DELETE\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-delete-before.png)


1. Dans ce même compartiment, lorsque l’opération `DELETE(<bucket>, "documents/reports/quarterly.txt")` est exécutée, l’objet `quarterly.txt` est supprimé, laissant le répertoire `reports/` vide, ce qui entraîne sa suppression immédiate. Le répertoire `documents/` n’est pas vide, car il contient le répertoire `logs/` et l’objet `readme.txt`. Il n’est donc pas supprimé. Pour cette opération, un seul objet et un seul répertoire ont été supprimés.  
![\[Schéma illustrant la structure du répertoire après l’opération DELETE pour documents/reports/quarterly.txt\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-delete1.png)

1. Lorsque l’opération `DELETE(<bucket>, "documents/readme.txt")` est exécutée, l’objet `readme.txt` est supprimé. Le répertoire `documents/` n’est toujours pas vide, car il contient le répertoire `logs/`. Il n’est donc pas supprimé. Pour cette opération, aucun répertoire n’est supprimé. Seul l’objet l’est.  
![\[Schéma illustrant la structure du répertoire après l’opération DELETE pour documents/readme.txt\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-delete2.png)

1. Enfin, lorsque l’opération `DELETE(<bucket>, "documents/logs/application.txt")` est exécutée, l’objet `application.txt` est supprimé, laissant le sous-répertoire `logs/` vide, ce qui entraîne sa suppression immédiate. Le répertoire `documents/` est alors vide et immédiatement supprimé. Pour cette opération, deux répertoires et un objet sont supprimés. Le compartiment est maintenant vide.  
![\[Schéma illustrant la structure du répertoire après l’opération DELETE pour documents/logs/application.txt\]](http://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/images/directory-examples-delete3.png)