Création d’une classe de nœuds Création d’une entrée d’accès pour la classe de nœuds Spécification de la classe de nœuds Considérations Sous-réseaux et groupes de sécurité distincts pour les pods Mode IP secondaire pour les pods Désactivez la sortie IPv4 à partir des pods IPv6 dans les clusters IPv6.

Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Création d’une classe de nœuds pour Amazon EKS

Les classes de nœuds Amazon EKS sont des modèles qui offrent un contrôle précis de la configuration de vos nœuds gérés par le mode automatique EKS. Une classe de nœuds définit les paramètres d’infrastructure appliqués à des groupes de nœuds de votre cluster EKS, notamment la configuration réseau, les paramètres de stockage et le balisage des ressources. Cette rubrique explique comment créer et configurer une classe de nœuds pour répondre à vos exigences opérationnelles spécifiques.

Lorsque vous devez personnaliser la façon dont le mode automatique EKS provisionne et configure les instances EC2 au-delà des paramètres par défaut, la création d’une classe de nœuds vous permet de contrôler précisément des paramètres d’infrastructure essentiels. Par exemple, vous pouvez spécifier le placement dans des sous-réseaux privés pour renforcer la sécurité, configurer un stockage éphémère des instances pour les charges de travail sensibles aux performances ou appliquer des étiquettes personnalisées pour l’allocation des coûts.

Création d’une classe de nœuds

Pour créer une NodeClass, procédez comme suit :

Créez un fichier YAML (par exemple nodeclass.yaml) contenant la configuration de votre classe de nœuds
Appliquez la configuration à votre cluster à l’aide de kubectl
Référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter Création d’un pool de nœuds pour le mode automatique EKS.

Vous devez avoir installé et configuré kubectl. Pour de plus amples informations, veuillez consulter Configuration pour utiliser Amazon EKS.

Exemple de classe de nœuds simple

Voici un exemple de classe de nœuds :


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
  ephemeralStorage:
    size: "160Gi"

Cela NodeClass augmente la quantité de stockage éphémère sur le nœud.

Appliquez cette configuration en utilisant :


kubectl apply -f nodeclass.yaml

Ensuite, référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter Création d’un pool de nœuds pour le mode automatique EKS.

Création d’une entrée d’accès pour la classe de nœuds

Si vous créez une classe de nœuds personnalisée, vous devez créer une entrée d’accès EKS pour permettre aux nœuds de rejoindre le cluster. EKS crée automatiquement les entrées d’accès lorsque vous utilisez la classe de nœuds intégrée et les groupes de nœuds intégrés.

Pour plus d’informations sur le fonctionnement des entrées d’accès, consultez Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS.

Lorsque vous créez des entrées d’accès pour les classes de nœuds du mode automatique EKS, vous devez utiliser le type d’entrée d’accès EC2.

Création d’une entrée d’accès à l’aide de la CLI

Pour créer une entrée d’accès pour les nœuds EC2 et associer la politique de nœud automatique EKS :

Mettez à jour les commandes CLI suivantes avec le nom de votre cluster et l’ARN du rôle de nœud. L’ARN du rôle de nœud est spécifié dans le fichier YAML de la classe de nœuds.


# Create the access entry for EC2 nodes
aws eks create-access-entry \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --type EC2

# Associate the auto node policy
aws eks associate-access-policy \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
  --access-scope type=cluster

Créez une entrée d'accès avec CloudFormation

Pour créer une entrée d’accès pour les nœuds EC2 et associer la politique de nœud automatique EKS :

Mettez à jour ce qui suit CloudFormation avec le nom de votre cluster et l'ARN du rôle de nœud. L’ARN du rôle de nœud est spécifié dans le fichier YAML de la classe de nœuds.


EKSAutoNodeRoleAccessEntry:
  Type: AWS::EKS::AccessEntry
  Properties:
    ClusterName: <cluster-name>
    PrincipalArn: <node-role-arn>
    Type: "EC2"
    AccessPolicies:
      - AccessScope:
          Type: cluster
        PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

Pour plus d'informations sur le déploiement CloudFormation de stacks, voir Getting started with CloudFormation

Spécification de la classe de nœuds


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields

  # role and instanceProfile are mutually exclusive fields.
  role: MyNodeRole  # IAM role for EC2 instances
  # instanceProfile: eks-MyNodeInstanceProfile  # IAM instance-profile for EC2 instances

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0123456789abcdef0"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
    # Alternative approaches:
    # - id: "sg-0123456789abcdef0"
    # - name: "eks-cluster-security-group"

  # Optional: Pod subnet selector for advanced networking
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0987654321fedcba0"
  # must include Pod security group selector also
  podSecurityGroupSelectorTerms:
    - tags:
        Name: "eks-pod-sg"
    # Alternative using direct security group ID
    # - id: "sg-0123456789abcdef0"

  # Optional: Selects on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        Name: "targeted-odcr"
      # Optional owning account ID filter
      owner: "012345678901"

  # Optional fields
  snatPolicy: Random  # or Disabled

  networkPolicy: DefaultAllow  # or DefaultDeny
  networkPolicyEventLogs: Disabled  # or Enabled

  ephemeralStorage:
    size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
    iops: 3000      # Range: 3000-16000
    throughput: 125 # Range: 125-1000
    # Optional KMS key for encryption
    kmsKeyID: "arn:aws: kms:region:account:key/key-id"
    # Accepted formats:
    # KMS Key ID
    # KMS Key ARN
    # Key Alias Name
    # Key Alias ARN

  advancedNetworking:
    # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
    # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
    associatePublicIPAddress: false

    # Optional: Forward proxy, commonly requires certificateBundles as well
    # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
    httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
    #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
    noProxy: #Max 50 entries
        - localhost #Max 255 characters each
        - 127.0.0.1
        #- ::1 # IPv6 localhost
        #- 0:0:0:0:0:0:0:1 # IPv6 localhost
        - 169.254.169.254 # EC2 Instance Metadata Service
        #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
        # Domains to exclude, put all VPC endpoints here
        - .internal
        - .eks.amazonaws.com
    # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
    ipv4PrefixSize: Auto # or "32"

    # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
    enableV4Egress: false

  advancedSecurity:
    # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
    fips: false

  # Optional: Custom certificate bundles.
  certificateBundles:
    - name: "custom-cert"
      data: "base64-encoded-cert-data"

  # Optional: EC2 Placement Group
  placementGroupSelector:
    name: "targeted-pg"
    # Alternative use direct placement group ID
    # id: "pg-02465754522cda020"

  # Optional: Additional EC2 tags (with restrictions)
  tags:
    Environment: "production"
    Team: "platform"
    # Note: Cannot use restricted tags like:
    # - kubernetes.io/cluster/*
    # - karpenter.sh/provisioner-name
    # - karpenter.sh/nodepool
    # - karpenter.sh/nodeclaim
    # - karpenter.sh/managed-by
    # - eks.amazonaws.com/nodeclass

Considérations

Si vous souhaitez vérifier le volume de stockage local d’une instance, vous pouvez décrire le nœud pour voir la ressource de stockage éphémère.
Chiffrement du volume : EKS utilise la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l'instance et le read/write volume de données.
Remplacement du rôle IAM du nœud : si vous modifiez le rôle IAM du nœud associé à une NodeClass, vous devrez créer une nouvelle entrée d’accès. EKS crée automatiquement une entrée d’accès pour le rôle IAM du nœud lors de la création du cluster. Le rôle IAM du nœud nécessite la stratégie d’accès AmazonEKSAutoNodePolicy EKS. Pour de plus amples informations, veuillez consulter Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS.
Densité maximale de pods : EKS limite le nombre maximal de pods sur un nœud à 110. Cette limite s’applique après le calcul existant du nombre maximal de pods. Pour de plus amples informations, veuillez consulter Choix du type d’instance Amazon EC2 optimal pour les nœuds.
Balises : si vous souhaitez propager des balises de Kubernetes vers EC2, vous devez configurer des autorisations IAM supplémentaires. Pour de plus amples informations, veuillez consulter Informations sur les identités et l’accès dans le mode automatique EKS.
Classe de nœuds par défaut : ne nommez pas votre classe de nœuds personnalisée default. En effet, le mode automatique EKS inclut une NodeClass appelée default, provisionnée automatiquement lorsque vous activez au moins un NodePool intégré. Pour plus d’informations sur l’activation des NodePools intégrés, consultez Activer ou désactiver la fonction intégrée NodePools.
Comportement des subnetSelectorTerms avec plusieurs sous-réseaux : si plusieurs sous-réseaux correspondent aux conditions subnetSelectorTerms ou sont fournis par ID, le mode automatique EKS crée des nœuds répartis sur l’ensemble des sous-réseaux.
- Si les sous-réseaux se trouvent dans différentes zones de disponibilité (AZ), vous pouvez utiliser des fonctionnalités Kubernetes telles que les contraintes de propagation de la topologie des pods et le routage adapté à la topologie pour répartir les pods et le trafic entre les zones, respectivement.
- S’il existe plusieurs sous-réseaux dans la même zone de disponibilité qui correspondent aux subnetSelectorTerms, le mode automatique EKS crée des pods sur chaque nœud répartis dans ces sous-réseaux de cette même zone de disponibilité. Le mode automatique EKS crée également des interfaces réseau secondaires sur chaque nœud dans les autres sous-réseaux de la même zone de disponibilité. Il choisit en fonction du nombre d’adresses IP disponibles dans chaque sous-réseau, afin d’utiliser les sous-réseaux plus efficacement. Cependant, vous ne pouvez pas spécifier quel sous-réseau le mode automatique EKS utilise pour chaque pod ; si vous avez besoin que des pods s’exécutent dans des sous-réseaux spécifiques, utilisez Sous-réseaux et groupes de sécurité distincts pour les pods.
Restrictions relatives à la stratégie des groupes de placement : chaque stratégie de groupe de placement (cluster, partition, spread) comporte des limites spécifiques en ce qui concerne les types d'instances, les zones d'action et la capacité. Pour plus de détails, consultez la section Stratégies des groupes de placement dans le guide de l'utilisateur Amazon EC2.
Groupe de placement de spread — Limite de 7 instances — Un groupe de placement de spread au niveau du rack autorise un maximum de 7 instances en cours d'exécution par zone de disponibilité et par groupe. Cela crée les cas extrêmes suivants :
- Le remplacement par dérive est bloqué à pleine capacité : le mode automatique EKS lance un nœud de remplacement avant de mettre fin à l'ancien. Lorsqu'un spread PG possède 7 instances dans un AZ, le lancement de remplacement échoue et le nœud dérivé continue de fonctionner jusqu'à ce qu'un emplacement soit libéré.
- Toutes les AZ à pleine capacité — Si chaque AZ du spread PG atteint sa limite de 7 instances, aucun remplacement ne peut être planifié. Les nœuds dérivés ou candidats à la consolidation continuent de fonctionner indéfiniment.
- Aucune solution de secours en dehors du groupe de placement : le mode automatique d'EKS ne tente pas de lancer des instances de remplacement en dehors du groupe de placement.
- Solution : utilisez la politique WhenEmpty de consolidation (consolidationPolicy: WhenEmpty). Les nœuds ne sont supprimés qu'une fois que tous les pods n'appartenant pas à des démons sont épuisés, libérant ainsi un emplacement PG sans qu'il soit nécessaire de le lancer de remplacement au préalable. Notez que la dérive utilise toujours les options replace-then-delete, quelle que soit la politique de consolidation, de sorte que la dérive reste bloquée à pleine capacité.
Épinglage AZ du groupe de placement de clusters — Une fois que la première instance est lancée dans un groupe de placement de clusters, le PG est épinglé dans cet AZ. Si vous NodePool autorisez plusieurs AZ, les lancements parallèles risquent de s'accélérer lors de la mise à l'échelle initiale : l'un d'eux réussit et épingle l'AZ, les autres échouent en raison d'erreurs de capacité. Intégrez l'AZ à vos NodePool besoins pour éviter les défaillances transitoires.
Groupe de placement de partitions : les groupes de placement de partitions sont pris en charge sans aucune contrainte supplémentaire au-delà des limites standard EC2.
La consolidation peut déplacer des modules hors d'un groupe de placement : si un espace n'est soumis à aucune contrainte de planification de groupe de placement (telle qu'une activation nodeSelectoreks.amazonaws.com/placement-group-id), la consolidation peut le déplacer vers un nœud extérieur au PG. Les applications qui nécessitent l'appartenance à un groupe de placement doivent l'exprimer via des contraintes au niveau du pod.
Groupe de placement inexistant ou supprimé : si un NodeClass fait référence à un groupe de placement qui n'existe pas ou qui a été supprimé, aucune instance n'est lancée. Le format de l'identifiant du groupe de placement est validé lors de l'admission, mais son existence n'est vérifiée qu'au moment du lancement. Si un groupe de placement est supprimé alors que les nœuds sont en cours d'exécution, les nœuds existants sont marqués comme dérivés et restent actifs indéfiniment car les lancements de remplacement par dérive sont également bloqués.

Sous-réseaux et groupes de sécurité distincts pour les pods

Les podSecurityGroupSelectorTerms champs podSubnetSelectorTerms et permettent des configurations réseau avancées en permettant aux pods d'utiliser des sous-réseaux et des groupes de sécurité différents de ceux de leurs nœuds. Les deux champs doivent être spécifiés ensemble. Cette séparation offre un meilleur contrôle du routage du trafic réseau et des politiques de sécurité.

Note

Cette fonctionnalité est différente de la fonctionnalité Security Groups for Pods (SGPP) utilisée avec le CNI VPC d'AWS pour le calcul en mode automatique hors EKS. Le SGPP n'est pas pris en charge en mode automatique EKS. Utilisez plutôt podSecurityGroupSelectorTerms in NodeClass pour appliquer des groupes de sécurité distincts au trafic du pod. Les groupes de sécurité s'appliquent au NodeClass niveau, ce qui signifie que tous les pods situés sur les nœuds utilisateurs NodeClass partagent les mêmes groupes de sécurité Pod.

Comment ça marche

Lorsque vous configurez podSubnetSelectorTerms et podSecurityGroupSelectorTerms :

L'ENI principal du nœud utilise les sous-réseaux et les groupes de sécurité provenant de subnetSelectorTerms etsecurityGroupSelectorTerms. Seule l'adresse IP du nœud est attribuée à cette interface.
Le mode automatique EKS crée des ENI secondaires dans les sous-réseaux correspondantspodSubnetSelectorTerms, avec les groupes de podSecurityGroupSelectorTerms sécurité attachés. Les adresses IP des pods sont allouées à partir de ces ENI secondaires à l'aide des préfixes /28 par défaut, avec un retour automatique aux adresses IP secondaires (/32) lorsqu'aucun bloc de préfixe contigu n'est disponible. Si ipv4PrefixSize ce paramètre est défini sur "32" inadvancedNetworking, seules les adresses IP secondaires sont utilisées.
Les groupes de sécurité spécifiés dans podSecurityGroupSelectorTerms s'appliquent au trafic des pods au sein du VPC. Pour le trafic destiné à l'extérieur du VPC, les pods utilisent l'ENI principal du nœud (et ses groupes de sécurité) car la traduction d'adresses réseau source (SNAT) traduit l'adresse IP du pod en adresse IP du nœud. Vous pouvez modifier ce comportement à l'aide du snatPolicy champ situé dans leNodeClass.

Cas d’utilisation

À utiliser podSubnetSelectorTerms et podSecurityGroupSelectorTerms quand vous devez :

Appliquez différents groupes de sécurité pour contrôler le trafic des nœuds et des pods séparément.
Séparez le trafic d'infrastructure (communication nœud à nœud) du trafic applicatif (Pod-to-Pod communication).
Appliquer des configurations réseau différentes aux sous-réseaux des nœuds et aux sous-réseaux des pods.
Configurer des serveurs proxy inverses ou des filtres réseau spécifiquement pour le trafic des nœuds sans affecter le trafic des pods. Utiliser advancedNetworking et certificateBundles pour définir votre serveur proxy inverse ainsi que tout certificat autosigné ou privé pour ce serveur.

Exemple de configuration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  # Subnets and security groups for EC2 instances (nodes)
  subnetSelectorTerms:
    - tags:
        Name: "node-subnet"
        kubernetes.io/role/internal-elb: "1"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  # Separate subnets and security groups for Pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

  podSecurityGroupSelectorTerms:
  - tags:
      Name: "eks-pod-sg"

Considérations relatives aux sous-réseaux Pod et aux groupes de sécurité distincts

Étendue du groupe de sécurité : les groupes de sécurité provenant de podSecurityGroupSelectorTerms sont attachés aux ENI secondaires et s'appliquent au trafic des pods au sein du VPC. Lorsque le SNAT est activé (valeur par défautsnatPolicy: Random), le trafic quittant le VPC est traduit vers l'adresse IP ENI principale du nœud, de sorte que les groupes de sécurité du nœud s'appliquent securityGroupSelectorTerms plutôt à ce trafic. Si vous le configurezsnatPolicy: Disabled, les pods utilisent leurs propres adresses IP pour l'ensemble du trafic, et vous devez vous assurer que les groupes de routage et de sécurité sont configurés en conséquence.
NodeClass-level granularité : Les groupes de sécurité Pod s'appliquent à tous les Pods planifiés sur les nœuds utilisant leNodeClass. Pour appliquer différents groupes de sécurité à différentes charges de travail, créez des NodePool ressources NodeClass et utilisez des restrictions, des tolérances ou des sélecteurs de nœuds pour planifier les charges de travail sur les nœuds appropriés.
Densité de pods réduite : moins de pods peuvent être exécutés sur chaque nœud car l'interface réseau principale du nœud est réservée à l'adresse IP du nœud et ne peut pas être utilisée pour les pods.
Limites du sélecteur de sous-réseau : la norme subnetSelectorTerms et les securityGroupSelectorTerms configurations ne s'appliquent pas à la sélection du sous-réseau ou du groupe de sécurité du Pod.
Planification du réseau : assurez-vous de disposer d’un espace d’adresses IP suffisant dans les sous-réseaux des nœuds et des pods pour répondre aux besoins de vos charges de travail.
Configuration du routage : vérifiez que la table de routage et les listes de contrôle d’accès (ACL) réseau des sous-réseaux destinés aux pods sont correctement configurées pour permettre la communication entre les sous-réseaux des nœuds et ceux des pods.
Zones de disponibilité : vérifiez que vous avez créé des sous-réseaux pour les pods dans plusieurs zones de disponibilité. Si vous utilisez un sous-réseau Pod spécifique, il doit se trouver dans le même AZ que le sous-réseau de nœuds AZ.

Mode IP secondaire pour les pods

Le ipv4PrefixSize champ permet des configurations réseau avancées en n'allouant que des adresses IP secondaires aux nœuds. Cette fonctionnalité n'alloue pas de préfixes (/28) aux nœuds et ne conserve qu'une seule adresse IP secondaire en tant que MinimalIPTarget.

Cas d’utilisation

Utilisez ipv4PrefixSize lorsque vous devez :

Utilisation IP réduite : une seule adresse IP sera réchauffée dans chaque nœud.
Réduction du taux de barattage des capsules : la vitesse de création des capsules n'est pas une préoccupation majeure.
Aucune fragmentation des préfixes : Prefix-caused la fragmentation est un problème majeur ou un obstacle à l'utilisation du mode automatique.

Exemple de configuration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    ipv4PrefixSize: "32"

Considérations relatives au mode IP secondaire

Vitesse de création de pods réduite : étant donné qu'une seule adresse IP secondaire est réchauffée, le service IPAM a besoin de plus de temps pour fournir des adresses IP lorsque d'autres pods sont créés.

Désactivez la sortie IPv4 à partir des pods IPv6 dans les clusters IPv6.

Le enableV4Egress champ est défini true par défaut. Pour les clusters IPv6 en mode automatique, la fonctionnalité peut être désactivée afin que le mode automatique ne crée pas d'interface IPv4 de sortie uniquement pour les pods IPv6. Ceci est important car l'interface de sortie IPv4 n'est pas soumise à l'application de la politique réseau. Les politiques réseau ne sont appliquées que sur l'interface principale du Pod (eth0).

Cas d’utilisation

Utilisez enableV4Egress lorsque vous devez :

Utiliser le cluster IPv6 : le trafic de sortie IPv4 est autorisé par défaut.
Utiliser la politique réseau : actuellement, EKS Network Policy ne prend pas en charge le double stack. La désactivation enableV4Egress peut empêcher le trafic du pod de sortir de manière inattendue via IPv4.

Exemple de configuration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    enableV4Egress: false

Considérations relatives à la désactivation d'EnableV4egress

Politique réseau dans le cluster IPv6 : les clusters IPv6 autorisent le trafic IPv4 par défaut. Le réglage enableV4Egress: false bloque le trafic de sortie IPv4, offrant ainsi une sécurité renforcée, en particulier lorsqu'il est utilisé avec des politiques réseau.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Configurer

Création d’un groupe de nœuds