翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
データに接続するための EMR Serverless アプリケーションの VPC アクセスの設定
Amazon Redshift クラスター、Amazon RDS データベース、VPC エンドポイントを持つ Amazon S3 バケットなど、VPC 内のデータストアに接続するように EMR Serverless アプリケーションを設定できます。EMR Serverless アプリケーションは、VPC 内のデータストアにアウトバウンド接続します。デフォルトでは、EMR Serverless はアプリケーションへのインバウンドアクセスとアウトバウンドインターネットアクセスの両方をブロックしてセキュリティを強化します。
注記
アプリケーションに外部 Hive メタストアデータベースを使用する場合は、VPC アクセスを設定する必要があります。外部 Hive メタストアを設定する方法については、「メタストア設定」を参照してください。
アプリケーションを作成
アプリケーションの作成ページで、カスタム設定を選択し、EMR Serverless アプリケーションが使用できる VPC、サブネット、セキュリティグループを指定します。
VPC
データストアを含む仮想プライベートクラウド (VPC) の名前を選択します。[アプリケーションの作成] ページには、選択した AWS リージョンのすべての VPC が一覧表示されます。
サブネット
データストアを含む VPC 内のサブネットを選択します。[アプリケーションの作成] ページには、VPC 内のデータストアのすべてのサブネットが一覧表示されます。パブリックサブネットとプライベートサブネットの両方がサポートされています。プライベートサブネットまたはパブリックサブネットをアプリケーションに渡すことができます。パブリックサブネットとプライベートサブネットのどちらを使用するかの選択には、いくつかの考慮事項があります。
プライベートサブネットの場合:
関連付けられたルートテーブルにインターネットゲートウェイがあってはなりません。
インターネットへのアウトバウンド接続の場合は、必要に応じて NAT ゲートウェイを使用してアウトバウンドルートを設定します。NAT ゲートウェイを設定するには、NAT ゲートウェイを参照してください。
Amazon S3 接続の場合は、NAT ゲートウェイまたは VPC エンドポイントを設定します。S3 VPC エンドポイントを設定するには、「ゲートウェイエンドポイントの作成」を参照してください。
S3 VPC エンドポイントを設定し、アクセスを制御するエンドポイントポリシーをアタッチする場合は、「マネージドストレージを使用した EMR Serverless のログ記録」の手順に従って、EMR Serverless がアプリケーションログを保存して処理するためのアクセス許可を提供します。
Amazon DynamoDB など、VPC AWS のサービス 外の他の に接続するには、VPC エンドポイントまたは NAT ゲートウェイを設定します。の VPC エンドポイントを設定するには AWS のサービス、「VPC エンドポイントの使用」を参照してください。
注記
プライベートサブネットで Amazon EMR Serverless アプリケーションを設定するときは、Amazon S3 の VPC エンドポイントも設定することをお勧めします。EMR Serverless アプリケーションが Amazon S3 の VPC エンドポイントのないプライベートサブネットにある場合、S3 トラフィックに関連する追加の NAT ゲートウェイ料金が発生します。これは、VPC エンドポイントが設定されていない場合、EMR アプリケーションと Amazon S3 間のトラフィックが VPC 内にとどまらないためです。
パブリックサブネットの場合:
これらには、インターネットゲートウェイへのルートがあります。
アウトバウンドトラフィックを制御するには、適切なセキュリティグループ設定を確認する必要があります。
ワーカーは、アウトバウンドトラフィックを介して VPC 内のデータストアに接続できます。デフォルトでは、EMR Serverless はワーカーへのインバウンドアクセスをブロックします。これはセキュリティを向上させるためです。
を使用すると AWS Config、EMR Serverless はワーカーごとに Elastic Network Interface 項目レコードを作成します。このリソースに関連するコストを回避するには、 をオフにすることを検討AWS::EC2::NetworkInterfaceしてください AWS Config。
注記
複数のアベイラビリティーゾーンで複数のサブネットを選択することをお勧めします。これは、選択したサブネットによって、EMR Serverless アプリケーションの起動に使用できるアベイラビリティーゾーンが決定されるためです。各ワーカーは、起動するサブネットの IP アドレスを使用します。指定したサブネットに、起動するワーカー数に対して十分な IP アドレスがあることを確認してください。サブネット計画の詳細については、「」を参照してくださいサブネット計画の作成に関するベストプラクティス。
サブネットに関する考慮事項と制限事項
パブリックサブネットを持つ EMR Serverless は AWS Lake Formation をサポートしていません。
インバウンドトラフィックは、パブリックサブネットではサポートされていません。
セキュリティグループ
データストアと通信できる 1 つ以上のセキュリティグループを選択します。[アプリケーションの作成] ページには、VPC 内のすべてのセキュリティグループが一覧表示されます。EMR Serverless は、VPC サブネットにアタッチされている Elastic Network Interface にこれらのセキュリティグループを関連付けます。
注記
EMR Serverless アプリケーション用に別のセキュリティグループを作成することをお勧めします。セキュリティグループで 0.0.0.0/0 または ::/0 の範囲にパブリックインターネットへのポートが開いている場合、EMR Serverless ではアプリケーションを作成/更新/開始できません。 これにより、セキュリティと分離が強化され、ネットワークルールの管理がより効率的になります。たとえば、これにより、パブリック IP アドレスを持つワーカーへの予期しないトラフィックがブロックされます。例えば、Amazon Redshift クラスターと通信するには、次のセクションの例に示すように、Redshift と EMR Serverless セキュリティグループ間のトラフィックルールを定義します。
例 — Amazon Redshift クラスターとの通信
-
EMR Serverless セキュリティグループの一つから Amazon Redshift セキュリティグループにインバウンドトラフィックのルールを追加します。
タイプ プロトコル ポート範囲 ソース すべての TCP
TCP
5439
emr-serverless-security-group -
EMR Serverless セキュリティグループの一つからのアウトバウンドトラフィックのルールを追加します。これは、2 つの方法のいずれかで行います。まず、すべてのポートへのアウトバウンドトラフィックを開きます。
タイプ プロトコル ポート範囲 ルーティング先 すべてのトラフィック
TCP
すべて
0.0.0.0/0
または、アウトバウンドトラフィックを Amazon Redshift クラスターに制限することもできます。これは、アプリケーションが Amazon Redshift クラスターとのみ通信する必要がある場合に限って有効です。
タイプ プロトコル ポート範囲 ソース すべての TCP
TCP
5439
redshift-security-group
アプリケーションの設定
既存の EMR Serverless アプリケーションのネットワーク設定は、[アプリケーションの設定] ページから変更できます。
ジョブ実行の詳細にアクセスする
ジョブ実行の詳細ページで、ジョブが特定の実行に使用するサブネットにアクセスします。ジョブは、指定されたサブネットから選択された 1 つのサブネットでのみ実行されることに注意してください。
サブネット計画の作成に関するベストプラクティス
AWS リソースは、Amazon VPC で使用可能な IP アドレスのサブセットであるサブネットに作成されます。例えば、/16 ネットマスクを持つ VPC には最大 65,536 個の使用可能な IP アドレスがあり、サブネットマスクを使用して複数の小さなネットワークに分割できます。例えば、この範囲を 2 つのサブネットに分割し、それぞれに /17 マスクと 32,768 個の使用可能な IP アドレスを使用できます。サブネットはアベイラビリティーゾーン内に存在し、複数のゾーンにわたって存在することはできません。
サブネットは、EMR Serverless アプリケーションのスケーリング制限を考慮して設計する必要があります。たとえば、4 つの vCpu ワーカーをリクエストするアプリケーションがあり、4,000 vCpu までスケールできる場合、アプリケーションには最大 1,000 人のワーカーと合計 1,000 のネットワークインターフェイスが必要です。複数のアベイラビリティーゾーンにサブネットを作成することをお勧めします。これにより、EMR Serverless は、アベイラビリティーゾーンが失敗した場合に、万一、ジョブを再試行する、または別のアベイラビリティーゾーンに事前初期化された容量をプロビジョニングすることができます。したがって、少なくとも 2 つのアベイラビリティーゾーンの各サブネットには、1,000 個を超える使用可能な IP アドレスが必要です。
1,000 個のネットワークインターフェイスをプロビジョニングするには、マスクサイズが 22 以下のサブネットが必要です。22 を超えるマスクは要件を満たしていません。例えば、/23 のサブネットマスクは 512 個の IP アドレスを提供し、/22 のマスクは 1,024 個を提供し、/21 のマスクは 2,048 個の IP アドレスを提供します。以下に示すのは、異なるアベイラビリティーゾーンに割り当てることができる /16 ネットマスクの VPC に /22 マスクを持つ 4 つのサブネットの例です。各サブネットの最初の 4 つの IP アドレスと最後の IP アドレスは によって予約されるため、使用可能な IP アドレスと使用可能な IP アドレスには 5 つの違いがあります AWS。
| サブネット ID | サブネットアドレス | サブネットマスク | IP アドレス範囲 | 利用可能な IP アドレス | 使用可能な IP アドレス |
|---|---|---|---|---|---|
|
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.8.0 - 10.0.11.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 |
ワークロードがより大きなワーカーサイズに適しているかどうかを評価する必要があります。より大きなワーカーサイズを使用すると、必要なネットワークインターフェイスが少なくなります。例えば、アプリケーションのスケーリング制限が 4,000 16vCpuvCpu ワーカーを使用する場合、ネットワークインターフェイスをプロビジョニングするには、最大 250 のワーカーが必要で、合計 250 の使用可能な IP アドレスが必要です。250 個のネットワークインターフェイスをプロビジョニングするには、マスクサイズが 24 以下の複数のアベイラビリティーゾーンにサブネットが必要です。24 を超えるマスクサイズは、250 個未満の IP アドレスを提供します。
複数のアプリケーション間でサブネットを共有する場合、各サブネットはすべてのアプリケーションの集合的なスケーリング制限を念頭に置いて設計する必要があります。たとえば、4 つの vCpu ワーカーをリクエストする 3 つのアプリケーションがあり、それぞれが 12,000 個の vCpu アカウントレベルのサービスベースのクォータで 4,000 個の vCpu にスケールアップできる場合、各サブネットには 3,000 個の使用可能な IP アドレスが必要です。使用する VPC に十分な数の IP アドレスがない場合は、使用可能な IP アドレスの数を増やしてみてください。この操作を行うには、VPC への追加の Classless Inter-Domain Routing (CIDR) ブロックの関連付けが必要になります。詳細については、「Amazon VPC ユーザーガイド」の「追加の IPv4 CIDR ブロックを VPC に関連付ける」を参照してください。
オンラインで利用可能な多数のツールのいずれかを使用して、サブネット定義をすばやく生成し、使用可能な IP アドレスの範囲を確認できます。
