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.
Configuration de l'accès VPC pour que les applications EMR sans serveur se connectent aux données
Vous pouvez configurer des applications EMR sans serveur pour qu'elles se connectent à vos magasins de données au sein de votre VPC, tels que les clusters Amazon Redshift, les bases de données Amazon RDS ou les compartiments Amazon S3 dotés de points de terminaison VPC. Votre application EMR Serverless dispose d'une connectivité sortante vers les magasins de données de votre VPC. Par défaut, EMR Serverless bloque l'accès entrant à vos applications afin d'améliorer la sécurité.
Note
Vous devez configurer l'accès VPC si vous souhaitez utiliser une base de données de métastore Hive externe pour votre application. Pour plus d'informations sur la configuration d'un métastore Hive externe, consultez la section Configuration du métastore.
Créer une application
Sur la page Créer une application, vous pouvez choisir des paramètres personnalisés et spécifier le VPC, les sous-réseaux et les groupes de sécurité que les applications EMR Serverless peuvent utiliser.
VPCs
Choisissez le nom du cloud privé virtuel (VPC) qui contient vos magasins de données. La page Créer une application répertorie toutes VPCs les applications que vous avez choisies Région AWS.
Sous-réseaux
Choisissez les sous-réseaux du VPC qui contient votre magasin de données. La page Créer une application répertorie tous les sous-réseaux des magasins de données de votre VPC. Les sous-réseaux publics et privés sont pris en charge. Vous pouvez transmettre des sous-réseaux privés ou publics à vos applications. Le choix d'avoir un sous-réseau public ou privé comporte quelques considérations connexes à prendre en compte.
Pour les sous-réseaux privés :
Les tables de routage associées ne doivent pas comporter de passerelles Internet.
Pour la connectivité sortante à Internet, si nécessaire, configurez les routes sortantes à l'aide d'une passerelle NAT. Pour configurer une passerelle NAT, consultez la section Passerelles NAT.
Pour la connectivité Amazon S3, configurez une passerelle NAT ou un point de terminaison VPC. Pour configurer un point de terminaison VPC S3, consultez la section Créer un point de terminaison de passerelle.
Pour la connectivité à d'autres Services AWS entités extérieures au VPC, comme Amazon DynamoDB, configurez des points de terminaison VPC ou une passerelle NAT. Pour configurer les points de terminaison VPC pour Services AWS, consultez la section Utilisation des points de terminaison VPC.
Note
Lorsque vous configurez une application Amazon EMR Serverless dans un sous-réseau privé, nous vous recommandons de configurer également des points de terminaison VPC pour Amazon S3. Si votre application EMR Serverless se trouve dans un sous-réseau privé sans points de terminaison VPC pour Amazon S3, vous pourriez avoir à payer des frais de passerelle NAT supplémentaires associés au trafic S3. Cela est dû au fait que le trafic entre votre application EMR et Amazon S3 ne restera pas dans votre VPC lorsque les points de terminaison du VPC ne sont pas configurés.
Pour les sous-réseaux publics :
Ils ont une route vers un Internet Gateway.
Vous devez vous assurer que les groupes de sécurité sont correctement configurés pour contrôler le trafic sortant.
Les collaborateurs peuvent se connecter aux magasins de données de votre VPC par le biais du trafic sortant. Par défaut, EMR Serverless bloque l'accès entrant aux travailleurs. Il s'agit d'améliorer la sécurité.
Lorsque vous l'utilisez AWS Config, EMR Serverless crée un enregistrement d'élément Elastic Network Interface pour chaque collaborateur. Pour éviter les coûts liés à cette ressource, pensez AWS::EC2::NetworkInterface à la désactiver AWS Config.
Note
Nous vous recommandons de sélectionner plusieurs sous-réseaux dans plusieurs zones de disponibilité. Cela est dû au fait que les sous-réseaux que vous choisissez déterminent les zones de disponibilité disponibles pour le lancement d'une application EMR sans serveur. Chaque travailleur consomme une adresse IP sur le sous-réseau où il est lancé. Assurez-vous que les sous-réseaux spécifiés possèdent suffisamment d'adresses IP pour le nombre de travailleurs que vous prévoyez de lancer. Pour plus d'informations sur la planification des sous-réseaux, consultezBonnes pratiques pour la planification des sous-réseaux.
Considérations et limites relatives aux sous-réseaux
L'EMR Serverless avec sous-réseaux publics ne prend pas en charge Lake Formation. AWS
Le trafic entrant n'est pas pris en charge pour les sous-réseaux publics.
Groupes de sécurité
Choisissez un ou plusieurs groupes de sécurité qui peuvent communiquer avec vos banques de données. La page Créer une application répertorie tous les groupes de sécurité de votre VPC. EMR Serverless associe ces groupes de sécurité à des interfaces réseau élastiques associées à vos sous-réseaux VPC.
Note
Nous vous recommandons de créer un groupe de sécurité distinct pour les applications EMR Serverless. EMR Serverless ne vous permettra pas de créer/mettre à jour/démarrer une application si les groupes de sécurité ont des ports ouverts à l'Internet public sur 0.0.0.0/0 ou sur la plage : :/0. Cela améliore la sécurité, l'isolation et rend la gestion des règles réseau plus efficace. Par exemple, cela bloque le trafic inattendu destiné aux employés possédant des adresses IP publiques. Pour communiquer avec les clusters Amazon Redshift, par exemple, vous pouvez définir les règles de trafic entre les groupes de sécurité Redshift et EMR Serverless, comme illustré dans l'exemple ci-dessous.
Exemple — Communication avec les clusters Amazon Redshift
-
Ajoutez une règle pour le trafic entrant au groupe de sécurité Amazon Redshift depuis l'un des groupes de sécurité EMR Serverless.
Type Protocole Plage de ports Source Tous les TCP
TCP
5439
emr-serverless-security-group -
Ajoutez une règle pour le trafic sortant depuis l'un des groupes de sécurité EMR Serverless. Vous pouvez effectuer cette opération de deux manières. Tout d'abord, vous pouvez ouvrir le trafic sortant à tous les ports.
Type Protocole Plage de ports Destination Tout le trafic
TCP
ALL
0.0.0.0/0
Vous pouvez également restreindre le trafic sortant vers les clusters Amazon Redshift. Cela n'est utile que lorsque l'application doit communiquer avec les clusters Amazon Redshift et rien d'autre.
Type Protocole Plage de ports Source Tous les TCP
TCP
5439
redshift-security-group
Configuration de l'application
Vous pouvez modifier la configuration réseau d'une application EMR Serverless existante à partir de la page Configurer l'application.
Afficher les détails de l'exécution des tâches
Sur la page détaillée de l'exécution du job, vous pouvez voir le sous-réseau utilisé par votre job pour une exécution spécifique. Notez qu'une tâche ne s'exécute que dans un sous-réseau sélectionné parmi les sous-réseaux spécifiés.
Bonnes pratiques pour la planification des sous-réseaux
AWS les ressources sont créées dans un sous-réseau qui est un sous-ensemble d'adresses IP disponibles dans un Amazon VPC. Par exemple, un VPC doté d'un masque réseau /16 possède jusqu'à 65 536 adresses IP disponibles qui peuvent être divisées en plusieurs réseaux plus petits à l'aide de masques de sous-réseau. Par exemple, vous pouvez diviser cette plage en deux sous-réseaux, chacun utilisant le masque /17 et 32 768 adresses IP disponibles. Un sous-réseau réside dans une zone de disponibilité et ne peut pas s'étendre sur plusieurs zones.
Les sous-réseaux doivent être conçus en tenant compte des limites de dimensionnement de votre application EMR Serverless. Par exemple, si votre application demande 4 processeurs virtuels et peut évoluer jusqu'à 4 000 processeurs virtuels, votre application aura besoin d'au plus 1 000 travailleurs pour un total de 1 000 interfaces réseau. Nous vous recommandons de créer des sous-réseaux dans plusieurs zones de disponibilité. Cela permet à EMR Serverless de réessayer votre tâche ou de fournir une capacité préinitialisée dans une autre zone de disponibilité dans le cas peu probable d'une défaillance d'une zone de disponibilité. Par conséquent, chaque sous-réseau d'au moins deux zones de disponibilité doit avoir plus de 1 000 adresses IP disponibles.
Vous avez besoin de sous-réseaux dont la taille de masque est inférieure ou égale à 22 pour approvisionner 1 000 interfaces réseau. Tout masque supérieur à 22 ne répondra pas à cette exigence. Par exemple, un masque de sous-réseau de /23 fournit 512 adresses IP, tandis qu'un masque de /22 fournit 1024 et un masque de /21 fournit 2048 adresses IP. Vous trouverez ci-dessous un exemple de 4 sous-réseaux avec un masque /22 dans un VPC de masque réseau /16 qui peuvent être alloués à différentes zones de disponibilité. Il existe une différence de cinq entre les adresses IP disponibles et utilisables, car les quatre premières adresses IP et la dernière adresse IP de chaque sous-réseau sont réservées par AWS.
| ID de sous-réseau (subnet) | Adresse du sous-réseau | Masque de sous-réseau | Plage d'adresses IP | Adresses IP disponibles | Adresses IP utilisables |
|---|---|---|---|---|---|
|
1 |
10,0.0.0 |
255,255,252,0/22 |
10.0.0.0 - 10.0.3.255 |
1,024 |
1 019 |
|
2 |
10.0.4.0 |
255,255,252,0/22 |
10.0.4.0 - 10.0.7.255 |
1,024 |
1 019 |
|
3 |
10,0.8.0 |
255,255,252,0/22 |
10.0.4.0 - 10.0.7.255 |
1,024 |
1 019 |
|
4 |
10,0.12,0 |
255,255,252,0/22 |
10,0.12,0 - 10,0.15,255 |
1,024 |
1 019 |
Vous devez évaluer si votre charge de travail convient le mieux à des travailleurs de plus grande taille. L'utilisation de travailleurs de plus grande taille nécessite moins d'interfaces réseau. Par exemple, l'utilisation de 16 processeurs virtuels avec une limite de mise à l'échelle des applications de 4 000 processeurs virtuels nécessitera au maximum 250 travailleurs pour un total de 250 adresses IP disponibles pour provisionner les interfaces réseau. Vous avez besoin de sous-réseaux répartis dans plusieurs zones de disponibilité avec une taille de masque inférieure ou égale à 24 pour approvisionner 250 interfaces réseau. Toute taille de masque supérieure à 24 propose moins de 250 adresses IP.
Si vous partagez des sous-réseaux entre plusieurs applications, chaque sous-réseau doit être conçu en tenant compte des limites d'échelle collectives de toutes vos applications. Par exemple, si 3 applications demandent 4 processeurs virtuels et que chacune peut évoluer jusqu'à 4 000 processeurs virtuels avec un quota basé sur le service de 12 000 processeurs virtuels au niveau du compte, chaque sous-réseau aura besoin de 3 000 adresses IP disponibles. Si le VPC que vous souhaitez utiliser ne dispose pas d'un nombre suffisant d'adresses IP, essayez d'augmenter le nombre d'adresses IP disponibles. Vous pouvez effectuer cette opération en associant des blocs d'adresse CIDR (Routage inter-domaines sans classe) supplémentaires avec votre VPC. Pour plus d'informations, consultez Associer des blocs IPv4 CIDR supplémentaires à votre VPC dans le guide de l'utilisateur Amazon VPC.
Vous pouvez utiliser l'un des nombreux outils disponibles en ligne pour générer rapidement des définitions de sous-réseaux et passer en revue la plage d'adresses IP disponibles.
