# Amazon Virtual Private Cloud のセキュリティの責任の管理
AWS ではクラウドセキュリティが最優先事項です。セキュリティを最も重視する組織の要件を満たすために構築された 「AWS」 のデータセンターとネットワークアーキテクチャは、お客様に大きく貢献します。
セキュリティは、AWS とお客様とが共有する責務です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これを クラウド *の* セキュリティ および クラウド *内*の セキュリティ と説明しています。
+ **クラウドのセキュリティ** - AWS は AWS Cloud で AWS のサービスを実行するインフラストラクチャを保護する責任を負います。また、AWS は使用するサービスを安全に提供します。[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティ監査者が定期的にセキュリティの有効性をテストおよび検証します。Amazon Virtual Private Cloud に適用されるコンプライアンスプログラムの詳細については、[コンプライアンスプログラムによる AWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** - ユーザーの責任は、使用する AWS のサービスに応じて異なります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、Amazon VPC を使用する際の責任共有モデルの適用方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するように Amazon VPC を設定する方法について説明します。また、Amazon VPC リソースの監視や保護に役立つ他の AWS のサービスの使用方法についても説明します。
**Topics**
+ [Amazon Virtual Private Cloud のデータ保護の確保](data-protection.md)
+ [転送時の VPC 暗号化を強制する](vpc-encryption-controls.md)
+ [Amazon VPC の Identity and Access Management](security-iam.md)
+ [Amazon VPC のインフラストラクチャセキュリティ](infrastructure-security.md)
+ [セキュリティグループを使用して AWS リソースへのトラフィックを制御する](vpc-security-groups.md)
+ [ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する](vpc-network-acls.md)
+ [Amazon Virtual Private Cloud での耐障害性](disaster-recovery-resiliency.md)
+ [Amazon Virtual Private Cloud のコンプライアンス検証](VPC-compliance.md)
+ [VPC とサブネットへのパブリックアクセスをブロックする](security-vpc-bpa.md)
+ [VPC のセキュリティのベストプラクティス](vpc-security-best-practices.md)
# Amazon Virtual Private Cloud のデータ保護の確保
AWS [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)は Amazon Virtual Private Cloud のデータ保護に適用されます。このモデルで説明されているように、「AWS」は、「AWS クラウド」のすべてを実行するグローバルインフラストラクチャを保護する責任があります。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「AWS のサービス」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データを保護するため、「AWS アカウント」認証情報を保護し、AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーをセットアップすることをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ AWS CloudTrail で API とユーザーアクティビティロギングを設定します。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「**AWS CloudTrail ユーザーガイド」の「[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS のサービス内のすべてのデフォルトセキュリティコントロールに加え、AWS 暗号化ソリューションを使用します。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API を使用して AWS にアクセスする際に FIPS 140-3 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これには、コンソール、API、AWS CLI、または AWS SDK を使用して、Amazon VPC または他の AWS のサービス で作業する場合も含まれます。タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
# Amazon VPC でのインターネットワークトラフィックのプライバシーの確保
Amazon Virtual Private Cloud では、次の機能を使用して、仮想プライベートクラウド (VPC) のセキュリティを強化し、監視できます。
+ **セキュリティグループ**: セキュリティグループは、リソースレベル (EC2 インスタンスなど) で特定のインバウンドおよびアウトバウンドトラフィックを許可します。インスタンスを起動する際、そのインスタンスに 1 つまたは複数のセキュリティグループを割り当てることができます。VPC 内のインスタンスごとに異なるセキュリティグループのセットに割り当てることができます。インスタンスを起動する際にセキュリティグループを指定しなかった場合、インスタンスはその VPC のデフォルトのセキュリティグループに自動的に関連付けられます。詳細については、「[セキュリティグループ](vpc-security-groups.md)」を参照してください。
+ **ネットワークアクセスコントロールリスト (ACL)**: ネットワーク ACL は、サブネットレベルで特定のインバウンドおよびアウトバウンドトラフィックを許可または拒否します。詳細については、「[ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する](vpc-network-acls.md)」を参照してください。
+ **フローログ**: フローログは、 のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャします。VPC、サブネット、または個々のネットワークインターフェイスのフローログを作成できます。フローログデータは、CloudWatch Logs または Amazon S3 に発行され、過度に制限されているか制限のないセキュリティグループとネットワーク ACL ルールを診断するうえで役立ちます。詳細については、「」を参照してください[VPC フローログを使用した IP トラフィックのログ記録](flow-logs.md)
+ **トラフィックのミラーリング**: Amazon EC2 インスタンスの Elastic Network Interface からネットワークトラフィックをコピーできます。その後、トラフィックを帯域外セキュリティアプライアンスおよびモニタリングアプライアンスに送信できます。詳細については、「[トラフィックミラーリングガイド](https://docs.aws.amazon.com/vpc/latest/mirroring/)」を参照してください。
# 転送時の VPC 暗号化を強制する
VPC 暗号化コントロールは、トラフィックフローの暗号化ステータスをモニタリングするための一元的な権限制御を提供するセキュリティおよびコンプライアンス機能です。これにより、クリアテキスト通信が可能なリソースを特定し、最終的にはリージョンでの VPC 内での転送、および複数の VPC 間での転送時に暗号化を強制するメカニズムを提供できるようになります。
VPC 暗号化コントロールでは、アプリケーションレイヤー暗号化と組み込み暗号化の両方を AWS Nitro System ハードウェアの転送機能で使用して、暗号化を確実に強制できるようにします。また、この機能により、ネイティブハードウェアレイヤー暗号化が最新の Nitro インスタンスから Fargate、Application Load Balancer、Transit Gateway などの他の AWS サービスにまで拡張されます。
この機能は、すべてのトラフィックの暗号化ステータスで可視性と制御を確保する必要がある、すべてのユーザー向けに設計されています。HIPAA、FedRamp、PCI DSS などのコンプライアンス基準を満たすためにデータ暗号化が最優先される業界では、特に便利な機能です。セキュリティ管理者とクラウドアーキテクトは、この機能を使用して AWS 環境全体で転送時の暗号化ポリシーを一元的に実践できます。
この機能は、モニタリングモードと強制モードという 2 つのモードで使用できます。
## 暗号化コントロールのモード
**モニタリングモード**
モニタリングモードでは、暗号化コントロールによって、VPC 内および VPC 間の AWS リソース間のトラフィックフローの暗号化ステータスが可視化されます。また、転送時に暗号化が強制されない VPC リソースを特定することもできます。VPC フローログを設定すると、トラフィックが暗号化されているかどうかを示すエンリッチされたフィールド (`encryption-status`) を出力できます。また、コンソールまたは `GetVpcResourcesBlockingEncryptionEnforcement` コマンドを使用して、転送時に暗号化が強制されていないリソースを特定することもできます。
**注記**
既存の VPC は、最初はモニタリングモードでのみ有効にできます。これにより、クリアテキストトラフィックであるリソース、またはクリアテキストトラフィックが可能なリソースを可視化できます。VPC で強制モードを有効にすることができるのは、これらのリソースが暗号化の強制を開始したとき (または暗号化に対する除外を作成したとき) のみです。
**強制モード**
強制モードでは、VPC 暗号化コントロールにより、VPC 境界内で暗号化されていないトラフィックを許可する機能やサービスを使用できなくなります。既存の VPC では、強制モードで暗号化コントロールを直接有効にすることはできません。まず、モニタリングモードで暗号化コントロールを有効にし、非準拠のリソースを特定および変更のうえ転送時に暗号化を強制してから、強制モードを有効にする必要があります。ただし、新規 VPC の場合は、作成時に強制モードで暗号化コントロールを有効にすることができます。
有効にしても、強制モードでは、ネイティブの組み込み暗号化をサポートしていない古い EC2 インスタンスやインターネットゲートウェイなど、暗号化されていない VPC リソースの作成やアタッチはできません。暗号化が強制された VPC で非準拠のリソースを実行する場合は、そのリソースに対して除外を作成する必要があります。
## トラフィックフローの暗号化ステータスのモニタリング
VPC フローログの `encryption-status` フィールドを使用して、VPC 内のトラフィックフローの暗号化ステータスを監査できます。以下のイベント値があります。
+ `0` = 暗号化なし
+ `1` = Nitro 暗号化 (VPC 暗号化コントロールによって管理)
+ `2` = アプリケーション暗号化
+ AWS サービスへのインターフェイスエンドポイントに対する TCP ポート 443 のフロー\$1
+ ゲートウェイエンドポイントに対する TCP ポート 443 のフロー\$1
+ VPC エンドポイント経由で暗号化された Redshift クラスターに対するフロー\$1\$1
+ `3` = Nitro 暗号化とアプリケーション暗号化の両方
+ `(-)` = 不明な暗号化ステータスまたは VPC 暗号化コントロールがオフ
**メモ:**
\$1 インターフェイスエンドポイントとゲートウェイエンドポイントの場合、AWS はパケットデータを調べて暗号化ステータスを判断するのではなく、暗号化ステータスを引き受けるために使用されるポートに依存します。
\$1\$1 指定された AWS マネージドエンドポイントの場合、AWS はサービス設定の TLS の要件に基づいて暗号化ステータスを決定します。
**VPC フローログの制限事項**
+ VPC 暗号化コントロールのフローログを有効にするには、encryption-status フィールドを使用して新しいフローログを手動で作成する必要があります。encryption-status フィールドは、既存のフローログに自動的に追加されません。
+ フローログの詳細を確認するには、\$1\$1traffic-path\$1 フィールドと \$1\$1flow-direction\$1 フィールドをフローログに追加することをお勧めします。
例:
```
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-12345678901234567 \
--traffic-type ALL \
--log-group-name my-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs
--log-format '${encryption-status} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${traffic-path} ${flow-direction} ${reject-reason}'
```
## VPC 暗号化コントロールの除外
VPC 暗号化コントロールの強制モードでは、VPC 内のすべてのリソースに暗号化を強制する必要があります。これにより、リージョンの AWS 内で確実に暗号化が実行されます。ただし、インターネットゲートウェイ、NAT ゲートウェイ、仮想プライベートゲートウェイなど、お客様がエンドツーエンドの暗号化の設定と維持を担当する AWS のネットワーク以外への接続を許可するリソースが含まれている場合があります。これらのリソースを暗号化が強制された VPC で実行するには、リソースの除外を作成できます。除外では、顧客が暗号化の維持を担うリソース (通常はアプリケーションレイヤー) に対して監査可能な例外が作成されます。
VPC 暗号化コントロールでサポートされている除外は 8 つのみです。VPC にこれらのリソースがあり、強制モードに移行する場合は、モニタリングモードから強制モードに切り替えるときにこれらの除外を追加する必要があります。他のリソースは除外できません。これらのリソースの除外を作成することで、VPC を強制モードに移行できます。これらのリソースとの間で送受信されるトラフィックフローの暗号化については、お客様の責任となります。
+ インターネットゲートウェイ
+ NAT Gateway
+ Egress-only インターネットゲートウェイ
+ 暗号化が強制されていない VPC への VPC ピアリング接続 (詳細なシナリオについては、「VPC ピアリングサポート」セクションを参照してください)
+ 仮想プライベートゲートウェイ
+ VPC 内の Lambda 関数
+ VPC Lattice
+ Elastic File System
## 実装ワークフロー
1. **モニタリングを有効化** - モニタリングモードで VPC 暗号化コントロールを作成します
1. **トラフィックの分析** - フローログを確認して、トラフィックフローの暗号化ステータスをモニタリングします
1. **リソースの分析** - コンソールまたは `GetVpcResourcesBlockingEncryptionEnforcement` コマンドを使用して、転送時に暗号化が強制されていないリソースを特定します。
1. **準備 (オプション)** - 強制モードを有効にする場合に、リソースの移行と必要な除外について計画します
1. **強制 (オプション)** - 必要な除外が設定された状態で強制モードに切り替えます
1. **監査** - フローログによる継続的なコンプライアンスのモニタリング
詳細なセットアップ手順については、ブログ記事「[VPC 暗号化コントロールのご紹介: リージョンの VPC 内および VPC 間での転送中の暗号化の強制](https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region)」を参照してください。
## VPC 暗号化コントロールの状態
VPC 暗号化コントロールは、次のいずれかの状態になります。
**作成中**
VPC 暗号化コントロールが VPC に作成されています。
**変更中**
VPC 暗号化コントロールが VPC で変更されています
**削除中**
VPC 暗号化コントロールが VPC で削除されています
**利用可能**
VPC 暗号化コントロールが VPC でのモニタリングモードまたは強制モードの実装に成功しました
## AWS サービスのサポートと互換性
暗号化に準拠するには、ハードウェアレイヤーまたはアプリケーションレイヤーでリソースが常に転送時の暗号化を強制する必要があります。ほとんどのリソースでは、お客様によるアクションは必要ありません。
### 自動コンプライアンスによるサービス
クロスリージョン接続の PrivateLinks など、PrivateLinks でサポートされているほとんどの AWS サービスが、アプリケーションレイヤーで暗号化されたトラフィックを受け入れます。これらのリソースを変更する必要はありません。AWS によって、アプリケーションレイヤーで暗号化されていないトラフィックは自動的にドロップされます。いくつかの例外として、Redshift クラスターなどがあります (プロビジョニング済みとサーバーレスの両方。基盤となるリソースを手動で移行する必要があります)。
### 自動的に移行するリソース
Network Load Balancer、Application Load Balancer、Fargate クラスター、EKS Control Plane は、モニタリングモードを有効にすると、暗号化をネイティブにサポートするハードウェアに自動的に移行します。これらのリソースを変更する必要はありません。AWS で自動的に移行が処理されます。
### 手動による移行が必要なリソース
特定の VPC リソースおよびサービスでは、基盤となるインスタンスタイプを選択する必要があります。最新の EC2 インスタンスでは、すべて転送中の暗号化がサポートされています。お使いのサービスで既に最新の EC2 インスタンスを使用している場合は、変更を加える必要はありません。コンソールまたは GetVpcResourcesBlockingEncryptionEnforcement コマンドを使用して、これらのサービスのいずれかが古いインスタンスを使用しているかどうかを特定できます。このようなリソースを特定する場合は、Nitro System ハードウェアのネイティブ暗号化をサポートする最新の EC2 インスタンスにアップグレードする必要があります。これらのサービスには、EC2 インスタンス、Auto Scaling グループ、RDS (すべてのデータベースおよびドキュメント DB)、プロビジョニングされた Elasticache、Amazon Redshift でプロビジョニングされたクラスター、EKS、ECS-EC2、プロビジョニングされた OpenSearch、EMR が含まれます。
**互換性のあるリソース:**
次のリソースは VPC 暗号化コントロールと互換性があります。
+ [Nitro ベースの EC2 インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit)
+ Network Load Balancer (制限付き)
+ アプリケーション ロード バランサー
+ AWS Fargate クラスター
+ Amazon Elastic Kubernetes Service (EKS)
+ Amazon EC2 Auto Scaling グループ
+ Amazon Relational Database Service (RDS: すべてのデータベース)
+ Amazon ElastiCache のノードベースのクラスター
+ Amazon Redshift でプロビジョニングされたクラスターとサーバーレスクラスター
+ Amazon Elastic Container Service (ECS) - EC2 コンテナインスタンス
+ Amazon OpenSearch Service
+ Amazon Elastic MapReduce (EMR)
+ Amazon Managed Streaming for Apache Kafka (Amazon MSK)
+ VPC 暗号化コントロールにより、PrivateLink 経由でアクセスされるすべての AWS サービスに対して、アプリケーションレイヤーで暗号化が強制されます。アプリケーションレイヤーで暗号化されていないトラフィックは、VPC 内でホストされている PrivateLink エンドポイントと強制モードの暗号化コントロールによってドロップされます。
### サービス固有の制限
**Network Load Balancer の制限**
TLS 設定: 含まれる VPC で暗号化コントロールを強制する場合に、TLS リスナーを使用して、暗号化と復号の作業をロードバランサーにオフロードすることはできません。ただし、TLS 暗号化と復号を実行するようにターゲットを設定できます。
**プロビジョニングされた Redshift とサーバーレスの Redshift**
既存のクラスター/エンドポイントが含まれる VPC で、顧客が強制モードに移行することはできません。Redshift で VPC 暗号化コントロールを使用するには、スナップショットからクラスターまたは名前空間を復元する必要があります。プロビジョニングされたクラスターの場合は、既存の Redshift クラスターのスナップショットを作成し、クラスタースナップショットからの復元オペレーションを使用してスナップショットから復元します。サーバーレスクラスターの場合は、既存の名前空間のスナップショットを作成し、サーバーレスワークグループのスナップショットからの復元オペレーションを使用してスナップショットから復元します。VPC 暗号化コントロールは、スナップショットと復元プロセスを実行しないと、既存のクラスターまたは名前空間で有効にできないことに注意してください。スナップショットの作成については、[Amazon Redshift のドキュメント](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html)を参照してください。
**Amazon MSK (Managed Streaming for Apache Kafka)**
この機能は、独自の VPC の 4.1 に対応する、新しいクラスターでサポートされています。次の手順は、MSK で VPC 暗号化を使用する際に役立ちます。
+ 顧客は、他に MSK クラスターのない VPC で VPC 暗号化を有効にします
+ 顧客は、Kafka バージョン 4.1 を使用し、インスタンスタイプを M7g としてクラスターを作成します
### リージョンとゾーンの制限
+ **ローカルゾーンサブネット**: 強制モードではサポートされていません - VPC から削除する必要があります
### VPC ピアリングサポート
2 つの VPC 間で VPC ピアリングを使用して転送時の暗号化を確実に実行するには、2 つの VPC が同じリージョンに存在し、暗号化コントロールが除外なく強制モードで有効になっている必要があります。暗号化が強制された VPC を、別のリージョンに存在する、または強制モードで暗号化コントロールが有効になっていない (除外のない) 別の VPC にピアリングする場合は、ピアリングの除外を作成する必要があります。
2 つの VPC が強制モードで相互にピアリングしている場合、強制モードからモニタリングモードに変更することはできません。VPC 暗号化コントロールでモニタリングモードに変更する前に、まずピアリングの除外を作成する必要があります。
### Transit Gateway 暗号化サポート
暗号化コントロールが有効になっている VPC 間のトラフィックを暗号化するには、Transit Gateway で暗号化サポートを明示的に有効にする必要があります。既存の Transit Gateway で暗号化を有効にすると、既存のトラフィックフローが中断されることなく、暗号化されたレーンへの VPC アタッチメントの移行がシームレスかつ自動的に実行されます。強制モード (除外なし) では、Transit Gateway を介した 2 つの VPC 間のトラフィックは、100% 暗号化されたレーンを通過します。また、Transit Gateway での暗号化によって、異なる暗号化コントロールモードでも同様に 2 つの VPC を接続できます。これは、暗号化が強制されていない VPC に接続する暗号化コントロールを VPC に強制するときに使用する必要があります。このようなシナリオでは、VPC 間トラフィックを含む、暗号化が強制された VPC 内のすべてのトラフィックが暗号化されます。VPC 間トラフィックは、暗号化が強制された VPC 内のリソースと Transit Gateway の間で暗号化されます。さらに、暗号化は、トラフィックが強制されていない VPC で送信されるリソースに依存し、暗号化が保証されません (VPC は強制モードではないため)。すべての VPC は同じリージョンに存在する必要があります (詳細は[こちら](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-encryption-support.html)をご覧ください)。
![\[暗号化コントロールのステータスが異なる VPC 間のトラフィックフロー\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-enc-control-arch.png)
+ この図では、VPC 1、VPC 2、VPC3 の暗号化コントロールが強制モードで実行され、暗号化コントロールがモニタリングモードで実行されている VPC 4 に接続されます。
+ VPC1、VPC2、VPC3 間のすべてのトラフィックが暗号化されます。
+ 具体的には、VPC 1 のリソースと VPC 4 のリソース間のトラフィックが、Nitro System ハードウェアによって提供される暗号化を使用する Transit Gateway まで暗号化されます。さらに、暗号化ステータスは VPC 4 のリソースに依存し、暗号化される保証はありません。
Transit Gateway 暗号化サポートの詳細については、[Transit Gateway ドキュメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-encryption-support.html)を参照してください。
## 料金
料金については、「[Amazon VPC の料金](https://aws.amazon.com/vpc/pricing/)」を参照してください。
## AWS CLI コマンドリファレンス
### セットアップと設定
+ [aws ec2 create-vpc-encryption-control](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc-encryption-control.html)
+ [aws ec2 modify-vpc-encryption-control](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpc-encryption-control.html)
+ [aws ec2 tgw modify-transit-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway.html)
### モニタリングとトラブルシューティング
+ [aws ec2 describe-vpc-encryption-controls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpc-encryption-controls.html)
+ [aws ec2 get-vpc-resources-blocking-encryption-enforcement](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-vpc-resources-blocking-encryption-enforcement.html)
+ [aws ec2 create-flow-logs](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-flow-logs.html)
+ [aws ec2 describe-flow-logs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-flow-logs.html)
+ [aws logs query](https://docs.aws.amazon.com/cli/latest/reference/logs/query.html)
### クリーンアップ
+ [aws ec2 delete-vpc-encryption-control](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpc-encryption-control.html)
## その他のリソース
詳細なセットアップ手順については、ブログ記事「[VPC 暗号化コントロールのご紹介: リージョンの VPC 内および VPC 間での転送中の暗号化の強制](https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region)」を参照してください。
API 情報の詳細については、「[EC2 API リファレンスガイド](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html)」を参照してください。
# Amazon VPC の Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービス です。IAM 管理者は、誰を*認証* (サインイン) し、誰に Amazon VPC リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、追加費用なしで使用できる AWS のサービスです。
**Topics**
+ [対象者](#security_iam_audience)
+ [ID で認証する](#security_iam_authentication)
+ [ポリシーを使用してアクセスを管理する](#security_iam_access-manage)
+ [Amazon VPC で IAM を使用する方法](security_iam_service-with-iam.md)
+ [Amazon VPC ポリシーの例](vpc-policy-examples.md)
+ [Amazon VPC の ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ [Amazon Virtual Private Cloud の AWS 管理ポリシー](security-iam-awsmanpol.md)
+ [VPC のサービスにリンクされたロールの使用](using-service-linked-roles.md)
## 対象者
AWS Identity and Access Management (IAM) の用途は、Amazon VPC で行う作業によって異なります。
**サービスユーザー** – ジョブを実行するために Amazon VPC サービスを使用する場合は、管理者から必要なアクセス許可と認証情報が与えられます。さらに多くの Amazon VPC 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon VPC の機能にアクセスできない場合は、「[Amazon VPC の ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。
**サービス管理者** – 社内の Amazon VPC リソースを担当している場合は、通常、Amazon VPC へのフルアクセスがあります。管理者は、従業員にアクセスを許可する Amazon VPC 機能とリソースを決定します。サービスユーザーのアクセス許可を変更するリクエストを IAM 管理者に送信します。IAM の基本概念については、このページの情報を確認します。会社で Amazon VPC を使用して IAM を利用する方法の詳細については、「[Amazon VPC で IAM を使用する方法](security_iam_service-with-iam.md)」を参照してください。
**IAM 管理者** – 管理者は、Amazon VPC へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。ポリシーの例を表示するには、「[Amazon VPC ポリシーの例](vpc-policy-examples.md)」を参照してください。
## ID で認証する
認証は、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、IAM ユーザー の AWS アカウントのルートユーザー として、または IAM ロールを引き受けることによって、認証される 必要があります。
AWS IAM アイデンティティセンター (IAM アイデンティティセンター)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント のルートユーザー
AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)、または AWS CLI や AWS API オペレーションを呼び出すことで、ロールを引き受けることができます。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用してアクセスを管理する
AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは、アイデンティティやリソースとの関連付けに伴うアクセス許可を定義します。AWS は、プリンシパルがリクエストを行うときに、これらのポリシーを評価します。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは IAM の AWSマネージドポリシーは使用できません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
### 他のポリシータイプ
AWS は、より一般的なポリシータイプで付与された最大数のアクセス許可を設定できる、追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations 内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、「*IAM ユーザーガイド*」の「[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# Amazon VPC で IAM を使用する方法
IAM を使用して Amazon VPC へのアクセスを管理する前に、Amazon VPC で使用できる IAM 機能について理解しておく必要があります。Amazon VPC およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには、「*IAM ユーザーガイド*」の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [アクション](#security_iam_service-with-iam-id-based-policies-actions)
+ [リソース](#security_iam_service-with-iam-id-based-policies-resources)
+ [条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys)
+ [Amazon VPC リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies)
+ [タグに基づいた承認](#security_iam_service-with-iam-tags)
+ [IAM ロール](#security_iam_service-with-iam-roles)
IAM アイデンティティベースのポリシーでは、許可されるアクションまたは拒否されるアクションを指定できます。一部のアクションでは、アクションを許可または拒否するリソースと条件を指定できます。Amazon VPC は、特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については「*IAM ユーザーガイド*」の「[IAM JSON ポリシーエレメントのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
## アクション
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Amazon VPC は、その API 名前空間を Amazon EC2 と共有します。Amazon VPC のポリシーアクションは、アクションの前にプレフィックス `ec2:` を使用します。例えば、`CreateVpc` API オペレーションを使用して VPC を作成するアクセス許可を付与するには、`ec2:CreateVpc` アクションへのアクセス許可を付与します。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。
1 つのステートメントで複数のアクションを指定するには、次の例のようにカンマで区切ります。
```
"Action": [
"ec2:action1",
"ec2:action2"
]
```
ワイルドカード (\$1) を使用して複数のアクションを指定することができます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。
```
"Action": "ec2:Describe*"
```
Amazon VPC アクションのリストを確認するには、「*Service Authorization Reference*」の「[Actions defined by Amazon EC2](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)」を参照してください。
## リソース
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
VPC リソースには、次の例に示す ARN があります。
```
arn:${Partition}:ec2:${Region}:${Account}:vpc/${VpcId}
```
たとえば、ステートメントで `vpc-1234567890abcdef0` VPC を指定するには、次の例に示す ARN を使用します。
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-1234567890abcdef0"
```
特定のアカウントに属する特定のリージョン内のすべての VPC を指定するには、ワイルドカード (\$1) を使用します。
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:vpc/*"
```
リソースの作成など、一部の Amazon VPC アクションは、特定のリソースで実行できません。このような場合は、ワイルドカード (\$1) を使用する必要があります。
```
"Resource": "*"
```
Amazon EC2 API アクションの多くが複数のリソースと関連します。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。
```
"Resource": [
"resource1",
"resource2"
]
```
Amazon VPC リソースのタイプとその ARN のリストを確認するには、「*Service Authorization Reference*」の「[Resource types defined by Amazon EC2](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-resources-for-iam-policies)」を参照してください。
## 条件キー
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどんな**リソース**にどんな**条件**で**アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。
すべての Amazon EC2 アクションは `aws:RequestedRegion` および `ec2:Region` 条件キーをサポートします。詳細については、「[例: 特定のリージョンへのアクセスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)」を参照してください。
Amazon VPC は独自の条件キーを定義し、一部のグローバル条件キーの使用をサポートしています。Amazon VPC 条件キーのリストを確認するには、「*Service Authorization Reference*」の「[Condition keys for Amazon EC2](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys)」を参照してください。どのアクションおよびリソースと条件キーを使用できるかについては、「[Amazon EC2 で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)」を参照してください。
## Amazon VPC リソースベースのポリシー
リソースベースのポリシーとは、Amazon VPC リソース上で指定するプリンシパルとしてのどのアクションをどの条件で実行できるかを指定する JSON ポリシードキュメントです。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、[リソースベースのポリシーのプリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)として指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる AWS アカウントにある場合は、リソースにアクセスするためのアクセス許可をプリンシパルエンティティにも付与する必要があります。アクセス許可は、アイデンティティベースのポリシーをエンティティにアタッチすることで付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、ID ベースのポリシーをさらに付与する必要はありません。詳細については、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
## タグに基づいた承認
タグを Amazon VPC リソースにアタッチするか、リクエストでタグを渡すことができます。タグに基づいてアクセスを制御するには、条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[リソース作成時にタグ付けする許可の付与](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/supported-iam-actions-tagging.html)」を参照してください。
リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースのポリシーの例を表示するには、「[特定の VPC 内にインスタンスを起動する](vpc-policy-examples.md#subnet-ami-example-iam)」を参照してください。
## IAM ロール
[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) は、特定の権限を持つ、AWS アカウント 内のエンティティです。
### 一時認証情報の使用
一時的な認証情報を使用して、フェデレーションでサインイン、IAM ロールを引き受ける、またはクロスアカウントロールを引き受けることができます。一時的なセキュリティ認証情報を取得するには、[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS STS API オペレーションを呼び出します。
Amazon VPC では、一時認証情報の使用をサポートしています。
### サービスにリンクされたロール
[サービスリンクロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)は、AWS サービスが他のサービスのリソースにアクセスしてお客様の代わりにアクションを完了することを許可します。サービスリンクロールは IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
[トランジットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/tgw/service-linked-roles.html)は、サービスにリンクされたロールをサポートします。
### サービスロール
この機能により、ユーザーに代わってサービスが[サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)を引き受けることが許可されます。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールはIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、これを行うことにより、サービスの機能が損なわれる場合があります。
Amazon VPC では、フローログのサービスロールがサポートされています。フローログを作成するときは、フローログサービスへ CloudWatch Logs のアクセスを許可するロールを選択する必要があります。詳細については、「[CloudWatch Logs へのフローログ発行のための IAM ロール](flow-logs-iam-role.md)」を参照してください。
# Amazon VPC ポリシーの例
デフォルトでは、IAM ロールには、VPC リソースを作成または変更するアクセス許可はありません。AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、ロールに必要な、指定されたリソースで特定の API オペレーションを実行するアクセス許可をロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらのアクセス許可が必要な IAM ロールに、そのポリシーをアタッチします。
これらサンプルの、JSON ポリシードキュメントを使用して、IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [Amazon VPC コンソールを使用する](#security_iam_id-based-policy-examples-console)
+ [パブリックサブネットを持つ VPC を作成する](#vpc-public-subnet-iam)
+ [VPC リソースの変更と削除](#modify-vpc-resources-iam)
+ [セキュリティグループの管理](#vpc-security-groups-iam)
+ [セキュリティグループルールの管理](#vpc-security-group-rules-iam)
+ [特定のサブネット内にインスタンスを起動する](#subnet-sg-example-iam)
+ [特定の VPC 内にインスタンスを起動する](#subnet-ami-example-iam)
+ [VPC とサブネットへのパブリックアクセスをブロックする](#vpc-bpa-example-iam)
+ [その他の Amazon VPC ポリシーの例](#security-iam-additional-examples)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内で誰かが Amazon VPC リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、AWS アカウント に費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## Amazon VPC コンソールを使用する
Amazon VPC コンソールにアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、AWS アカウントの Amazon VPC リソースの詳細をリストおよび表示できます。最小限必要なアクセス許可よりも厳しく制限されたアイデンティティベースポリシーを作成すると、そのポリシーを添付したエンティティ (IAM ロール) に対してコンソールが意図したとおりに機能しません。
次のポリシーは、VPC コンソールでリソースを一覧表示するアクセス許可をロールに付与しますが、リソースを作成、更新、削除することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeClassicLinkInstances",
"ec2:DescribeClientVpnEndpoints",
"ec2:DescribeCustomerGateways",
"ec2:DescribeDhcpOptions",
"ec2:DescribeEgressOnlyInternetGateways",
"ec2:DescribeFlowLogs",
"ec2:DescribeInternetGateways",
"ec2:DescribeManagedPrefixLists",
"ec2:DescribeMovingAddresses",
"ec2:DescribeNatGateways",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaceAttribute",
"ec2:DescribeNetworkInterfacePermissions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePrefixLists",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroupReferences",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeStaleSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeTrafficMirrorFilters",
"ec2:DescribeTrafficMirrorSessions",
"ec2:DescribeTrafficMirrorTargets",
"ec2:DescribeTransitGateways",
"ec2:DescribeTransitGatewayVpcAttachments",
"ec2:DescribeTransitGatewayRouteTables",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcClassicLink",
"ec2:DescribeVpcClassicLinkDnsSupport",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcEndpointConnectionNotifications",
"ec2:DescribeVpcEndpointConnections",
"ec2:DescribeVpcEndpointServiceConfigurations",
"ec2:DescribeVpcEndpointServicePermissions",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcPeeringConnections",
"ec2:DescribeVpcs",
"ec2:DescribeVpnConnections",
"ec2:DescribeVpnGateways",
"ec2:GetManagedPrefixListAssociations",
"ec2:GetManagedPrefixListEntries"
],
"Resource": "*"
}
]
}
```
------
AWS CLI または AWS API のみを呼び出すロールには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、ロールが実行する必要がある API オペレーションに一致するアクションのみへのアクセスが許可されます。
## パブリックサブネットを持つ VPC を作成する
次の例では、ロールが VPC、サブネット、ルートテーブル、およびインターネットゲートウェイを作成できるようにします。ロールは、インターネットゲートウェイを VPC にアタッチし、ルートテーブルにルートを作成することもできます。`ec2:ModifyVpcAttribute` アクションにより、ロールは、VPC 内で起動される各インスタンスが DNS ホスト名を受け取ることができるように、VPC の DNS ホスト名を有効にできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:CreateVpc",
"ec2:CreateSubnet",
"ec2:DescribeAvailabilityZones",
"ec2:CreateRouteTable",
"ec2:CreateRoute",
"ec2:CreateInternetGateway",
"ec2:AttachInternetGateway",
"ec2:AssociateRouteTable",
"ec2:ModifyVpcAttribute"
],
"Resource": "*"
}
]
}
```
------
前述のポリシーにより、ロールは、Amazon VPC コンソールで VPC を作成することもできます。
## VPC リソースの変更と削除
ロールが変更または削除できる VPC リソースを制御することもできます。例えば、次のポリシーでは、タグ `Purpose=Test` を持つルートテーブルの操作と削除をロールに許可します。また、このポリシーでは、ロールがタグ `Purpose=Test` を持つインターネットゲートウェイのみを削除できることを指定します。ロールは、このタグを持たないルートテーブルまたはインターネットゲートウェイを操作できません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteInternetGateway",
"Resource": "arn:aws:ec2:*:*:internet-gateway/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Test"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteRouteTable",
"ec2:CreateRoute",
"ec2:ReplaceRoute",
"ec2:DeleteRoute"
],
"Resource": "arn:aws:ec2:*:*:route-table/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Test"
}
}
}
]
}
```
------
## セキュリティグループの管理
次のポリシーでは、ロールがセキュリティグループを管理することを許可します。1 番目のステートメントでは、タグ `Stack=test` の付いたセキュリティグループを削除したり、タグ `Stack=test` の付いたセキュリティグループのインバウンドおよびアウトバウンドのルールを管理することをロールに許可します。2 番目のステートメントでは、ロールが作成したセキュリティグループにタグ `Stack=Test` を付ける必要があります。3 番目のステートメントは、セキュリティグループの作成時に、タグを作成することをロールに許可します。4 番目のステートメントでは、すべてのセキュリティグループとセキュリティグループのルールを表示することをロールに許可します。5 番目のステートメントは、VPC にセキュリティグループを作成することをロールに許可します。
**注記**
AWS CloudFormation サービスでは、このポリシーを使用して、必須タグを含むセキュリティグループを作成することはできません。タグを必要とする `ec2:CreateSecurityGroup` アクションの条件を削除すると、このポリシーが機能します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:DeleteSecurityGroup",
"ec2:ModifySecurityGroupRules",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress"
],
"Resource": "arn:aws:ec2:*:*:security-group/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Stack": "test"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateSecurityGroup",
"Resource": "arn:aws:ec2:*:*:security-group/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Stack": "test"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "Stack"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:security-group/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateSecurityGroup"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateSecurityGroup",
"Resource": "arn:aws:ec2:*:*:vpc/*"
}
]
}
```
------
インスタンスに関連付けられたセキュリティグループをロールが変更できるようにするには、ポリシーに `ec2:ModifyInstanceAttribute` アクションを追加します。
ロールがネットワークインターフェイスのセキュリティグループを変更できるようにするには、ポリシーに `ec2:ModifyNetworkInterfaceAttribute` アクションを追加します。
## セキュリティグループルールの管理
次のポリシーは、セキュリティグループとセキュリティグループルールの表示、特定の VPC のセキュリティグループのインバウンドおよびアウトバウンドのルールの追加と削除、および指定された VPC のルールの説明を変更するアクセス許可をロールに付与します。1 番目のステートメントでは、`ec2:Vpc` 条件キーを使用して、特定の VPC に許可をスコープしています。
2 番目のステートメントは、すべてのセキュリティグループ、セキュリティグループルール、タグについて説明するアクセス許可をロールに付与します。これにより、ロールはセキュリティグループルールを表示して変更できるようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress",
"ec2:ModifySecurityGroupRules"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:security-group/*",
"Condition": {
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-1234567890abcdef0"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySecurityGroupRules"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:security-group-rule/*"
}
]
}
```
------
## 特定のサブネット内にインスタンスを起動する
以下のポリシーは、特定のサブネット内にインスタンスを起動し、リクエストで特定のセキュリティグループを使用するアクセス許可をロールに付与します。このポリシーは、サブネットの ARN およびセキュリティグループの ARN を指定することで許可を与えます。ロールが別のサブネット内でまたは別のセキュリティグループを使用してインスタンスを起動しようとすると、リクエストは失敗します (ただし、別のポリシーまたは別の定義文で、ロールにそのアクセス許可が付与されている場合を除きます)。
このポリシーは、ネットワークインターフェイスリソースを使用する許可も与えます。サブネット内に起動すると、`RunInstances` リクエストは、デフォルトでプライマリネットワークインターフェイスを作成するので、ロールには、インスタンスを起動するときにこのリソースを作成するアクセス許可が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:123456789012:instance/*",
"arn:aws:ec2:us-east-1:123456789012:subnet/subnet-1234567890abcdef0",
"arn:aws:ec2:us-east-1:123456789012:network-interface/*",
"arn:aws:ec2:us-east-1:123456789012:volume/*",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/sg-0abcdef1234567890"
]
}
]
}
```
------
## 特定の VPC 内にインスタンスを起動する
以下のポリシーは、特定の VPC 内の任意のサブネットにインスタンスを起動するアクセス許可をロールに付与します。このポリシーは、条件キー (`ec2:Vpc`) をサブネットリソースに適用することで許可を与えます。
また、このポリシーは、タグ「`department=dev`」のある AMI のみを使用してインスタンスを起動するアクセス許可をロールに付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:123456789012:subnet/*",
"Condition": {
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:123456789012:vpc/vpc-1234567890abcdef0"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/department": "dev"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:123456789012:instance/*",
"arn:aws:ec2:us-east-1:123456789012:volume/*",
"arn:aws:ec2:us-east-1:123456789012:network-interface/*",
"arn:aws:ec2:us-east-1:123456789012:key-pair/*",
"arn:aws:ec2:us-east-1:123456789012:security-group/*"
]
}
]
}
```
------
## VPC とサブネットへのパブリックアクセスをブロックする
次のポリシー例は、[VPC ブロックパブリックアクセス (BPA) 機能](security-vpc-bpa.md)を使用して VPC およびサブネット内のリソースに対するパブリックアクセスをブロックするための許可をロールに付与します。
例 1 - VPC BPA アカウント全体の設定と VPC BPA の除外に対する読み取り専用アクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VPCBPAReadOnlyAccess",
"Action": [
"ec2:DescribeVpcBlockPublicAccessOptions",
"ec2:DescribeVpcBlockPublicAccessExclusions"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
例 2 - VPC BPA アカウント全体の設定と VPC BPA の除外に対する読み取りおよび書き込みのフルアクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VPCBPAFullAccess",
"Action": [
"ec2:DescribeVpcBlockPublicAccessOptions",
"ec2:DescribeVpcBlockPublicAccessExclusions",
"ec2:ModifyVpcBlockPublicAccessOptions",
"ec2:CreateVpcBlockPublicAccessExclusion",
"ec2:ModifyVpcBlockPublicAccessExclusion",
"ec2:DeleteVpcBlockPublicAccessExclusion"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
例 3 - VPC BPA の設定の変更と除外の作成を除くすべての EC2 API に対するアクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2FullAccess",
"Action": [
"ec2:*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "VPCBPAPartialAccess",
"Action": [
"ec2:ModifyVpcBlockPublicAccessOptions",
"ec2:CreateVpcBlockPublicAccessExclusion"
],
"Effect": "Deny",
"Resource": "*"
}
]
}
```
------
## その他の Amazon VPC ポリシーの例
Amazon VPC に関連するその他の IAM ポリシーの例については、次のドキュメントを参照してください。
+ [マネージドプレフィックスリスト](managed-prefix-lists.md#managed-prefix-lists-iam)
+ [トラフィックのミラーリング](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-security.html)
+ [トランジットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-authentication-access-control.html#tgw-example-iam-policies)
+ [VPC エンドポイントおよび VPC エンドポイントサービス (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/security_iam_id-based-policy-examples.html)
+ [VPC ピアリング接続](https://docs.aws.amazon.com/vpc/latest/peering/security-iam.html)
# Amazon VPC の ID とアクセスのトラブルシューティング
次の情報は、Amazon VPC と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [Amazon VPC でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [AWS アカウント以外のユーザーに Amazon VPC リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## Amazon VPC でアクションを実行する権限がない
AWS マネジメントコンソール から、アクションを実行する権限がないと通知された場合は、管理者に問い合わせてサポートを依頼する必要があります。サインイン認証情報を提供した担当者が管理者です。
以下の例のエラーは、`mateojackson` IAM ユーザーがコンソールを使用して、サブネットの詳細を表示しようとしているが、`ec2:DescribeSubnets` アクセス許可がない IAM ロールに属していた場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: ec2:DescribeSubnets on resource: subnet-id
```
この場合、Mateo は、サブネットにアクセスできるように、ポリシーの更新を管理者に依頼します。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon VPC にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールやサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon VPC でアクションを実行しようする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## AWS アカウント以外のユーザーに Amazon VPC リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外のユーザーが、リソースへのアクセスに使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Amazon VPC がこれらの機能をサポートしているかどうかについては、「[Amazon VPC で IAM を使用する方法](security_iam_service-with-iam.md)」を参照してください。
+ 所有している AWS アカウント 全体のリソースへのアクセス権を提供する方法については、「*IAM ユーザーガイド*」の「[所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。
+ サードパーティの AWS アカウント にリソースへのアクセス権を提供する方法については、「*IAM ユーザーガイド*」の「[サードパーティが所有する AWS アカウント へのアクセス権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
# Amazon Virtual Private Cloud の AWS 管理ポリシー
AWS マネージドポリシーは、AWS が作成および管理するスタンドアロンポリシーです。AWS マネージドポリシーは、多くの一般的なユースケースに対してアクセス許可を提供するように設計されているため、ユーザー、グループ、ロールへのアクセス許可の割り当てを開始できます。
AWS マネージドポリシーは、ご利用の特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることにご注意ください。これは、すべての AWS ユーザーが使用できるようになるのを避けるためです。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS マネージドポリシーで定義されたアクセス許可は変更できません。AWS が AWS マネージドポリシーに定義されているアクセス許可を更新すると、更新はポリシーがアタッチされているすべてのプリンシパルアイデンティティ (ユーザー、グループ、ロール) に影響します。新しい AWS のサービス を起動するか、既存のサービスで新しい API オペレーションが使用可能になると、AWS が AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS 管理ポリシー: AmazonVPCFullAccess
`AmazonVPCFullAccess` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、Amazon VPC への完全なアクセスを可能にする許可を付与します。
このポリシーの許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonVPCFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonVPCFullAccess.html)」を参照してください。
## AWS 管理ポリシー: AmazonVPCReadOnlyAccess
`AmazonVPCReadOnlyAccess` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、Amazon VPC への読み取り専用アクセスを可能にする許可を付与します。
このポリシーの許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonVPCReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonVPCReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: AmazonVPCCrossAccountNetworkInterfaceOperations
`AmazonVPCCrossAccountNetworkInterfaceOperations` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、ID がネットワークインターフェイスを作成し、クロスアカウントリソースにアタッチするためのアクセス許可を付与します。
このポリシーの許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AmazonVPCCrossAccountNetworkInterfaceOperations](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonVPCCrossAccountNetworkInterfaceOperations.html)」を参照してください。
## AWS マネージドポリシー: AWSServiceRoleForNATGateway
`AWSServiceRoleForNATGateway` ポリシーを IAM アイデンティティにアタッチできます。このポリシーにより、ユーザーに代わってリージョン NAT ゲートウェイを自動的にスケールする ID を許可するアクセス許可を付与します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSServiceRoleForNATGateway](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForNATGateway.html)」を参照してください。
## Amazon VPC による AWS 管理ポリシーの更新
Amazon VPC の AWS 管理ポリシーに対する更新の詳細について、このサービスがこれらの変更の追跡を開始した 2021 年 3 月以降のものを表示します。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWS 管理ポリシー: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) - 既存ポリシーへの更新 | AWSIPAMServiceRolePolicy マネージドポリシー (ec2:ModifyManagedPrefixList、ec2:DescribeManagedPrefixLists、および ec2:GetManagedPrefixListEntries) に追加されたアクションで、IPAM がマネージドプレフィックスリストを変更および読み取りできるようになりました。 | 2025 年 10 月 31 日 |
| [AWS マネージドポリシー: AWSServiceRoleForNATGateway](#security-iam-awsmanpol-AWSServiceRoleForNATGateway) - 新しいポリシー | 新しい AWSServiceRoleForNATGateway ポリシーにより、リージョン NAT ゲートウェイを自動的にスケールする ID を許可します。 | 2025 年 11 月 19 日 |
| [AWS 管理ポリシー: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) – 既存ポリシーへの更新 | VPC とセキュリティグループの関連付けの関連付け実行、関連付けの解除、および表示を可能にする AssociateSecurityGroupVpc、DescribeSecurityGroupVpcAssociations、および DisassociateSecurityGroupVpc アクションが追加されました。 | 2024 年 12 月 9 日 |
| [AWS 管理ポリシー: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) – 既存ポリシーへの更新 | VPC とセキュリティグループの関連付けを表示できる DescribeSecurityGroupVpcAssociations アクションが追加されました。 | 2024 年 12 月 9 日 |
| [AWS 管理ポリシー: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) – 既存ポリシーへの更新 | VPC で使用可能なセキュリティグループを取得できる GetSecurityGroupsForVpc アクションを追加しました。 | 2024 年 2 月 8 日 |
| [AWS 管理ポリシー: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) – 既存ポリシーへの更新 | VPC で使用可能なセキュリティグループを取得できる GetSecurityGroupsForVpc アクションを追加しました。 | 2024 年 2 月 8 日 |
| [AWS 管理ポリシー: AmazonVPCCrossAccountNetworkInterfaceOperations](#security-iam-awsmanpol-AmazonVPCCrossAccountNetworkInterfaceOperations) – 既存ポリシーへの更新 | ネットワークインターフェイスに関連付けられた IPv6 アドレスを管理できる AssignIpv6Addresses アクション および UnassignIpv6Addresses アクションが追加されました。 | 2023 年 9 月 25 日 |
| [AWS 管理ポリシー: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) – 既存ポリシーへの更新 | [セキュリティグループルール](security-group-rules.md)を表示できる DescribeSecurityGroupRules アクションが追加されました。 | 2021 年 8 月 2 日 |
| [AWS 管理ポリシー: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) – 既存ポリシーへの更新 | [セキュリティグループルール](security-group-rules.md)を表示、変更できる DescribeSecurityGroupRules および ModifySecurityGroupRules アクションが追加されました。 | 2021 年 8 月 2 日 |
| [AWS 管理ポリシー: AmazonVPCFullAccess](#security-iam-awsmanpol-AmazonVPCFullAccess) – 既存ポリシーへの更新 | キャリアゲートウェイ、IPv6 プール、ローカルゲートウェイ、およびローカルゲートウェイルートテーブルに対するアクションが追加されました。 | 2021 年 6 月 23 日 |
| [AWS 管理ポリシー: AmazonVPCReadOnlyAccess](#security-iam-awsmanpol-AmazonVPCReadOnlyAccess) – 既存ポリシーへの更新 | キャリアゲートウェイ、IPv6 プール、ローカルゲートウェイ、およびローカルゲートウェイルートテーブルに対するアクションが追加されました。 | 2021 年 6 月 23 日 |
# VPC のサービスにリンクされたロールの使用
Amazon VPC は、AWS Identity and Access Management (IAM) の[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスリンクロールは、VPC に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、VPC が事前定義しており、このサービスがお客様の代わりにその他の AWS サービスを呼び出すのに必要なアクセス許可がすべて含まれています。
サービスにリンクされたロールを使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、VPC の設定が簡単になります。VPC は、サービスにリンクされたロールのアクセス許可を定義します。特に定義されている場合を除き、VPC のみがそのロールを引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。これにより、リソースにアクセスするための許可を意図せず削除することが防止され、VPC リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、**サービスリンクロール列**内で**はい**と表記されたサービスを確認してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。
## VPC のサービスにリンクされたロールのアクセス許可
VPC は、**AWSServiceRoleForNATGateway** という名前のサービスにリンクされたロールを使用します。このサービスにリンクされたロールにより、Amazon VPC はユーザーに代わって Elastic IP アドレスを割り当ててリージョン NAT ゲートウェイを自動的にスケールし、リクエストに応じて既存の Elastic IP をリージョン NAT ゲートウェイに関連付け/関連付け解除したり、ネットワークインターフェイスを記述して既存のインフラストラクチャを識別し、新しいアベイラビリティーゾーンに自動的に拡張したりできます。
AWSServiceRoleForNATGateway サービスリンクロールは、次のサービスを信頼してロールを引き受けます。
+ `ec2-nat-gateway.amazonaws.com`
AWSNATGatewayServiceRolePolicy という名前のロール許可ポリシーは、指定されたリソースで VPC が以下のアクションを完了できるようにします。
+ アクション: サービスマネージド EIP の `AllocateAddress` を使用して、ユーザーに代わり EIP を割り当てます。サービスマネージド EIP により、サービスマネージドタグと ReleaseAddress による後続のタグ付けが自動的に処理されます。
+ アクション: 既存の Elastic IP アドレスで `AssociateAddress` を使用して、リクエストに応じリージョン NAT ゲートウェイに手動で関連付けます。
+ アクション: 既存の Elastic IP アドレスで `DisassociateAddress` を使用して、リクエストに応じリージョン NAT ゲートウェイから削除します。
+ アクション: `DescribeAddresses` を使用して、関連付けで顧客が指定した EIP からパブリック IP アドレス情報を取得します。
+ アクション: 既存のネットワークインターフェイスで、`DescribeNetworkInterface` を使用してインフラストラクチャが存在するアベイラビリティーゾーンを自動的に識別し、新しいゾーンに自動的にスケールアウトします。
ユーザー、グループ、またはロールにサービスリンクロールの作成、編集、または削除を許可するには、アクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## VPC のサービスにリンクされたロールの作成
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で「リージョン」アベイラビリティーモードを使用して NAT ゲートウェイを作成すると、VPC によってサービスにリンクされたロールが作成されます。
**重要**
このサービスリンクロールはこのロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。また、2017 年 1 月 1 日以前に VPC サービスを使用していた場合、サービスにリンクされたロールのサポートが開始された時点で、VPC が [AWSServiceRoleForNATGateway] ロールをアカウントに作成済みです。詳細については、「[AWS アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。「リージョン」アベイラビリティーモードで NAT ゲートウェイを作成すると、VPC によってサービスにリンクされたロールが再度作成されます。
また、**AWSServiceRoleForNATGateway** ユースケースでサービスにリンクされたロールを作成するには、IAM コンソールを使用できます。AWS CLI または AWS API では、`ec2-nat-gateway.amazonaws.com` サービス名を使用してサービスリンクロールを作成します。詳細については、*IAM ユーザーガイド*の「[サービスリンクロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。このサービスリンクロールを削除しても、同じ方法でロールを再作成できます。
## VPC のサービスにリンクされたロールの編集
VPC では、AWSServiceRoleForNATGateway のサービスにリンクされたロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## VPC のサービスにリンクされたロールの削除
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、使用していないエンティティがアクティブにモニタリングされたり、メンテナンスされたりすることがなくなります。ただし、手動で削除する前に、サービスリンクロールのリソースをクリーンアップする必要があります。
**注記**
リソースを削除する際に、VPC のサービスでロールが使用されていると、削除に失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
**AWSServiceRoleForNATGateway が使用する VPC リソースを削除するには**
+ デプロイされたすべてのリージョンで、すべてのリージョン NAT ゲートウェイを削除します。
**サービスリンクロールを IAM で手動削除するには**
IAM コンソール、AWS CLI、または AWS API を使用して、AWSServiceRoleForNATGateway サービスリンクロールを削除します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## VPC のサービスにリンクされたロールをサポートするリージョン
VPC は、サービスが利用可能なすべてのリージョンで、サービスにリンクされたロールの使用をサポートしています。詳細については、「[AWS リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
VPC は、サービスを利用できるすべてのリージョンで、サービスにリンクされたロールの使用をサポートしているわけではありません。AWSServiceRoleForNATGateway ロールは、以下のリージョンで使用できます。
| リージョン名 | リージョン識別子 | VPC でのサポート |
| --- | --- | --- |
| 米国東部 (バージニア北部) | us-east-1 | はい |
| 米国東部 (オハイオ) | us-east-2 | はい |
| 米国西部 (北カリフォルニア) | us-west-1 | はい |
| 米国西部 (オレゴン) | us-west-2 | はい |
| アフリカ (ケープタウン) | af-south-1 | はい |
| アジアパシフィック (香港) | ap-east-1 | はい |
| アジアパシフィック (台北) | ap-east-2 | はい |
| アジアパシフィック (ジャカルタ) | ap-southeast-3 | はい |
| アジアパシフィック (ムンバイ) | ap-south-1 | はい |
| アジアパシフィック (ハイデラバード) | ap-south-2 | はい |
| アジアパシフィック (大阪) | ap-northeast-3 | はい |
| アジアパシフィック (ソウル) | ap-northeast-2 | はい |
| アジアパシフィック (シンガポール) | ap-southeast-1 | はい |
| アジアパシフィック (シドニー) | ap-southeast-2 | はい |
| アジアパシフィック (東京) | ap-northeast-1 | はい |
| アジアパシフィック (メルボルン) | ap-southeast-4 | はい |
| アジアパシフィック (マレーシア) | ap-southeast-5 | はい |
| アジアパシフィック (ニュージーランド) | ap-southeast-6 | はい |
| アジアパシフィック (タイ) | ap-southeast-7 | はい |
| カナダ (中部) | ca-central-1 | はい |
| カナダ西部 (カルガリー) | ca-west-1 | はい |
| 欧州 (フランクフルト) | eu-central-1 | はい |
| 欧州 (チューリッヒ) | eu-central-2 | はい |
| 欧州 (アイルランド) | eu-west-1 | はい |
| 欧州 (ロンドン) | eu-west-2 | はい |
| 欧州 (ミラノ) | eu-south-1 | はい |
| 欧州 (スペイン) | eu-south-2 | はい |
| 欧州 (パリ) | eu-west-3 | はい |
| 欧州 (ストックホルム) | eu-north-1 | はい |
| イスラエル (テルアビブ) | il-central-1 | はい |
| 中東 (バーレーン) | me-south-1 | はい |
| 中東 (アラブ首長国連邦) | me-central-1 | はい |
| 中東 (サウジアラビア) | me-west-1 | はい |
| メキシコ (中部) | mx-central-1 | はい |
| 南米 (サンパウロ) | sa-east-1 | はい |
| AWS GovCloud (米国東部) | us-gov-east-1 | いいえ |
| AWS GovCloud (米国西部) | us-gov-west-1 | いいえ |
# Amazon VPC のインフラストラクチャセキュリティ
マネージドサービスである Amazon Virtual Private Cloud は、AWS グローバルネットワークセキュリティによって保護されています。AWSセキュリティサービスと AWS がインフラストラクチャを保護する方法については、[AWS クラウドセキュリティ](https://aws.amazon.com/security/) を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには *セキュリティの柱 - AWS 適切なアーキテクチャを備えたフレームワーク* の [インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) を参照してください。
AWS が公開した API 呼び出しを使用して、ネットワーク経由で Amazon VPC にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
## ネットワークの隔離
仮想プライベートクラウド (VPC) はAWS クラウド内の論理的に隔離された領域にある仮想ネットワークです。ワークロードまたは組織エンティティ単位でインフラストラクチャを隔離するには個別の VPC を使用します。
サブネットはある範囲の IP アドレスが示す VPC 内の領域です。インスタンスを起動する場合にはVPC 内のあるサブネットにおいて起動することになります。サブネットを使用すると、単一の VPC 内で多階層ウェブアプリケーションの各階層 (ウェブサーバー、アプリケーションサーバーおよびデータベースサーバーなど) を隔離できます。インターネットからの直接アクセスを認めるべきでないインスタンスには、プライベートサブネットを使用します。
[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/) を使用して、VPC 内のリソースが、サービスが VPC で直接ホストされているかのようにプライベート IP アドレスを使用して AWS のサービス に接続することを許可します。したがって、AWS のサービス へのアクセスにインターネットゲートウェイまたは NAT デバイスを使用する必要はありません。
## ネットワークトラフィックの制御
EC2 インスタンスなど、VPC 内のリソースへのネットワークトラフィックを制御するには、以下のオプションを検討してください。
+ VPC へのネットワークアクセスを制御するための主要なメカニズムとして、[セキュリティグループ](vpc-security-groups.md)を使用します。必要に応じて、[ネットワーク ACL](vpc-network-acls.md) 使用すると、ステートレスできめの粗いネットワーク制御を行うことができます。セキュリティグループは、ステートフルなパケットフィルター処理を実行して、他のセキュリティグループを参照するルールを作成できるため、ネットワーク ACL よりも汎用性があります。ネットワーク ACL は、セカンダリ制御 (特定のトラフィックのサブセットを拒否するなど) または高レベルのサブネットガードレールとして効果的に使用できます。また、ネットワーク ACL はサブネット全体に適用されるため、万が一正しいセキュリティグループがない状態でインスタンスが起動された場合に、深層防御として活用できます。
+ インターネットからの直接アクセスを認めるべきでないインスタンスにはプライベートサブネットを使用します。プライベートサブネット内にあるインスタンスからのインターネットアクセスには、踏み台ホストまたは NAT ゲートウェイを使用します。
+ 接続要件を満たす最小限のネットワークルートでサブネット[ルートテーブル](VPC_Route_Tables.md)を設定します。
+ 追加のセキュリティグループまたはネットワークインターフェイスを使用して、Amazon EC2 インスタンス管理トラフィックを通常のアプリケーショントラフィックとは別に制御および監査することをご検討ください。このアプローチにより、変更管理のための特別な IAM ポリシーを実装できるため、セキュリティグループルールや自動化されたルール検証スクリプトへの変更を容易に監査することができます。複数のネットワークインターフェイスでは、ホストベースのルーティングポリシーを作成したり、サブネットに割り当てられたネットワークインターフェイスに基づいて異なる VPC サブネットルーティングルールを活用したりするなど、ネットワークトラフィックを制御するための追加のオプションも提供されます。
+ AWS Virtual Private Network または Direct Connectを使用して、リモートネットワークから VPC へのプライベート接続を確立します。詳細については、[ネットワークから Amazon VPC への接続オプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)を参照してください。
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)を使用して、インスタンスに到達するトラフィックを監視します。
+ [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)を使用して、インスタンスからの意図しないネットワークアクセスを確認する。
+ [AWS Network Firewall](network-firewall.md) を使用して、VPC 内のサブネットを一般的なネットワークの脅威から保護します。
## セキュリティグループとネットワーク ACL を比較する
次の表は、セキュリティグループとネットワーク ACL の基本的な違いをまとめたものです。
| 特性 | セキュリティグループ | ネットワーク ACL |
| --- | --- | --- |
| オペレーションのレベル | インスタンスレベル | サブネットレベル |
| スコープ | セキュリティグループに関連付けられているすべてのインスタンスに適用されます | 関連付けられたサブネット内のすべてのインスタンスに適用されます |
| ルールタイプ | ルールのみを許可します | 許可ルールと拒否ルール |
| ルールの評価 | トラフィックを許可するかどうかを決める前に、すべてのルールを評価します | トラフィックの一致が見つかるまで昇順でルールを評価します |
| 返されるトラフィック | 自動許可 (ステートフル) | 明示的に許可する必要があります (ステートレス) |
次の図は、セキュリティグループおよびネットワーク ACL が提供するセキュリティレイヤーを示しています。たとえば、インターネットゲートウェイからのトラフィックは、ルーティングテーブルのルートを使用して適切なサブネットにルーティングされます。サブネットに対してどのトラフィックが許可されるかは、そのサブネットに関連付けられているネットワーク ACL のルールによってコントロールされます。インスタンスに対してどのトラフィックが許可されるかは、そのインスタンスに関連付けられているセキュリティグループのルールによってコントロールされます。
![\[セキュリティグループおよびネットワーク ACL を使用してトラフィックをコントロール\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/security-comparison.png)
セキュリティグループのみを使用してインスタンスを保護できます。ただし、ネットワーク ACL は追加の防御レイヤーとして追加できます。詳細については、「[例: サブネットのインスタンスへのアクセス制御](nacl-examples.md)」を参照してください。
# セキュリティグループを使用して AWS リソースへのトラフィックを制御する
*セキュリティグループ*は、関連付けられたリソースに到達できるトラフィックおよびリソースから発信できるトラフィックを制御します。例えば、セキュリティグループを EC2 インスタンスに関連付けると、インスタンスのインバウンドトラフィックとアウトバウンドトラフィックが制御されます。
VPC を作成すると、デフォルトのセキュリティグループが使用されます。VPC ごとに追加のセキュリティグループを作成し、それぞれに独自のインバウンドルールとアウトバウンドルールを設定できます。インバウンドルールごとに、送信元、ポート範囲、プロトコルを指定できます。アウトバウンドルールごとに、送信先、ポート範囲、プロトコルを指定できます。
次の図は、サブネット、インターネットゲートウェイ、セキュリティグループを備えた VPC を示しています。サブネットには EC2 インスタンスが含まれています。セキュリティグループは、インスタンスに割り当てられます。セキュリティグループは、仮想ファイアウォールとして機能します。インスタンスに到達するトラフィックは、セキュリティグループのルールで許可されているトラフィックだけです。例えば、ネットワークからインスタンスへの ICMP トラフィックを許可するルールがセキュリティグループに含まれている場合は、お使いのコンピュータからインスタンスに ping を送信できます。SSH トラフィックを許可するルールがセキュリティグループに含まれていない場合、SSH を使用してインスタンスに接続することはできません。
![\[2 つのサブネット、2 つのセキュリティグループ、異なるセキュリティグループに関連付けられたサブネット内のサーバーを持つ VPC\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/security-group-overview.png)
**Topics**
+ [セキュリティグループの基本](#security-group-basics)
+ [セキュリティグループの例](#security-group-example-details)
+ [「セキュリティグループのルール」](security-group-rules.md)
+ [デフォルトのセキュリティグループ](default-security-group.md)
+ [セキュリティグループを作成する](creating-security-groups.md)
+ [セキュリティグループのルールを設定する](working-with-security-group-rules.md)
+ [セキュリティグループを削除する](deleting-security-groups.md)
+ [セキュリティグループを複数の VPCに関連付ける](security-group-assoc.md)
+ [AWS Organizations とセキュリティグループを共有する](security-group-sharing.md)
**料金**
セキュリティグループは追加料金なしで使用できます。
## セキュリティグループの基本
+ [セキュリティグループ VPC 関連付け機能](security-group-assoc.md)を使用してセキュリティグループを同じリージョン内の他の VPC に関連付ける場合は、セキュリティグループをセキュリティグループと同じ VPC 内に作成されたリソースに割り当てるか、他の VPC リソースに割り当てることができます。1 つのリソースに複数のセキュリティ グループを割り当てることもできます。
+ セキュリティグループを作成する場合、名前と説明を指定する必要があります。以下のルールが適用されます。
+ セキュリティグループ名は VPC 内で一意である必要があります。
+ セキュリティグループ名では大文字と小文字が区別されません。
+ 名前と説明の長さは最大 255 文字とすることができます。
+ 名前と説明に使用できる文字は、a～z、A～Z、0～9、スペース、.\$1-:/()\$1,@[]\$1=&;\$1\$1\$1\$1\$1 です。
+ 名前に末尾のスペースが含まれている場合は、名前の末尾のスペースを削除します。例えば、名前に「セキュリティグループのテスト 」と入力すると、「セキュリティグループのテスト」として保存されます。
+ セキュリティグループ名は、`sg-` で開始できません。
+ セキュリティグループはステートフルです。例えば、インスタンスからリクエストを送信した場合、そのリクエストのレスポンストラフィックは、インバウンドセキュリティグループのルールに関係なく、インスタンスに到達が許可されます。許可されたインバウンドトラフィックへのレスポンスは、アウトバウンドルールに関係なく、インスタンスを離れることができます。
+ セキュリティグループでは、以下で送受信されるトラフィックはフィルターされません。
+ Amazon ドメインネームサービス (DNS)
+ Amazon Dynamic Host Configuration Protocol (DHCP)
+ Amazon EC2 インスタンスメタデータ。
+ Amazon ECS タスクメタデータエンドポイント
+ Windows インスタンスのライセンスアクティベーション
+ Amazon Time Sync Service
+ デフォルトの VPC ルーターによる予約済み IP アドレス
+ VPC あたりの作成可能なセキュリティグループの数、各セキュリティグループに追加できるルールの数、ネットワークインターフェイスに関連付けることができるセキュリティグループの数にはクォータがあります。詳細については、「[Amazon VPC クォータ](amazon-vpc-limits.md)」を参照してください。
**ベストプラクティス**
+ 特定の IAM プリンシパルのみにセキュリティグループの作成と変更を許可します。
+ エラーのリスクを減らすために、必要最小限の数のセキュリティグループを作成してください。各セキュリティグループを使用して、同様の機能とセキュリティ要件を持つリソースへのアクセスを管理します。
+ EC2 インスタンスにアクセスできるようにするために、ポート 22 (SSH) または 3389 (RDP) のインバウンドルールを追加する場合は、特定の IP アドレスの範囲のみを許可する必要があります。0.0.0.0/0 (IPv4) と ::/ (IPv6) を指定すると、指定したプロトコルを使用して、誰でも任意の IP アドレスからインスタンスにアクセスできるようになります。
+ 広い範囲のポートを開かないでください。各ポートからのアクセスが、それを必要とする送信元または宛先に制限されていることを確認します。
+ セキュリティの追加レイヤーを VPC に追加するには、セキュリティグループと同様のルールを指定したネットワーク ACL を作成することを検討してください。セキュリティグループとネットワーク ACL の違いの詳細については、「[セキュリティグループとネットワーク ACL を比較する](infrastructure-security.md#VPC_Security_Comparison)」を参照してください。
## セキュリティグループの例
次の図は、2 つのセキュリティグループと 2 つのサブネットを持つ VPC を示しています。サブネット A のインスタンスは、接続要件が同じであるため、セキュリティグループ 1 に関連付けられます。サブネット B のインスタンスは、接続要件が同じであるため、セキュリティグループ 2 に関連付けられます。セキュリティグループのルールでは、トラフィックを次のように許可します。
+ セキュリティグループ 1 の最初のインバウンドルールは、指定されたアドレス範囲 (例えば、独自のネットワーク内の範囲) からサブネット A のインスタンスへの SSH トラフィックを許可します。
+ セキュリティグループ 1 の 2 番目のインバウンドルールは、サブネット A のインスタンスが任意のプロトコルとポートを使用して相互に通信することを許可します。
+ セキュリティグループ 2 の最初のインバウンドルールは、サブネット B のインスタンスが任意のプロトコルとポートを使用して相互に通信することを許可します。
+ セキュリティグループ 2 の 2 番目のインバウンドルールは、サブネット A のインスタンスが SSH を使用してサブネット B のインスタンスと通信することを許可します。
+ どちらのセキュリティグループも、すべてのトラフィックを許可するデフォルトのアウトバウンドルールを使用します。
![\[2 つのサブネットに 2 つのセキュリティグループとサーバーを持つ VPC。サブネット A のサーバーは、セキュリティグループ 1 に関連付けられています。サブネット B のサーバーは、セキュリティグループ 2 に関連付けられています。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/security-group-details.png)
# 「セキュリティグループのルール」
セキュリティグループルールは、セキュリティグループに関連付けられたリソースに到達することを許可するインバウンドトラフィックを制御します。また、このルールによって、インスタンスから送信されるアウトバウンドトラフィックも制御されます。
セキュリティグループのルールは追加または削除できます (インバウンドまたはアウトバウンドアクセスの*許可*または*取り消し*とも呼ばれます)。ルールが適用されるのは、インバウンドトラフィック (受信) またはアウトバウンドトラフィック (送信) のいずれかです。特定のソースまたは送信先へのアクセス権を付与できます。
**Topics**
+ [セキュリティグループのルールの基本](#security-group-rule-characteristics)
+ [セキュリティグループルールの構成要素](#security-group-rule-components)
+ [セキュリティグループの参照](#security-group-referencing)
+ [セキュリティグループのサイズ](#security-group-size)
+ [古くなったセキュリティグループルール](#vpc-stale-security-group-rules)
## セキュリティグループのルールの基本
セキュリティグループのルールの特徴を次に示します。
+ 許可ルールを指定できます。拒否ルールは指定できません。
+ セキュリティグループを初めて作成するときには、インバウンドルールはありません。したがって、インバウンドルールをセキュリティグループに追加するまで、インバウンドトラフィックは許可されません。
+ セキュリティグループを最初に作成するとき、リソースからのすべてのアウトバウンドトラフィックを許可するアウトバウンドルールが設定されます。ルールを削除し、任意の発信トラフィックのみを許可するアウトバウンドルールを追加できます。セキュリティグループにアウトバウンドルールがない場合、アウトバウンドトラフィックは許可されません。
+ 複数のセキュリティグループをリソースに関連付けると、各セキュリティグループのルールが集約されて、アクセス許可の判断に使用する 1 つのルールセットが形成されます。
+ ルールを追加、更新、または削除すると、セキュリティグループに関連付けられたすべてのリソースにこの変更が自動的に適用されます。手順については、「[セキュリティグループのルールを設定する](working-with-security-group-rules.md)」を参照してください。
+ 一部のルール変更の影響は、トラフィックの追跡方法によって異なる場合があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[接続追跡](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)」を参照してください。
+ セキュリティグループルールを作成する際、AWS により、一意の ID がそのルールに割り当てられます。このルールの ID は、API または CLI を使用してルールを変更または削除する際に使用します。
**制限**
セキュリティグループは、「VPC\$12 IP アドレス」 (「*Amazon Route 53 デベロッパーガイド*」の「[Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)」を参照) または [AmazonProvidedDNS](DHCPOptionSet.md) と呼ばれることがある Route 53 Resolver から送受信される DNS リクエストをブロックできません。Route 53 Resolver 経由の DNS リクエストをフィルタリングするには、[Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) を使用します。
## セキュリティグループルールの構成要素
以下は、インバウンドおよびアウトバウンドセキュリティグループルールの構成要素です。
+ **プロトコル**: 許可するプロトコル。最も一般的なプロトコルは、6 (TCP)、17 (UDP)、1 (ICMP) です。
+ **ポートの範囲**: TCP、UDP、カスタムプロトコルの場合、許可するポートの範囲。1 つのポート番号 (`22` など)、または一定範囲のポート番号 (`7000-8000` など) を指定できます。
+ **ICMP タイプおよびコード**: ICMP の場合、ICMP タイプおよびコードです。例えば、ICMP エコー要求にはタイプ 8、ICMPv6 エコー要求にはタイプ 128 を使用します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Ping/ICMP のルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-ping)」を参照してください。
+ **Source or destination** (送信元または送信先): 許可するトラフィックの送信元 (インバウンドルール) または送信先 (アウトバウンドルール)。次のいずれかを指定します。
+ 単一の IPv4 アドレス。`/32` プレフィクス長を使用する必要があります。例えば、`203.0.113.1/32`。
+ 単一の IPv6 アドレス。`/128` プレフィクス長を使用する必要があります。例えば、`2001:db8:1234:1a00::123/128`。
+ CIDR ブロック表記の IPv4 アドレスの範囲。例えば、`203.0.113.0/24`。
+ CIDR ブロック表記の IPv6 アドレスの範囲。例えば、`2001:db8:1234:1a00::/64`。
+ プレフィクスリストの ID。例えば、`pl-1234abc1234abc123` です。詳細については、「[マネージドプレフィックスリスト](managed-prefix-lists.md)」を参照してください。
+ セキュリティグループの ID。例えば、`sg-1234567890abcdef0` です。詳細については、「[セキュリティグループの参照](#security-group-referencing)」を参照してください。
+ **(オプション) 説明**: 後で分かりやすいように、このルールの説明を追加できます。説明の長さは最大 255 文字とすることができます。使用できる文字は、a～z、A～Z、0～9、スペース、.\$1-:/()\$1,@[]\$1=;\$1\$1\$1\$1\$1 です。
例については、「*Amazon EC2 ユーザーガイド*」の「[さまざまなユースケースのセキュリティグループのルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html)」を参照してください。
## セキュリティグループの参照
ルールのソースまたは宛先としてセキュリティグループを指定する場合、ルールはセキュリティグループに関連付けられているすべてのインスタンスに影響します。インスタンスは、指定されたプロトコルとポート経由で、インスタンスのプライベート IP アドレスを使用して、指定された方向の通信を行うことができます。
例えば、以下は、セキュリティグループ sg-0abcdef1234567890 を参照するセキュリティグループのインバウンドルールを表しています。このルールは、sg-0abcdef1234567890 に関連付けられたインスタンスからのインバウンド SSH トラフィックを許可します。
| ソース | プロトコル | ポート範囲 |
| --- | --- | --- |
| sg-0abcdef1234567890 | TCP | 22 |
セキュリティグループルール内のセキュリティグループを参照するときは、以下の点に注意してください。
+ 次のいずれかに該当する場合、別のセキュリティグループのインバウンドルールのセキュリティグループを参照できます:
+ セキュリティグループは同じ VPC に関連付けられます。
+ セキュリティグループが関連付けられている VPC 間にピアリング接続があります。
+ セキュリティグループが関連付けられている VPC 間にトランジットゲートウェイがあります。
+ 次のいずれかに該当する場合、アウトバウンドルールのセキュリティグループを参照できます:
+ セキュリティグループは同じ VPC に関連付けられます。
+ セキュリティグループが関連付けられている VPC 間にピアリング接続があります。
+ 参照されるセキュリティグループからのルールが、このグループを参照するセキュリティグループに追加されていない。
+ インバウンドルールの場合は、セキュリティグループに関連付けられた EC2 インスタンスが、参照されるセキュリティグループに関連付けられた EC2 インスタンスのネットワークインターフェイスからのプライベート IP アドレスからのインバウンドトラフィックを受信できる。
+ アウトバウンドルールの場合は、セキュリティグループに関連付けられた EC2 インスタンスが、参照されるセキュリティグループに関連付けられた EC2 インスタンスのネットワークインターフェイスからのプライベート IP アドレスへのアウトバウンドトラフィックを送信できる。
+ `AuthorizeSecurityGroupIngress`、`AuthorizeSecurityGroupEgress`、`RevokeSecurityGroupIngress`、および `RevokeSecurityGroupEgress` の各アクションでは、参照されるセキュリティグループに対しては認可されません セキュリティグループが存在するかどうかが確認されるだけです。この結果は以下のようになります。
+ IAM ポリシーで、これらのアクションについて参照されるセキュリティグループを指定しても効果はありません。
+ 参照されるセキュリティグループが別のアカウントによって所有されている場合、所有者アカウントはこれらのアクションについて CloudTrail イベントを受信しません。
**制限**
ミドルボックスアプライアンスを介して異なるサブネット内の 2 つのインスタンス間のトラフィックを転送するようにルートを設定するには、両方のインスタンスのセキュリティグループでインスタンス間のトラフィックがフローできるようにする必要があります。各インスタンスのセキュリティグループは、他のインスタンスのプライベート IP アドレス、または他のインスタンスを含むサブネットの CIDR 範囲を送信元として参照される必要があります。他のインスタンスのセキュリティグループを送信元として参照する場合、インスタンス間のトラフィックは許可されません。
**例**
次の図は、2 つのアベイラビリティーゾーン、1 つのインターネットゲートウェイ、1 つの Application Load Balancer のサブネットを使用する VPC を示しています。各アベイラビリティーゾーンには、ウェブサーバー用のパブリックサブネットと、データベースサーバー用のプライベートサブネットがあります。ロードバランサー、ウェブサーバー、データベースサーバーには個別のセキュリティグループがあります。以下のセキュリティグループルールを作成して、トラフィックを許可します。
+ ロードバランサーのセキュリティグループにルールを追加して、インターネットからの HTTP および HTTPS トラフィックを許可します。送信元は 0.0.0.0/0 です。
+ ウェブサーバーのセキュリティグループにルールを追加して、ロードバランサーからの HTTP および HTTPS トラフィックのみを許可します。送信元はロードバランサーのセキュリティグループです。
+ データベースサーバーのセキュリティグループにルールを追加して、ウェブサーバーからのデータベースリクエストを許可します。送信元はウェブサーバーのセキュリティグループです。
![\[ウェブサーバーと DB サーバー、セキュリティグループ、インターネットゲートウェイ、ロードバランサーを持つアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/security-group-referencing.png)
## セキュリティグループのサイズ
各ルールがセキュリティグループごとに設定できるルールの最大数にカウントされる方法は、ソースまたは送信先のタイプに応じて判断されます。
+ CIDR ブロックを参照するルールは、1 個のルールとしてカウントされます。
+ 別のセキュリティグループを参照するルールは、参照されるセキュリティグループのサイズにかかわらず、1 個のルールとしてカウントされます。
+ カスタマーマネージドプレフィックスリストを参照するルールは、プレフィックスリストの最大サイズにならってカウントされます。例えば、プレフィックスリストの最大サイズが 20 の場合、このプレフィックスリストを参照するルールも 20 個のルールとしてカウントされます。
+ AWS マネージドプレフィックスリストを参照するルールは、プレフィックスリストのウェイトにならってカウントされます。例えば、プレフィックスリストの最大サイズが 10 の場合、このプレフィックスリストを参照するルールも 10 個のルールとしてカウントされます。詳細については、「[使用可能な AWS マネージドプレフィックスリスト](working-with-aws-managed-prefix-lists.md#available-aws-managed-prefix-lists)」を参照してください。
## 古くなったセキュリティグループルール
VPC に別の VPC との VPC ピアリング接続がある場合、または別のアカウントで共有されている VPC を使用している場合、VPC のセキュリティグループルールは、そのピア VPC または共有 VPC のセキュリティグループを参照できます。これにより、参照されるセキュリティグループに関連付けられているリソースと、参照するセキュリティグループに関連付けられているリソースが、相互に通信できるようになります。詳細については、「*Amazon VPC ピアリングガイド*」の「[セキュリティグループの更新とピアセキュリティグループの参照](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html)」を参照してください。
ピア VPC または共有 VPC のセキュリティグループを参照するセキュリティグループルールがあって、共有 VPC のセキュリティグループが削除されたまたは VPC ピアリング接続が削除された場合、そのセキュリティグループは陳腐化とマークされます。古くなったセキュリティグループルールは他のセキュリティグループルールと同じ方法で削除できます。
# VPC のデフォルトセキュリティグループ
デフォルトの VPC および作成した VPC には、デフォルトのセキュリティグループが適用されます。デフォルトセキュリティグループの名前は「default」です。
デフォルトのセキュリティグループを使用する代わりに、特定のリソース、またはリソースグループのセキュリティグループを作成することをお勧めします。ただし、作成時に何らかのリソースとセキュリティグループを関連付けない場合は、デフォルトのセキュリティグループが関連付けられます。例えば、EC2 インスタンス起動時にセキュリティグループを指定しない場合、インスタンスにはデフォルトの VPC 用セキュリティグループが関連付けられます。
## デフォルトセキュリティグループの基本
+ デフォルトのセキュリティグループのルールは変更できます。
+ デフォルトのセキュリティグループを削除することはできません。デフォルトのセキュリティグループを削除しようとした場合、`Client.CannotDelete` のエラーが発生します。
## デフォルトのルール
次の表では、デフォルトのセキュリティグループ用のデフォルトインバウンドルールについて説明します。
| ソース | プロトコル | ポート範囲 | 説明 |
| --- | --- | --- | --- |
| sg-1234567890abcdef0 | すべて | すべて | このセキュリティグループに割り当てられたすべてのリソースからのインバウンドトラフィックを許可します。ソースは、このセキュリティグループの ID です。 |
次の表では、デフォルトのセキュリティグループ用のデフォルトアウトバウンドルールについて説明します。
| 目的地 | プロトコル | ポート範囲 | 説明 |
| --- | --- | --- | --- |
| 0.0.0.0/0 | すべて | すべて | すべてのアウトバウンド IPv4 トラフィックを許可します。 |
| ::/0 | すべて | すべて | すべてのアウトバウンド IPv6 トラフィックを許可します。このルールは、VPC に IPv6 CIDR ブロックが関連付けられている場合にのみ追加されます。 |
## 例
次の図は、デフォルトのセキュリティグループ、インターネットゲートウェイ、NAT ゲートウェイを備えた VPC を示しています。デフォルトのセキュリティにはデフォルトルールのみが含まれており、VPC で実行されている 2 つの EC2 インスタンスに関連付けられています。このシナリオでは、各インスタンスはすべてのポートとプロトコルで他のインスタンスからのインバウンドトラフィックを受信できます。デフォルトのルールでは、インスタンスはインターネットゲートウェイまたは NAT ゲートウェイからのトラフィックを受信できません。インスタンスが追加のトラフィックを受信する必要がある場合は、必要なルールを含むセキュリティグループを作成し、その新しいセキュリティグループをデフォルトのセキュリティグループではなくインスタンスに関連付けることをお勧めします。
![\[2 つのサブネット、デフォルトのセキュリティグループ、2 つの EC2 インスタンス、インターネットゲートウェイ、NAT ゲートウェイを持つ VPC\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/default-security-group.png)
# VPC 用のセキュリティグループを作成するには
仮想プライベートクラウド (VPC) には、デフォルトのセキュリティグループが備わっています。追加のセキュリティグループを作成することができます。セキュリティグループは、作成時に対象とした VPC のリソースにのみ使用できます。
デフォルトでは、新しいセキュリティグループにはすべてのトラフィックがリソースを離れることを許可するアウトバウンドルールのみが設定されています。任意のインバウンドトラフィックを許可するには、またはアウトバウンドトラフィックを制限するには、ルールを追加する必要があります。ルールは、セキュリティグループ作成時に、または後で追加することができます。詳細については、「[「セキュリティグループのルール」](security-group-rules.md)」を参照してください。
**必要な アクセス許可**
作業を開始する前に、必要なアクセス許可があることを確認してください。詳細については次を参照してください:
+ [セキュリティグループの管理](vpc-policy-examples.md#vpc-security-groups-iam)
+ [セキュリティグループルールの管理](vpc-policy-examples.md#vpc-security-group-rules-iam)
**コンソールを使用してセキュリティグループを作成するには**
1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。
1. ナビゲーションペインで [**セキュリティグループ**] をクリックします。
1. **セキュリティグループの作成** を選択します。
1. セキュリティグループの名前と説明を入力します。セキュリティグループの作成後は、その名前と説明を変更することはできません。
1. **[VPC]** では、セキュリティグループを関連付けるリソースを作成する VPC を選択します。
1. (任意) インバウンドルールを追加するには、**[インバウンドルール]** を選択します。ルールごとに、**[ルールを追加]** を選択し、プロトコル、ポート、および送信元を指定します。詳細については、「[セキュリティグループのルールを設定する](working-with-security-group-rules.md)」を参照してください。
1. (任意) アウトバウンドルールを追加するには、**[アウトバウンドルール]** を選択します。ルールごとに、**[ルールを追加]** を選択し、プロトコル、ポート、および送信先を指定します。
1. (オプション) タグを追加するには、**[Add new tag]** (新しいタグを追加) を選択し、そのタグのキーと値を入力します。
1. **[セキュリティグループの作成]** を選択してください。
**AWS CLI を使用してセキュリティグループを作成するには**
[create-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html) コマンドを使用します。
または、既存のセキュリティグループをコピーすることで、新しいセキュリティグループを作成することができます。セキュリティグループをコピーすると、元のセキュリティグループと同じインバウンドルールとアウトバウンドルールが自動的に追加され、元のセキュリティグループと同じ VPC が使用されます。新しいセキュリティグループの名前と説明を入力できます。任意で別の VPC を選択でき、また必要に応じてインバウンドルールとアウトバウンドルールを変更できます。ただし、セキュリティグループはあるリージョンから別のリージョンにはコピーできません。
**既存のセキュリティグループに基づいてセキュリティグループを作成するには**
1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。
1. ナビゲーションペインで、**[セキュリティグループ]** を選択します。
1. セキュリティグループを選択します。
1. **[アクション]**、**[新しいセキュリティグループにコピー]** の順に選択します。
1. セキュリティグループの名前と説明を入力します。
1. (任意) 必要に応じて別の VPC を選択します。
1. (任意) 必要に応じてセキュリティグループのルールを追加、削除、または編集します。
1. **[セキュリティグループの作成]** を選択してください。
# セキュリティグループのルールを設定する
セキュリティグループを作成したら、そのセキュリティグループルールを追加、更新、削除できます。ルールを追加、更新、または削除すると、変更はそのセキュリティグループに関連付けられているリソースに自動的に適用されます。
**必要なアクセス許可**
作業を開始する前に、必要なアクセス許可があることを確認してください。詳細については、「[セキュリティグループルールの管理](vpc-policy-examples.md#vpc-security-group-rules-iam)」を参照してください。
**プロトコルとポート**
+ コンソールでは、事前定義されたタイプを選択すると、**プロトコル**と**ポート範囲**が指定されます。ポート範囲を入力するには、**[カスタム TCP]** または **[カスタム UDP]** のいずれかのカスタムタイプを選択する必要があります。
+ AWS CLI では、`--protocol` オプションおよび `--port` オプションを使用して、単一のポートを持つ単一のルールを追加できます。複数のルール、またはポート範囲を持つルールを追加するには、代わりに `--ip-permissions` オプションを使用します。
**送信元と送信先**
+ コンソールでは、インバウンドルールの送信元またはアウトバウンドルールの送信先として、以下を指定できます。
+ **[カスタム]** – IPv4 CIDR ブロック、IPv6 CIDR ブロック、セキュリティグループ、またはプレフィックスリスト。
+ **[Anywhere-IPv4]** – 0.0.0.0/0 IPv4 CIDR ブロック。
+ **[Anywhere-IPv6]** – ::/0 IPv6 CIDR ブロック。
+ **[マイ IP]** – ローカルコンピュータのパブリック IPv4 アドレス。
+ AWS CLI では、`--cidr` オプションを使用して IPv4 CIDR ブロックを指定するか、`--source-group` オプションを使用してセキュリティグループを指定できます。プレフィックスリストまたは IPv6 CIDR ブロックを指定するには、`--ip-permissions` オプションを使用します。
**警告**
**[Anywhere-IPv4]** を選択すると、すべての IPv4 アドレスからのトラフィックが許可されます。**[Anywhere-IPv6]** を選択すると、すべての IPv6 アドレスからのトラフィックが許可されます。リソースへのアクセスが必要な特定の IP アドレス範囲のみを許可するのがベストプラクティスです。
**コンソールを使用してセキュリティグループを設定するには**
1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。
1. ナビゲーションペインで [**セキュリティグループ**] をクリックします。
1. セキュリティグループを選択します。
1. インバウンドルールを編集するには、**[アクション]** または **[インバウンドルール]** タブから **[インバウンドルールを編集]** を選択します。
1. ルールを追加するには、**[ルールを追加]** を選択し、ルールのタイプ、プロトコル、ポート、および送信元を入力します。
タイプが TCP または UDP の場合は、許可するポート範囲を入力する必要があります。カスタムの ICMP の場合は、[**プロトコル**] から ICMP タイプ名を選択し、該当するものがある場合は [**ポート範囲**] からコード名を選択します。その他のタイプについては、プロトコルとポート範囲は自動的に設定されます。
1. ルールを更新するには、必要に応じてプロトコル、説明、送信元を変更します。ただし、送信元のタイプを変更することはできません。例えば、送信元が IPv4 CIDR ブロックの場合、IPv6 CIDR ブロック、プレフィックスリスト、またはセキュリティグループを指定することはできません。
1. ルールを削除するには、**[削除]** ボタンを選択します。
1. アウトバウンドルールを編集するには、**[アクション]** または **[アウトバウンドルール]** タブから **[アウトバウンドルールを編集]** を選択します。
1. ルールを追加するには、**[ルールを追加]** を選択し、ルールのタイプ、プロトコル、ポート、および送信先を入力します。オプションとして説明を入力することもできます。
タイプが TCP または UDP の場合は、許可するポート範囲を入力する必要があります。カスタムの ICMP の場合は、[**プロトコル**] から ICMP タイプ名を選択し、該当するものがある場合は [**ポート範囲**] からコード名を選択します。その他のタイプについては、プロトコルとポート範囲は自動的に設定されます。
1. ルールを更新するには、必要に応じてプロトコル、説明、送信元を変更します。ただし、送信元のタイプを変更することはできません。例えば、送信元が IPv4 CIDR ブロックの場合、IPv6 CIDR ブロック、プレフィックスリスト、またはセキュリティグループを指定することはできません。
1. ルールを削除するには、**[削除]** ボタンを選択します。
1. [**ルールの保存**] を選択します。
**AWS CLI を使用してセキュリティグループのルールを設定するには**
+ **追加** – [authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html) コマンドおよび [authorize-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-egress.html) コマンドを使用します。
+ **削除** – [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) コマンドおよび [revoke-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-egress.html) コマンドを使用します。
+ **変更** – [modify-security-group-rules](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-security-group-rules.html)、[update-security-group-rule-descriptions-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/update-security-group-rule-descriptions-ingress.html)、および [update-security-group-rule-descriptions-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/update-security-group-rule-descriptions-egress.html) コマンドを使用します。
# セキュリティグループを削除する
作成したセキュリティグループが用済みになったら、削除することができます。
**要件**
+ このセキュリティグループをリソースに関連付けることはできません。
+ 別のセキュリティグループのルールでこのセキュリティグループを参照することはできません。
+ このセキュリティグループは、VPC のデフォルトのセキュリティグループにはできません。
**コンソールを使用してセキュリティグループを削除するには**
1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。
1. ナビゲーションペインで [**セキュリティグループ**] をクリックします。
1. セキュリティグループを選択して、**[アクション]**、**[セキュリティグループを削除]** を選択します。
1. 複数のセキュリティグループを選択した場合は、確認を求められます。一部のセキュリティグループを削除できない場合は、削除されるかどうかを示す、各セキュリティグループのステータスが表示されます。削除を確認するには、「**Delete**」と入力します。
1. **[削除]** を選択します。
**AWS CLI を使用してセキュリティグループを削除するには**
[delete-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html) コマンドを使用します。
# セキュリティグループを複数の VPCに関連付ける
ネットワークセキュリティ要件を共有する複数の VPC でワークロードを実行している場合は、セキュリティグループの VPC の関連付け機能を使用して、セキュリティグループを同じリージョン内の複数の VPC に関連付けることができます。これにより、アカウント内の複数の VPC のために、セキュリティグループを 1 か所で管理および維持できます。
![\[2 つの VPC に関連付けられたセキュリティグループの図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/sec-group-vpc-assoc.png)
上記の図は、2 つの VPC がある AWS アカウント A を示しています。各 VPC には、プライベートサブネットで実行されているワークロードがあります。この場合、VPC A および B サブネットのワークロードは同じネットワークトラフィック要件を共有するため、アカウント A はセキュリティグループの VPC の関連付け機能を使用して VPC A のセキュリティグループを VPC B に関連付けることができます。関連付けられたセキュリティグループに加えられた更新は、VPC B サブネットのワークロードへのトラフィックに自動的に適用されます。
**セキュリティグループの VPC の関連付け機能の要件**
+ セキュリティグループを VPC に関連付けるには、VPC を所有するか、または VPC サブネットの 1 つを共有する必要があります。
+ VPC とセキュリティグループは同じ AWS リージョンに存在する必要があります。
+ デフォルトのセキュリティグループを別の VPC に関連付けたり、セキュリティグループをデフォルトの VPC に関連付けたりすることはできません。
+ セキュリティグループの所有者と VPC 所有者の両方が、セキュリティグループの VPC の関連付けを表示できます。
**この機能をサポートするサービス**
+ Amazon API Gateway (REST API のみ)
+ AWS Auto Scaling
+ CloudFormation
+ Amazon EC2
+ Amazon EFS
+ Amazon EKS
+ Amazon FSx
+ AWS PrivateLink
+ Amazon Route 53
+ Elastic Load Balancing
+ Application Load Balancer
+ Network Load Balancer
## セキュリティグループを別の VPC に関連付ける
このセクションでは、AWS マネジメントコンソールと AWS CLI を使用してセキュリティグループを VPC に関連付ける方法について説明します。
------
#### [ AWS Management Console ]
**セキュリティグループを別の VPC と関連付けるには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[セキュリティグループ]** を選択します。
1. セキュリティグループを選択して、詳細を表示します。
1. **[VPC の関連付け]** タブを選択します。
1. [**Associate VPC**] を選択します。
1. **[VPC ID]** で、セキュリティグループに関連付ける VPC を選択します。
1. [**Associate VPC**] を選択します。
------
#### [ Command line ]
**セキュリティグループを別の VPC と関連付けるには**
1. [associate-security-group-vpc](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/associate-security-group-vpc.html) との VPC の関連付けを作成します。
1. [describe-security-group-vpc-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-group-vpc-associations.html) との VPC の関連付けのステータスを確認し、ステータスが `associated` になるまで待ちます。
------
これで、VPC がセキュリティグループに関連付けられました。
VPC をセキュリティグループに関連付けると、例えば、[VPC 内にインスタンスを起動し、この新しいセキュリティグループを選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)したり、[既存のセキュリティグループルールでこのセキュリティグループを参照](security-group-rules.md#security-group-referencing)したりできます。
## 別の VPC からセキュリティグループの関連付けを解除する
このセクションでは、AWS マネジメントコンソールと AWS CLI を使用して VPC からセキュリティグループの関連付けを解除する方法について説明します。セキュリティグループの削除を目標としている場合、この操作を実行することが考えられます。セキュリティグループは、関連付けられている場合は削除できません。セキュリティグループの関連付けを解除できるのは、そのセキュリティグループを使用する関連付けられた VPC にネットワークインターフェイスがない場合のみです。
------
#### [ AWS Management Console ]
**VPC からセキュリティグループの関連付けを解除するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[セキュリティグループ]** を選択します。
1. セキュリティグループを選択して、詳細を表示します。
1. **[VPC の関連付け]** タブを選択します。
1. **[VPC の関連付けを解除]** を選択します。
1. **[VPC ID]** で、セキュリティグループから関連付けを解除する VPC を選択します。
1. **[VPC の関連付けを解除]** を選択します。
1. VPC の関連付けタブで関連付け解除の **[ステータス]** を表示し、ステータスが `disassociated` になるまで待ちます。
------
#### [ Command line ]
**VPC からセキュリティグループの関連付けを解除するには**
1. [disassociate-security-group-vpc](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disassociate-security-group-vpc.html) を使用して VPC の関連付けを解除します。
1. [describe-security-group-vpc-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-group-vpc-associations.html) との VPC の関連付け解除のステータスを確認し、ステータスが `disassociated` になるまで待ちます。
------
これで、VPC とセキュリティグループの関連付けが解除されました。
# AWS Organizations とセキュリティグループを共有する
共有セキュリティグループ機能を使用すると、同じ AWS リージョンにある他の AWS Organizations アカウントとセキュリティグループを共有し、それらのアカウントでセキュリティグループを使用できるようになります。
次の図は、共有セキュリティグループ機能を使用して、AWS Organizations 内のアカウント間のセキュリティグループ管理を簡素化する方法を示しています:
![\[共有 VPC サブネット内の他のアカウントとのセキュリティグループ共有の図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/sec-group-sharing.png)
この図は、同じ Organization の一部である 3 つのアカウントを示しています。アカウント A は VPC サブネットをアカウント B および C と共有します。アカウント A は、共有セキュリティグループ機能を使用して、アカウント B および C とセキュリティグループを共有します。その後、アカウント B と C は、共有サブネットでインスタンスを起動する際に、そのセキュリティグループを使用します。これにより、アカウント A はセキュリティグループを管理できます。セキュリティグループに対する更新は、アカウント B と C が共有 VPC サブネットで実行しているリソースに適用されます。
**共有セキュリティグループ機能の要件**
+ この機能は、AWS Organizations の同じ Organizations 内のアカウントでのみ使用できます。AWS Organizations で [[リソース共有]](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html) が有効になっている必要があります。
+ セキュリティグループを共有するアカウントは、VPC とセキュリティグループの両方を所有している必要があります。
+ デフォルトのセキュリティグループを共有することはできません。
+ デフォルトの VPC にあるセキュリティグループを共有することはできません。
+ 参加者アカウントは共有 VPC にセキュリティグループを作成できますが、それらのセキュリティグループを共有することはできません。
+ IAM プリンシパルがセキュリティグループを AWS RAM と共有するには、最小限の許可セットが必要です。共有セキュリティグループを共有および使用するために必要な許可が IAM プリンシパルに付与されるよう、`AmazonEC2FullAccess` および `AWSResourceAccessManagerFullAccess` マネージド IAM ポリシーを使用します。カスタム IAM ポリシーを使用する場合は、`c2:PutResourcePolicy` および `ec2:DeleteResourcePolicy` アクションが必要です。これらはアクセス許可のみの IAM アクションです。IAM プリンシパルにこれらのアクセス許可が付与されていない場合、AWS RAM を使用してセキュリティグループを共有しようとするとエラーが発生します。
**この機能をサポートするサービス**
+ Amazon API Gateway
+ Amazon EC2
+ Amazon ECS
+ Amazon EFS
+ Amazon EKS
+ Amazon EMR
+ Amazon FSx
+ Amazon ElastiCache
+ AWS Elastic Beanstalk
+ AWS Glue
+ Amazon MQ
+ Amazon SageMaker AI
+ Elastic Load Balancing
+ Application Load Balancer
+ Network Load Balancer
**この機能が既存のクォータに及ぼす影響**
[セキュリティグループのクォータ](amazon-vpc-limits.md#vpc-limits-security-groups)が適用されます。ただし、[ネットワークインターフェイスあたりのセキュリティグループ] のクォータでは、参加者が Elastic Network Interface (ENI) で所有グループと共有グループの両方を使用する場合、所有者と参加者のクォータの最小値が適用されます。
クォータがこの機能によってどのように影響を受けるかを示す例:
+ 所有者アカウントのクォータ: インターフェイスあたり 4 つのセキュリティグループ
+ 参加者アカウントのクォータ: インターフェイスあたり 5 つのセキュリティグループ
+ 所有者は、グループ SG-O1、SG-O2、SG-O3、SG-O4、SG-O5 を参加者と共有します。参加者は、VPC に既に独自のグループを持っています: SG-P1、SG-P2、SG-P3、SG-P4、SG-P5。
+ 参加者が ENI を作成し、自分の所有グループのみを使用する場合、5 つのセキュリティグループ (SG-P1、SG-P2、SG-P3、SG-P4、SG-P5) すべてを関連付けることができます。なぜなら、これが参加者のクォータだからです。
+ 参加者が ENI を作成し、その ENI で共有グループを使用する場合、関連付けることができるグループは最大 4 つのみです。この場合、このような ENI のクォータは、所有者と参加者のクォータの最小値です。考えられる有効な設定は次のようになります:
+ SG-O1、SG-P1、SG-P2、SG-P3
+ SG-O1、SG-O2、SG-O3、SG-O4
## セキュリティグループを共有する
このセクションでは、AWS マネジメントコンソールと AWS CLI を使用して、Organization 内の他のアカウントとセキュリティグループを共有する方法について説明します。
------
#### [ AWS Management Console ]
**セキュリティグループを共有するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[セキュリティグループ]** を選択します。
1. セキュリティグループを選択して、詳細を表示します。
1. [**共有**] タブを選択します。
1. **[セキュリティグループを共有]** を選択します。
1. **[リソースの共有の作成]** を選択します。すると、AWS RAM コンソールが開きます。そこで、セキュリティグループのリソース共有を作成します。
1. リソース共有の **[名前]** を入力します。
1. **[リソース - オプション]** で、**[セキュリティグループ]** を選択します。
1. [セキュリティグループ] をクリックします。セキュリティグループをデフォルトのセキュリティグループにしたり、デフォルトの VPC に関連付けたりすることはできません。
1. [**次へ**] を選択します。
1. プリンシパルによる実行が許可されているアクションを確認し、**[次へ]** を選択します。
1. **[プリンシパル - オプション]** で **[自分の組織内でのみ共有を許可]** を選択します。
1. **[プリンシパル]** で、次のいずれかのプリンシパルタイプを選択し、適切な数値を入力します:
+ **[AWS アカウント]**: Organization 内のアカウントのアカウント番号。
+ **[Organization]**: AWS Organization ID。
+ **[組織単位 (OU)]**: Organization 内の OU の ID。
+ **[IAM ロール]**: IAM ロールの ARN。ロールを作成したアカウントは、このリソース共有を作成するアカウントと同じ Organization のメンバーである必要があります。
+ **[IAM ユーザー]**: IAM ユーザーの ARN。ユーザーを作成したアカウントは、このリソース共有を作成するアカウントと同じ Organization のメンバーである必要があります。
+ **[サービスプリンシパル]**: セキュリティグループをサービスプリンシパルと共有することはできません。
1. **[Add]** (追加) を選択します。
1. [**次へ**] を選択します。
1. **[リソースの共有の作成]** を選択します。
1. **[共有リソース]** で、`Associated` の **[ステータス]** が表示されるまで待ちます。セキュリティグループの関連付けに障害が発生した場合は、上記の制限のいずれかが原因である可能性があります。詳細ページでセキュリティグループの詳細と **[共有中]** タブを表示して、セキュリティグループを共有できない理由に関連するメッセージを確認します。
1. VPC コンソールのセキュリティグループリストに戻ります。
1. 共有したセキュリティグループを選択します。
1. [**共有**] タブを選択します。そこで AWS RAM リソースが表示されるはずです。表示されない場合、リソース共有の作成が失敗した可能性があり、再作成する必要がある場合があります。
------
#### [ Command line ]
**セキュリティグループを共有するには**
1. AWS RAM と共有するセキュリティグループのリソース共有を最初に作成する必要があります。AWS CLI を使用して AWS RAM とのリソース共有を作成するステップについては、「*AWS RAM ユーザーガイド*」の「[AWS RAM でのリソース共有の作成](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)」を参照してください。
1. 作成されたリソース共有の関連付けを表示するには、[get-resource-share-associations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/get-resource-share-associations.html) を使用します。
------
これで、セキュリティグループが共有されました。同じ VPC 内の共有サブネットで [ EC2 インスタンスを起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)するときに、セキュリティグループを選択できます。
## セキュリティグループの共有を停止する
このセクションでは、AWS マネジメントコンソールと AWS CLI を使用して、Organization 内の他のアカウントとセキュリティグループの共有を停止する方法について説明します。
------
#### [ AWS Management Console ]
**セキュリティグループの共有を停止するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[セキュリティグループ]** を選択します。
1. セキュリティグループを選択して、詳細を表示します。
1. [**共有**] タブを選択します。
1. セキュリティグループのリソース共有を選択し、**[共有を停止]** を選択します。
1. **[はい、共有を停止します]** を選択します。
------
#### [ Command line ]
**セキュリティグループの共有を停止するには**
[delete-resource-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-resource-share.html) を使用してリソース共有を削除します。
------
セキュリティグループは共有されなくなりました。所有者がセキュリティグループの共有を停止すると、次のルールが適用されます:
+ 既存の参加者の Elastic Network Interface (ENI) は、共有解除されたセキュリティグループに対して行われたセキュリティグループルールの更新を引き続き取得します。共有の解除による影響は、参加者が共有解除されたグループと新しい関連付けを作成できなくなることだけです。
+ 参加者は、共有解除されたセキュリティグループを所有している ENI に関連付けることができなくなります。
+ 参加者は、共有解除されたセキュリティグループに引き続き関連付けられている ENI を記述および削除できます。
+ 共有解除されたセキュリティグループに関連付けられている ENI を参加者が引き続き持っている場合、所有者は、共有解除されたセキュリティグループを削除できません。所有者は、参加者がすべての ENI からセキュリティグループの関連付けを解除 (セキュリティグループを削除) した後にのみ、セキュリティグループを削除できます。
+ 参加者は、共有されていないセキュリティグループに関連付けられた ENI を使用して新しい EC2 インスタンスを起動することはできません。
# ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する
*ネットワークアクセスコントロールリスト (ACL)* は、サブネットレベルで特定のインバウンドまたはアウトバウンドのトラフィックを許可または拒否します。VPC のデフォルトのネットワーク ACL を使用するか、セキュリティグループと同様のルールを使用して VPC のカスタムネットワーク ACL を作成し、セキュリティの追加レイヤーを VPC に追加できます。
ネットワーク ACL は追加料金なしで使用できます。
次の図は、2 つのサブネットを持つ VPC を示しています。各サブネットにはネットワーク ACL があります。トラフィックが (ピアリングされた VPC、VPN 接続、インターネットなどから) VPC に入ると、ルーターはこのトラフィックを宛先に送信します。ネットワーク ACL A は、サブネット 1 を宛先とするトラフィックのうち、サブネット 1 への送信を許可するトラフィックと、サブネット 1 以外を宛先とするトラフィックのうち、サブネット 1 からの送信を許可するトラフィックを決定します。同様に、ネットワーク ACL B は、どのトラフィックがサブネット 2 に出入りできるかを決定します。
![\[2 つのサブネットと各サブネットのネットワーク ACL を持つ VPC。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/network-acl.png)
セキュリティグループとネットワーク ACL の違いについては、「[セキュリティグループとネットワーク ACL を比較する](infrastructure-security.md#VPC_Security_Comparison)」を参照してください。
**Topics**
+ [ネットワーク ACL の基本](#nacl-basics)
+ [ネットワーク ACL ルール](nacl-rules.md)
+ [VPC のデフォルトのネットワーク ACL](default-network-acl.md)
+ [VPC のカスタムネットワーク ACL](custom-network-acl.md)
+ [パス MTU 検出とネットワーク ACL](path_mtu_discovery.md)
+ [VPC のネットワーク ACL を作成する](create-network-acl.md)
+ [VPC のネットワーク ACL の関連付けを管理する](network-acl-associations.md)
+ [VPC のネットワーク ACL を削除する](delete-network-acl.md)
+ [例: サブネットのインスタンスへのアクセス制御](nacl-examples.md)
## ネットワーク ACL の基本
開始する前にネットワーク ACL について知っておくべき基本的な情報を以下に示します。
**ネットワーク ACL の関連付け**
+ VPC 内の各サブネットにネットワーク ACL を関連付ける必要があります。ネットワーク ACL に明示的にサブネットを関連付けない場合、サブネットは[デフォルトのネットワーク ACL](default-network-acl.md) に自動的に関連付けられます。
+ [カスタムネットワーク ACL](custom-network-acl.md) を作成して、それをサブネットに関連付けることで、サブネットレベルで特定のインバウンドトラフィックまたはアウトバウンドトラフィックを許可または拒否することができます。
+ ネットワーク ACL を複数のサブネットに関連付けることができます。ただし、サブネットは一度に 1 つのネットワーク ACL にのみ関連付けることができます。サブネットとネットワーク ACL を関連付けると、以前の関連付けは削除されます。
**ネットワーク ACL ルール**
+ ネットワーク ACL には、インバウンドルールとアウトバウンドルールがあります。[ネットワーク ACL ごとに設定できるルールの数にはクォータ (または制限)](amazon-vpc-limits.md#vpc-limits-nacls) が設定されています。各ルールでは、トラフィックを許可または拒否できます。各ルールには 1 から 32,766 までの番号が設定されます。トラフィックを許可するか拒否するかを決定する際は、最も低い番号のルールから順にルールを評価します トラフィックがルールに一致すると、そのルールが適用され、追加のルールは評価されません。まずは増分 (例えば 10 または 100 の増分) でルールを作成することをお勧めします。こうすると、必要になったときに後で新しいルールを挿入できます。
+ ネットワーク ACL ルールは、トラフィックがサブネット内でルーティングされるときではなく、サブネットに出入りするときに評価されます。
+ NACL は*ステートレス*です。つまり、以前に送受信されたトラフィックに関する情報は保存されません。例えば、サブネットへの特定のインバウンドトラフィックを許可する NACL ルールを作成しても、そのトラフィックへの応答は自動的には許可されません。これは、セキュリティグループの仕組みとは対照的です。セキュリティグループは*ステートフル*です。つまり、以前に送受信されたトラフィックに関する情報が保存されます。例えば、セキュリティグループが EC2 インスタンスへのインバウンドトラフィックを許可している場合、アウトバウンドセキュリティグループのルールにかかわらず、レスポンスは自動的に許可されます。
**制限事項**
+ ネットワーク ACL にはクォータ (制限とも呼ばれます) が設定されています。詳細については、「[ネットワーク ACL](amazon-vpc-limits.md#vpc-limits-nacls)」を参照してください。
+ ネットワーク ACL では、Route 53 Resolver (VPC\$12 IP アドレスまたは AmazonProvidedDNS とも呼ばれます) で送受信される DNS リクエストをブロックすることはできません。Route 53 Resolver 経由の DNS リクエストをフィルタリングするために、[Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) を有効化できます。
+ ネットワーク ACL では、インスタンスメタデータサービス (IMDS) へのトラフィックをブロックすることはできません。IMDS へのアクセスを管理するには、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータオプションの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)」を参照してください。
+ ネットワーク ACL では、以下で送受信されるトラフィックはフィルターされません。
+ Amazon ドメインネームサービス (DNS)
+ Amazon Dynamic Host Configuration Protocol (DHCP)
+ Amazon EC2 インスタンスメタデータ。
+ Amazon ECS タスクメタデータエンドポイント
+ Windows インスタンスのライセンスアクティベーション
+ Amazon Time Sync Service
+ デフォルトの VPC ルーターによる予約済み IP アドレス
# ネットワーク ACL ルール
デフォルトのネットワーク ACL に対してルールの追加または削除を行うことができます。また、VPC に合わせて追加のネットワーク ACL を作成することができます。ネットワーク ACL に対してルールの追加または削除を行うと、変更内容は、その ACL に関連付けられているサブネットに自動的に適用されます。
次に、ネットワーク ACL ルールの一部を示します。
+ **ルール番号**。ルールは、最も低い番号のルールから評価されます。ルールがトラフィックに一致すると、それと相反するより高い数値のルールの有無にかかわらず、すぐに適用されます。
+ **タイプ**。トラフィックのタイプ（SSH など）。また、すべてのトラフィックまたはカスタム範囲を指定することもできます。
+ **プロトコル**。標準のプロトコル番号を持つ任意のプロトコルを指定できます。詳細については、「[プロトコル番号](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)」を参照してください。プロトコルとして ICMP を指定する場合、任意またはすべての ICMP タイプとコードを指定できます。
+ **ポート範囲**。トラフィックのリスニングポートまたはポート範囲。たとえば、HTTP トラフィックの場合は 80 です。
+ **ソース**: [インバウンドルールのみ] トラフィックの送信元 (CIDR 範囲)。
+ **送信先**。[アウトバウンドルールのみ] トラフィックの送信先 (CIDR 範囲)。
+ **許可/拒否**。指定されたトラフィックを*許可する*か*拒否する*かを指定します。
ロールの例については、「[例: サブネットのインスタンスへのアクセス制御](nacl-examples.md)」を参照してください。
## 考慮事項
+ ネットワーク ACL あたりのルールの数には、クォータ (制限とも呼ばれます) があります。詳細については、「[Amazon VPC クォータ](amazon-vpc-limits.md)」を参照してください。
+ ACL のルールの追加または削除を行うと、その ACL に関連付けられたすべてのサブネットに変更が反映されます。変更は短期間で有効になります。
+ コマンドラインツールまたは Amazon EC2 API を使用してルールを追加すると、CIDR 範囲は自動的に正規形式に変更されます。たとえば、CIDR 範囲に `100.68.0.18/18` を指定すると、`100.68.0.0/18` の CIDR 範囲を持つルールが作成されます。
+ 広い範囲のポートを開く必要があるが、その範囲内の特定のポートは拒否する場合は、拒否ルールを追加する必要があります。拒否ルールには、より広範なポートトラフィックを許可するルールよりも少ない数を指定してください。
+ ネットワーク ACL のルールを同時に追加および削除する場合は、注意が必要です。インバウンドルールまたはアウトバウンドルールを削除し、許可されている数より多くのエントリを追加した場合 ([Amazon VPC クォータ](amazon-vpc-limits.md) を参照)、削除対象として選択されたエントリは削除され、新しいエントリは*追加されません*。これにより、予期しない接続の問題が発生し、VPC へのアクセスや VPC からのアクセスが妨げられる可能性があります。
# VPC のデフォルトのネットワーク ACL
仮想プライベートクラウド (VPC) には、デフォルトのネットワーク ACL が自動的に付属します。デフォルトのネットワーク ACL は、すべてのトラフィックが、関連するサブネットを出入りすることを許可するように設定されます。各ネットワーク ACL には、ルール番号がアスタリスク (\$1) であるルールも含まれます。これらのルールにより、パケットが他のいずれの番号のルールとも一致しない場合は、確実に拒否されます。
ルールを追加したり、デフォルトの番号付きルールを削除したりすることで、デフォルトのネットワーク ACL を変更できます。ルール番号がアスタリスクになっているルールは削除できません。
**デフォルトのインバウンドルール**
次の表は、デフォルトのネットワーク ACL のデフォルトのインバウンドルールを示しています。IPv6 のルールは、関連付けられた IPv6 CIDR ブロックを使用して VPC を作成するか、IPv6 CIDR ブロックを VPC に関連付ける場合にのみ追加されます。ただし、デフォルトのネットワーク ACL のインバウンドルールを変更した場合は、IPv6 ブロックを VPC と関連付けても、すべてのインバウンド IPv6 トラフィックを許可するルールは追加されません。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| --- | --- | --- | --- | --- | --- |
| 100 | すべての IPv4 トラフィック | すべて | すべて | 0.0.0.0/0 | 許可 |
| 101 | すべての IPv6 トラフィック | すべて | すべて | ::/0 | 許可 |
| \$1 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | DENY |
| \$1 | すべての IPv6 トラフィック | すべて | すべて | ::/0 | DENY |
**デフォルトのアウトバウンドルール**
次の表は、デフォルトネットワーク ACL のデフォルトのアウトバウンドルールを示しています。IPv6 のルールは、関連付けられた IPv6 CIDR ブロックを使用して VPC を作成するか、IPv6 CIDR ブロックを VPC に関連付ける場合にのみ追加されます。ただし、デフォルトのネットワーク ACL のアウトバウンドルールを変更した場合、IPv6 ブロックを VPC に関連付けるときにすべてのアウトバウンド IPv6 トラフィックを許可するルールは追加されません。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信先 | 許可/拒否 |
| --- | --- | --- | --- | --- | --- |
| 100 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 許可 |
| 101 | すべての IPv6 トラフィック | すべて | すべて | ::/0 | 許可 |
| \$1 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | DENY |
| \$1 | すべての IPv6 トラフィック | すべて | すべて | ::/0 | DENY |
# VPC のカスタムネットワーク ACL
カスタムネットワーク ACL を作成して、それをサブネットに関連付けることで、サブネットレベルで特定のインバウンドトラフィックまたはアウトバウンドトラフィックを許可または拒否することができます。詳細については、「[VPC のネットワーク ACL を作成する](create-network-acl.md)」を参照してください。
各ネットワーク ACL には、デフォルトのインバウンドルールと、ルール番号がアスタリスク (\$1) であるデフォルトの送信ルールが含まれます。これらのルールにより、パケットが他のどのルールにも一致しない場合は拒否されます。
ルールを追加または削除することで、ネットワーク ACL を変更できます。ルール番号がアスタリスクになっているルールは削除できません。
追加するルールごとに、応答トラフィックを許可するインバウンドルールまたはアウトバウンドルールが必要です。適切な一時ポートの範囲を選択する方法については、「[一時ポート](#nacl-ephemeral-ports)」を参照してください。
**インバウンドルールの例**
次の表は、ネットワーク ACL のインバウンドルールの例を示しています。IPv6 のルールは、VPC に関連付けられた IPv6 CIDR ブロックがある場合にのみ追加されます。IPv4 トラフィックと IPv6 トラフィックは個別に評価されます。したがって、IPv4 トラフィックのルールは IPv6 トラフィックには適用されません。対応する IPv4 ルールの横に IPv6 ルールを追加したり、最後の IPv4 ルールの後に IPv6 ルールを追加したりもできます。
パケットがサブネットに送信されると、サブネットが関連付けられている ACL のインバウンドルールに対して、最も小さい番号のルールから順に評価されます。例えば、HTTPS ポート (443) 宛ての IPv4 トラフィックがあるとします。パケットがルール 100 または 105 と一致しません。これは、サブネットへのトラフィックを許可するルール 110 と一致します。パケットの宛先がポート 139 (NetBIOS) だった場合、番号付きルールのいずれにも一致しないため、IPv4 トラフィックの \$1 ルールによって最終的にパケットが拒否されます。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 | コメント |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | 許可 | 任意の IPv4 アドレスからのインバウンド HTTP トラフィックを許可します。 |
| 105 | HTTP | TCP | 80 | ::/0 | 許可 | 任意の IPv6 アドレスからのインバウンド HTTP トラフィックを許可します。 |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | 許可 | 任意の IPv4 アドレスからのインバウンド HTTPS トラフィックを許可します。 |
| 115 | HTTPS | TCP | 443 | ::/0 | 許可 | 任意の IPv6 アドレスからのインバウンド HTTPS トラフィックを許可します。 |
| 120 | SSH | TCP | 22 | *192.0.2.0/24* | 許可 | （インターネットゲートウェイを介した）ホームネットワークのパブリック IPv4 アドレスの範囲からのインバウンド SSH トラフィックを許可します。 |
| 140 | カスタム TCP | TCP | *32768-65535* | 0.0.0.0/0 | 許可 | (サブネットから発信されたリクエストの場合) インターネットからのインバウンドリターン IPv4 トラフィックを許可します。 |
| 145 | カスタム TCP | TCP | *32768-65535* | ::/0 | 許可 | （送信元がサブネットであるリクエストの場合）インターネットからのインバウンドリターン IPv6 トラフィックを許可します。 |
| \$1 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | DENY | 前のルールでまだ処理されていないすべてのインバウンド IPv4 トラフィックを拒否します (変更不可)。 |
| \$1 | すべてのトラフィック | すべて | すべて | ::/0 | 拒否 | 前のルールでまだ処理されていないすべてのインバウンド IPv6 トラフィックを拒否します (変更不可)。 |
**アウトバウンドルールの例**
次の表は、カスタムネットワーク ACL のアウトバウンドルールの例を示しています。IPv6 のルールは、VPC に関連付けられた IPv6 CIDR ブロックがある場合にのみ追加されます。IPv4 トラフィックと IPv6 トラフィックは個別に評価されます。したがって、IPv4 トラフィックのルールは IPv6 トラフィックには適用されません。対応する IPv4 ルールの横に IPv6 ルールを追加したり、最後の IPv4 ルールの後に IPv6 ルールを追加したりもできます。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信先 | 許可/拒否 | コメント |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | 許可 | サブネットからインターネットへのアウトバウンド IPv4 HTTP トラフィックを許可します。 |
| 105 | HTTP | TCP | 80 | ::/0 | 許可 | サブネットからインターネットへのアウトバウンド IPv6 HTTP トラフィックを許可します。 |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | 許可 | サブネットからインターネットへのアウトバウンド IPv4 HTTPS トラフィックを許可します。 |
| 115 | HTTPS | TCP | 443 | ::/0 | 許可 | サブネットからインターネットへのアウトバウンド IPv6 HTTPS トラフィックを許可します。 |
| 120 | カスタム TCP | TCP | *1024-65535* | *192.0.2.0/24* | 許可 | ホーム ネットワークからの SSH トラフィックへのアウトバンド応答を許可します。 |
| 140 | カスタム TCP | TCP | *32768-65535* | 0.0.0.0/0 | 許可 | インターネット上のクライアントに対するアウトバウンド IPv4 応答を許可します（例: ウェブページの提供）。 |
| 145 | カスタム TCP | TCP | *32768-65535* | ::/0 | 許可 | インターネット上のクライアントに対するアウトバウンド IPv6 応答を許可します（例: ウェブページの提供）。 |
| \$1 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | DENY | 前のルールでまだ処理されていないすべてのアウトバウンド IPv4 トラフィックを拒否します。 |
| \$1 | すべてのトラフィック | すべて | すべて | ::/0 | DENY | 前のルールでまだ処理されていないすべてのアウトバウンド IPv6 トラフィックを拒否します。 |
## 一時ポート
前のセクションでは、ネットワーク ACL の例に 32768～65535 という一時ポートの範囲を使用しています。ただし、使用または通信しているクライアントの種類によっては、ネットワーク ACL に別の範囲を使用してもかまいません。
リクエストを開始するクライアントは、一時ポートの範囲を選択します。範囲は、クライアントのオペレーティングシステムによって変わります。
+ 多くの Linux カーネル (Amazon Linux カーネルを含む) は、ポート 32768～61000 を使用します。
+ Elastic Load Balancing からのリクエストは、ポート 1024-65535 を使用します。
+ Windows Server 2003 を介する Windows オペレーティングシステムは、ポート 1025～5000 を使用します。
+ Windows Server 2008 以降のバージョンでは、ポート 49152～65535 を使用します。
+ NAT ゲートウェイはポート 1024～65535 を使用します。
+ AWS Lambda 関数は、ポート 1024-65535 を使用します。
たとえば、インターネット上の Windows 10 クライアントから、お客様の VPC のウェブサーバーにリクエストが送信される場合、ネットワーク ACL には、ポート 49152 ～ 65535 宛てのトラフィックを可能にするアウトバウンドルールを用意する必要があります。
VPC 内のインスタンスが、リクエストを開始するクライアントの場合、ネットワーク ACL には、インスタンスのオペレーティング システムに固有の一時ポートあてのトラフィックを可能にするインバウンドルールを用意する必要があります。
実際に、VPC 内のパブリックに面したインスタンスに対して、トラフィックを開始することができる多様なクライアントを対象にするには、一時ポート 1024～65535 を開くことができます。ただし、その範囲内で悪意のあるポートのトラフィックを拒否するルールを ACL を追加することもできます。このとき、テーブル内で、幅広い範囲の一時ポートを開く許可ルールよりも先に拒否ルールを配置します。
## カスタムネットワーク ACL およびその他の AWS のサービス
カスタムネットワーク ACL を作成する場合は、他の AWS のサービスを使用して作成したリソースにどのように影響するか注意してください。
Elastic Load Balancing では、バックエンドインスタンスのサブネットに、ソースが `0.0.0.0/0` であるかサブネットの CIDR のいずれかであるすべてのトラフィックに追加した*拒否*ルールを適用するネットワーク ACL がある場合、ロードバランサーはインスタンスのヘルスチェックを実行できません。ロードバランサーとバックエンドインスタンスに推奨されるネットワーク ACL ルールに関する詳細については、以下を参照してください。
+ [Network ACLs for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html)
+ [Network ACLs for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#network-acls)
+ [Network ACLs for your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-vpc-network-acls.html)
## 到達可能性に関する問題のトラブルシューティング
Reachability Analyzer は静的な設定分析ツールです。Reachability Analyzer を使用して、VPC 内の 2 つのリソース間のネットワーク到達可能性を分析およびデバッグできます。Reachability Analyzer は、これらのリソースに到達可能な場合は、リソース間にある仮想パスのホップバイホップの詳細を生成し、そうでない場合はブロッキングコンポーネントを識別します。例えば、欠落した、または誤って設定されたネットワーク ACL のルールを特定できます。
詳細については、「[Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/)」(到達可能性アナライザーガイド) を参照してください。
# パス MTU 検出とネットワーク ACL
2 つのデバイス間のパス MTU を判断するために、パス MTU 検出が使用されます。パス MTU は、送信側ホストと受信側ホスト間のパスでサポートされている最大のパケットサイズです。
IPv4 の場合、ホストがパスに沿って送信するパケットが、受信側ホストの MTU、あるいはデバイスの MTU よりも大きな場合、受信側ホストまたはデバイスはそのパケットをドロップし、次のような ICMP メッセージ `Destination Unreachable: Fragmentation Needed and Don't Fragment was Set` (タイプ 3、コード 4) を返します。このメッセージは送信側ホストに対し、ペイロードを複数の小さなパケットに分割し再送信することを指示します。
IPv6 プロトコルはネットワークのフラグメンテーションをサポートしていません。ホストがパスに沿って送信するパケットが、受信側ホストの MTU、あるいはデバイスの MTU よりも大きな場合、受信側ホストまたはデバイスはそのパケットをドロップし、次のような ICMP メッセージ `ICMPv6 Packet Too Big (PTB)` (タイプ 2) を返します。このメッセージは送信側ホストに対し、ペイロードを複数の小さなパケットに分割し再送信することを指示します。
サブネット内のホスト間の最大送信単位 (MTU) が異なる場合、またはインスタンスがインターネット経由でピアと通信する場合、インバウンドとアウトバウンドの両方に、以下のネットワーク ACL ルールを追加する必要があります。これにより、パス MTU 検出が正しく機能し、パケット損失を防ぐことができます。タイプに [**Custom ICMP Rule**] を選択し、ポート範囲（タイプ 3、コード 4）に [**送信先に到達できません**]、[**fragmentation required, and DF flag set (フラグメンテーションが必要、および DF フラグを設定)**] を選択します。トレースルートを使用する場合は、次のルールも追加します。[**カスタム ICMP ルール**] (タイプ)、[**時間超過**]、[**TTL 伝送期限切れ**] (ポート範囲: タイプ 11、コード 0) を選択します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 インスタンスのネットワーク最大送信単位 (MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html)」を参照してください。
# VPC のネットワーク ACL を作成する
次のタスクは、ネットワーク ACL を作成し、ルールをネットワーク ACL に追加してから、ネットワーク ACL をサブネットに関連付ける方法を示します。
**Topics**
+ [ステップ 1: ネットワーク ACL を作成する](#CreateACL)
+ [ステップ 2: ルールを追加する](#Rules)
+ [ステップ 3: サブネットをネットワーク ACL に関連付ける](#NetworkACL)
+ [(オプション) Firewall Manager を使用してネットワーク ACL を管理する](#nacls-using-firewall-manager)
## ステップ 1: ネットワーク ACL を作成する
VPC のカスタムネットワーク ACL を作成できます。カスタムネットワーク ACL の初期ルールは、すべてのインバウンドトラフィックとアウトバウンドトラフィックをブロックします。新しいカスタムネットワーク ACL は、デフォルトではサブネットに関連付けられていないため、明示的にサブネットに関連付ける必要があります。
**コンソールを使用してネットワーク ACL を作成するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの [**Network ACLs**] を選択します。
1. **[ネットワーク ACL の作成]** を選択します。
1. (オプション) **[名前]** に、ネットワーク ACL の名前を入力します。
1. **[VPC]** で、VPC を選択します。
1. (オプション) **[タグ]** で、**[タグの追加]** を選択して、タグのキーと値を指定します。
1. **[ネットワーク ACL の作成]** を選択します。
**コマンドラインを使用してネットワーク ACL を作成するには**
+ [create-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-network-acl.html)（AWS CLI）
+ [New-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NetworkAcl.html)（AWS Tools for Windows PowerShell）
## ステップ 2: ルールを追加する
インバウンドトラフィックまたはアウトバウンドトラフィックを許可または拒否するルールを追加できます。
最も小さい番号のルールから順にルールを処理します。ルール番号は、連続番号 (101、102、103 など) を使用せずに、間を空けておくことをお勧めします (100、200、300 など)。こうすることで、既存のルールに番号を振り直さなくても、新しいルールを簡単に追加できるようになります。
Amazon EC2 API またはコマンドラインツールを使用している場合は、ルールを変更できません。ルールの追加と削除のみを行うことができます。Amazon VPC コンソールを使用している場合は、既存のルールのエントリを変更できます。コンソールは既存のルールを削除し、新しいルールを追加します。ACL のルールの順序を変更する必要がある場合は、新しいルール番号を指定した新しいルールを追加してから、元のルールを削除します。
**コンソールを使用してネットワーク ACL にルールを追加するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの [**Network ACLs**] を選択します。
1. ネットワーク ACL を選択します。
1. インバウンドルールを追加するには、次の手順を実行します。
1. **[Inbound rules]** (インバウンドルール) タブを開きます。
1. **[インバウンドのルールの編集]** ページで、**[新しいルールの追加** を選択します。
1. まだ使用されていないルール番号、タイプ、プロトコル、ポート範囲、ソース、トラフィックを許可または拒否するかどうかを入力します。一部のタイプでは、プロトコルとポートが自動的に入力されます。ポート範囲の入力を求められた場合は、ポート番号またはポート範囲 (49152-65535 など) を入力します。
リストにないプロトコルを使用するには、タイプの **[カスタムプロトコル]** をクリックし、プロトコルを選択します。詳細については、「[IANA プロトコル番号](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)」を参照してください。
1. **[Save changes]** (変更の保存) をクリックします。
1. アウトバウンドルールを追加するには、次の手順を実行します。
1. **[Outbound rules]** (アウトバウンドルール) タブを選択します。
1. **[アウトバウンドのルールの編集]**、**[ルールの追加]** の順に選択します。
1. まだ使用されていないルール番号、タイプ、プロトコル、ポート範囲、ソース、トラフィックを許可または拒否するかどうかを入力します。一部のタイプでは、プロトコルとポートが自動的に入力されます。ポート範囲の入力を求められた場合は、ポート番号またはポート範囲 (49152-65535 など) を入力します。
リストにないプロトコルを使用するには、タイプの **[カスタムプロトコル]** をクリックし、プロトコルを選択します。詳細については、「[IANA プロトコル番号](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)」を参照してください。
1. **[Save changes]** (変更の保存) をクリックします。
**コマンドラインを使用してネットワーク ACL にルールを追加するには**
+ [create-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-network-acl-entry.html)（AWS CLI）
+ [New-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NetworkAclEntry.html)（AWS Tools for Windows PowerShell）
**コマンドラインを使用してネットワーク ACL のルールを置き換えるには**
+ [replace-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-entry.html)（AWS CLI）
+ [Set-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclEntry.html)（AWS Tools for Windows PowerShell）
**コマンドラインを使用してネットワーク ACL からルールを削除するには**
+ [delete-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl-entry.html)（AWS CLI）
+ [Remove-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NetworkAclEntry.html)（AWS Tools for Windows PowerShell）
## ステップ 3: サブネットをネットワーク ACL に関連付ける
ネットワーク ACL のルールを特定のサブネットに適用するには、サブネットをネットワーク ACL と関連付ける必要があります。ネットワーク ACL を複数のサブネットに関連付けることができます。ただし、サブネットに関連付けることができるネットワーク ACL は 1 つだけです。特定の ACL に関連付けられていないサブネットは、デフォルトでデフォルトのネットワーク ACL と関連付けられます。
**サブネットをネットワーク ACL と関連付けるには**
1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。
1. ナビゲーションペインで [**Network ACLs**] を選択してから、ネットワーク ACL を選択します。
1. 詳細ペインの [**Subnet Associations**] タブで、[**Edit**] を選択します。ネットワーク ACL に関連付けるサブネットの [**Associate**] チェックボックスをオンにしてから、[**Save**] を選択します。
## (オプション) Firewall Manager を使用してネットワーク ACL を管理する
AWS Firewall Manager は、複数のアカウントおよび複数のサブネット間でネットワーク ACL の管理およびメンテナンスタスクを簡略化します。Firewall Manager を使用して、組織内のアカウントとサブネットをモニタリングし、定義したネットワーク ACL の設定を自動的に適用できます。Firewall Manager は、組織全体を保護する場合や、中央管理者アカウントで自動的に保護する新しいサブネットを頻繁に追加する場合に特に便利です。
Firewall Manager のネットワーク ACL ポリシーでは、単一の管理者アカウントを使用して、組織全体で使用するネットワーク ACL で定義する最小ルールセットを設定、モニタリング、および管理できます。組織内のどのアカウントとサブネットが Firewall Manager ポリシーの範囲内にあるかを指定します。Firewall Manager は、対象範囲内のサブネットのネットワーク ACL のコンプライアンスステータスを報告します。また、Firewall Manager を設定して、コンプライアンス違反のネットワーク ACL の修復を自動化することもできます。
詳細については、「*AWS Firewall Manager デベロッパーガイド*」で以下のリソースを参照してください。
+ [AWS Firewall Manager の前提条件](https://docs.aws.amazon.com/waf/latest/developerguide/fms-prereq.html)
+ [AWS Firewall Manager ネットワーク ACL ポリシーのセットアップ](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html)
+ [Firewall Manager でネットワーク ACL ポリシーを使用する](https://docs.aws.amazon.com/waf/latest/developerguide/network-acl-policies.html)
# VPC のネットワーク ACL の関連付けを管理する
各サブネットは 1 つのネットワーク ACL に関連付けられます。サブネットを初めて作成すると、VPC のデフォルトのネットワーク ACL に関連付けられます。カスタムネットワーク ACL を作成し、それを 1 つ以上のサブネットに関連付け、以前のネットワーク ACL の関連付けを置き換えることができます。
**Topics**
+ [ネットワーク ACL の関連付けを記述する](#describe-network-acl-association)
+ [ネットワーク ACL に関連付けられたサブネットを変更する](#DisassociateNetworkACL)
+ [サブネットに関連付けられたネットワーク ACL を変更する](#ChangeNetworkACL)
## ネットワーク ACL の関連付けを記述する
サブネットに関連付けられているネットワーク ACL を記述したり、ネットワーク ACL に関連付けられているサブネットを記述したりすることもできます。
**コンソールを使用してサブネットに関連付けられたネットワーク ACL を記述するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインで、[**サブネット**] を選択してください。
1. サブネットを選択します。
1. **[ネットワーク ACL]** タブを選択します。
**AWS CLI を使用してサブネットに関連付けられたネットワーク ACL を記述するには**
指定されたサブネットに関連付けられているネットワーク ACL を一覧表示するには、次の [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) コマンドを使用します。
```
aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=subnet-0d2d1b81e0bc9c6d4 --query NetworkAcls[*].NetworkAclId
```
以下は出力の例です。
```
[
"acl-03701d1f82d8c3fd6"
]
```
**コンソールを使用してネットワーク ACL に関連付けられたサブネットを記述するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの [**Network ACLs**] を選択します。
1. ネットワーク ACL を選択します。
1. **[サブネットの関連付け]** タブを選択します。
**AWS CLI を使用してネットワーク ACL に関連付けられたサブネットを記述するには**
指定されたネットワーク ACL に関連付けられたサブネットを一覧表示するには、次の [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) コマンドを使用します。
```
aws ec2 describe-network-acls --network-acl-ids acl-060415a18fcc9afde --query NetworkAcls[*].Associations[].SubnetId
```
以下は出力の例です。
```
[
"subnet-0d2d1b81e0bc9c6d4",
"subnet-0e990c67809773b19",
"subnet-0eb17d85f5dfd33b1",
"subnet-0e01d500780bb7468"
]
```
## ネットワーク ACL に関連付けられたサブネットを変更する
サブネットからカスタムネットワーク ACL の関連付けを解除できます。サブネットをカスタム ネットワーク ACL から関連付け解除すると、そのサブネットはデフォルトのネットワーク ACL に自動的に関連付けられます。変更はしばらくすると有効になります。
**ネットワーク ACL に関連付けられたサブネットを変更するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの [**Network ACLs**] を選択します。
1. ネットワーク ACL を選択します。
1. **[アクション]**、**[サブネットの関連付けの編集]** を選択します。
1. **[選択済みサブネット]** からサブネットを削除します。
1. **[Save changes]** (変更の保存) をクリックします。
## サブネットに関連付けられたネットワーク ACL を変更する
サブネットに関連付けられているネットワーク ACL を変更できます。例えば、サブネットを作成すると、初期設定では VPC のデフォルトのネットワーク ACL に関連付けられます。カスタムネットワーク ACL を作成する場合は、ネットワーク ACL を 1 つ以上のサブネットに関連付けることで、ネットワーク ACL ルールを適用します。
サブネットのネットワーク ACL を変更すると、変更はしばらくすると有効になります。
**サブネットに関連付けられたネットワーク ACL を変更するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインで、[**サブネット**] を選択してください。
1. サブネットを選択します。
1. **[アクション]**、**[ネットワーク ACL の関連付けの編集]** の順に選択します。
1. **ネットワーク ACL ID** で、サブネットに関連付けるネットワーク ACL を選択し、選択したネットワーク ACL のインバウンドルールとアウトバウンドルールを確認します。
1. **[保存]** を選択します。
**コマンドラインを使用してネットワーク ACL の関連付けを置き換えるには**
+ [replace-network-acl-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-association.html)（AWS CLI）
+ [Set-EC2NetworkAclAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclAssociation.html)（AWS Tools for Windows PowerShell）
# VPC のネットワーク ACL を削除する
ネットワーク ACL の使用が終了したら、削除できます。サブネットが関連付けられている場合は、ネットワーク ACL を削除できません。デフォルトのネットワーク ACL は削除できません。
**コンソールを使用してネットワーク ACL からサブネットの関連付けを削除するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの [**Network ACLs**] を選択します。[**関連付け**] 列には、各ネットワーク ACL に関連付けられているサブネットの数が表示されます。関連付けられたサブネットがない場合、この列は `-` になります。
1. ネットワーク ACL を選択します。
1. **[アクション]**、**[サブネットの関連付けの編集]** を選択します。
1. サブネットの関連付けを削除します。
1. **[Save changes]** (変更の保存) をクリックします。
**コマンドラインを使用して、関連付けを含むネットワーク ACL を記述するには**
+ [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html)（AWS CLI）
+ [Get-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2NetworkAcl.html)（AWS Tools for Windows PowerShell）
**コマンドラインを使用してネットワーク ACL の関連付けを置き換えるには**
+ [replace-network-acl-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-association.html)（AWS CLI）
+ [Set-EC2NetworkAclAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclAssociation.html)（AWS Tools for Windows PowerShell）
**コンソールを使用してネットワーク ACL を削除するには**
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインの [**Network ACLs**] を選択します。
1. ネットワーク ACL を選択します。
1. **[アクション]**、**[ネットワーク ACL の削除]** の順に選択します。
1. 確認を求められたら、**delete**と入力し、[**削除**] を選択します。
**コマンドラインを使用してネットワーク ACL を削除するには**
+ [delete-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl.html)（AWS CLI）
+ [Remove-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NetworkAcl.html)（AWS Tools for Windows PowerShell）
# 例: サブネットのインスタンスへのアクセス制御
この例では、サブネットにあるインスタンスは相互に通信でき、管理タスクを実行するために信頼できるリモート コンピューターからアクセスできます。リモートコンピュータは、図に示すようにローカル ネットワーク内のコンピュータである場合もあれば、別のサブネットまたは VPC 内のインスタンスである場合もあります。サブネットのネットワーク ACL ルールとインスタンスのセキュリティグループルールにより、リモートコンピューターの IP アドレスからのアクセスが許可されます。インターネットまたは他のネットワークからのその他のトラフィックはすべて拒否されます。
![\[セキュリティグループと NACL の使用\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/nacl-example-diagram.png)
ネットワーク ACL を使用すると、ネットワーク ACL を防御のバックアップレイヤーとして利用しながら、インスタンスのセキュリティグループまたはセキュリティグループルールを柔軟に変更できるようになります。例えば、セキュリティグループを誤って更新してどこからでもインバウンド SSH アクセスを許可し、ネットワーク ACL がリモートコンピュータの IP アドレス範囲からのアクセスのみを許可した場合、ネットワーク ACL は他の IP アドレスからのインバウンド SSH トラフィックを拒否します。
## ネットワーク ACL ルール
次は、サブネットに関連付けられたネットワーク ACL のインバウンドルールの例を示します。これらのルールはサブネット内のすべてのインスタンスに適用されます。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 | コメント |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | SSH | TCP | 22 | 172.31.1.2/32 | 許可 | リモートコンピュータからインバウンドトラフィックを許可します。 |
| \$1 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | DENY | 他のすべてのインバウンドトラフィックを拒否します。 |
以下は、サブネットに関連付けられたネットワーク ACL の送信ルールの例です。ネットワーク ACL はステートレスです。したがって、インバウンドトラフィックへの応答を許可するルールを含める必要があります。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信先 | 許可/拒否 | コメント |
| --- | --- | --- | --- | --- | --- | --- |
| 100 | カスタム TCP | TCP | 1024-65535 | 172.31.1.2/32 | 許可 | リモートコンピュータに対するアウトバウンド応答を許可します。 |
| \$1 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 | 他のすべてのアウトバウンドトラフィックを拒否します。 |
## 「セキュリティグループのルール」
以下は、インスタンスに関連付けられたセキュリティ グループのインバウンドルールの例です。これらのルールは、セキュリティグループに関連付けられているすべてのインスタンスに適用されます。インスタンスに関連付けられたキーペアのプライベートキーを持つユーザーは、SSH を使用してリモートコンピュータからインスタンスに接続できます。
| プロトコルのタイプ | プロトコル | ポート範囲 | 送信元 | コメント |
| --- | --- | --- | --- | --- |
| すべてのトラフィック | すべて | すべて | sg-1234567890abcdef0 | このセキュリティグループに関連付けられたインスタンス間の通信を許可します。 |
| SSH | TCP | 22 | 172.31.1.2/32 | リモートコンピュータからのインバウンド SSH アクセスを許可します。 |
以下は、インスタンスに関連付けられたセキュリティグループのアウトバウンドバウンドルールの例です。セキュリティグループはステートフルです。したがって、インバウンドトラフィックへの応答を許可するルールは必要ありません。
| プロトコルタイプ | プロトコル | ポート範囲 | 送信先 | コメント |
| --- | --- | --- | --- | --- |
| すべてのトラフィック | すべて | すべて | sg-1234567890abcdef0 | このセキュリティグループに関連付けられたインスタンス間の通信を許可します。 |
## ネットワーク ACL とセキュリティグループの違い
次の表は、ネットワーク ACL とセキュリティグループの基本的な違いをまとめたものです。
| 特性 | ネットワーク ACL | セキュリティグループ |
| --- | --- | --- |
| オペレーションのレベル | サブネットレベル | インスタンスレベル |
| スコープ | 関連付けられたサブネット内のすべてのインスタンスに適用されます | セキュリティグループに関連付けられているすべてのインスタンスに適用されます |
| ルールタイプ | 許可ルールと拒否ルール | ルールのみを許可します |
| ルールの評価 | トラフィックの一致が見つかるまで昇順でルールを評価します | トラフィックを許可するかどうかを決める前に、すべてのルールを評価します |
| 返されるトラフィック | 明示的に許可する必要があります (ステートレス) | 自動許可 (ステートフル) |
# Amazon Virtual Private Cloud での耐障害性
AWS グローバルインフラストラクチャは AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。AWS リージョン には、低レイテンシー、高スループットで、高度な冗長ネットワークを使用して接続され、物理的に独立および隔離された複数のアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェールオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、フォールトトレランス、および拡張性が優れています。
AWS リージョン は主要な構成要素であり、それぞれが、物理的に分離され隔離された複数のアベイラビリティーゾーンを格納する、個別の地理的位置を表しています。これらのアベイラビリティーゾーンは、低レイテンシーで高スループットかつ高度に冗長なネットワークファブリックを介して接続されており、相互のシームレスな通信とデータ転送が可能です。
アベイラビリティーゾーンのアーキテクチャは、従来の単一または複数のデータセンター構成よりもはるかに堅牢にかつ耐障害性が高くなるように設計されており、重要な差別化要因となっています。リージョン内の複数のアベイラビリティーゾーンにリソースを分散することにより、アプリケーションとデータベースを、サービスを中断することなくゾーン間で自動的にフェイルオーバーするように設計することができます。このレベルの冗長性と高可用性は、ミッションクリティカルなワークロードにとって不可欠な要件であり、組織は回復力のあるクラウドネイティブソリューションを構築することが可能になります。
さらに、AWS のインフラストラクチャのスケールと世界的な展開力により、ユーザーは、エンドユーザーに近い場所にアプリケーションをデプロイし、レイテンシーを削減してユーザーエクスペリエンス全般を高めることができます。また、世界中の複数のリージョンを利用できるため、特定の規制やビジネスニーズによって要請される地理的な境界内でデータを保存し処理することにより、データ主権とコンプライアンスを効果的に実現できます。
AWS のグローバルなインフラストラクチャを活用することで、組織は、要件の変化やビジネスニーズの進化に柔軟に対応できる、可用性、耐障害性、スケーラビリティに優れたクラウド環境を構築できます。こうした堅牢な基盤は、最新のクラウドベースのアプリケーションやサービスを最適に実装するために欠かせない要素です。
AWS リージョン とアベイラビリティーゾーン (AZ) の詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
ワークロードのレジリエンス要件を満たすように VPC を設定できます。詳細については次を参照してください:
+ [レジリエンシーのパターンとトレードオフを理解する](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) (AWS アーキテクチャブログ)
+ [ネットワークトポロジーの計画](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) (AWS Well-Architected フレームワーク)
+ [Amazon Virtual Private Cloud の接続オプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) (AWS ホワイトペーパー)
# Amazon Virtual Private Cloud のコンプライアンス検証
ある AWS のサービス が特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「[コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照して、関心のあるコンプライアンスプログラムを選択してください。一般的な情報については、[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) を参照してください。
AWS Artifact を使用して、サードパーティの監査レポートをダウンロードできます。詳細については、「[AWS Artifact でレポートをダウンロードする](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」「」を参照してください。
AWS のサービスを使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目的、適用可能な法律および規制によって決定されます。AWS のサービス を使用する際のコンプライアンス責任の詳細については、「[AWS セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# VPC とサブネットへのパブリックアクセスをブロックする
VPC ブロックパブリックアクセス (BPA) は、AWS アカウント全体で VPC リソースに対するパブリックインターネットアクセスを厳然と防止できるようにする一元的なセキュリティ機能です。これにより、特定の例外や監査機能については柔軟に対応しながら、セキュリティ要件を確実に遵守できます。
VPC BPA 機能には次のモードがあります:
+ **[双方向]**: このリージョンのインターネットゲートウェイとエグレスのみのインターネットゲートウェイとの間のすべてのトラフィック (除外された VPC とサブネットを除く) がブロックされます。
+ **[イングレスのみ]**: このリージョンの VPC に対するすべてのインターネットトラフィック (除外される VPC またはサブネットを除く) がブロックされます。NAT ゲートウェイとエグレスのみのインターネットゲートウェイとの間のトラフィックのみが許可されます。なぜなら、これらのゲートウェイはアウトバウンド接続の確立のみを許可するからです。
また、ブロックしないトラフィックのために、この機能で「除外」を作成することもできます。除外は、単一の VPC またはサブネットに適用できるモードであり、アカウントの VPC BPA モードから除外し、双方向または Egress-Only のアクセスを許可します。
除外では、次のいずれかのモードを使用できます:
+ **[双方向]**: 除外された VPC とサブネットとの間のすべてのインターネットトラフィックが許可されます。
+ **[エグレスのみ]**: 除外された VPCとサブネットからのアウトバウンドインターネットトラフィックが許可されます。除外された VPC とサブネットに対するインバウンドインターネットトラフィックはブロックされます。これは、VPC BPA が [双方向] に設定されている場合にのみ適用されます。
**Topics**
+ [VPC BPA の基本](security-vpc-bpa-basics.md)
+ [VPC BPA の影響を評価し、VPC BPA をモニタリングする](security-vpc-bpa-assess-impact-main.md)
+ [高度な例](security-vpc-bpa-example.md)
# VPC BPA の基本
このセクションでは、VPC BPA をサポートするサービスや、VPC BPA の使用方法など、VPC BPA に関する重要な詳細について説明します。
**Topics**
+ [リージョナルな可用性](#security-vpc-bpa-reg-avail)
+ [AWS サービスへの影響とサポート](#security-vpc-bpa-service-support)
+ [VPC BPA の制限事項](#security-vpc-bpa-limits)
+ [IAM ポリシーを使用して VPC BPA に対するアクセスを制御する](#security-vpc-bpa-iam-example)
+ [アカウントのために VPC BPA 双方向モードを有効にする](#security-vpc-bpa-enable-bidir)
+ [VPC BPA モードをイングレスのみに変更する](#security-vpc-bpa-ingress-only)
+ [除外を作成および削除する](#security-vpc-bpa-exclusions)
+ [組織レベルで VPC BPA を有効にする](#security-vpc-bpa-exclusions-orgs)
## リージョナルな可用性
VPC BPA は、GovCloud および中国リージョンを含むすべての商用 [AWS リージョン](https://aws.amazon.com//about-aws/global-infrastructure/regions_az/)で利用できます。
また、このガイドでは、Network Access Analyzer および Reachability Analyzer と VPC BPA の併用についても説明します。Network Access Analyzer と Reachability Analyzer は、すべての商用リージョンで利用できるわけではありません。Network Access Analyzer と Reachability Analyzer を利用できるリージョンについては、「*Network Access Analyzer ガイド*」の「[Limitations](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)」と「*Reachability Analyzer ガイド*」の「[Considerations](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)」を参照してください。
## AWS サービスへの影響とサポート
次のリソースとサービスは VPC BPA をサポートし、これらのサービスとリソースに対するトラフィックは VPC BPA の影響を受けます。
+ **[インターネットゲートウェイ]**: すべてのインバウンドトラフィックとアウトバウンドトラフィックがブロックされます。
+ **[エグレスのみのインターネットゲートウェイ]**: すべてのアウトバウンドトラフィックがブロックされます。エグレスのみのインターネットゲートウェイは、インバウンドトラフィックを許可しません。
+ **Gateway Load Balancer (GWLB)**: GWLB エンドポイントを含むサブネットが除外されていても、インバウンドトラフィックとアウトバウンドトラフィックはすべてブロックされます。
+ **[NAT ゲートウェイ]**: すべてのインバウンドトラフィックとアウトバウンドトラフィックがブロックされます。NAT ゲートウェイには、インターネット接続のためのインターネットゲートウェイが必要です。
+ **[インターネット向け Network Load Balancer]**: すべてのインバウンドトラフィックとアウトバウンドトラフィックがブロックされます。インターネット向け Network Load Balancer には、インターネット接続のためのインターネットゲートウェイが必要です。
+ **[インターネット向け Application Load Balancer]**: すべてのインバウンドトラフィックとアウトバウンドトラフィックがブロックされます。インターネット向け Application Load Balancer には、インターネット接続のためのインターネットゲートウェイが必要です。
+ **Amazon CloudFront VPC オリジン**: すべてのインバウンドトラフィックとアウトバウンドトラフィックがブロックされます。
+ **Direct Connect**: パブリック仮想インターフェイス (パブリック IPv4 またはグローバルユニキャスト IPv6 アドレス) を使用するすべてのインバウンドトラフィックとアウトバウンドトラフィックはブロックされます。このトラフィックは、接続にインターネットゲートウェイ (または Egress-Only インターネットゲートウェイ) を使用します。
+ **AWS Global Accelerator**: ターゲットがインターネットからアクセス可能かどうかにかかわらず、VPC へのインバウンドトラフィックはブロックされます。
+ **AWS Network Firewall**: ファイアウォールエンドポイントを含むサブネットが除外されていても、インバウンドトラフィックとアウトバウンドトラフィックはすべてブロックされます。
+ **AWS Wavelength キャリア ゲートウェイ**: すべてのインバウンドトラフィックとアウトバウンドトラフィックがブロックされます。
次のサービスやリソースについてのトラフィックなど、プライベート接続に関連するトラフィックは、VPC BPA によってブロックされず、影響も受けません。
+ AWS Client VPN
+ AWS CloudWAN
+ AWS Outposts ローカルゲートウェイ
+ AWS Site-to-Site VPN
+ トランジットゲートウェイ
+ AWS Verified Access
**重要**
サブネット内の EC2 インスタンスで実行されているアプライアンス (サードパーティーのセキュリティやモニタリングツールなど) を通じて送受信トラフィックをルーティングする場合、VPC BPA を使用すると、トラフィックが送受信されるようにそのサブネットを除外する必要があります。インターネットゲートウェイではなくアプライアンスサブネットにトラフィックを送信する他のサブネットは、追加で除外に設定する必要はありません。
VPC 内のリソースから Route 53 Resolver など、VPC で実行されている他のサービスにプライベートに送信されるトラフィックは、VPC 内のインターネットゲートウェイを通過しないため、VPC BPA がオンになっている場合でも許可されます。これらのサービスは、DNS クエリを解決するためなど、ユーザーに代わって VPC 外のリソースに対してリクエストを実行し、VPC 内のリソースのアクティビティに関する情報を公開する可能性があります (他のセキュリティコントロールを通じて緩和されない場合)。
## VPC BPA の制限事項
VPC BPA のイングレスのみのモードは、NAT ゲートウェイとエグレスのみのインターネットゲートウェイが許可されていないローカルゾーン (LZ) ではサポートされていません。
## IAM ポリシーを使用して VPC BPA に対するアクセスを制御する
VPC BPA 機能に対するアクセスを許可/拒否する IAM ポリシーの例については、「[VPC とサブネットへのパブリックアクセスをブロックする](vpc-policy-examples.md#vpc-bpa-example-iam)」を参照してください。
## アカウントのために VPC BPA 双方向モードを有効にする
VPC BPA 双方向モードは、このリージョンのインターネットゲートウェイとエグレスのみのインターネットゲートウェイとの間のすべてのトラフィックをブロックします (除外された VPC とサブネットを除く)。除外の詳細については、「[除外を作成および削除する](#security-vpc-bpa-exclusions)」を参照してください。
**重要**
本番アカウントで VPC BPA を有効にする前に、インターネットアクセスを必要とするワークロードを徹底的に確認することを強くお勧めします。
**注記**
アカウントの VPC とサブネットで VPC BPA を有効にするには、その VPC とサブネットを所有している必要があります。
現在 VPC サブネットを他のアカウントと共有している場合、サブネット所有者によって強制適用される VPC BPA モードも参加者のトラフィックに適用されますが、参加者は共有サブネットに影響を及ぼす VPC BPA の設定を制御することはできません。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[パブリックアクセスの設定を編集]** を選択します。
1. **[ブロックパブリックアクセスをオンにする]** と **[双方向]** を選択し、**[変更を保存]** を選択します。
1. **[ステータス]** が **[オン]** に変わるまで待ちます。VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
VPC BPA の [双方向] モードがオンになりました。
------
#### [ AWS CLI ]
1. VPC BPA をオンにします。
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
```
VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
1. VPC BPA のステータスを表示します。
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
## VPC BPA モードをイングレスのみに変更する
VPC BPA のイングレスのみのモードは、このリージョンの VPC に対するすべてのインターネットトラフィックをブロックします (除外される VPC またはサブネットを除く)。NAT ゲートウェイとエグレスのみのインターネットゲートウェイとの間のトラフィックのみが許可されます。なぜなら、これらのゲートウェイはアウトバウンド接続の確立のみを許可するからです。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[パブリックアクセスの設定を編集]** を選択します。
1. 方向を **Ingress-only** に変更します。
1. 変更を保存し、ステータスが更新されるまで待ちます。VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
------
#### [ AWS CLI ]
1. VPC BPA ブロックの方向を変更します:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-ingress
```
VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
1. VPC BPA のステータスを表示します。
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
## 除外を作成および削除する
VPC BPA の除外は、単一の VPC またはサブネットに適用できるモードであり、アカウントの VPC BPA モードから除外し、双方向または Egress-Only のアクセスを許可します。アカウントで VPC BPA が有効になっていない場合でも VPC とサブネットのために VPC BPA の除外を作成して、VPC BPA がオンになっているときに除外に対するトラフィックの中断が発生しないようにできます。VPC の除外は、VPC 内のすべてのサブネットに自動的に適用されます。
最大 50 個の除外を作成できます。制限の引き上げをリクエストする方法については、「[Amazon VPC クォータ](amazon-vpc-limits.md)」の「*VPC BPA exclusions per account*」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[パブリックアクセスをブロックする]** タブの **[除外]** で、次のいずれかを実行します。
+ 除外を削除するには、削除する除外項目を選択し、**[アクション]** > **[除外の削除]** を選択します。
+ 除外を作成するには、**[除外を作成]** を選択し、次のステップに進みます。
1. ブロック方向を選択します。
+ **[双方向]**: 除外された VPC とサブネットとの間のすべてのインターネットトラフィックを許可します。
+ **[エグレスのみ]**: 除外された VPCとサブネットからのアウトバウンドインターネットトラフィックを許可します。除外された VPC とサブネットに対するインバウンドインターネットトラフィックをブロックします。この設定は、VPC BPA が **[双方向]** に設定されている場合に適用されます。
1. [VPC] または [サブネット] を選択します。
1. **[除外を作成]** を選択します。
1. **[除外ステータス]** が **[アクティブ]** に変わるまで待ちます。変更を確認するには、除外テーブルを更新する必要がある場合があります。
除外が作成されました。
------
#### [ AWS CLI ]
1. 除外の許可の方向を変更します:
```
aws ec2 --region us-east-2 create-vpc-block-public-access-exclusion --subnet-id subnet-id --internet-gateway-exclusion-mode allow-bidirectional
```
1. 除外ステータスが更新されるまでに時間がかかる場合があります。除外のステータスを表示するには:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-exclusions --exclusion-ids exclusion-id
```
------
## 組織レベルで VPC BPA を有効にする
AWS Organizations を使用して組織内のアカウントを管理している場合は、[AWSOrganizations 宣言型ポリシー](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_declarative.html)を使用して、組織内のアカウントに VPC BPA を適用できます。VPC BPA 宣言型ポリシーの詳細については、「*AWS Organizations ユーザーガイド*」の「[サポートされている宣言型ポリシー](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-vpc-block-public-access)」を参照してください。
**注記**
VPC BPA 宣言型ポリシーを使用して、除外を許可するかどうかを設定できますが、ポリシーを使用して除外を作成することはできません。除外を作成するには、VPC を所有するアカウントで除外を作成する必要があります。VPC BPA の除外の作成方法の詳細については、「[除外を作成および削除する](#security-vpc-bpa-exclusions)」を参照してください。
VPC BPA 宣言型ポリシーが有効になっている場合、**[パブリックアクセスをブロックする]** では、**[宣言型ポリシーによる管理]** と表示され、アカウントレベルで VPC BPA 設定を変更することはできません。
# VPC BPA の影響を評価し、VPC BPA をモニタリングする
このセクションには、VPC BPA をオンにする前に VPC BPA の影響を評価する方法に関する情報と、VPC BPA をオンにした後にトラフィックがブロックされるかどうかをモニタリングする方法に関する情報が含まれています。
**Topics**
+ [Network Access Analyzer を使用して VPC BPA の影響を評価する](#security-vpc-bpa-assess-impact)
+ [フローログを使用して VPC BPA の影響をモニタリングする](#security-vpc-bpa-fl)
+ [CloudTrail を使用して除外の削除を追跡する](#security-vpc-bpa-cloudtrail)
+ [Reachability Analyzer を使用して接続がブロックされていることを検証する](#security-vpc-bpa-verify-RA)
## Network Access Analyzer を使用して VPC BPA の影響を評価する
このセクションでは、VPC BPA を有効にしてアクセスをブロックする*前*に、Network Access Analyzer を使用して、インターネットゲートウェイを使用するアカウントのリソースを表示します。この分析を使用して、アカウントで VPC BPA をオンにし、トラフィックをブロックした場合の影響を理解します。
**注記**
Network Access Analyzer は IPv6 をサポートしていないため、Egress-Only インターネットゲートウェイのアウトバウンド IPv6 トラフィックに対する VPC BPA の潜在的な影響を表示するために使用することはできません。
Network Access Analyzer で実行する分析には料金がかかります。詳細については、「*Network Access Analyzer ガイド*」の「[料金](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html#pricing)」を参照してください。
Network Access Analyzer が利用できるリージョンについては、「*Network Access Analyzer ガイド*」の「[Limitations](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/networkinsights/](https://console.aws.amazon.com/networkinsights/) で AWS Network Insights コンソールを開きます。
1. **[Network Access Analyzer]** を選択します。
1. **[ネットワークアクセススコープを作成]** を選択します。
1. **[Assess impact of VPC Block Public Access]** を選択し、**[次へ]**を選択します。
1. テンプレートは、アカウントのインターネットゲートウェイとの間のトラフィックを分析するように既に設定されています。これは、**[ソース]** と **[宛先]** で確認できます。
1. [**次へ**] を選択します。
1. **[ネットワークアクセススコープを作成]** を選択します。
1. 先ほど作成したスコープを選択し、**[分析]** を選択します。
1. 分析が完了するまで待ちます。
1. 分析の検出結果を表示します。**[検出結果]** の各行には、アカウントのインターネットゲートウェイとの間のネットワーク内でパケットが沿うことができるネットワークパスが表示されます。この場合、VPC BPA をオンにし、これらの検出結果に表示される VPC やサブネットのいずれも VPC BPA の除外として設定されていない場合、それらの VPC やサブネットに対するトラフィックは制限されます。
1. 各検出結果を分析して、VPC 内のリソースに対する VPC BPA の影響を理解します。
影響分析が完了しました。
------
#### [ AWS CLI ]
1. ネットワークアクセススコープを作成します:
```
aws ec2 create-network-insights-access-scope --region us-east-2 --match-paths "Source={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}" "Destination={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}"
```
1. スコープ分析を開始します:
```
aws ec2 start-network-insights-access-scope-analysis --region us-east-2 --network-insights-access-scope-id nis-id
```
1. 分析の結果を取得します:
```
aws ec2 get-network-insights-access-scope-analysis-findings --region us-east-2 --network-insights-access-scope-analysis-id nisa-0aa383a1938f94cd1 --max-items 1
```
その結果、アカウント内のすべての VPC のインターネットゲートウェイとの間のトラフィックが表示されます。結果は「検出結果」として整理されます。"FindingId": "AnalysisFinding-1" は、これが分析の最初の結果であることを示します。複数の検出結果があり、それぞれが VPC BPA をオンにすることで影響を受けるトラフィックフローを示しています。最初の検出結果は、トラフィックがインターネットゲートウェイ ("SequenceNumber": 1) で開始され、NACL ("SequenceNumber": 2)、セキュリティグループ ("SequenceNumber": 3) の順に渡され、インスタンス ("SequenceNumber": 4) で終了したことを示しています。
1. 検出結果を分析して、VPC 内のリソースに対する VPC BPA の影響を理解します。
影響分析が完了しました。
------
## フローログを使用して VPC BPA の影響をモニタリングする
VPC フローログは、VPC の Elastic Network Interface との間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。この機能を使用して、インスタンスのネットワークインターフェイスに到達しないように VPC BPA によってブロックされたトラフィックをモニタリングできます。
[フローログの使用](working-with-flow-logs.md) のステップを使用して、VPC のフローログを作成します。
フローログを作成する際には、フィールド `reject-reason` を含むカスタム形式を使用してください。
フローログを表示する際に、VPC BPA が原因で ENI に対するトラフィックが拒否された場合、フローログエントリに `BPA` の `reject-reason` が表示されます。
VPC フローログについての標準の[制限](flow-logs-limitations.md)に加えて、VPC BPA に固有の次の制限に留意してください。
+ VPC BPA のフローログには、[スキップされたレコード](flow-logs-records-examples.md#flow-log-example-no-data)は含まれません。
+ VPC BPA のフローログには、フローログに `bytes` フィールドを含めた場合であっても、[`bytes`](flow-log-records.md#flow-logs-fields) は含まれません。
## CloudTrail を使用して除外の削除を追跡する
このセクションでは、AWS CloudTrail を使用して VPC BPA の除外の削除をモニタリングおよび追跡する方法について説明します。
------
#### [ AWS マネジメントコンソール ]
[https://console.aws.amazon.com/cloudtrailv2/](https://console.aws.amazon.com/cloudtrailv2/) の AWS CloudTrail コンソールの **[リソースタイプ]** > `AWS::EC2::VPCBlockPublicAccessExclusion` にアクセスして、**[CloudTrail イベント履歴]** で、削除された除外を確認できます。
------
#### [ AWS CLI ]
除外の削除に関連するイベントを表示するには、`lookup-events` コマンドを使用します:
```
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::VPCBlockPublicAccessExclusion
```
------
## Reachability Analyzer を使用して接続がブロックされていることを検証する
[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) を使用して、VPC BPA の設定を含むネットワーク設定を踏まえて、特定のネットワークパスに到達できるかどうかを評価できます。
Reachability Analyzer を利用できるリージョンについては、「*Reachability Analyzer ガイド*」の「[Considerations](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer](https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer) で AWS Network Insights コンソールを開きます。
1. **[パスを作成および分析]** をクリックします。
1. **[ソースタイプ]** で、**[インターネットゲートウェイ]** を選択し、**[ソースドロップダウン]** からトラフィックをブロックするインターネットゲートウェイを選択します。
1. **[宛先タイプ]** で、**[インスタンス]** を選択し、**[宛先]** ドロップダウンからトラフィックをブロックするインスタンスを選択します。
1. **[パスを作成および分析]** をクリックします。
1. 分析が完了するまで待ちます。数分かかる場合があります。
1. 完了すると、**[可達のステータス]** が **[到達不可能]** となり、**[パスの詳細]** に `VPC_BLOCK_PUBLIC_ACCESS_ENABLED ` がこの到達可能性に関する問題の原因であることが示されます。
------
#### [ AWS CLI ]
1. トラフィックをブロックするインターネットゲートウェイの ID (ソース) と、トラフィックをブロックするインスタンスの ID (宛先) を使用してネットワークパスを作成します。
```
aws ec2 --region us-east-2 create-network-insights-path --source igw-id --destination instance-id --protocol TCP
```
1. ネットワークパスで分析を開始します:
```
aws ec2 --region us-east-2 start-network-insights-analysis --network-insights-path-id nip-id
```
1. 分析の結果を取得します:
```
aws ec2 --region us-east-2 describe-network-insights-analyses --network-insights-analysis-ids nia-id
```
1. 到達可能性の欠如について、`VPC_BLOCK_PUBLIC_ACCESS_ENABLED` が `ExplanationCode` であることを確認します。
------
# 高度な例
このセクションでは、VPC ブロックパブリックアクセス機能がさまざまなシナリオでどのように機能するかを理解するのに役立つ高度な例を示します。各シナリオはその前のシナリオに依拠するため、ステップを順番に完了することが重要です。
**重要**
本番アカウントでは、この例を実行しないでください。本番アカウントで VPC BPA を有効にする前に、インターネットアクセスを必要とするワークロードを徹底的に確認することを強くお勧めします。
**注記**
VPC BPA の機能を完全に理解するには、アカウントに特定のリソースが必要です。このセクションでは、この機能の仕組みを完全に理解するために必要なリソースをプロビジョニングするために使用できる CloudFormation テンプレートを提供します。CloudFormation テンプレートを使用してプロビジョニングするリソースと、Network Access Analyzer と Reachability Analyzer を使用して実行する分析にはコストがかかります。このセクションのテンプレートを使用する場合は、この例を完了したら、クリーンアップのステップを完了してください。
**Topics**
+ [CloudFormation テンプレートをデプロイする (オプション)](#security-vpc-bpa-example-deploy-cfn)
+ [Network Access Analyzer を使用して VPC BPA の影響を表示する](#vpc-bpa-naa)
+ [シナリオ 1 - VPC BPA が有効になっていないインスタンスに接続する](#vpc-bpa-scenario-1-connect-scen1)
+ [シナリオ 2 - 双方向モードで VPC BPA を有効にする](#vpc-bpa-scenario-1-connect-scen2)
+ [シナリオ 3 - VPC BPA を Ingress-Only モードに変更する](#vpc-bpa-scenario-3)
+ [シナリオ 4 - 除外を作成する](#vpc-bpa-scenario-4)
+ [シナリオ 5 - 除外モードを変更する](#vpc-bpa-scenario-5)
+ [シナリオ 6 - VPC BPA モードを変更する](#vpc-bpa-scenario-6)
+ [クリーンアップ](#vpc-bpa-scenario-cleanup)
## CloudFormation テンプレートをデプロイする (オプション)
この機能の仕組みのデモには、VPC、サブネット、インスタンス、および他のリソースが必要です。このデモをより簡単に完了できるように、このデモのシナリオのために必要なリソースを迅速にスピンアップするために使用できる CloudFormation テンプレートを以下で提供しています。このステップはオプションであり、このセクションのシナリオの図のみを表示できます。
**注記**
NAT ゲートウェイやパブリック IPv4 アドレスのコストなど、CloudFormation テンプレートを使用してこのセクションで作成するリソースに関連するコストがかかります。余分なコストがかからないよう、クリーンアップのステップを完了して、この例のために作成されたすべてのリソースを削除してください。
この CloudFormation テンプレートは、VPC BPA に必要な基盤となるリソースを作成しますが、VPC BPA 機能自体は有効にしません。ここでデプロイされるリソースは、VPC BPA 機能を個別に有効にした後、VPC BPA 機能を理解しテストするのに役立ちます。
このテンプレートによって以下のリソースがアカウントに作成されます。
+ Egress-only インターネットゲートウェイ
+ インターネットゲートウェイ
+ NAT ゲートウェイ
+ 2 つのパブリックサブネット
+ 1 つのプライベートサブネット
+ パブリックおよびプライベート IPv4 アドレスを持つ 2 つの EC2 インスタンス
+ IPv6 アドレスとプライベート IPv4 アドレスを持つ 1 つの EC2 インスタンス
+ プライベート IPv4 アドレスのみを持つ 1 つの EC2 インスタンス
+ SSH および ICMP インバウンドトラフィックが許可され、すべてのアウトバウンドトラフィックが許可されているセキュリティグループ
+ VPC フローログ
+ サブネット B の 1 つの EC2 Instance Connect エンドポイント
以下のテンプレートをコピーし、.yaml ファイルに保存します。
```
AWSTemplateFormatVersion: '2010-09-09'
Description: Creates a VPC with public and private subnets, NAT gateway, and EC2 instances for VPC BPA.
Parameters:
InstanceAMI:
Description: ID of the Amazone Machine Image (AMI) to use with the instances launched by this template
Type: AWS::EC2::Image::Id
InstanceType:
Description: EC2 Instance type to use with the instances launched by this template
Type: String
Default: t2.micro
Resources:
# VPC
VPCBPA:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
EnableDnsSupport: true
InstanceTenancy: default
Tags:
- Key: Name
Value: VPC BPA
# VPC IPv6 CIDR
VPCBPAIpv6CidrBlock:
Type: AWS::EC2::VPCCidrBlock
Properties:
VpcId: !Ref VPCBPA
AmazonProvidedIpv6CidrBlock: true
# EC2 Key Pair
VPCBPAKeyPair:
Type: AWS::EC2::KeyPair
Properties:
KeyName: vpc-bpa-key
# Internet Gateway
VPCBPAInternetGateway:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: VPC BPA Internet Gateway
VPCBPAInternetGatewayAttachment:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref VPCBPA
InternetGatewayId: !Ref VPCBPAInternetGateway
# Egress-Only Internet Gateway
VPCBPAEgressOnlyInternetGateway:
Type: AWS::EC2::EgressOnlyInternetGateway
Properties:
VpcId: !Ref VPCBPA
# Subnets
VPCBPAPublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPCBPA
CidrBlock: 10.0.1.0/24
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: VPC BPA Public Subnet A
VPCBPAPublicSubnetB:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPCBPA
CidrBlock: 10.0.2.0/24
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: VPC BPA Public Subnet B
VPCBPAPrivateSubnetC:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPCBPA
CidrBlock: 10.0.3.0/24
MapPublicIpOnLaunch: false
Ipv6CidrBlock: !Select [0, !GetAtt VPCBPA.Ipv6CidrBlocks]
AssignIpv6AddressOnCreation: true
Tags:
- Key: Name
Value: VPC BPA Private Subnet C
# NAT Gateway
VPCBPANATGateway:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt VPCBPANATGatewayEIP.AllocationId
SubnetId: !Ref VPCBPAPublicSubnetB
Tags:
- Key: Name
Value: VPC BPA NAT Gateway
VPCBPANATGatewayEIP:
Type: AWS::EC2::EIP
Properties:
Domain: vpc
Tags:
- Key: Name
Value: VPC BPA NAT Gateway EIP
# Route Tables
VPCBPAPublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPCBPA
Tags:
- Key: Name
Value: VPC BPA Public Route Table
VPCBPAPublicRoute:
Type: AWS::EC2::Route
DependsOn: VPCBPAInternetGatewayAttachment
Properties:
RouteTableId: !Ref VPCBPAPublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref VPCBPAInternetGateway
VPCBPAPublicSubnetARouteTableAssoc:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref VPCBPAPublicSubnetA
RouteTableId: !Ref VPCBPAPublicRouteTable
VPCBPAPublicSubnetBRouteTableAssoc:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref VPCBPAPublicSubnetB
RouteTableId: !Ref VPCBPAPublicRouteTable
VPCBPAPrivateRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPCBPA
Tags:
- Key: Name
Value: VPC BPA Private Route Table
VPCBPAPrivateRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref VPCBPAPrivateRouteTable
DestinationCidrBlock: 0.0.0.0/0
NatGatewayId: !Ref VPCBPANATGateway
VPCBPAPrivateSubnetCRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref VPCBPAPrivateRouteTable
DestinationIpv6CidrBlock: ::/0
EgressOnlyInternetGatewayId: !Ref VPCBPAEgressOnlyInternetGateway
VPCBPAPrivateSubnetCRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref VPCBPAPrivateSubnetC
RouteTableId: !Ref VPCBPAPrivateRouteTable
# EC2 Instances Security Group
VPCBPAInstancesSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: VPC BPA Instances Security Group
GroupDescription: Allow SSH and ICMP access
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
CidrIp: 0.0.0.0/0
- IpProtocol: icmp
FromPort: -1
ToPort: -1
CidrIp: 0.0.0.0/0
VpcId: !Ref VPCBPA
Tags:
- Key: Name
Value: VPC BPA Instances Security Group
# EC2 Instances
VPCBPAInstanceA:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: t2.micro
KeyName: !Ref VPCBPAKeyPair
SubnetId: !Ref VPCBPAPublicSubnetA
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
Tags:
- Key: Name
Value: VPC BPA Instance A
VPCBPAInstanceB:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: !Ref InstanceType
KeyName: !Ref VPCBPAKeyPair
SubnetId: !Ref VPCBPAPublicSubnetB
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
Tags:
- Key: Name
Value: VPC BPA Instance B
VPCBPAInstanceC:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: !Ref InstanceType
KeyName: !Ref VPCBPAKeyPair
SubnetId: !Ref VPCBPAPrivateSubnetC
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
Tags:
- Key: Name
Value: VPC BPA Instance C
VPCBPAInstanceD:
Type: AWS::EC2::Instance
Properties:
ImageId: !Ref InstanceAMI
InstanceType: !Ref InstanceType
KeyName: !Ref VPCBPAKeyPair
NetworkInterfaces:
- DeviceIndex: '0'
GroupSet:
- !Ref VPCBPAInstancesSecurityGroup
SubnetId: !Ref VPCBPAPrivateSubnetC
Ipv6AddressCount: 1
Tags:
- Key: Name
Value: VPC BPA Instance D
# Flow Logs IAM Role
VPCBPAFlowLogRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: vpc-flow-logs.amazonaws.com
Action: 'sts:AssumeRole'
Tags:
- Key: Name
Value: VPC BPA Flow Logs Role
VPCBPAFlowLogPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: VPC-BPA-FlowLogsPolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- 'logs:CreateLogGroup'
- 'logs:CreateLogStream'
- 'logs:PutLogEvents'
- 'logs:DescribeLogGroups'
- 'logs:DescribeLogStreams'
Resource: '*'
Roles:
- !Ref VPCBPAFlowLogRole
# Flow Logs
VPCBPAFlowLog:
Type: AWS::EC2::FlowLog
Properties:
ResourceId: !Ref VPCBPA
ResourceType: VPC
TrafficType: ALL
LogDestinationType: cloud-watch-logs
LogGroupName: /aws/vpc-flow-logs/VPC-BPA
DeliverLogsPermissionArn: !GetAtt VPCBPAFlowLogRole.Arn
LogFormat: '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${vpc-id} ${subnet-id} ${instance-id} ${tcp-flags} ${type} ${pkt-srcaddr} ${pkt-dstaddr} ${region} ${az-id} ${sublocation-type} ${sublocation-id} ${pkt-src-aws-service} ${pkt-dst-aws-service} ${flow-direction} ${traffic-path} ${reject-reason}'
Tags:
- Key: Name
Value: VPC BPA Flow Logs
# EC2 Instance Connect Endpoint
VPCBPAEC2InstanceConnectEndpoint:
Type: AWS::EC2::InstanceConnectEndpoint
Properties:
SecurityGroupIds:
- !Ref VPCBPAInstancesSecurityGroup
SubnetId: !Ref VPCBPAPublicSubnetB
Outputs:
VPCBPAVPCId:
Description: A reference to the created VPC
Value: !Ref VPCBPA
Export:
Name: vpc-id
VPCBPAPublicSubnetAId:
Description: The ID of the public subnet A
Value: !Ref VPCBPAPublicSubnetA
VPCBPAPublicSubnetAName:
Description: The name of the public subnet A
Value: VPC BPA Public Subnet A
VPCBPAPublicSubnetBId:
Description: The ID of the public subnet B
Value: !Ref VPCBPAPublicSubnetB
VPCBPAPublicSubnetBName:
Description: The name of the public subnet B
Value: VPC BPA Public Subnet B
VPCBPAPrivateSubnetCId:
Description: The ID of the private subnet C
Value: !Ref VPCBPAPrivateSubnetC
VPCBPAPrivateSubnetCName:
Description: The name of the private subnet C
Value: VPC BPA Private Subnet C
VPCBPAInstanceAId:
Description: The ID of instance A
Value: !Ref VPCBPAInstanceA
VPCBPAInstanceBId:
Description: The ID of instance B
Value: !Ref VPCBPAInstanceB
VPCBPAInstanceCId:
Description: The ID of instance C
Value: !Ref VPCBPAInstanceC
VPCBPAInstanceDId:
Description: The ID of instance D
Value: !Ref VPCBPAInstanceD
```
------
#### [ AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/cloudformation/](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。
1. **[スタックを作成]** を選択し、.yaml テンプレートファイルをアップロードします。
1. テンプレートを起動するステップを実行します。[[イメージ ID]](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html) と [[インスタンスタイプ]](https://aws.amazon.com/ec2/instance-types/) (t2.micro など) を入力する必要があります。また、フローログの作成と CloudWatch へのログ記録の許可のために、CloudFormation が IAM ロールを作成することを許可する必要があります。
1. スタックを起動したら、**[イベント]** タブで進行状況を表示し、続行する前にスタックが完了していることを確認します。
------
#### [ AWS CLI ]
1. CloudFormation スタックを作成するには、次のコマンドを実行します:
```
aws cloudformation create-stack --stack-name VPC-BPA-stack --template-body file://sampletemplate.yaml --capabilities CAPABILITY_IAM --region us-east-2
```
出力:
```
{
"StackId": "arn:aws:cloudformation:us-east-2:470889052923:stack/VPC-BPA-stack/8a7a2cc0-8001-11ef-b196-06386a84b72f"
}
```
1. 進行状況を表示し、続行する前にスタックが完了しているようにします:
```
aws cloudformation describe-stack-events --stack-name VPC-BPA-stack --region us-east-2
```
------
## Network Access Analyzer を使用して VPC BPA の影響を表示する
このセクションでは、Network Access Analyzer を使用して、インターネットゲートウェイを使用するアカウントのリソースを表示します。この分析を使用して、アカウントで VPC BPA をオンにし、トラフィックをブロックした場合の影響を理解します。
Network Access Analyzer が利用できるリージョンについては、「*Network Access Analyzer ガイド*」の「[Limitations](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/networkinsights/](https://console.aws.amazon.com/networkinsights/) で AWS Network Insights コンソールを開きます。
1. **[Network Access Analyzer]** を選択します。
1. **[ネットワークアクセススコープを作成]** を選択します。
1. **[Assess impact of VPC Block Public Access]** を選択し、**[次へ]**を選択します。
1. テンプレートは、アカウントのインターネットゲートウェイとの間のトラフィックを分析するように既に設定されています。これは、**[ソース]** と **[宛先]** で確認できます。
1. [**次へ**] を選択します。
1. **[ネットワークアクセススコープを作成]** を選択します。
1. 先ほど作成したスコープを選択し、**[分析]** を選択します。
1. 分析が完了するまで待ちます。
1. 分析の検出結果を表示します。**[検出結果]** の各行には、アカウントのインターネットゲートウェイとの間のネットワーク内でパケットが沿うことができるネットワークパスが表示されます。この場合、VPC BPA をオンにし、これらの検出結果に表示される VPC やサブネットのいずれも VPC BPA の除外として設定されていない場合、それらの VPC やサブネットに対するトラフィックは制限されます。
1. 各検出結果を分析して、VPC 内のリソースに対する VPC BPA の影響を理解します。
影響分析が完了しました。
------
#### [ AWS CLI ]
1. ネットワークアクセススコープを作成します:
```
aws ec2 create-network-insights-access-scope --match-paths "Source={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}" "Destination={ResourceStatement={ResourceTypes=["AWS::EC2::InternetGateway"]}}" --region us-east-2
```
出力:
```
{
"NetworkInsightsAccessScope": {
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"NetworkInsightsAccessScopeArn": "arn:aws:ec2:us-east-2:470889052923:network-insights-access-scope/nis-04cad3c4b3a1d5e3e",
"CreatedDate": "2024-09-30T15:55:53.171000+00:00",
"UpdatedDate": "2024-09-30T15:55:53.171000+00:00"
},
"NetworkInsightsAccessScopeContent": {
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"MatchPaths": [
{
"Source": {
"ResourceStatement": {
"ResourceTypes": [
"AWS::EC2::InternetGateway"
]
}
}
},
{
"Destination": {
"ResourceStatement": {
"ResourceTypes": [
"AWS::EC2::InternetGateway"
]
}
}
}
]
}
}
```
1. スコープ分析を開始します:
```
aws ec2 start-network-insights-access-scope-analysis --network-insights-access-scope-id nis-04cad3c4b3a1d5e3e --region us-east-2
```
出力:
```
{
"NetworkInsightsAccessScopeAnalysis": {
"NetworkInsightsAccessScopeAnalysisId": "nisa-0aa383a1938f94cd1",
"NetworkInsightsAccessScopeAnalysisArn": "arn:aws:ec2:us-east-2:470889052923:network-insights-access-scope-analysis/nisa-0aa383a1938f94cd",
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"Status": "running",
"StartDate": "2024-09-30T15:56:59.109000+00:00",
"AnalyzedEniCount": 0
}
}
```
1. 分析の結果を取得します:
```
aws ec2 get-network-insights-access-scope-analysis-findings --network-insights-access-scope-analysis-id nisa-0aa383a1938f94cd1 --region us-east-2 --max-items 1
```
出力:
```
{
"AnalysisFindings": [
{
"NetworkInsightsAccessScopeAnalysisId": "nisa-0aa383a1938f94cd1",
"NetworkInsightsAccessScopeId": "nis-04cad3c4b3a1d5e3e",
"FindingId": "AnalysisFinding-1",
"FindingComponents": [
{
"SequenceNumber": 1,
"Component": {
"Id": "igw-04a5344b4e30486f1",
"Arn": "arn:aws:ec2:us-east-2:470889052923:internet-gateway/igw-04a5344b4e30486f1",
"Name": "VPC BPA Internet Gateway"
},
"OutboundHeader": {
"DestinationAddresses": [
"10.0.1.85/32"
]
},
"InboundHeader": {
"DestinationAddresses": [
"10.0.1.85/32"
],
"DestinationPortRanges": [
{
"From": 22,
"To": 22
}
],
"Protocol": "6",
"SourceAddresses": [
"0.0.0.0/5",
"100.0.0.0/10",
"96.0.0.0/6"
],
"SourcePortRanges": [
{
"From": 0,
"To": 65535
}
]
},
"Vpc": {
"Id": "vpc-0762547ec48b6888d",
"Arn": "arn:aws:ec2:us-east-2:470889052923:vpc/vpc-0762547ec48b6888d",
"Name": "VPC BPA"
}
},
{
"SequenceNumber": 2,
"AclRule": {
"Cidr": "0.0.0.0/0",
"Egress": false,
"Protocol": "all",
"RuleAction": "allow",
"RuleNumber": 100
},
"Component": {
"Id": "acl-06194fc3a4a03040b",
"Arn": "arn:aws:ec2:us-east-2:470889052923:network-acl/acl-06194fc3a4a03040b"
}
},
{
"SequenceNumber": 3,
"Component": {
"Id": "sg-093dde06415d03924",
"Arn": "arn:aws:ec2:us-east-2:470889052923:security-group/sg-093dde06415d03924",
"Name": "VPC BPA Instances Security Group"
},
"SecurityGroupRule": {
"Cidr": "0.0.0.0/0",
"Direction": "ingress",
"PortRange": {
"From": 22,
"To": 22
},
"Protocol": "tcp"
}
},
{
"SequenceNumber": 4,
"AttachedTo": {
"Id": "i-058db34f9a0997895",
"Arn": "arn:aws:ec2:us-east-2:470889052923:instance/i-058db34f9a0997895",
"Name": "VPC BPA Instance A"
},
"Component": {
"Id": "eni-0fa23f2766f03b286",
"Arn": "arn:aws:ec2:us-east-2:470889052923:network-interface/eni-0fa23f2766f03b286"
},
"InboundHeader": {
"DestinationAddresses": [
"10.0.1.85/32"
],
"DestinationPortRanges": [
{
"From": 22,
"To": 22
}
],
"Protocol": "6",
"SourceAddresses": [
"0.0.0.0/5",
"100.0.0.0/10",
"96.0.0.0/6"
],
"SourcePortRanges": [
{
"From": 0,
"To": 65535
}
]
},
"Subnet": {
"Id": "subnet-035d235a762eeed04",
"Arn": "arn:aws:ec2:us-east-2:470889052923:subnet/subnet-035d235a762eeed04",
"Name": "VPC BPA Public Subnet A"
},
"Vpc": {
"Id": "vpc-0762547ec48b6888d",
"Arn": "arn:aws:ec2:us-east-2:470889052923:vpc/vpc-0762547ec48b6888d",
"Name": "VPC BPA"
}
}
]
}
],
"AnalysisStatus": "succeeded",
"NetworkInsightsAccessScopeAnalysisId": "nisa-0aa383a1938f94cd1",
"NextToken": "eyJOZXh0VG9rZW4iOiBudWxsLCAiYm90b190cnVuY2F0ZV9hbW91bnQiOiAxfQ=="
}
```
その結果、アカウント内のすべての VPC のインターネットゲートウェイとの間のトラフィックが表示されます。結果は「検出結果」として整理されます。"FindingId": "AnalysisFinding-1" は、これが分析の最初の結果であることを示します。複数の検出結果があり、それぞれが VPC BPA をオンにすることで影響を受けるトラフィックフローを示しています。最初の検出結果は、トラフィックがインターネットゲートウェイ ("SequenceNumber": 1) で開始され、NACL ("SequenceNumber": 2)、セキュリティグループ ("SequenceNumber": 3) の順に渡され、インスタンス ("SequenceNumber": 4) で終了したことを示しています。
1. 検出結果を分析して、VPC 内のリソースに対する VPC BPA の影響を理解します。
影響分析が完了しました。
------
## シナリオ 1 - VPC BPA が有効になっていないインスタンスに接続する
このセクションでは、パブリックサブネット A と B の EC2 インスタンスにインターネットゲートウェイ経由でインターネットから到達可能であり、インバウンドトラフィックとアウトバウンドトラフィックの両方を許可します。プライベートサブネットのインスタンス C および D は、NAT ゲートウェイまたは Egress-Only インターネットゲートウェイを介してアウトバウンドトラフィックを開始できますが、インターネットから直接到達することはできません。この設定では、一部のリソースへのインターネットアクセスを提供しながら、他のリソースを保護します。この設定の目的は、ベースラインを設定し、VPC BPA を有効にする前にすべてのインスタンスに到達できるようにし、すべてのインスタンスに接続してパブリック IP アドレスに対して ping を実行することです。
VPC BPA がオンになっていない VPC の図
![\[VPC BPA が有効になっていない VPC を示す図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-bpa-1.png)
### 1.1 インスタンスに接続する
VPC BPA をオフにした状態でインスタンスに接続し、問題なく接続できるようにするには、このセクションを完了します。この例のために CloudFormation を使用して作成されたすべてのインスタンスには、「VVPC BPA Instance A」のような名前が付けられています。
------
#### [ AWS マネジメントコンソール ]
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. インスタンス A の詳細を開きます。
1. **[EC2 Instance Connect]** > **[EC2 Instance Connect エンドポイントを使用して接続]** オプションを使用して、インスタンス A に接続します。
1. **接続** を選択します。インスタンスに正常に接続したら、www.amazon.com に対して ping を実行して、アウトバウンドリクエストをインターネットに送信できることを検証します。
1. インスタンス A への接続に使用したのと同じ方法を使用してインスタンス B、C、D に接続します。各インスタンスから www.amazon.com に対し ping を実行してアウトバウンドリクエストをインターネットに送信できるかどうかを確認します。
------
#### [ AWS CLI ]
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 18.225.8.244
```
出力:
```
Pinging 18.225.8.244 with 32 bytes of data:
Reply from 18.225.8.244: bytes=32 time=51ms TTL=110
Reply from 18.225.8.244: bytes=32 time=61ms TTL=110
```
ping は成功し、トラフィックはブロックされていません。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 18:27:57 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING www-amazon-com.customer.fastly.net (18.65.233.187) 56(84) bytes of data.
64 bytes from 18.65.233.187 (18.65.233.187): icmp_seq=15 ttl=58 time=2.06 ms
64 bytes from 18.65.233.187 (18.65.233.187): icmp_seq=16 ttl=58 time=2.26 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス B に対して Ping を実行します:
```
ping 3.18.106.198
```
出力:
```
Pinging 3.18.106.198 with 32 bytes of data:
Reply from 3.18.106.198: bytes=32 time=83ms TTL=110
Reply from 3.18.106.198: bytes=32 time=54ms TTL=110
```
ping は成功し、トラフィックはブロックされていません。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available.
Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Fri Sep 27 18:12:27 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=249 time=1.55 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=249 time=1.67 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インスタンス C に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available.
Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Thu Sep 19 20:31:26 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=248 time=1.75 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=248 time=1.97 ms
64 bytes from server-3-160-24-26.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=3 ttl=248 time=1.08 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インスタンス D に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
出力:
```
The authenticity of host '10.0.3.59 can't be established.
ECDSA key fingerprint is SHA256:c4naBCqbC61/cExDyccEproNU+1HHSpMSzl2J6cOtIZA8g.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.3.59' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ _/
_/m/'
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:ee00:7:49a5:5fd4:b121 (2600:9000:25f3:ee00:7:49a5:5fd4:b121)) 56 data bytes
64 bytes from 2600:9000:25f3:ee00:7:49a5:5fd4:b121 (2600:9000:25f3:ee00:7:49a5:5fd4:b121): icmp_seq=1 ttl=58 time=1.19 ms
64 bytes from 2600:9000:25f3:ee00:7:49a5:5fd4:b121 (2600:9000:25f3:ee00:7:49a5:5fd4:b121): icmp_seq=2 ttl=58 time=1.38 ms
```
ping は成功し、トラフィックはブロックされていません。
------
## シナリオ 2 - 双方向モードで VPC BPA を有効にする
このセクションでは、VPC BPA をオンにし、アカウントのインターネットゲートウェイとの間のトラフィックをブロックします。
双方向モードがオンになっている VPC BPA を示す図
![\[VPC BPA の双方向が有効になっている VPC を示す図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-bpa-2.png)
### 2.1 VPC BPA 双方向モードを有効にする
VPC BPA を有効にするには、このセクションを完了します。VPC BPA 双方向モードは、このリージョンのインターネットゲートウェイとエグレスのみのインターネットゲートウェイとの間のすべてのトラフィックをブロックします (除外された VPC とサブネットを除く)。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[パブリックアクセスの設定を編集]** を選択します。
1. **[ブロックパブリックアクセスをオンにする]** と **[双方向]** を選択し、**[変更を保存]** を選択します。
1. **[ステータス]** が **[オン]** に変わるまで待ちます。VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
VPC BPA がオンになりました。
------
#### [ AWS CLI ]
1. modify-vpc-block-public-access-options コマンドを使用して、VPC BPA をオンにします。
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
```
VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
1. VPC BPA のステータスを表示します。
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
### 2.2 インスタンスに接続する
インスタンスに接続するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. シナリオ 1 で実行したように、インスタンス A とインスタンス B のパブリック IPv4 アドレスに対して Ping を実行します。トラフィックがブロックされます。
1. シナリオ 1 で行ったように、**[EC2 Instance Connect]** > **[EC2 Instance Connect Endpoint]** オプションを使用して、インスタンス A に接続します。エンドポイントオプションを使用していることを確認してください。
1. **接続** を選択します。インスタンスに正常に接続したら、www.amazon.com に ping を実行します。すべてのアウトバウンドトラフィックがブロックされます。
1. インスタンス A への接続に使用したのと同じ方法を使用してインスタンス B、C、D に接続し、インターネットにアウトバウンドリクエストを送信できるかテストします。すべてのアウトバウンドトラフィックがブロックされます。
------
#### [ AWS CLI ]
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 18.225.8.244
```
出力:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
The authenticity of host '10.0.1.85' can't be established.
ECDSA key fingerprint is SHA256:3zo/gSss+HAZ+7eTyWlOB/Ke04IM+hadjsoLJeRTWBk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.1.85' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 14:16:53 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス B に対して Ping を実行します:
```
ping 3.18.106.198
```
出力:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
出力:
```
The authenticity of host '10.0.2.98' can't be established.
ECDSA key fingerprint is SHA256:0IjXKKyVlDthcCfI0IPIJMUiItAOLYKRNLGTYURnFXo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.2.98' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Fri Sep 27 14:18:16 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス C に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
/ /
/m/'
Last login: Tue Sep 24 15:17:56 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス D に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ _/
_/m/'
Last login: Fri Sep 27 16:42:01 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:8200:7:49a5:5fd4:b121 (2600:9000:25f3:8200:7:49a5:5fd4:b121)) 56 data bytes
```
ping が失敗し、トラフィックがブロックされます。
------
### 2.3 オプション: Reachability Analyzer を使用して接続がブロックされていることを確認する
[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) を使用して、VPC BPA の設定を含むネットワーク設定を踏まえて、特定のネットワークパスに到達できるかどうかを把握できます。この例では、以前に試行したのと同じネットワークパスを分析し、VPC BPA が接続に失敗する理由であることを確認します。
------
#### [ AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer](https://console.aws.amazon.com/networkinsights/home#ReachabilityAnalyzer) の Network Insights コンソールに移動します。
1. **[パスを作成および分析]** をクリックします。
1. **[ソースタイプ]** で、**[インターネットゲートウェイ]** を選択し、**[ソース]** ドロップダウンから **[VPC BPA インターネットゲートウェイ]** のタグが付けられたインターネットゲートウェイを選択します。
1. **[送信先タイプ]** で、**[インスタンス]** を選択し、**[送信先]** ドロップダウンから **[VPC BPA インスタンス A]** のタグが付けられたインスタンスを選択します。
1. **[パスを作成および分析]** をクリックします。
1. 分析が完了するまで待ちます。数分かかる場合があります。
1. 完了すると、**[可達のステータス]** が **[到達不可能]** となり、**[パスの詳細]** に `VPC_BLOCK_PUBLIC_ACCESS_ENABLED` が原因であることが示されます。
------
#### [ AWS CLI ]
1. [VPC BPA インターネットゲートウェイ] のタグが付けられたインターネットゲートウェイの ID と、[VPC BPA インスタンス A] のタグが付けられたインスタンスの ID を使用してネットワークパスを作成します。
```
aws ec2 --region us-east-2 create-network-insights-path --source igw-id --destination instance-id --protocol TCP
```
1. ネットワークパスで分析を開始します:
```
aws ec2 --region us-east-2 start-network-insights-analysis --network-insights-path-id nip-id
```
1. 分析の結果を取得します:
```
aws ec2 --region us-east-2 describe-network-insights-analyses --network-insights-analysis-ids nia-id
```
1. 到達可能性の欠如について、`VPC_BLOCK_PUBLIC_ACCESS_ENABLED` が `ExplanationCode` であることを確認します。
------
[フローログを使用して VPC BPA の影響をモニタリングする](security-vpc-bpa-assess-impact-main.md#security-vpc-bpa-fl)ことも可能です。
## シナリオ 3 - VPC BPA を Ingress-Only モードに変更する
このセクションでは、VPC BPA トラフィックの方向を変更し、NAT ゲートウェイまたはエグレスのみのインターネットゲートウェイを使用するトラフィックのみを許可します。BPA はインターネットゲートウェイ経由のインバウンドトラフィックをブロックするため、パブリックサブネットの EC2 インスタンス A と B はインターネットから到達できません。プライベートサブネットのインスタンス C と D は、NAT ゲートウェイと Egress-Only インターネットゲートウェイを介してアウトバウンドトラフィックを開始できるため、引き続きインターネットに到達できます。
VPC BPA のイングレスのみのモードがオンになっている図
![\[VPC BPA の Ingress-Only が有効になっている VPC を示す図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-bpa-3.png)
### 3.1 モードを「イングレスのみ」に変更する
モードを変更するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[パブリックアクセスをブロックする]** タブで、**[パブリックアクセス設定を編集する]** を選択します。
1. VPC コンソールでパブリックアクセスの設定を変更し、方向を **[イングレスのみ]** に変更します。
1. 変更を保存し、ステータスが更新されるまで待ちます。VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
------
#### [ AWS CLI ]
1. VPC BPA モードを変更します:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-ingress
```
VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
1. VPC BPA のステータスを表示します。
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
### 3.2 インスタンスに接続する
インスタンスに接続するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. シナリオ 1 で実行したように、インスタンス A とインスタンス B のパブリック IPv4 アドレスに対して Ping を実行します。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス A とインスタンス B に接続し、そこから www.amazon.com に対して ping を実行します。インスタンス A または B からインターネット上のパブリックサイトに対して ping を実行することはできず、トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス C とインスタンス D に接続し、そこから www.amazon.com に対して ping を実行します。インスタンス C または D からインターネット上のパブリックサイトに対して ping を実行でき、トラフィックが許可されます。
------
#### [ AWS CLI ]
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 18.225.8.244
```
出力:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
The authenticity of host '10.0.1.85' can't be established.
ECDSA key fingerprint is SHA256:3zo/gSss+HAZ+7eTyWlOB/Ke04IM+hadjsoLJeRTWBk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.1.85' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 14:16:53 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス B に対して Ping を実行します:
```
ping 3.18.106.198
```
出力:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
出力:
```
The authenticity of host '10.0.2.98 ' can't be established.
ECDSA key fingerprint is SHA256:0IjXKKyVlDthcCfI0IPIJMUiItAOLYKRNLGTYURnFXo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.2.98' (ECDSA) to the list of known hosts.
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ /
/m/'
Last login: Fri Sep 27 14:18:16 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス C に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Tue Sep 24 15:28:09 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=248 time=1.84 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=248 time=1.40 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インスタンス D に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 16:48:38 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:5800:7:49a5:5fd4:b121 (2600:9000:25f3:5800:7:49a5:5fd4:b121)) 56 data bytes
64 bytes from 2600:9000:25f3:5800:7:49a5:5fd4:b121 (2600:9000:25f3:5800:7:49a5:5fd4:b121): icmp_seq=14 ttl=58 time=1.47 ms
64 bytes from 2600:9000:25f3:5800:7:49a5:5fd4:b121 (2600:9000:25f3:5800:7:49a5:5fd4:b121): icmp_seq=16 ttl=58 time=1.59 ms
```
ping は成功し、トラフィックはブロックされていません。
------
## シナリオ 4 - 除外を作成する
このセクションでは、除外を作成します。その後、VPC BPA は除外*なし*でサブネット上のトラフィックのみをブロックします。VPC BPA の除外は、単一の VPC またはサブネットに適用できるモードであり、アカウントの VPC BPA モードから除外し、双方向または Egress-Only のアクセスを許可します。アカウントで VPC BPA が有効になっていない場合でも VPC とサブネットのために VPC BPA の除外を作成して、VPC BPA がオンになっているときに除外に対するトラフィックの中断が発生しないようにできます。
この例では、サブネット A の除外を作成して、除外に対するトラフィックが VPC BPA によってどのように影響を受けるかを示します。
VPC BPA のイングレスのみのモードがオンになっており、[双方向] モードがオンになっているサブネット A の除外の図:
![\[VPC BPA が Ingress-Only モードであり、除外が設定されている VPC を示す図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-bpa-4.png)
### 4.1 サブネット A の除外を作成する
除外を作成するには、このセクションを完了します。VPC BPA の除外は、単一の VPC またはサブネットに適用できるモードであり、アカウントの VPC BPA モードから除外し、双方向または Egress-Only のアクセスを許可します。アカウントで VPC BPA が有効になっていない場合でも VPC とサブネットのために VPC BPA の除外を作成して、VPC BPA がオンになっているときに除外に対するトラフィックの中断が発生しないようにできます。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[ブロックパブリックアクセス]** タブの **[除外]** で、**[除外を作成]** を選択します。
1. **[VPC BPA パブリックサブネット A]** を選択し、許可の方向として **[双方向]** が選択されているようにして、**[除外を作成]** を選択します。
1. **[除外ステータス]** が **[アクティブ]** に変わるまで待ちます。変更を確認するには、除外テーブルを更新する必要がある場合があります。
除外が作成されました。
------
#### [ AWS CLI ]
1. 除外の許可の方向を変更します:
```
aws ec2 --region us-east-2 create-vpc-block-public-access-exclusion --subnet-id subnet-id --internet-gateway-exclusion-mode allow-bidirectional
```
1. 除外ステータスが更新されるまでに時間がかかる場合があります。除外のステータスを表示するには:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-exclusions --exclusion-ids exclusion-id
```
------
### 4.2 インスタンスに接続する
インスタンスに接続するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. インスタンス A のパブリック IPv4 アドレスに対して Ping を実行します。トラフィックが許可されます。
1. インスタンス B のパブリック IPv4 アドレスに対して Ping を実行します。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス A に接続し、www.amazon.com に対して ping を実行します。インスタンス A からインターネット上のパブリックサイトに対して ping を実行できます。トラフィックは許可されます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス B に接続し、そこから www.amazon.com に対して ping を実行します。インスタンス B からインターネット上のパブリックサイトに対して ping を実行することはできません。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス C とインスタンス D に接続し、そこから www.amazon.com に対して ping を実行します。インスタンス C または D からインターネット上のパブリックサイトに対して ping を実行できます。トラフィックは許可されます。
------
#### [ AWS CLI ]
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 18.225.8.244
```
出力:
```
Pinging 18.225.8.244 with 32 bytes of data:
Reply from 18.225.8.244: bytes=32 time=51ms TTL=110
Reply from 18.225.8.244: bytes=32 time=61ms TTL=110
```
ping は成功し、トラフィックはブロックされていません。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~_ ####_ Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
/ /
/m/'
Last login: Fri Sep 27 17:58:12 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=249 time=1.03 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=249 time=1.72 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス B に対して Ping を実行します:
```
ping 3.18.106.198
```
出力:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-08552a0774b5c8f72 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ /
/m/'
Last login: Fri Sep 27 18:12:03 2024 from 3.16.146.5
[ec2-user@ip-10-0-2-98 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス C に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
Output
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, # ~_ #### Amazon Linux 2023
~~ _#####\ ~~ ###|
~~ #/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~.. _/
_/ /
/m/'
Last login: Tue Sep 24 15:28:09 2024 from 10.0.2.86
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=1 ttl=248 time=1.84 ms
64 bytes from server-3-160-24-126.cmh68.r.cloudfront.net (18.65.233.187): icmp_seq=2 ttl=248 time=1.40 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インスタンス D に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
Output
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:00:52 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(g2600-141f-4000-059a-0000-0000-0000-3bd4.deploy.static.akamaitechnologies.com (2600:141f:4000:59a::3bd4)) 56 data bytes
64 bytes from g2600-141f-4000-059a-0000-0000-0000-3bd4.deploy.static.akamaitechnologies.com (2600:141f:4000:59a::3bd4): icmp_seq=1 ttl=48 time=15.9 ms
64 bytes from g2600-141f-4000-059a-0000-0000-0000-3bd4.deploy.static.akamaitechnologies.com (2600:141f:4000:59a::3bd4): icmp_seq=2 ttl=48 time=15.8 ms
```
ping は成功し、トラフィックはブロックされていません。
------
### 4.3 オプション: Reachability Analyzer との接続を検証する
シナリオ 2 で Reachability Analyzer において作成したのと同じネットワークパスを使用して、新しい分析を実行し、パブリックサブネット A についての除外が作成されたことでパスが到達可能になったことを確認できるようになりました。
Reachability Analyzer を利用できるリージョンについては、「*Reachability Analyzer ガイド*」の「[Considerations](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)」を参照してください。
------
#### [ AWS マネジメントコンソール ]
1. Network Insights コンソールで前に作成したネットワークパスから、**[分析を再実行]** をクリックします。
1. 分析が完了するまで待ちます。これには数分間かかる場合があります。
1. パスが **[到達可能]** になっていることを確認します。
------
#### [ AWS CLI ]
1. 前に作成したネットワークパス ID を使用して、新しい分析を開始します:
```
aws ec2 --region us-east-2 start-network-insights-analysis --network-insights-path-id nip-id
```
1. 分析の結果を取得します:
```
aws ec2 --region us-east-2 describe-network-insights-analyses --network-insights-analysis-ids nia-id
```
1. `VPC_BLOCK_PUBLIC_ACCESS_ENABLED` 説明コードが存在しないことを確認します。
------
## シナリオ 5 - 除外モードを変更する
このセクションでは、除外における許可トラフィックの方向を変更して、VPC BPA がどのような影響を受けるのかを確認します。
**注記**
このシナリオでは、除外モードを Egress-Only に変更します。これを行うと、サブネット A の Egress-Only の除外ではアウトバウンドトラフィックが許可されないことに注意してください。Egress-Only という名前からすると、アウトバウンドトラフィックが許可されると予想されるため、直感に反します。ただし、アカウントレベルの BPA は Ingress-Only であるため、Egress-Only の除外は無視され、サブネット A のインターネットゲートウェイへのルーティングは VPC BPA によって制限され、アウトバウンドトラフィックがブロックされます。サブネット A でアウトバウンドトラフィックを有効にするには、VPC BPA を双方向モードに切り替える必要があります。
VPC BPA のイングレスのみのモードがオンになっており、エグレスのみのモードがオンになっているサブネット A の除外の図:
![\[VPC BPA が Ingress-Only モードであり、NAT ゲートウェイ経由のアウトバウンドトラフィックを許可する VPC を示す図。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-bpa-5.png)
### 5.1 除外の許可の方向をエグレスのみに変更する
除外の許可の方向を変更するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. シナリオ 4 で作成した除外を編集し、許可の方向を **[エグレスのみ]** に変更します。
1. **[Save changes]** (変更の保存) をクリックします。
1. **[除外]** ステータスが **[アクティブ]** に変わるまで待ちます。VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。変更を確認するには、除外テーブルを更新する必要がある場合があります。
------
#### [ AWS CLI ]
1. 除外の許可の方向を変更します:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-exclusion --exclusion-id exclusion-id --internet-gateway-exclusion-mode allow-egress
```
VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
1. 除外ステータスが更新されるまでに時間がかかる場合があります。除外のステータスを表示するには:
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-exclusion
```
------
### 5.2 インスタンスに接続する
インスタンスに接続するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. インスタンス A およびインスタンス B のパブリック IPv4 アドレスに対して Ping を実行します。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス A およびインスタンス B に接続し、www.amazon.com に対して ping を実行します。インスタンス A またはインスタンス B からインターネット上のパブリックサイトに対して ping を実行することはできません。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス C とインスタンス D に接続し、そこから www.amazon.com に対して ping を実行します。インスタンス C または D からインターネット上のパブリックサイトに対して ping を実行できます。トラフィックは許可されます。
------
#### [ AWS CLI ]
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 18.225.8.244
```
出力:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:09:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス B に対して Ping を実行します:
```
ping 3.18.106.198
```
出力:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:09:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス C に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:00:31 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:a600:7:49a5:5fd4:b121 (2600:9000:25f3:a600:7:49a5:5fd4:b121)) 56 data bytes
64 bytes from 2600:9000:25f3:a600:7:49a5:5fd4:b121 (2600:9000:25f3:a600:7:49a5:5fd4:b121): icmp_seq=1 ttl=58 time=1.51 ms
64 bytes from 2600:9000:25f3:a600:7:49a5:5fd4:b121 (2600:9000:25f3:a600:7:49a5:5fd4:b121): icmp_seq=2 ttl=58 time=1.49 ms
```
ping は成功し、トラフィックはブロックされていません。
1. インスタンス D に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:13:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2606:2cc0::374 (2606:2cc0::374)) 56 data bytes
64 bytes from 2606:2cc0::374 (2606:2cc0::374): icmp_seq=1 ttl=58 time=1.21 ms
64 bytes from 2606:2cc0::374 (2606:2cc0::374): icmp_seq=2 ttl=58 time=1.51 ms
```
ping は成功し、トラフィックはブロックされていません。
------
## シナリオ 6 - VPC BPA モードを変更する
このセクションでは、トラフィックにどのような影響が及ぶのかを確認するために、VPC BPA のブロックの方向を変更します。このシナリオでは、双方向モードで有効になっている VPC BPA は、シナリオ 1 と同様にすべてのトラフィックをブロックします。除外が NAT ゲートウェイまたはエグレスのみのインターネットゲートウェイにアクセスできる場合を除き、トラフィックはブロックされます。
VPC BPA の [双方向] モードがオンになっており、[エグレスのみ] のモードがオンになっているサブネット A の除外の図:
![\[VPC BPA が Ingress-Only モードであり、NAT ゲートウェイ経由のアウトバウンドトラフィックを許可する VPC を示す図\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/images/vpc-bpa-6.png)
### 6.1 VPC BPA を双方向モードに変更する
VPC BPA のモードを変更するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. 左のナビゲーションペインで、**[設定]** を選択します。
1. **[パブリックアクセスの設定を編集]** を選択します。
1. ブロックの方向を **[双方向]** に変更し、**[変更を保存]** を選択します。
1. **[ステータス]** が **[オン]** に変わるまで待ちます。VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
------
#### [ AWS CLI ]
1. VPC BPA ブロックの方向を変更します:
```
aws ec2 --region us-east-2 modify-vpc-block-public-access-options --internet-gateway-block-mode block-bidirectional
```
VPC BPA の設定が有効になり、ステータスが更新されるまでに数分かかる場合があります。
1. VPC BPA のステータスを表示します。
```
aws ec2 --region us-east-2 describe-vpc-block-public-access-options
```
------
### 6.2 インスタンスに接続する
インスタンスに接続するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. インスタンス A およびインスタンス B のパブリック IPv4 アドレスに対して Ping を実行します。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス A およびインスタンス B に接続し、www.amazon.com に対して ping を実行します。インスタンス A またはインスタンス B からインターネット上のパブリックサイトに対して ping を実行することはできません。トラフィックがブロックされます。
1. シナリオ 1 で実行したように、EC2 Instance Connect を使用してインスタンス C とインスタンス D に接続し、そこから www.amazon.com に対して ping を実行します。インスタンス C またはインスタンス D からインターネット上のパブリックサイトに対して ping を実行することはできません。トラフィックがブロックされます。
------
#### [ AWS CLI ]
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 18.225.8.244
```
出力:
```
Pinging 18.225.8.244 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:17:44 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インバウンドトラフィックをチェックするために、パブリック IPv4 アドレスを使用してインスタンス A に対して Ping を実行します:
```
ping 3.18.106.198
```
出力:
```
Pinging 3.18.106.198 with 32 bytes of data:
Request timed out.
```
ping が失敗し、トラフィックがブロックされます。
1. プライベート IPv4 アドレスを使用して、アウトバウンドトラフィックに接続してチェックします。
```
aws ec2-instance-connect ssh --instance-id i-058db34f9a0997895 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:09:55 2024 from 3.16.146.5
[ec2-user@ip-10-0-1-85 ~]$ ping www.amazon.com
PING d3ag4hukkh62yn.cloudfront.net (18.65.233.187) 56(84) bytes of data.
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス C に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-04eca55f2a482b2c4 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:19:45 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-180 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:6200:7:49a5:5fd4:b121 (2600:9000:25f3:6200:7:49a5:5fd4:b121)) 56 data bytes
```
ping が失敗し、トラフィックがブロックされます。
1. インスタンス D に接続します。ping を実行するためのパブリック IP アドレスがないので、EC2 Instance Connect を使用して接続してから、インスタンスからパブリック IP に対して ping を実行してアウトバウンドトラフィックをチェックします:
```
aws ec2-instance-connect ssh --instance-id i-05f9e6a9cfac1dba0 --region us-east-2 --connection-type eice
```
出力:
```
A newer release of "Amazon Linux" is available. Version 2023.5.20240916:
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_ ~\_ ####_ Amazon Linux 2023
~~ \_#####\ ~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Sep 27 18:20:58 2024 from 3.16.146.5
[ec2-user@ip-10-0-3-59 ~]$ ping www.amazon.com
PING www.amazon.com(2600:9000:25f3:b400:7:49a5:5fd4:b121 (2600:9000:25f3:b400:7:49a5:5fd4:b121)) 56 data bytes
```
ping が失敗し、トラフィックがブロックされます。
------
## クリーンアップ
このセクションでは、この高度な例のために作成したすべてのリソースを削除します。アカウントで作成されたリソースについて余分な追加料金が発生しないように、リソースをクリーンアップすることが重要です。
### CloudFormation リソースを削除する
CloudFormation テンプレートを使用して作成したリソースを削除するには、このセクションを完了します。
------
#### [ AWS マネジメントコンソール ]
1. [https://console.aws.amazon.com/cloudformation/](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。
1. VPC BPA スタックを選択します。
1. **[削除]** を選択します。
1. スタックの削除を開始したら、**[イベント]** タブで進行状況を表示し、スタックが削除されていることを確認します。スタックを完全に削除するには、[そのスタックを強制削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)する必要がある場合があります。
------
#### [ AWS CLI ]
1. CloudFormation スタックを削除します。スタックを完全に削除するには、[そのスタックを強制削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)する必要がある場合があります。
```
aws cloudformation delete-stack --stack-name VPC-BPA-stack --region us-east-2
```
1. 進行状況を表示し、スタックが削除されていることを確認します。
```
aws cloudformation describe-stack-events --stack-name VPC-BPA-stack --region us-east-2
```
------
### CloudTrail を使用して除外の削除を追跡する
AWS CloudTrail を使用して除外の削除を追跡するには、このセクションを完了します。CloudTrail エントリは、除外を削除すると表示されます。
------
#### [ AWS マネジメントコンソール ]
[https://console.aws.amazon.com/cloudtrailv2/](https://console.aws.amazon.com/cloudtrailv2/) で AWS CloudTrail コンソールにおいて **[リソースタイプ]** > **AWS::EC2::VPCBlockPublicAccessExclusion** を検索すると、CloudTrail Event の履歴で、削除された除外を表示できます。
------
#### [ AWS CLI ]
lookup-events コマンドを使用して、除外の削除に関連するイベントを表示できます:
```
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::VPCBlockPublicAccessExclusion
```
------
高度な例が完了しました。
# VPC のセキュリティのベストプラクティス
以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは指示ではなく、有用な考慮事項と見なしてください。
+ VPC にサブネットを追加してアプリケーションをホストするときは、複数のアベイラビリティーゾーンにサブネットを作成します。アベイラビリティーゾーンは、AWS リージョンに冗長電源、ネットワーク、および接続を備えた 1 つ以上の個別のデータセンターです。複数のアベイラビリティーゾーンを使用すると、本番環境アプリケーションの可用性、耐障害性、およびスケーラビリティが向上します。
+ セキュリティグループを使用して、サブネット内の EC2 インスタンスへのトラフィックを制御します。詳細については、「[セキュリティグループ](vpc-security-groups.md)」を参照してください。
+ ネットワーク ACL を使用して、サブネットレベルでインバウンドトラフィックとアウトバウンドトラフィックを制御します。詳細については、「[ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する](vpc-network-acls.md)」を参照してください。
+ AWS Identity and Access Management (IAM) ID フェデレーション、ユーザー、およびロールを使用して、VPC 内の AWS リソースへのアクセスを管理します。詳細については、「[Amazon VPC の Identity and Access Management](security-iam.md)」を参照してください。
+ VPC フローログを使用して、VPC、サブネット、またはネットワークインターフェイス間で送受信される IP トラフィックを監視します。詳細については、「[VPC フローログ](flow-logs.md)」を参照してください。
+ Network Access Analyzer を使用して、VPC 内のリソースへの意図しないネットワークアクセスを特定します。詳細については、「[Network Access Analyzer ガイド](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/)」を参照してください。
+ AWS Network Firewall を使用して、インバウンドトラフィックとアウトバウンドトラフィックをフィルタリングすることにより、VPC を監視および保護します。詳細については、「[AWS Network Firewall ガイド](https://docs.aws.amazon.com/network-firewall/latest/developerguide/)」を参照してください。
+ Amazon GuardDuty は、AWS 環境内のアカウント、コンテナ、ワークロード、データに対する潜在的な脅威を特定するために使用します。基本的な脅威検出には、Amazon EC2 インスタンスに関連付けられた VPC フローログのモニタリングが含まれます。詳細については、「*Amazon GuardDuty ユーザーガイド*」の「[VPC Flow Logs](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_data-sources.html#guardduty_vpc)」を参照してください。
VPC セキュリティに関するよくある質問への回答については、「[Amazon VPC のよくある質問](https://aws.amazon.com/vpc/faqs/)」の「*セキュリティとフィルタリング*」を参照してください。