翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# データに接続するための EMR Serverless アプリケーションの VPC アクセスの設定
Amazon Redshift クラスター、Amazon RDS データベース、VPC エンドポイントを持つ Amazon S3 バケットなど、VPC 内のデータストアに接続するように EMR Serverless アプリケーションを設定できます。EMR Serverless アプリケーションは、VPC 内のデータストアにアウトバウンド接続します。デフォルトでは、EMR Serverless はアプリケーションへのインバウンドアクセスおよびアウトバウンドインターネットアクセスの両方をブロックし、セキュリティを強化します。
**注記**
アプリケーションに外部 Hive メタストアデータベースを使用する場合は、VPC アクセスを設定する必要があります。外部 Hive メタストアを設定する方法については、「[Metastore configuration](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/metastore-config.html)」を参照してください。
## アプリケーションを作成
**[アプリケーションの作成]** ページで、カスタム設定を選択し、EMR Serverless アプリケーションで使用できる VPC、サブネット、セキュリティグループを指定します。
### VPC
データストアを含む仮想プライベートクラウド (VPC) の名前を選択します。**[アプリケーションの作成]** ページには、選択した AWS リージョンのすべての VPC が一覧表示されます。
### サブネット
データストアを含む VPC 内のサブネットを選択します。**[アプリケーションの作成]** ページには、VPC 内のデータストアのすべてのサブネットが一覧表示されます。パブリックサブネットとプライベートサブネットの両方がサポートされています。プライベートサブネットまたはパブリックサブネットをアプリケーションに渡すことができます。パブリックサブネットとプライベートサブネットのどちらを持つかの選択には、いくつかの関連する考慮事項があります。
プライベートサブネットの場合:
+ 関連付けられたルートテーブルにインターネットゲートウェイがあってはなりません。
+ インターネットへのアウトバウンド接続では、必要な場合、NAT Gateway を使用したアウトバウンドルートを設定します。NAT ゲートウェイを設定するには、「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-working-with)」を参照してください。
+ Amazon S3 接続の場合、NAT ゲートウェイまたは VPC エンドポイントを設定します。S3 VPC エンドポイントを設定するには、「[Create a gateway endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3)」を参照してください。
+ S3 VPC エンドポイントを設定し、アクセスを制御するエンドポイントポリシーをアタッチする場合は、「[Logging for EMR Serverless with managed storage](logging.html#jobs-log-storage-managed-storage)」の手順に従って、EMR Serverless がアプリケーションログを保存して処理するためのアクセス許可を提供します。
+ Amazon DynamoDB など、VPC AWS のサービス 外の他の に接続するには、VPC エンドポイントまたは NAT ゲートウェイを設定します。 AWS のサービスの VPC エンドポイントを設定するには、「[Work with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html#working-with-privatelink)」を参照してください。
**注記**
プライベートサブネットに 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 アドレスがあることを確認してください。サブネット計画の作成について詳しくは、「[サブネット計画の作成に関するベストプラクティス](#subnet-best-practices)」を参照してください。
#### サブネットの考慮事項と制約事項
+ パブリックサブネットを持つ 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 セキュリティグループ間のトラフィックルールを定義します。
**Example 例 — Amazon Redshift クラスターとの通信**
1. EMR Serverless セキュリティグループの一つから Amazon Redshift セキュリティグループにインバウンドトラフィックのルールを追加します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/EMR-Serverless-UserGuide/vpc-access.html)
1. EMR Serverless セキュリティグループの一つからのアウトバウンドトラフィックのルールを追加します。これは以下の 2 つの方法のいずれかで行います。まず、すべてのポートへのアウトバウンドトラフィックを開きます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/EMR-Serverless-UserGuide/vpc-access.html)
または、アウトバウンドトラフィックを Amazon Redshift クラスターに制限することもできます。これは、アプリケーションが Amazon Redshift クラスターとのみ通信する必要がある場合に限って有効です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/EMR-Serverless-UserGuide/vpc-access.html)
## アプリケーションの設定
既存の 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 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 の関連付け](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr)」を参照してください。
オンラインで利用可能な多数のツールのいずれかを使用して、サブネット定義をすばやく生成し、使用可能な IP アドレスの範囲を確認できます。