Questions fréquentes (FAQ) sur Amazon EBS

Questions d'ordre général

Oui, veuillez consulter la page relative aux FAQ sur EC2 pour en savoir plus.

Contrairement aux données enregistrées sur un stockage d'instance local (qui persistent uniquement tant que cette instance est active), les données stockées sur un volume Amazon EBS persistent indépendamment de la durée de vie de l'instance. Par conséquent, nous vous recommandons d'utiliser le stockage d'instances local uniquement pour les données temporaires. Pour les données nécessitant un niveau de durabilité supérieur, nous vous recommandons d'utiliser des volumes Amazon EBS ou de sauvegarder les données sur Amazon S3. Si vous utilisez un volume Amazon EBS en tant que partition racine, définissez l'indicateur « Delete on termination » sur « No » pour que votre volume Amazon EBS persiste indépendamment de la durée de vie de l'instance.

Amazon EBS propose six types de volumes : SSD IOPS provisionnés (io2 Block Express et io1), SSD polyvalent (gp3 et gp2), disque dur à débit optimisé (st1) et disque dur pour les données peu utilisées (sc1). Ils se distinguent par leurs caractéristiques de performance et leurs tarifs, ce qui vous permet d'adapter vos performances de stockage et vos coûts en fonction des besoins de vos applications. La latence moyenne entre les instances EC2 et EBS est de quelques millisecondes à un chiffre, tandis que la latence moyenne des volumes io2 Block Express est inférieure à la milliseconde. Pour en savoir plus sur les performances, reportez-vous à la page de présentation d'EBS. Pour plus d'informations sur les recommandations de performances Amazon EBS, consultez Augmentation des performances EBS.

Amazon EBS comprend deux grandes catégories de stockage : le stockage SSD pour les charges de travail transactionnelles (les performances dépendent principalement de l'IOPS, de la latence et de la durabilité), et le stockage sur disque HDD pour les charges de travail à haut débit (les performances dépendent principalement du débit, mesuré en Mo/s). Les volumes SSD sont conçus pour les applications de travail de base de données transactionnelles à hauts volumes d'IOPS, les volumes de démarrage et les applications nécessitant un volume élevé d'IOPS. Les volumes SSD comprennent les volumes SSD IOPS provisionnés (io2 Block Express et io1) et les volumes SSD polyvalents (gp3 et gp2). Io2 Block Express des volumes SSD IOPS provisionnés est conçu pour offrir une durabilité 100 fois supérieure, soit 99,999 %, ce qui en fait la solution idéale pour les applications critiques nécessitant une disponibilité accrue. Gp3 est la dernière génération de volumes SSD à usage général qui offre le juste équilibre entre prix et performances pour la plupart des applications ne nécessitant pas les meilleures performances IOPS ou une durabilité de 99,999 %. Les volumes HDD sont conçus pour les charges de travail à débit élevé et Big Data, les grandes tailles d'E/S et les modèles d'E/S séquentiels. Les volumes HDD comprennent les volumes Throughput Optimized HDD (st1) et Cold HDD (sc1).

La durabilité élevée des volumes, les instantanés et la réplication des volumes dans les zones de disponibilité protègent contre différents types de pannes, et les clients peuvent choisir d'utiliser une, deux ou toutes ces approches en fonction de leurs besoins en matière de durabilité des données. Une durabilité de volume plus élevée réduit la probabilité de perdre la copie principale de vos données Les instantanés protègent contre l'éventualité peu probable d'un volume défectueux. La réplication des volumes dans les zones de disponibilité protège contre une défaillance de zone de disponibilité et permet également une récupération plus rapide en cas de panne.

Les volumes Amazon EBS sont hautement disponibles et fiables. Les données d'un volume Amazon EBS sont répliquées sans coût supplémentaire sur plusieurs serveurs au sein d'une zone de disponibilité, afin de prévenir toute perte des données due à la défaillance d'un seul composant. Selon le degré de haute disponibilité (HA) que votre application exige, nous recommandons les directives suivantes pour atteindre un degré de haute disponibilité solide :
1) Concevoir le système pour qu'il ne présente pas de point unique de défaillance. Pour plus de détails, voir Haute disponibilité et mise à l'échelle sur AWS.
2) Utiliser des mécanismes automatisés de surveillance, de détection des défaillances et de basculement. Voir Surveillance du statut de vos volumes EBS et Surveillance des volumes EBS à l'aide de CloudWatch pour plus de détails sur la surveillance des performances de vos volumes EBS.
3) Préparer des procédures opérationnelles pour les mécanismes manuels afin de réagir aux défaillances, de les atténuer et d'assurer la récupération après de telles défaillances. Cela inclut détacher les volumes indisponibles et attacher un volume de récupération de sauvegarde en cas de panne. Pour plus de détails, voir la documentation sur Remplacement d'un volume EBS.

Modifier la configuration d'un volume est une tâche relativement simple. La fonctionnalité Elastic Volumes vous permet d'augmenter les capacités, d'ajuster les performances ou de modifier le type de votre volume à l'aide d'un simple appel de l'interface de ligne de commande, d'un appel de l'API ou en quelques clics via la console. Pour en savoir plus sur Elastic Volumes, consultez la documentation Elastic Volumes.

Les volumes standard EBS ont été renommés en volumes magnétiques EBS. Les volumes existants restent identiques, et les volumes magnétiques EBS ne présentent pas de différence majeure avec les volumes standard EBS. Le nom de cette offre a été modifié pour éviter toute confusion avec notre nouveau type de volume SSD à usage général (gp2) qui représente le type de volume que nous recommandons par défaut.

Les volumes SSD IOPS provisionnés (io2 Block Express et io1) sont disponibles pour tous les types d'instances EC2. Utilisez des instances EC2 optimisées pour EBS pour fournir des IOPS constants et prévisibles sur les volumes io2 Block Express et io1. Les instances optimisées pour EBS fournissent un débit dédié entre Amazon EC2 et Amazon EBS, avec des options variant entre 62,5 Mo/s et 12 500 Mo/s, selon le type d'instance utilisé. Pour atteindre la limite de 256 000 IOPS et un débit de 4 000 Mo/s, vous devez utiliser des volumes io2 Block Express attachés à des instances basées sur le système Nitro.

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.

Performances

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.
 

Instantanés

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 cours d'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.

Chiffrement

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

Facturation et mesures

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.

Multi-Attach

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.