Questions fréquentes (FAQ) sur Amazon EBS

Lorsqu'ils sont attachés à des instances optimisées pour EBS, les volumes SSD IOPS provisionnés (io2 Block Express et io1) fournissent les performances des volumes IOPS provisionnés avec une marge de 10 %, 99,9 % du temps sur une année donnée. Vos performances exactes dépendent des besoins en E/S de votre application.

Associés à des instances optimisées pour EBS, les volumes IOPS provisionnés io2 Block Express peuvent présenter une latence inférieure à une milliseconde et les volumes io1 peuvent atteindre une latence de quelques millisecondes. Vos performances exactes dépendent des besoins en E/S de votre application.

Oui. Lorsque vous provisionnez les IOPS des volumes io2 Block Express, le taux d'IOPS que vous obtenez dépend de la taille des E/S de votre application en lecture et en écriture. Les volumes IOPS provisionnés disposent d'une taille d'E/S de base de 16 Ko. Ainsi, si vous avez provisionné un volume avec 40 000 IOPS pour une taille d'entrée/sortie de 16 Ko, ils atteindront jusqu'à 40 000 IOPS à cette taille. Si la taille d’E/S est augmentée à 256 Ko, vous atteindrez jusqu'à 16 000 IOPS, car le débit maximal de 4 000 MiB/s est atteint à 16 000 IOPS. Pour plus d’informations, consultez la documentation technique sur les volumes IOPS provisionnés. Vous pouvez utiliser Amazon CloudWatch pour surveiller votre débit et vos tailles d'E/S.

Les volumes SSD IOPS provisionnés (io2 Block Express et io1) attachés aux instances optimisées pour EBS offrent des performances constantes, en fournissant les performances des volumes IOPS provisionnés avec une marge de 10 %, 99,9 % du temps sur une année donnée. Pour bénéficier d’une constance maximale des performances avec les nouveaux volumes créés à partir d'un instantané, nous recommandons d'activer la fonction Fast Snapshot Restore (FSR) sur vos instantanés. Les volumes EBS restaurés à partir d'instantanés FSR bénéficient fonctionnent instantanément de manière optimale.

Un autre facteur pouvant altérer les performances est l'envoi insuffisant de demandes d'E/S par votre application. Vous pouvez contrôler cet aspect en observant la profondeur de la file d'attente de votre volume. La profondeur de la file d'attente est le nombre de demandes d'E/S en attente, en provenance de votre application et à destination de votre volume. Pour une constance maximale, un volume IOPS dimensionné doit conserver une profondeur de file d'attente moyenne (arrondie à l'entier le plus proche) de un par tranche de 1 000 IOPS provisionnés par minute. Par exemple, pour un volume provisionné avec 3 000 IOPS, la profondeur moyenne de la file d'attente doit être de 3. Pour en savoir plus sur la cohérence des performances de vos volumes, consultez la section Increasing EBS Performance.

Lorsqu'ils sont associés à des instances optimisées pour EBS, les volumes Throughput Optimized HDD (st1) et Cold HDD (sc1) sont conçus pour fournir le débit prévu 99 % du temps sur une année et ce, avec une marge de 10 %. Votre niveau exact de performance dépend des besoins en E/S de votre application et des performances de votre instance EC2.

Oui. Le débit obtenu dépend de la taille d'E/S en écriture et en lecture de votre application. Les volumes HDD traitent les lectures et écritures avec une taille d'E/S de 1 Mo. Les E/S séquentielles sont fusionnées et traitées sous forme d'unités de 1 Mo, tandis que chaque E/S non séquentielle est traitée comme une unité de 1 Mo même si la taille d'E/S réelle est inférieure. Ainsi, une charge de travail transactionnelle comprenant de petites E/S aléatoires (une base de données, par exemple) ne fonctionnera pas bien sur des volumes HDD, tandis que les entrées séquentielles et les grandes tailles d'E/S permettront d'obtenir les performances annoncées pour les volumes st1 et sc1 pendant une plus longue période.

Les volumes Throughput Optimized HDD (st1) et Cold HDD (sc1) associés à des instances optimisées pour EBS sont conçus pour fournir des performances constantes en matière de débit prévu (avec une marge de 10 %), et ce, 99 % du temps sur une année. Plusieurs facteurs peuvent avoir un impact sur le niveau de constance que vous observez. Par exemple, l'équilibre relatif entre les opérations d'E/S aléatoires et séquentielles sur le volume peuvent influer sur vos performances. Beaucoup trop d'opérations d'E/S aléatoires et à petite échelle épuisent rapidement vos crédits d'E/S et ramènent vos performances au taux de base. Votre débit peut également être plus faible en fonction de l'instance sélectionnée. Bien que les volumes st1 permettent d'obtenir un débit de 500 Mo/s, les performances seront restreintes par la limite du trafic EBS appliquée séparément au niveau des instances. Un autre facteur pouvant altérer les performances est la réalisation d'une capture d'écran qui ramènera les performances en écriture prévues au taux de base, jusqu'à ce que la capture d'écran soit terminée. Ce facteur est propre aux volumes st1 et sc1.

Vos performances peuvent également être affectées si votre application n'envoie pas suffisamment de demandes d'E/S. Il est possible de contrôler ce phénomène en examinant la profondeur de file d'attente et la taille d'E/S de votre volume. La profondeur de la file d'attente est le nombre de demandes d'E/S en attente, en provenance de votre application et à destination de votre volume. Pour une constance maximale, les volumes sauvegardés sur le disque dur doivent conserver une profondeur de file d'attente moyenne (arrondie à l'entier le plus proche) par tranche de quatre ou plus pour chaque E/S séquentielle de 1 Mo. Pour en savoir plus sur la cohérence des performances de vos volumes, consultez la section Increasing EBS Performance.

Oui. Vous pouvez agréger plusieurs volumes afin d'obtenir jusqu'à 400 000 opérations d'E/S par seconde ou 12 500 Mo/s en les associant à des instances EC2 plus volumineuses. Nous vous recommandons d'utiliser les volumes io2 Block Express pour faire face à des exigences de performances plus élevées sans avoir besoin de la gestion opérationnelle liée au découpage de plusieurs volumes. Les performances des volumes st1 et sc1 évoluent de façon linéaire en fonction de la taille du volume. Il est donc possible que l'agrégation de ces volumes ne soit pas aussi avantageuse.

EBS est un service de stockage par bloc à locataires multiples. Nous limitons le débit pour éviter les conflits de ressources. Dans un premier temps, nous définissons les critères de performances pour les volumes ; nos types de volume (gp2, PIOPS, st1 et sc1) ont tous des caractéristiques de performances en termes d'IOPS et de débit. Ensuite, nous définissons les performances au niveau de l'instance. Chaque instance optimisée EBS définit les performances (à la fois le débit et l'IOPS) de l'ensemble des volumes EBS associés à l'instance. Un client peut donc dimensionner les instances et les volumes pour obtenir le niveau de performances souhaité. En outre, les clients peuvent utiliser nos mesures présentées pour suivre les performances au niveau de l'instance et du volume. Ils peuvent définir des alarmes pour signaler que les données ne correspondent pas aux performances attendues. Les métriques peuvent également aider à déterminer si les clients sont configurés sur le bon type d'instance avec la bonne quantité de performances au niveau du volume. Du côté d'EBS, nous utilisons les performances configurées pour indiquer comment nous allouons l'instance appropriée et l'infrastructure EBS afin de prendre en charge les volumes. En allouant les infrastructures de manière appropriée, nous évitons les conflits de ressources. De plus, nous surveillons constamment notre infrastructure. Cette surveillance nous permet de détecter les pannes d'infrastructure actuelles ou imminentes et donc de déplacer les volumes de manière proactive vers du matériel opérationnel pendant la réparation ou le remplacement (selon le cas) de l'infrastructure sous-jacente.

Lorsqu'ils sont associés à des instances optimisées pour EBS, les volumes SSD Provisioned IOPS (gp3 et gp2) sont conçus pour fournir les performances mises en service 99 % du temps sur une année et ce, avec une marge de 10 %. Vos performances exactes dépendent des besoins en E/S de votre application.

Lorsqu'ils sont associés à des instances optimisées pour EBS, les volumes SSD à usage général (gp3 et gp2) peuvent atteindre des latences de l'ordre de quelques millisecondes. Vos performances exactes dépendent des besoins en E/S de votre application.

Non. Tous les volumes de SSD à usage général (gp3) incluent 3 000 IOPS et 125 Mo / s de performances constantes sans frais supplémentaires. Les volumes peuvent prendre en charge les 3 000 IOPS et 125 Mo / s indéfiniment

Les volumes SSD à usage courant (gp2) inférieurs à 1 000 Go reçoivent des performances IOPS en rafale allant jusqu'à 3 000 IOPS pendant au moins 30 minutes de performances soutenues. De plus, les volumes gp2 offrent des performances constantes de 3 IOPS par Go provisionné. Par exemple, un volume de 500 Go est capable de générer 1 500 IOPS de manière cohérente et d'atteindre 3 000 IOPS pendant 60 minutes (3 000 IOPS * 60 secondes * 30 minutes / 1 500 IOPS / 60secondes).

Les volumes io2 offrent un stockage par blocs à haute performance pour toutes les instances EC2. Pour les applications qui nécessitent des performances encore plus élevées, vous pouvez associer des volumes io2 à ces instances Amazon EC2 qui s'exécutent sur Block Express et offrent des performances 4 fois supérieures à celles de io2. Vous pourrez ainsi atteindre une capacité de 64 Tio, 256 000 IOPS et 4 000 Mo/s de débit à partir d'un seul volume io2, avec une latence IO moyenne inférieure à la milliseconde.

EBS Block Express est la nouvelle génération d'architecture de serveur de stockage Amazon EBS spécialement conçue pour offrir les plus hauts niveaux de performances avec une latence inférieure à la milliseconde pour les stockage en bloc à l'échelle infonuagique. Pour ce faire, Block Express utilise des datagrammes fiables évolutifs (SRD), un protocole réseau haute performance à faible latence, pour communiquer avec les instances EC2 basées sur Nitro System. Il s'agit de la même interface réseau hautes performances et à faible latence que celle utilisée pour la communication inter-instance dans Elastic Fabric Adapter (EFA) pour les charges de travail de calcul haute performance (HPC) et le Machine Learning (ML). En outre, Block Express offre des blocs de construction logiciels et matériels modulaires qui peuvent être assemblés de nombreuses façons différentes, ce qui nous donne la souplesse nécessaire pour concevoir et fournir des performances améliorées et de nouvelles fonctionnalités plus rapidement.

io2 Block Express est adapté aux charges de travail nécessitant une haute capacité et des performances élevées qui bénéficient d'une latence plus faible, d'un nombre plus élevé d'IOPS, d'un débit plus élevé ou d'une plus grande capacité dans un seul volume. Ces charges de travail comprennent les bases de données relationnelles et NoSQL telles que SAP HANA, Oracle, MS SQL, PostgreSQL, MySQL, MongoDB, Cassandra, et les charges de travail stratégiques opérationnelles telles que SAP Business Suite, NetWeaver, Oracle eBusiness, PeopleSoft, Siebel, et les applications ERP telles que Infor LN et Infor M3.

Si un volume io2 est associé à ces instances Amazon EC2, il s'exécute sur Block Express, qui offre une latence inférieure à la milliseconde et la capacité de générer jusqu'à 256 000 IOPS et un débit de 4 000 Mo/s, et jusqu'à 64 Tio pour un seul volume. Les volumes io2 attachés à toutes les autres instances ne s'exécutent pas sur Block Express et offrent une latence en millisecondes à un chiffre et la capacité de gérer jusqu'à 64 000 IOPS et 1 Go/s de débit et jusqu'à 16 Tio pour un seul volume.
 

Cette fonction peut être utilisée à l'aide des API suivantes, qui peuvent être appelées à l'aide d'AWS CLI ou d'AWS SDK.

• List Snapshot Blocks : l'opération d'API ListSnapshotBlocks renvoie les index de blocs et les jetons de blocs pour les blocs dans l'instantané spécifié.
• List Changed Blocks : l'opération d'API ListChangedBlocks renvoie les index de blocs et les jetons de blocs pour les blocs qui diffèrent entre deux instantanés spécifiés de même volume/lignée d'instantané.
• Get Snapshot Blocks : l'opération d'API GetSnapshotBlock renvoie les données dans un bloc pour l'ID d'instantané, l'index de bloc et le jeton de bloc spécifiés.
• Start Snapshot : l'opération StartSnapshot lance un instantané, soit un instantané incrémentiel, soit un nouvel instantané. L'instantané démarré reste en attente jusqu'à sa terminaison par l'action CompleteSnapshot.
• Put Snapshot Block : l'opération PutSnapshot ajoute des données sous la forme de blocs individuels à un instantané démarré et en attente. Vous devez spécifier un total de contrôle SHA256 codé en Base64 pour le bloc de données transmises. Le service valide le total de contrôle après la fin de la transmission des données. La requête échoue lorsque le total de contrôle calculé par le service ne correspond pas à la valeur que vous avez spécifiée.
• Complete Snapshot : l'opération CompleteSnapshot termine un instantané démarré qui est en attente. L'instantané passe alors à l'état terminé.

Pour en savoir plus, reportez-vous à la documentation technique.

Les API GetSnapshotBlock et PutSnapshotBlock prennent en charge une taille de blocs de 512 Kio.

Non, les instantanés sont uniquement disponibles via l'API Amazon EC2.

Non, les instantanés peuvent être pris en temps réel alors que le volume est attaché et en utilisation. Toutefois, les instantanés ne capturent que les données qui ont été écrites sur votre volume Amazon EBS, toute donnée ayant été cachée localement par votre application ou votre système d'exploitation pouvant être exclue. Pour obtenir des instantanés cohérents sur les volumes associés à une instance, nous recommandons de dissocier correctement le volume, d'exécuter la commande de génération d'instantanés, puis de réassocier le volume. Pour les volumes Amazon EBS qui font office de périphériques racine, nous recommandons d'éteindre la machine pour effectuer un instantané précis.

La création d'un instantané EBS de l'intégralité d'un volume de 16 To est pensée pour ne pas durer plus longtemps que celle de l'intégralité d'un volume de 1 To. Cependant, le temps réel nécessaire à la création d'un instantané dépend de différents facteurs, notamment de la quantité de données modifiées depuis le dernier instantané du volume EBS.

A chaque instantané est attribué un identifiant unique et les clients peuvent créer des volumes sur la base d'un des instantanés existants.

Vous trouverez les instantanés (snapshots) qui ont été partagés avec vous en sélectionnant Private Snapshots dans la liste figurant sous la section Snapshots dans AWS Management Console. Cette section répertorie à la fois les instantanés que vous possédez et ceux qui ont été partagés avec vous.

Vous trouverez les instantanés (snapshots) qui ont été partagés globalement en sélectionnant Public Snapshots dans la liste figurant sous la section Snapshots dans AWS Management Console. Vous pouvez également restreindre l'accès public aux instantanés d'un compte en activant l'option Bloquer l'accès public aux instantanés EBS.

Pour trouver des ensembles de données publics stockés en tant qu'instantanés Amazon, vous pouvez utiliser AWS Management Console. Connectez-vous à la console, sélectionnez le service Amazon EC2, sélectionnez les instantanés, puis filtrez sur les instantanés publics. Toutes les informations sur les ensembles de données publics sont disponibles dans notre centre de ressources Ensembles de données publics AWS.

Vous devez activer FSR sur les instantanés si vous êtes préoccupé par la latence de l'accès aux données lorsque vous restaurez les données d'un instantané sur un volume et que vous souhaitez éviter les pertes de performances lors de l'initialisation. FSR vise à vous aider dans les cas d'utilisation tels que l'infrastructure de bureau virtuel (VDI), la sauvegarde et la restauration, les copies de volume test/dev et le démarrage à partir d'AMI personnalisées. En activant FSR sur votre instantané, vous pouvez améliorer et prévoir les performances chaque fois que vous devez restaurer des données à partir de cet instantané.

Non. Les instantanés FSR améliorent la restauration des données de sauvegarde de votre instantané sur vos volumes. Les instantanés FSR n'accélèrent pas le temps de création d'un instantané.

Pour utiliser cette fonctionnalité, appelez la nouvelle API enable-fast-snapshot-restores sur un instantané situé dans la zone de disponibilité (AZ) dans laquelle les volumes initialisés doivent être restaurés.

L'instantané FSR peut se trouver dans l'un des états suivants : enabling (activation), optimizing (optimisation), enabled (activé), disabling (désactivation), disabled (désactivé). Les transitions d'état sont publiées sous forme d'événements CloudWatch et l'état FSR peut être vérifié via l'API describe-fast-snapshot-restores.

L'activation de FSR sur un instantané ne modifie aucune des interactions d'API d'instantané existantes, et les flux de travail existants n'ont pas besoin de changer. FSR peut être activé ou désactivé uniquement sur les instantanés appartenant à un compte. FSR ne peut pas être appliqué à des instantanés partagés. Vous pouvez afficher la liste de vos instantanés FSR via l'API ou la console.

Les volumes créés à partir d'un instantané FSR sont entièrement initialisés. Toutefois, le nombre de volumes pouvant être créés avec des performances maximales immédiates est limité. Ces limites sont exprimées sous la forme d'un compartiment de crédit associé à un instantané FSR dans une zone de disponibilité donnée. Informations importantes à connaître concernant les crédits :

1. Une opération de création de volume unique consomme un seul crédit.
2. Le nombre de crédits est fonction de la taille de l'instantané compatible FSR.
3. Les crédits sont rechargés au fil du temps.
4. La taille maximale d'un compartiment de crédit est 10.

Pour estimer la taille de votre compartiment de crédit et votre taux de remplissage, divisez 1 024 par la taille de votre instantané. Par exemple, un instantané FSR de 100 Gio aura un solde maximum de 10 crédits avec un taux de remplissage de 10 crédits par heure. Un instantané de 4 Tio aura un solde maximum de 1 avec un taux de remplissage de 1 crédit toutes les 4 heures.

Il est important de noter que la taille du compartiment de crédit est fonction de la taille de l'instantané FSR, et non pas de la taille des volumes créés. Par exemple, il est possible de créer jusqu'à dix volumes de 1 Tio simultanément à partir d'un instantané de 100 Gio.

Enfin, chaque zone de disponibilité dans laquelle l'instantané FSR dispose de son propre compartiment de crédit, indépendamment des autres zones de disponibilité.

La taille du compartiment de crédit de création représente le nombre maximal, et le solde du compartiment de crédit représente le nombre de créations disponibles. Une fois rempli, vous pouvez créer simultanément jusqu'à 10 volumes initialisés à partir d'un instantané FSR. La taille maximale du compartiment de crédit et son solde sont publiés en tant que métriques CloudWatch. Les créations de volumes au-delà de la limite continuent comme si FSR n'était pas activé sur l'instantané.

Lors de l'utilisation de FSR, un nouvel attribut spécifique à EBS (fastRestored) est ajouté dans l'API DescribeVolumes pour indiquer le statut au moment de la création. Lorsqu'un volume est créé à partir d'un instantané FSR sans suffisamment de crédits de création de volume, la création aboutit, mais le volume n'est pas initialisé.

Lorsque vous supprimez un instantané, la FSR de votre instantané est automatiquement désactivée et la facturation FSR de l'instantané s'arrête.

Oui, vous pouvez activer FSR pour les clichés publics, ainsi que pour tous les instantanés privés partagés avec votre compte. Pour activer FSR pour les instantanés partagés, vous pouvez utiliser le même ensemble d'appels d'API que celui que vous utilisez pour activer FSR sur les instantanés que vous possédez.

Lorsque vous activez FSR sur votre instantané partagé, vous êtes facturé aux tarifs FSR standard (voir les pages de tarification). Notez que seul votre compte est facturé pour la FSR de l'instantané partagé. Le propriétaire de l'instantané n'est pas facturé lorsque vous activez FSR sur l'instantané partagé.

Lorsque le propriétaire de votre instantané partagé supprime l'instantané ou arrête de le partager avec vous en révoquant vos autorisations de créer des volumes à partir de cet instantané, la FSR de votre instantané partagé est automatiquement désactivée, et la facturation FSR pour l'instantané est interrompue.

Vous pouvez utiliser Amazon Data Lifecycle Manager et AWS Systems Manager (SSM) pour coordonner le blocage, le vidage des E/S et le déblocage de votre application ou de votre base de données, ainsi que l'initialisation des instantanés EBS. Vous devrez fournir des commandes pour effectuer les actions spécifiques à votre application ou à votre base de données. Vous pouvez également consulter notre documentation pour le code fourni par AWS et les documents SSM pour les applications MySQL, PostgreSQL et Windows.

Amazon EBS Encryption offre un chiffrement aisé des volumes de données, des volumes de démarrage et des instantanés (snapshots) EBS, sans qu'il soit nécessaire de créer ni de gérer d'infrastructure de gestion sécurisée des clés. Le chiffrement EBS assure la sécurité des données au repos en chiffrant vos données à l'aide de clés gérées par Amazon ou de clés que vous créez et gérez avec AWS Key Management Service (KMS). Le chiffrement est effectué sur les serveurs hébergeant des instances EC2, assurant le chiffrement des données lorsqu'elles se déplacent entre les instances EC2 et le stockage EBS. Pour plus de détails, reportez-vous à la section Amazon EBS Encryption dans le manuel Guide de l'utilisateur Amazon EC2.

AWS KMS est un service géré qui facilite la création et le contrôle des clés de chiffrement utilisées pour crypter vos données. AWS Key Management Service est intégré à d'autres services AWS tels qu'Amazon EBS, Amazon S3 et Amazon Redshift, pour vous permettre de crypter facilement vos données à l'aide des clés de chiffrement que vous gérez. AWS Key Management Service est également intégré à AWS CloudTrail pour vous fournir des journaux contenant des informations sur toutes les utilisations de vos clés, dans le but de vous aider à répondre à vos besoins en matière de réglementation et de conformité. Pour en savoir plus sur KMS, consultez la page de présentation d'AWS Key Management Service.

Amazon EBS Encryption vous permet de répondre aux exigences de conformité en matière de sécurité et de chiffrement pour le chiffrement des données au repos dans le cloud. Associer le chiffrement aux stratégies de contrôle d'accès IAM existantes améliore la stratégie de défense approfondie de votre entreprise.

Amazon EBS Encryption se charge de la gestion des clés pour vous. Chaque volume créé obtient une clé AES unique de 256 bits. Les volumes créés à partir des instantanés chiffrés partagent la clé. Ces clés sont protégées par votre propre infrastructure de gestion des clés, qui met en œuvre d'importants contrôles de sécurité logique et physique, afin d'empêcher tout accès non autorisé. Vos données et clés associées sont chiffrées à l'aide de l'algorithme AES-256 standard.

Oui.

Oui. C'est possible en utilisant les clés principales client (CMK) qui sont soit gérées par AWS, soit par le client. Vous pouvez spécifier les détails et le chiffrement du volume par un appel d'API RunInstances avec le paramètre BlockDeviceMapping ou par l'assistant de lancement dans la console EC2.

Oui. Vous pouvez créer un volume de données chiffré avec un chiffrement par défaut ou avec un chiffrement CMK personnalisé au moment du lancement de l'instance. Vous pouvez spécifier les détails et le chiffrement du volume par un objet BlockDeviceMapping dans un appel RunInstances ou par l'assistant de lancement dans la console EC2.

Oui. Consultez la documentation technique pour en savoir plus.

Oui. Vous pouvez partager des instantanés et des AMI chiffrés à l'aide d'une clé principale gérée par le client (CMK) avec d'autres comptes AWS. Consultez la documentation technique pour en savoir plus.

Oui, vous pouvez activer le chiffrement EBS par défaut avec un seul paramètre par région. Cela garantit que tous les nouveaux volumes sont toujours chiffrés. Pour plus d'informations, consultez la documentation technique. 

Oui, vous serez facturé pour les E/S mises en services lorsque le volume IOPS dimensionné est déconnecté d'une instance. Lorsqu'un volume est détaché, nous vous conseillons de créer un instantané et de supprimer le volume, afin de réduire vos frais. Pour en savoir plus, consultez l'outil de vérification des volumes Amazon EBS sous-utilisés dans Trusted Advisor. Cette option vérifie les configurations de vos volumes Amazon Elastic Block Store (Amazon EBS) et vous avertit lorsque des volumes semblent être sous-utilisés.

Sauf indication contraire, nos prix n'incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. En savoir plus.

Non. Le Multi-Attach peut être activé sur un volume IOPS provisionnés d'EBS et il y aura des frais pour le stockage (GB-Mo) et l'IOPS (IOPS-Mo) provisionnés.

Non.

Le comportement deleteOnTermination du volume est tributaire de la configuration de la dernière instance attachée résiliée. Vous pouvez garantir un comportement prévisible en matière de suppression après résiliation. Pour ce faire, activez ou désactivez « deleteOnTermination » pour toutes les instances auxquelles le volume est attaché.

Si vous souhaitez que le volume soit supprimé après la résiliation des instances attachées, activez « deleteOnTermination » pour toutes les instances auxquelles le volume est attaché. Si vous souhaitez conserver le volume après la résiliation des instances attachées, désactivez « deleteOnTermination » pour toutes les instances jointes. Pour plus d'informations, consultez la documentation technique pour Multi-Attach.

Votre application peut utiliser Multi-Attach si elle est construite sur Windows Server Failover Cluster, si elle coordonne l'accès sécurisé au stockage partagé à l'aide de réservations NVMe ou si elle coordonne l'accès sécurisé au niveau de l'application.