データに接続するための EMR Serverless アプリケーションの VPC アクセスの設定

Amazon Redshift クラスター、Amazon RDS データベース、VPC エンドポイントを持つ Amazon S3 バケットなど、VPC 内のデータストアに接続するように EMR Serverless アプリケーションを設定できます。EMR Serverless アプリケーションは、VPC 内のデータストアにアウトバウンド接続します。デフォルトでは、EMR Serverless はアプリケーションへのインバウンドアクセスをブロックし、セキュリティを強化します。

アプリケーションの作成

[アプリケーションの作成] ページで、カスタム設定を選択し、EMR Serverless アプリケーションで使用できる VPC、サブネット、セキュリティグループを指定できます。

VPC

データストアを含む仮想プライベートクラウド (VPC) の名前を選択します。[アプリケーションの作成] ページには、選択した AWS リージョンのすべての VPC が一覧表示されます。

サブネット

データストアを含む VPC 内のサブネットを選択します。[アプリケーションの作成] ページには、VPC 内のデータストアのすべてのサブネットが一覧表示されます。

選択したサブネットはプライベートサブネットであることが必要です。つまり、サブネットの関連付けられたルートテーブルにインターネットゲートウェイが存在することを回避する必要があります。

インターネットへのアウトバウンド接続では、サブネットに NAT Gateway を使用したアウトバウンドルートが必要です。NAT ゲートウェイを設定するには、「NAT ゲートウェイの操作」を参照してください。

Amazon S3 接続の場合、サブネットには NAT ゲートウェイまたは VPC エンドポイントが設定されている必要があります。S3 VPC エンドポイントを設定するには、「ゲートウェイエンドポイントの作成」を参照してください。

Amazon DynamoDB などの VPC 外部の他の AWS のサービスへの接続に対しては、VPC エンドポイントまたは NAT ゲートウェイを設定する必要があります。AWS のサービスの VPC エンドポイントを設定するには、「VPC エンドポイントの操作」を参照してください。

ワーカーは、アウトバウンドトラフィックを介して VPC 内のデータストアに接続できます。デフォルトでは、EMR Serverless はワーカーへのインバウンドアクセスをブロックしてセキュリティを強化します。

AWS Config を使用すると、EMR Serverless はすべてのワーカーのエラスティックネットワークインターフェイス項目のレコードを作成します。このリソースに関連するコストを回避するには、AWS Config で AWS::EC2::NetworkInterface をオフにすることを検討してください。

セキュリティグループ

データストアと通信できる 1 つ以上のセキュリティグループを選択します。[アプリケーションの作成] ページには、VPC 内のすべてのセキュリティグループが一覧表示されます。EMR Serverless は、VPC サブネットにアタッチされている Elastic Network Interface にこれらのセキュリティグループを関連付けます。

アプリケーションの設定

既存の 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 アドレスは AWS によって予約されるため、利用可能な IP アドレスと使用可能な IP アドレスには 5 つの違いがあります。

ワークロードがより大きなワーカーサイズに適しているかどうかを評価する必要があります。より大きなワーカーサイズを使用すると、必要なネットワークインターフェイスが少なくなります。例えば、アプリケーションのスケーリング制限が 4,000 vCpu の 16 個の vCpu ワーカーを使用する場合、ネットワークインターフェイスをプロビジョニングするには、合計 250 個の使用可能な IP アドレスに対して最大 250 個のワーカーが必要になります。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 アドレスの範囲を確認できます。