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.
Vous pouvez activer le support d’hibernation pour une instance à la demande ou une instance ponctuelle lorsque vous la lancez. Vous ne pouvez pas activer la mise en veille prolongée sur une instance existante, qu’elle soit en cours d’exécution ou arrêtée. Pour de plus amples informations, veuillez consulter Activer la mise en veille prolongée de l’instance.
Exigences pour la mise en veille prolongée d’une instance
Régions AWS
Vous pouvez utiliser l'hibernation avec toutes Régions AWS les instances.
AMIs
Vous devez utiliser une AMI HVM prenant en charge la mise en veille prolongée. Les options suivantes AMIs prennent en charge l'hibernation :
AMIs pour les types d'instances Intel et AMD
-
AL2AMI 023 publiée le 2023.09.20 ou version ultérieure ¹
-
AMI Amazon Linux 2 publiée le 29 août 2019 ou version ultérieure
-
AMI Amazon Linux de mars 2018 publiée le 16 novembre 2018 ou version ultérieure
-
AMI CentOS version 8* ² (Configuration supplémentaire obligatoire)
-
AMI Fedora version 34 ou ultérieure ² (Configuration supplémentaire obligatoire)
-
AMI Red Hat Enterprise Linux (RHEL) 9 ² (Configuration supplémentaire obligatoire)
-
AMI Red Hat Enterprise Linux (RHEL) 8 ² (Configuration supplémentaire obligatoire)
-
AMI Ubuntu 22.04.2 LTS (Jammy Jellyfish) publiée avec le numéro de série 20230303 ou une version ultérieure ³
-
AMI Ubuntu 20.04 LTS (Focal Fossa) publiée avec le numéro de série 20210820 ou une version ultérieure ³
-
AMI Ubuntu 18.04 LTS (Bionic Beaver) publiée avec le numéro de série 20190722.1 ou une version ultérieure ³ ⁵
-
AMI Ubuntu 16.04 LTS (Xenial Xerus) ³ ⁴ ⁵ (Configuration supplémentaire obligatoire)
AMIs pour les types d'instances Graviton
-
AL2AMI 023 (Arm 64 bits) publiée le 2024.07.01 ou version ultérieure ¹
-
AMI Amazon Linux 2 (Arm 64 bits) publiée le 20 juin 2024 ou une version ultérieure
-
Ubuntu 22.04.2 LTS (Arm 64 bits) (Jammy Jellyfish) AMI publiée avec le numéro de série 20240701 ou une version ultérieure ³
-
Ubuntu 20.04 LTS (Arm 64 bits) (Focal Fossa) AMI publiée avec le numéro de série 20240701 ou une version ultérieure ³
¹ Pour une AMI minimale AL2 023, une configuration supplémentaire est requise.
² Pour CentOS, Fedora et Red Hat Enterprise Linux, la mise en veille prolongée n’est prise en charge que sur les instances Nitro.
³ Nous recommandons de désactiver KASLR sur les instances exécutant Ubuntu 22.04.2 LTS (Jammy Jellyfish), Ubuntu 20.04 LTS (Focal Fossa), Ubuntu 18.04 LTS (Bionic Beaver) et Ubuntu 16.04 LTS (Xenial Xerus). Pour de plus amples informations, veuillez consulter Désactiver KASLR sur une instance (Ubuntu uniquement).
⁴ Pour l’AMI Ubuntu 16.04 LTS (Xenial Xerus), la mise en veille prolongée n’est pas prise en charge sur les types d’instance t3.nano
. Aucun correctif ne sera disponible, car Ubuntu (Xenial Xerus) a mis fin au support en avril 2021. Si vous voulez utiliser les types d’instance t3.nano
, nous vous recommandons une mise à niveau vers l’AMI Ubuntu 22.04.2 LTS (Jammy Jellyfish), Ubuntu 20.04 LTS (Focal Fossa) ou l’AMI Ubuntu 18.04 LTS (Bionic Beaver).
⁵ La prise en charge d’Ubuntu 18.04 LTS (Bionic Beaver) et Ubuntu 16.04 LTS (Xenial Xerus) est arrivée à son terme.
Pour configurer votre propre AMI afin de prendre en charge la mise en veille prolongée, consultez Configurer une AMI Linux pour qu'elle prenne en charge la mise en veille prolongée.
La prise en charge d’autres versions d’Ubuntu et d’autres systèmes d’exploitation sera bientôt disponible.
-
AMI Windows Server 2022 publiée le 13/09/2023 ou version ultérieure
-
AMI Windows Server 2019 publiée le 11 septembre 2019 ou version ultérieure.
-
AMI Windows Server 2016 publiée le 11 septembre 2019 ou version ultérieure.
-
AMI Windows Server 2012 R2 publiée le 11 septembre 2019 ou version ultérieure.
-
AMI Windows Server 2012 publiée le 11 septembre 2019 ou version ultérieure.
Familles d’instances
Vous devez utiliser une famille d’instances qui prend en charge l’hibernation.
-
Usage général : M3, M4, M5, M5a, M5ad, M5d, M6a, M6g, M6gd, M6i, M6id, M6idn, M6in, M7a, M7g, M7GD, M7i, M7i-Flex, M8g, T2, T3, T3a, T4g
-
Optimisé pour le calcul : C3, C4, C5, C5d, C6a, C6g, C6gd, C6gn, C6i, C6id, C6in, C7a, C7g, C7gd, C7gn, C7i, C7i-Flex, C8g
-
Mémoire optimisée : R3, R4, R5, R5a, R5ad, R5d, R6a, R6g, R6gd, R6idn, R6in, R7a, R7g, R7gd, R7i, R7iz, R8g, X2gD
-
Stockage optimisé : i3, i3EN, i4G, i7IE, i8G, iM4GN, IS4Gen
Instances Nitro – Les instances en métal nu ne sont pas prises en charge.
Pour consulter les types d’instance disponibles qui prennent en charge la mise en veille prolongée dans une région spécifique
Les types d’instance disponibles varient selon la région. Pour voir les types d'instances disponibles qui prennent en charge l'hibernation dans une région, utilisez la describe-instance-types--region
paramètre. Incluez le paramètre --filters
pour étendre les résultats aux types d’instance qui prennent en charge la mise en veille prolongée et le paramètre --query
pour étendre la sortie à la valeur de InstanceType
.
aws ec2 describe-instance-types --filters Name=hibernation-supported,Values=true --query "InstanceTypes[*].[InstanceType]" --output text | sort
Exemple de sortie
c3.2xlarge
c3.4xlarge
c3.8xlarge
c3.large
c3.xlarge
c4.2xlarge
c4.4xlarge
c4.8xlarge
...
Taille de mémoire RAM d’instance
Instances Linux – Doit être inférieure à 150 Go.
Instances Windows – Peut avoir une taille de 16 Go au maximum. Pour la mise en veille prolongée d'une instance Windows T3 ou T3a, nous recommandons au moins 1 Go de RAM.
Type de volume racine
Le volume racine doit être un volume EBS, et non un volume de stockage d’instance.
Taille du volume racine
Le volume racine doit être suffisamment grand pour stocker le contenu de la mémoire vive et s’adapter à l’utilisation prévue, par exemple le système d’exploitation ou les applications. Si vous activez la mise en veille prolongée, un espace est alloué sur le volume racine au lancement pour stocker la mémoire RAM.
Chiffrement du volume racine
Le volume racine doit être chiffré pour assurer la protection du contenu sensible qui se trouve en mémoire au moment de la mise en veille prolongée. Lorsque les données de la mémoire RAM sont transférées vers le volume racine EBS, celui-ci est toujours chiffré. Le chiffrement du volume racine est appliqué au lancement de l’instance.
L’une des trois options suivantes permet de s’assurer que le volume racine est une volume EBS chiffré :
-
Chiffrement EBS par défaut — Vous pouvez activer le chiffrement EBS par défaut pour vous assurer que tous les nouveaux volumes EBS créés dans votre AWS compte sont chiffrés. De cette façon, vous pouvez activer l’hibernation pour vos instances sans spécifier d’intention de chiffrement au moment du lancement de l’instance. Pour plus d’informations, consultez la section Activer le chiffrement par défaut.
-
Chiffrement « en une seule étape » EBS : vous pouvez lancer des EC2 instances cryptées basées sur EBS à partir d'une AMI non chiffrée et activer l'hibernation en même temps. Pour de plus amples informations, veuillez consulter Utilisez le chiffrement avec EBS Backed AMIs.
-
Encrypted AMI (AMI chiffrée) : vous pouvez activer le chiffrement EBS en utilisant une AMI chiffrée pour lancer votre instance. Si votre AMI ne dispose d’aucun volume racine chiffré, vous pouvez le copier sur le nouvel AMI et demander son chiffrement. Pour plus d’informations, consultez Chiffrement d’une image non chiffrée pendant la copie et Copier une AMI.
Type de volume EBS
Les volumes EBS doivent utiliser l’un des types de volumes EBS suivants :
-
SSD à usage général (
gp2
etgp3
) -
SSD à IOPS provisionnés (
io1
etio2
)
Si vous choisissez un type de volume SSD à IOPS provisionnés, vous devez provisionner le volume EBS avec les IOPS appropriées pour obtenir des performances optimales pour la mise en veille prolongée,. Pour plus d’informations, consultez Types de volumes Amazon EBS dans le Guide de l’utilisateur Amazon EC2.
Demandes d’instance Spot
Les exigences suivantes s’appliquent aux instances Spot :
-
Le type de la demande d’instance Spot doit être
persistent
. -
Vous ne pouvez pas spécifier de groupe de lancement dans la demande d’instance Spot.