Kanji
・クラウドエンジニア / フリーランス ・1993年生まれ ・愛媛県出身 / 東京都渋谷区在住 ・AWS歴5年 プロフィールの詳細
目次
VPC (Virtual Private Cloud) は、AWS 上に仮想的なネットワークを構築するサービスです。 VPC を使用することで、AWS リソースをプライベートなネットワーク内で安全に運用できます。 VPC は、サブネット、ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイなどのコンポーネントで構成されます。
AWS の仕様上、VPC 内に起動するリソース（プライベートIPアドレスを持つリソース）は、EC2 インスタンス、RDS インスタンス、ELB (Elastic Load Balancer) などがあります。
それに対し、VPC 内に起動できないリソースは、S3 バケットや DynamoDB テーブルなどのサーバーレスリソースがあります。 もちろん、VPC 内に起動できないリソースも、VPC からインターネットゲートウェイ、もしくは VPC エンドポイントを介してアクセスすることは可能です。
VPC 内/外 どちらも起動できるリソースは、Lambda 関数や Glue ジョブなどがあります。 この「VPC 内/外 どちらも起動できるリソース」は、セキュリティやアプリケーションの要件に応じて決定します。
以下の表は、AWS サービスとそのリソースタイプ、および VPC 対応の有無を示しています。
<表の解説>
前提知識として AWS のセキュリティ設定を評価する Security Hub の Lambda コントロールの一つに[Lambda.3] Lambda 関数は VPC 内に存在する必要があります。というものがあります。 このコントロールは、Lambda 関数が VPC 内で実行されることを推奨しています。 このコントロールの説明にある通り VPC 内で Lambda 関数を実行することで、以下の引用のようなセキュリティとコントロールの強化が期待できます。
VPC にリソースをデプロイすると、ネットワーク設定のセキュリティとコントロールが強化されます。 このようなデプロイでは、複数のアベイラビリティーゾーンにわたってスケーラビリティと高い耐障害性も提供されます。 VPC デプロイをカスタマイズして、さまざまなアプリケーション要件を満たすことができます。 引用元: Lambda の Security Hub ブコントロール - AWS Security Hub
では、VPC 内で Lambda 関数などのサーバレスリソースを実行することでどのようなセキュリティとコントロールの強化が期待できるのでしょうか？以下にいくつかのポイントを挙げます。
これらのセキュリティとコントロールの強化により、Lambda 関数が内部不正や外部攻撃によって不正利用された場合でも、被害を最小限に抑えることができます。 とは言え、EC2 インスタンスと比較すると サーバレスリソースはファイルを持ち込んだり、人がログインして操作する手段が少ないため、セキュリティリスクは低いと考えられます。 参考として、サーバレスリソースを VPC 内で起動するか判断するフローを以下に示します。
VPC のサブネットの構成は、ルーティングの要件やセキュリティの要件に応じて決定します。 一般的な構成として、以下のようなサブネットの種類があります。
これらのサブネットの種類から社内ルールやシステムの要件に応じて、必要なサブネットの種類を選択します。 上の表のうち、確認する要件が「社内ルール」となっているサブネットは、社内のセキュリティポリシーや運用ルールに基づいて決定します。
VPC の CIDR ブロックは、VPC 内で使用する IP アドレスの範囲を定義します。 オンプレミス環境や外部システムとの接続を考慮し、CIDR ブロックの選定は慎重に行う必要があります。 オンプレミス環境を今まで利用していた場合はエクセルなどの管理台帳で IP アドレス範囲を管理することが多いかと存じます。 AWS では必要に応じて IPAM (IP Address Manager) を利用して IP アドレスの管理を行うことができます。
なお、今後メンバーアカウントの VPC を拡張、追加する場合はなるべく大きめの CIDR ブロックを確保する必要があります。 IP アドレス帯 が不足している場合は、ネットワーク同士の接続（VPC↔︎VPC、VPC↔︎オンプレミス など）の接続を行わない設計を検討するのも一つの方法です。
VPC 内の AWS リソースからの名前解決は以下の通信元/通信先に大分類されます。これらの通信元/通信先に対して、それぞれどのように名前解決を行うかを検討します。
① VPC 内のリソース ② オンプレミス環境のリソース ③ インターネット上のリソース
まず、前提知識として以下の 2 つの事項について解説いたします。
VPC 内のリソースはパブリック DNS 名を持つことができ、オンプレミス環境のリソースやインターネット上のリソースからもインターネットにさえ接続できれば名前解決が可能です。 Route 53 のプライベートホストゾーンを利用して、VPC 内のリソースに対してカスタム DNS 名を設定する場合はインターネット経由では名前解決ができません。 パブリック DNS を有効化するには、VPC の設定で「DNS ホスト名の有効化」と「DNS サポートの有効化」を行う必要があります。
VPC 外の DNS サーバーと連携するには、Route 53 のリゾルバーエンドポイントを利用します。 リゾルバーエンドポイントを利用することで、VPC 内のリソースから Resolerver エンドポイントを介して VPC 外の DNS サーバーに名前解決のリクエストを送信できます。 リゾルバーエンドポイントには、以下の 2 種類があります。
インバウンドエンドポイント: オンプレミス環境（VPC 外）の DNS サーバーからの名前解決リクエストを受け付けるためのエンドポイントです。オンプレミス環境から VPC 内のリソースに対して名前解決を行う場合に利用します。
アウトバウンドエンドポイント: VPC 内のリソースからオンプレミス環境（VPC 外） DNS サーバーに名前解決リクエストを送信するためのエンドポイントです。 VPC 内のリソースからオンプレミス環境のリソースに対して名前解決を行う場合に利用します。
関連記事
なお、Active Directory を利用している場合は、アウトバウンドエンドポイントを利用して、Active Directory の DNS サーバーに名前解決リクエストを送信することも可能です。
リゾルバーエンドポイントを利用する場合は、エンドポイントごとに以下の料金が発生します。
ENI ごとに 0.125 USD/時間 引用元: 料金 - Amazon Route 53 | AWS
ENI ごとに 0.125 USD/時間
引用元: 料金 - Amazon Route 53 | AWS
1 USD = 145 円で計算した場合、1ヶ月あたりの料金は 9,450 円 となります。 高額ではありませんが、VPC の数が増えるとコストが増加するため、外接アカウントを利用する場合はリゾルバーエンドポイントを集約することを検討します。
通信元/通信先毎の名前解決の方法の選択肢を以下の表にまとめます。
*1: アウトバウンドエンドポイント利用 *2: インバウンドエンドポイント利用
可用性などを考慮せずに選択肢を上げると選択肢が多くなりますが、可用性を考慮した場合はやはり環境毎に用意した DNS サーバーを利用するのが良いでしょう。 VPC 内のリソースからの名前解決は、Amazon Route 53 Resolver を利用、オンプレミス環境のリソースからの名前解決はオンプレミス環境の DNS サーバーを利用するのが一般的です。 システム間連携が少ない、コストを抑えたい場合は他の選択肢を検討します。
VPC フローログは、VPC 内のネットワークトラフィックの情報を記録するための機能です。 VPC フローログの出力先は、以下のいずれかを選択できます。
出力先の選定は、ログの分析や監視の要件に応じて決定します。 VPC フローログはネットワークログであり、監査ログとして長期間保存することが一般的です。 そのため、S3 バケットを出力先として選択することが多いです。AWS 環境以外でログ基盤を構築している場合は、Kinesis Data Firehose を利用してログを転送することもあります。 リアルタイムでの監視やログ分析が必要な場合は CloudWatch Logs を選択するのが良いでしょう。
ログの蓄積は「VPC を構成しているアカウント」もしくは「ログ集約アカウント（ログアーカイブアカウントと呼ばれることが多い）」で行います。 会社組織としてログを集約するアカウントを定めている場合は、ログ集約アカウントに出力するようにします。
VPC エンドポイントは、VPC 内のリソースが AWS サービスにアクセスする際に、インターネットを経由せずに直接接続するための機能です。 また、VPC エンドポイントポリシーを利用することで、VPC エンドポイントを通じてアクセスできる AWS サービスやリソースを制限することができます。 これにより、セキュリティを強化し、データの漏洩を防ぐことができます。
VPC エンドポイントを採用する理由として、インターネットを経由せずに AWS サービスにアクセスする要件から VPC エンドポイントを採用されているケースもありますが、これは適切ではありません。 以下の引用のように、インターネットゲートウェイ経由のトラフィックは AWS のプライベートネットワークを通過するため、インターネットを経由しません。
2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。 AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。 さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。 すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。 引用元： よくある質問 - Amazon VPC | AWS
2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか? いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。 AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。 すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。
引用元： よくある質問 - Amazon VPC | AWS
VPC エンドポイントを採用する理由としては以下の 2 点が挙げられます。
① VPC 外のリソースから AWS サービスにアクセスする際に、VPC エンドポイントを利用することで、インターネットを経由せずに直接接続できる。 ② VPC エンドポイントポリシーを利用して、VPC エンドポイントを通じてアクセスできる AWS サービスやリソースを制限することで、セキュリティを強化できる。
① のユースケースとして、例えば Site-to-Site VPN 接続を利用してオンプレミス環境から AWS サービスにアクセスする場合、VPC エンドポイントを利用することで、インターネットを経由せずに直接接続できます。 マネジメントコンソールや S3 のアクセスなど、運用時に必要な AWS サービスに対しては、VPC エンドポイントを利用することで、セキュリティを強化しつつ、インターネットを経由せずにアクセスできます。 これを開発期間中にも利用してしまうと、かなりの数の VPC エンドポイントが必要となり、コストが増加する可能性があります。
② のユースケースとして、VPC エンドポイントポリシーを利用して、特定の AWS サービスやリソースへのアクセスを制限することができます。 例えば、以下の様なポリシーを設定することで、組織内のリソースに対してのみアクセスを許可し、組織外のアカウントへデータを送信することを防ぐことができます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowRequestsByOrgsIdentitiesToOrgsResources", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "my-org-id", "aws:ResourceOrgID": "my-org-id" } } }, { "Sid": "AllowRequestsByAWSServicePrincipals", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "*", "Resource": "*", "Condition": { "Bool": { "aws:PrincipalIsAWSService": "true" } } } ] }
VPC リソースの管理者を誰にするかは、組織の運用ルールやセキュリティポリシーに基づいて決定します。 一般的には、以下のような役割が考えられます。
これらの役割は、組織の規模や運用体制に応じて異なる場合があります。 例えば、すべての開発をシステムの開発担当者が担う場合もあれば、ネットワーク管理者が VPC の設計や構築を行い、開発担当者はアプリケーションの開発に専念する場合もあります。 ネットワーク管理者が VPC の設計や構築を行う場合の VPC リソース毎の役割分担を整理した例を以下の表に示します。
セキュリティグループはシステム固有の要件に応じて開発担当者が設計・構築を行うことが多いです。 セキュリティグループも含めてネットワーク管理者が設計・構築を行う整理にしているお客様もいらっしゃいますが、セキュリティグループの設計の要件を詰めるのに時間がかかることが多く、開発のスピード感を損なう可能性があります。 このため、セキュリティグループの設計・構築は開発担当者が行うことを推奨します。