- ネットワーキングとコンテンツ配信›
- Amazon VPC›
- よくある質問
Amazon VPC のよくある質問
一般的な質問
すべて開くAmazon VPC では、Amazon Web Services (AWS) クラウド内で論理的に分離したセクションをプロビジョニングし、お客様が定義する仮想ネットワークで AWS リソースを起動できます。独自の IP アドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など、仮想ネットワーキング環境を完全に制御できます。また、企業のデータセンターと自分の VPC 間にハードウェア仮想プライベートネットワーク (VPN) 接続を構築できるので、AWS クラウドを企業の既存のデータセンターの延長として活用できます。
Amazon VPC のネットワーク設定は容易にカスタマイズすることができます。例えば、インターネットへのアクセスがあるウェブサーバーのパブリックサブネットを作成し、データベースやアプリケーションサーバーなどのバックエンドシステムをインターネットへのアクセスがないプライベートサブネットに配置できます。セキュリティグループやネットワークアクセスコントロールリストなどの複数のセキュリティレイヤーを活用し、各サブネットの Amazon EC2 インスタンスへのアクセスをコントロールすることができます。
Amazon VPC は、すでにご自身でネットワークを管理されているお客様にとって理解しやすいオブジェクト群で構成されています。
- 仮想プライベートクラウド: AWS クラウド内の、論理的に分離した仮想ネットワーク。VPC の IP アドレス空間を選択した範囲で定義できます。
- サブネット: VPC の IP アドレス範囲のセグメントで、分離されたリソースのグループを配置できます。
- インターネットゲートウェイ: Amazon VPC とパブリックインターネットを接続するためのゲートウェイです。
- NAT ゲートウェイ: 高い可用性を持つマネージド型のネットワークアドレス変換 (NAT) サービスで、プライベートサブネットにあるリソースからインターネットへの接続に利用します。
- 仮想プライベートゲートウェイ: VPN 接続の Amazon VPC 側です。
- ピアリング接続: ピアリング接続を使用すると、2 つのピア VPC 間のトラフィックをプライベート IP アドレス経由でルーティングできます。
- VPC エンドポイント: インターネットゲートウェイ、VPN、ネットワークアドレス変換 (NAT) デバイス、またはファイアウォールプロキシを使用せずに、VPC 内から AWS でホストされているサービスに対するプライベート接続を実現できます。
- Egress-Only インターネットゲートウェイ: VPC からインターネットへの IPv6 トラフィックに Egress-Only アクセスを提供するステートフルゲートウェイ。
お客様の AWS リソースはすぐに利用できるデフォルトの VPC 内へ自動的にプロビジョニングされます。追加の VPC を作成するには、AWS マネジメントコンソールの Amazon VPC ページで [Start VPC Wizard] を選択します。
そうすると、ネットワークアーキテクチャの 4 つの基本オプションが表示されます。オプションを選択したら、VPC とそのサブネットのサイズと IP アドレスの範囲を変更することができます。ハードウェア VPN アクセスのオプションを選択した場合は、ネットワーク上の VPN ハードウェアの IP アドレスを指定する必要があります。VPC に変更を加えて、セカンダリ IP アドレス範囲やゲートウェイを追加/削除することもできますし、IP 範囲にサブネットを追加することもできます。
以下がその 4 つのオプションです。
- 1 つのパブリックサブネットのみを持つ Amazon VPC
- パブリックサブネットとプライベートサブネットを持つ Amazon VPC
- パブリックサブネットとプライベートサブネットおよび AWS サイト間 VPN アクセスを持つ Amazon VPC
- 1 つのプライベートサブネットのみと AWS Site-to-Site VPN アクセスを持つ Amazon VPC
VPC エンドポイントにより、インターネットゲートウェイ、NAT デバイス、ファイアウォールプロキシを使うことなく、VPC から AWS でホストされたサービスへのプライベート接続が可能になります。エンドポイントは水平方向にスケーラブルで可用性の高い仮想デバイスで、VPC 内のインスタンスと AWS のサービス間の通信を可能にします。Amazon VPC には、ゲートウェイタイプとインターフェイスタイプという 2 種類のエンドポイントが用意されています。
ゲートウェイタイプエンドポイントは AWS 製品に対してのみ利用でき、S3、DynamoDB などがあります。このタイプのエンドポイントでは、選択したルートテーブルにエントリが追加され、トラフィックが Amazon のプライベートネットワークを経由してサポート対象のサービスにルーティングされます。
インターフェイスタイプのエンドポイントは PrivateLink を用いたサービスにプライベートに接続でき、AWS 製品ですので、お客様自身のサービスや SaaS ソリューションに、Direct Connect での接続をサポートします。将来はより多くの AWS、SaaS ソリューションがこれらのエンドポイントでサポートされるようになります。インターフェイスタイプのエンドポイントの料金については、VPC の料金をご覧ください。
請求
すべて開くVPC 自体の作成および使用には追加料金はかかりません。Amazon EC2 などの他のアマゾン ウェブ サービスの利用料金が、データ転送料金を含めこれらのリソースに指定レートで適用されます。お客様の VPC を貴社のデータセンターに接続するために、ハードウェア VPN 接続 (オプションのサービス) を使用する場合、ご利用料金は VPN 接続時間 (VPN 接続が「利用可能」状態である時間の長さ) 単位となります。 1 時間未満の消費時間は、1 時間分として請求されます。VPN 接続経由で転送されたデータは、標準の AWS データ転送料金で課金されます。VPC-VPN の料金情報については、Amazon VPC 製品ページの料金セクションをご覧ください。
Amazon EC2 を含む他の Amazon Web Services の使用料金は、これらのリソースの公表料金に基づいて引き続き適用されます。VPC インターネットゲートウェイを介して Amazon S3 のようなアマゾン ウェブ サービスへアクセスする場合は、データ転送料は発生しません。
VPN 接続を介して AWS リソースにアクセスする場合は、インターネットデータ転送料金が発生します。
接続
すべて開くAmazon VPC は以下に接続できます。
- インターネット (インターネットゲートウェイ経由)
- AWS サイト間 VPN 接続を使用する、お客様の自社データセンター (仮想プライベートゲートウェイ経由)
- インターネットとお客様の自社データセンターの両方 (インターネットゲートウェイと仮想プライベートゲートウェイの両方を利用)
- (インターネットゲートウェイ、NAT、仮想プライベートゲートウェイ、VPC エンドポイント経由での) その他の AWS のサービス
- その他の Amazon VPC (VPC ピアリング接続経由)
パブリック IP アドレスがないインスタンスは、2 つの方法のうちのいずれかでインターネットにアクセスすることができます。
- パブリック IP アドレスがないインスタンスは、NAT ゲートウェイや NAT インスタンスを通してトラフィックをルーティングし、インターネットにアクセスできます。こういったインスタンスは、NAT ゲートウェイや NAT インスタンスのパブリック IP アドレスを使って、インターネットに接続します。NAT ゲートウェイや NAT インスタンスは外向きの通信を許可しますが、インターネットのマシンがプライベートにアドレスを付与されたインスタンスへの接続を開始することは許可しません。
- ハードウェア VPN 接続や Direct Connect 接続を使用する VPC の場合、インスタンスからのインターネットトラフィックは、仮想プライベートゲートウェイ経由でお客様の既存のデータセンターにルーティングできます。そこから、既存の Egress ポイントとネットワークセキュリティ/モニタリングデバイスを介してインターネットにアクセスできます。
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間の Transport Layer Security (TLS) 接続などといった追加の暗号化レイヤーもあります。
IP アドレス関連
すべて開くプライマリ CIDR ブロックについては、RFC 1918 に規定されている IP アドレス範囲またはパブリックにルーティング可能な IP アドレス範囲のうち、任意の IPv4 アドレス範囲を使用できます。セカンダリ CIDR ブロックには、一定の制限が適用されます。 パブリックにルーティング可能な IP ブロックには、仮想プライベートゲートウェイ経由でのみ到達可能であり、インターネットゲートウェイを通してインターネット経由でアクセスすることはできません。 AWS 側では、お客様所有の IP アドレスブロックをインターネットにアドバタイズしません。Amazon 提供または BYOIP の IPv6 GUA CIDR ブロックは、関連 API の呼び出しまたは AWS マネジメントコンソールによって最大 5 つまで VPC に割り振ることができます。
VPC を作成する際に、1 つの Classless Internet Domain Routing (CIDR) IP アドレス範囲をプライマリ CIDR ブロックとして割り当てます。VPC の作成後は、最大 4 つまでのセカンダリ CIDR ブロックを追加できます。VPC 内のサブネットは、これらの CIDR 範囲から指定してください。IP アドレスの範囲が重複する複数の VPC を作成することができる一方で、そうすることにより、これらの VPC をハードウェア VPN 接続を介して同じホームネットワークへ接続することができなくなることにご注意ください。この理由から、当社は IP アドレス範囲を重複させないことをお勧めしています。Amazon 提供または BYOIP の IPv6 CIDR ブロックを最大 5 つまで VPC に割り振ることができます。
現在、Amazon VPC では 5 つの IP アドレス範囲 (IPv4 の 1 つのプライマリと 4 つのセカンダリ) がサポートされています。これらの各範囲のサイズは、CIDR 表記で /28～/16 となります。VPC の IP アドレス範囲と既存ネットワークの IP アドレス範囲を重複させることはできません。
IPv6 の場合、VPC のサイズは /56 (CIDR 表記法) に固定されています。IPv4 と IPv6 両方の CIDR ブロックを同じ VPC に関連付けることができます。
現在、VPC ごとに 200 のサブネットを作成できます。さらに作成する場合は、サポートセンターにケースを送信してください。
IPv4 の場合、サブネットの最小サイズは /28 (または 14 個の IP アドレス) です。サブネットを、それらが作成された VPC より大きくすることはできません。
IPv6 の場合、サブネットのサイズは /64 に固定されています。サブネットに割り振り可能なのは IPv6 CIDR ブロック 1 つのみです。
インスタンスが以下の条件を満たしていれば、どのような IP アドレスでも割り当てることができます。
- サブネットの IP アドレス範囲の一部である
- IP ネットワーク用に Amazon がリザーブしていない
- 別のインターフェイスに割り当てられていない
はい。Amazon VPC の Elastic Network Interface や EC2 インスタンスに、1 つまたは複数のセカンダリプライベート IP アドレスを割り当てることができます。割り当て可能なセカンダリプライベート IP アドレスの数は、インスタンスタイプにより異なります。インスタンスタイプごとの割り当て可能なセカンダリプライベート IP アドレスの数については、「EC2 ユーザーガイド」をご覧ください。
Bring Your Own IP
すべて開く自身の IP アドレスを AWS に持ち込むには以下の理由があります:
IP レピュテーション: お客様の多くは、その IP アドレスのレピュテーションを戦略的資産と見なし、これらの IP をそのリソースと共に AWS で使用したいと考えておられます。例えば、アウトバウント E メール MTA などのサービスを維持しておられ、レピュテーションの高い IPをお持ちのお客様は、その IP 空間を持ち込んで、既存の送信成功率を正常に維持することができるようになります。
お客様のホワイトリスト登録: BYOIP は、お客様が新しい IP アドレスでホワイトリストを再確立する必要なく、IP アドレスのホワイトリスト登録に依存するワークロードを AWS に移させることも可能にします。
ハードコーディングされた依存関係: お客様の中には、デバイスにハードコーディングされた IP がある、またはアーキテクチャ面でその IP に依存するお客様がおられます。BYOIP は、このようなお客様が AWS に簡単に移行できるようにします。
規制とコンプライアンス: 規制およびコンプライアンス上の理由により、多くのお客様に特定の IP の使用が義務付けられています。これらも、BYOIP で解決できます。
オンプレミス IPv6 ネットワークポリシー: 多くのお客様は、オンプレミスネットワークで IPv6 のみをルーティングできます。これらのお客様は、独自の IPv6 範囲を VPC に割り当て、インターネットまたは Direct Connect を使用してオンプレミスネットワークにルーティングすることを選択できるため、BYOIP によってロック解除されます。
BYOIP を利用できるリージョンの詳細については、ドキュメントをご覧ください。
IP アドレスマネージャー
すべて開くAWS IPAM には次の機能があります:
- アットスケールネットワークのための IP アドレスの割り振り: IPAM は、設定可能なビジネスルールに基づき、数百のアカウントや VPC に対して IP アドレスの割り振りを自動化することができます。
- ネットワーク全体の IP 使用状況のモニタリング: IPAM は IP アドレスをモニタリングし、ネットワークの成長を妨げる IP アドレスの枯渇や、誤ったルーティングを引き起こす IP アドレスの重複など、IPAM が潜在的な問題を検出したときにアラートを受け取ることが可能です。
- ネットワークのトラブルシューティングを行う: IPAM は、接続性の問題が IP アドレスの誤設定やその他の問題によるものであるかどうかを迅速に特定するのに役立ちます。
- IP アドレスの監査: IPAM は IP アドレスのモニタリングデータを自動的に保持します (最大 3 年間)。この履歴データを使って、ネットワークの遡及的分析や監査を行うことができます。
IPAM の主要な構成要素は次のとおりです:
- スコープは、IPAM 内の最高レベルのコンテナです。IPAM は、2 つのデフォルトスコープを含んでいます。各スコープは、1 つのネットワークの IP 空間を表します。プライベートスコープは、すべてのプライベート空間を対象としています。パブリックスコープは、すべての公共空間を対象としています。スコープは、IP アドレスの重複や競合を引き起こすことなく、接続されていない複数のネットワークで IP アドレスを再利用することを可能にします。スコープ内では、IPAM プールを作成します。
- プールは、連続した IP アドレス範囲 (または CIDR) の集合体です。IPAM プールは、ルーティングとセキュリティの必要性に応じて IP アドレスを整理することができます。トップレベルのプールの中に、複数のプールを持つことができます。例えば、開発用と本番用のアプリケーションで別々のルーティングとセキュリティのニーズがある場合、それぞれ用のプールを作成することができます。IPAM プール内では、AWS のリソースに CIDR を割り当てます。
- 割り振りとは、IPAM プールから他のリソースまたは IPAM プールへの CIDR 割り当てのことです。VPC を作成し、VPC の CIDR に IPAM プールを選択すると、CIDR は IPAM プールにプロビジョニングされた CIDR から割り振られます。IPAM を使用して割り振りをモニタリングおよび管理できます。
はい。IPAM は BYOIPv4 と BYOIPv6 の両方のアドレスに対応しています。BYOIPは、EC2 の機能で、自社で所有する IP アドレスを AWS に持ち込むことができます。IPAM を使用すると、アカウントや組織間でその IP アドレスブロックを直接プロビジョニングして共有することができます。IPv4 を使用している既存の BYOIP のユーザーは、プールを IPAM に移行して IP 管理を簡素化することができます。
トポロジー
すべて開くセキュリティとフィルタリング
すべて開くAmazon EC2 セキュリティグループを、Amazon VPC 内のセキュリティで保護されたインスタンスをよりセキュアにするために使用することができます。VPC 内のセキュリティグループにより、各 Amazon EC2 インスタンスにおける着信および発信両方のネットワークトラフィックを指定することができます。明示的に許可されていないトラフィックは自動的に拒否されます。
セキュリティグループに加えて、各サブネットに出入りするネットワークトラフィックは、ネットワークアクセスコントロールリスト (ACL) を使用して許可または拒否することができます。
ステートフルフィルタリングでは、リクエスト元を追跡し、リクエストに対する応答が自動的に元のコンピュータに戻るようにできます。例えば、ウェブサーバーで tcp ポート 80 の着信トラフィックを許可するステートフルフィルタでは、通常、さらに若い番号のポート (例: 送信先 tcp ポート 63、912) でクライアントとウェブサーバー間のステートフルフィルタを通過するリターントラフィックが許可されます。フィルタリングデバイスでは、送信元ならびに送信先ポート番号と IP アドレスを追跡するステートテーブルが維持されます。フィルタリングデバイスで必要とされるルールは、tcp ポート 80 でウェブサーバーへの着信トラフィックを許可することのみです。
一方ステートレスフィルタリングは、トラフィックが新しいリクエストであるか、またはリクエストへの応答であるかにかかわりなく、送信元または送信先 IP アドレスおよび送信先ポートのみを確認します。上記の例ではフィルタリングデバイスに、TCP ポート 80 でウェブサーバーへの着信トラフィックを許可するルールと、ウェブサーバーからの発信トラフィックを許可するルール (TCP ポート範囲 49、152 から 65、535) の、2 つのルールを実装する必要があります。
VPC フローログは、VPC 内のネットワークインターフェイスに出入りする IP トラフィックに関する情報を取得できるようにする機能です。フローログデータは、Amazon CloudWatch Logs または Amazon S3 のいずれかに発行できます。VPC フローログをモニタリングし、ネットワークの依存関係とトラフィックパターンの運用上の可視性を取得したり、異常を検出してデータ漏洩を防止したり、ネットワーク接続と設定の問題をトラブルシューティングしたりできます。フローログの強化されたメタデータは、TCP 接続を開始したユーザー、および NAT ゲートウェイなどの中間層を流れるトラフィックの実際のパケットレベルの送信元と送信先に関する洞察をさらに得るのに役立ちます。コンプライアンス要件を満たすためにフローログをアーカイブすることもできます。VPC フローログに関する詳細については、ドキュメントをご覧ください。
はい。Transit Gateway または個々の Transit Gateway アタッチメントの VPC フローログを作成することができます。この機能により、Transit Gateway を経由するネットワークフローについて、送信元/送信先 IP、ポート、プロトコル、トラフィックカウンター、タイムスタンプ、各種メタデータなどの詳細情報をエクスポートできます。Transit Gateway の Amazon VPC フローログのサポートについては、ドキュメントをご覧ください。
フローログを CloudWatch Logs または Amazon S3 に発行する場合、Vended Logs のデータインジェストとアーカイブ料金が適用されます。詳細と例については、Amazon CloudWatch の料金をご覧ください。コスト割り振りタグを使用して、フローログの発行から料金を追跡することもできます。
VPC トラフィックミラーリング
すべて開くトラフィックミラーリングでは、EC2 インスタンスの Elastic Network Interface (ENI) レベルでネットワークパケットをキャプチャします。Amazon VPC トラフィックミラーリングをサポートする EC2 インスタンスについては、トラフィックミラーリングのドキュメントをご覧ください。
Amazon VPC フローログでは、ネットワークフローログを収集、保存、分析できます。フローログでキャプチャされる情報には、許可/拒否されたトラフィック、送信元と送信先の IP アドレス、ポート、プロトコル番号、パケット数とバイト数、アクション (許可または拒否) に関する情報などがあります。この機能を使用すると、接続やセキュリティの問題のトラブルシューティングを実行したり、ネットワークアクセスルールが正常に機能しているかを確認したりできます。
Amazon VPC トラフィックミラーリングでは、ペイロードといった実際のトラフィックコンテンツを分析できるため、ネットワークトラフィックに関する深い理解を得ることができます。対象となるユースケースには、実際のパケットを分析してパフォーマンスの問題の根本原因を究明したり、複雑なネットワーク攻撃のリバースエンジニアリング作業を行ったり、内部者による不正使用やワークロードの侵害を検出および阻止したりする必要がある場合が挙げられます。
Amazon VPC と EC2
すべて開くAmazon VPC は現在、すべての Amazon EC2 リージョンにおいて、複数のアベイラビリティーゾーンでご利用になれます。
IPv4 アドレスを必要とするインスタンスについては、お客様の VPC が適切なサイズで、各インスタンスに割り当てられた IPv4 アドレスを保有している限り、VPC 内で任意の数の Amazon EC2 インスタンスを実行することができます。最初は、同時起動できる Amazon EC2 インスタンスの数は最大 20 まで、VPC サイズは最大 /16 (65,536 IP) までに制限されています。これらの制限数を超過して使用したい場合は、以下のフォームにご記入ください。 IPv6 のみのインスタンスの場合、サイズが /56 の VPC は、実質的に無制限の数の Amazon EC2 インスタンスを起動することができます。
お客様の VPC と同一のリージョン内に登録されている Amazon VPC の AMI を使用できます。例えば、us-east-1 に登録されている AMI を us-east-1 内の VPC で使用できます。Amazon EC2 のリージョンおよびアベイラビリティーゾーンのよくある質問で、詳細な情報をご覧いただけます。
はい。お客様の VPC と同一のリージョンにあれば、Amazon EBS スナップショットを使用することができます。Amazon EC2 リージョンおよびアベイラビリティーゾーンのよくある質問で、詳細な情報をご覧いただけます。
デフォルト VPC
すべて開く2013 年 3 月 18 日以降に作成された AWS アカウントであれば、デフォルト VPC 内でリソースを起動できます。どのリージョンでデフォルト VPC の機能が有効になっているかを確認するには、こちらのフォーラムでのお知らせをご覧ください。また、上記の日時より前に作られたアカウントであっても、デフォルト VPC が有効なリージョンのうち、これまでに EC2 インスタンスの起動や Elastic Loadbalancing、Amazon RDS、Amazon ElastiCache、Amazon Redshift などのリソースのプロビジョニングをしたことがないリージョンの中であれば、デフォルト VPC を利用できます。
「EC2 ユーザーガイド」の「EC2-Classic と EC2-VPC の違い」をご覧ください。
はい。AWS 側で既存のアカウントに対しデフォルト VPC を有効にすることは可能ですが、そのアカウントの EC2-Classic リソースが存在しないリージョンに限ります。該当のリージョン内で、VPC にプロビジョニングされていない Elastic Load Balancer、Amazon RDS、Amazon ElastiCache、Amazon Redshift のリソースが存在している場合、それらをすべて終了する必要があります。アカウントがデフォルト VPC を使用するよう設定されると、以後に起動されるリソースは、Auto Scaling により起動されるインスタンスを含め、すべてデフォルト VPC 内に配置されます。お使いの既存アカウントにデフォルト VPC のセットアップを希望する場合は、アカウントおよび請求 -> サービス: アカウント -> カテゴリ: EC2 Classic から VPC への変換の順に選択し、リクエストを送信してください。お客様のリクエストと AWS のサービスおよび EC2-Classic の利用状況を確認したうえで、今後の対応についてご連絡いたします。
EC2 Classic
すべて開くこの変更の影響を受けるのは、いずれかの AWS リージョンのアカウントで EC2-Classic を有効にしている場合のみです。AWS リージョンで EC2-Classic が有効になっているかどうかは、コンソールまたは describe-account-attributes コマンドを使用して確認することができます。詳細については、こちらのドキュメントをご覧ください。
EC2-Classic 上で稼働している AWS リソースがない場合は、そのリージョンのアカウントから EC2-Classic をオフにするようお願いします。リージョン内の EC2-Classic をオフにすると、そこにデフォルト VPC を起動することができます。これを行うには、AWS Support Center console.aws.amazon.com/support にアクセスし、[ケースの作成] を選択した後、[アカウントおよび請求サポート] を選択し、[Type] で [Account] を選択し、[Category] で [Convert EC2 Classic to VPC] を選択し、必要に応じてその他の詳細を入力し、[送信] をクリックします。
2021 年 1 月 1 日以降、EC2-Classic 上に AWS リソース (EC2 インスタンス、Amazon リレーショナルデータベース、AWS Elastic Beanstalk、Amazon Redshift、AWS Data Pipeline、Amazon EMR、AWS OpsWorks) が存在していない AWS リージョンについては、2021 年 10 月 30 日にお客様のアカウントから EC2-Classic を自動的にオフにします。
一方で、EC2-Classic 上で稼働している AWS リソースがある場合は、できるだけ早く Amazon VPC への移行を計画していただくようお願いします。2022 年 8 月 15 日以降は、EC2-Classic プラットフォーム上でインスタンスや AWS のサービスを起動することはできません。稼働中のワークロードやサービスは、2022 年 8 月 16 日以降、EC2-Classic 上のすべての AWS のサービスを使用停止にするため、徐々にアクセスできなくなります。
お使いの AWS リソースの移行ガイドは、次の質問でご覧いただけます。
Amazon VPC は、お客様の AWS アカウントから論理的に分離された AWS 上の仮想ネットワーク環境を完全に制御することができます。EC2-Classic 環境では、お客様のワークロードは、他のお客様と単一のフラットなネットワークを共有しています。Amazon VPC 環境では、独自の IP アドレス空間の選択、公開およびプライベートサブネットの設定、ルートテーブルやネットワークゲートウェイの管理など、EC2-Classic 環境に比べて他にも多くの利点があります。現在、EC2-Classic で利用できるすべてのサービスとインスタンスは、Amazon VPC 環境でも同等のサービスを利用できます。また、Amazon VPC では、EC2-Classic よりもはるかに幅広く、最新世代のインスタンスを提供しています。Amazon VPC の詳細については、このリンクをご覧ください。
リソースの移行をサポートするため、私たちはプレイブックを公開し、以下に示すソリューションを構築しました。移行するには、VPC に EC2-Classic リソースを再作成する必要があります。まず、このスクリプトを使用して、アカウント内のすべてのリージョンで EC2-Classic でプロビジョンされたすべてのリソースを特定します。その後、以下から関連する AWS リソースの移行ガイドを使用できます:
- インスタンスとセキュリティグループ
- Classic Load Balancer
- Amazon Relational Database Service
- AWS Elastic Beanstalk
- Amazon Redshift の DC1 クラスターの移行と他のノードタイプの移行について
- AWS Data Pipeline
- Amazon EMR
- AWS OpsWorks
上記の移行ガイドに加えて、高度に自動化されたリフト & シフト (リホスト) ソリューションである AWS Application Migration Service (AWS MGN) も提供しており、アプリケーションの移行を簡素化、迅速化、コスト削減することができます。AWS MGN に関するリソースはこちらからご覧いただけます。
- AWS Application Migration Service の使用の開始
- AWS Application Migration Service のオンデマンドテクニカルトレーニング
- AWS Application Migration Service の機能と特徴を深く理解するためのドキュメント
- サービスアーキテクチャとネットワークアーキテクチャのビデオ
EC2-Classic から VPC へのシンプルな個別 EC2 インスタンスの移行には、AWS MGN やインスタンス移行ガイドの他に、「AWS Systems Manager > Automation」から「AWSSupport-MigrateEC2 ClassicToVPC」ランブックを利用することもできます。このランブックは、EC2-Classic から VPC へのインスタンスの移行に必要なステップを自動化します。EC2-Classic でインスタンスの AMI を作成し、VPC でその AMI から新しいインスタンスを作成し、オプションで EC2-Classic インスタンスを終了させます。
ご質問やご不明な点がございましたら、AWS プレミアムサポートから AWS サポートチームにお問い合わせください。
注意: 複数の AWS リージョンで EC2-Classic 上で稼働している AWS リソースがある場合、それらのリージョンですべてのリソースを VPC に移行したら、すぐに各リージョンの EC2-Classic をオフにすることをお勧めします。
2022 年 8 月 15 日の使用停止日に先駆けて、以下の 2 つのアクションを実施します。
- 2021 年 10 月 30 日に EC2-Classic 環境の 3 年のリザーブドインスタンス (RI) と 1 年の RI の発行を停止します。すでに EC2-Classic 環境で使用されている RI は、この時点では影響を受けません。2022 年 8 月 15 日以降に期限切れとなる RI は、残りのリース期間で Amazon VPC 環境を使用するように変更する必要があります。RI の変更方法については、弊社のドキュメントをご覧ください。
- 2022 年 8 月 15 日、EC2-Classic 環境での新規インスタンス (スポットまたはオンデマンド) の作成やその他の AWS のサービスを許可しません。稼働中のワークロードやサービスは、2022 年 8 月 16 日以降、EC2-Classic 上のすべての AWS のサービスを使用停止にするため、徐々にアクセスできなくなります。
Elastic Network Interface
すべて開くネットワークインターフェイスは、同じアカウント内の VPC のインスタンスにのみアタッチできます。
ピアリング接続
すべて開くVPC ピアリング接続の作成に費用はかかりませんが、ピアリング接続間のデータ転送には料金が発生します。データ転送料金については、EC2 料金ページのデータ転送セクションをご覧ください。
AWS では VPC の既存のインフラストラクチャを使用して VPC ピアリング接続を作成しています。これはゲートウェイでも VPN 接続でもなく、個別の物理ハードウェアに依拠するものではありません。通信の単一障害点や帯域幅のボトルネックは存在しません。
インターリージョン VPC ピアリングは、現在 VPC に使用されているものと同じ、水平スケーリング、冗長化、高可用性を持ったテクノロジーを使って動作します。インターリージョン VPC ピアリングトラフィックは、冗長性と動的帯域幅割り当てを内蔵している AWS バックボーンを経由します。通信に単一の障害点はありません。
インターリージョンピアリング接続がダウンすると、トラフィックはインターネット経由でルーティングされません。
ピアリング接続されたインスタンス間の帯域幅は、同じ VPC 内のインスタンス間の帯域幅と同じです。注: プレイスメントグループをピアリング接続した VPC に設定することもできますが、ピアリング接続した VPC 内のインスタンス間では全二重帯域幅を使用できません。プレイスメントグループの詳細をお読みください。
ClassicLink
すべて開くClassicLink を使用するのに追加料金はかかりませんが、既存のアベイラビリティーゾーン間のデータ転送料金が適用されます。詳細については、EC2 の料金表のページをご覧ください。
AWS PrivateLink
すべて開くお客様はサービスのユーザーとして、PrivateLink を用いたサービスに対するインターフェイスタイプ VPC エンドポイントを作成する必要があります。これらのサービスエンドポイントは、プライベート IP を割り当てられた Elastic Network Interface (EIN) として VPC に表示されます。このようなエンドポイントが作成されると、該当する IP を送信先とするトラフィックは AWS の対応するサービスにプライベートでルーティングされます。
サービスの所有者として、お客様はサービスを AWS PrivateLink にオンボードでき、これには Network Load Balancer (NLB) をサービスのフロントに置き、PrivateLink サービスが NLB に登録されるように生成します。お客様の顧客はその VPC 内でエンドポイントを確立して、お客様が顧客のアカウントと IAM ロールをホワイトリストに登録するとお客様のサービスに接続できるようになります。
次の AWS 製品がこの機能をサポートしています: Amazon Elastic Compute Cloud (EC2)、Elastic Load Balancing (ELB)、Kinesis Streams、Service Catalog、EC2 Systems Manager、Amazon SNS、および AWS DataSync。多くの SaaS ソリューションもこの機能をサポートしています。AWS PrivateLink を用いたその他の SaaS 製品については、AWS Marketplace にアクセスしてください。
その他の質問
すべて開くVPC 制限数については、Amazon VPC ユーザーガイドをご覧ください。
はい。AWS サポートの詳細については、こちらをクリックしてください。
Amazon VPC を管理するための ElasticFox は公式にサポートされなくなりました。Amazon VPC のサポートは、AWS API、コマンドラインツール、AWS マネジメントコンソール、またサードパーティーのさまざまなユーティリティから利用できます。
VPC 暗号化コントロール
すべて開くリージョン内の VPC 内および VPC 間のトラフィックフローの暗号化をモニタリングおよび強制適用するための一元化されたコントロールを提供するセキュリティおよびコンプライアンス機能です。詳細については、こちらのドキュメントをお読みください。
モニターモード (可視性、評価、移行開始のため) と強制適用モード (暗号化されていないトラフィックの防止のため) です。
特に、HIPAA、FedRamp、PCI DSS などの標準へのコンプライアンスが求められる業界のセキュリティ管理者およびクラウドアーキテクトを対象としています。
アプリケーション層の暗号化と AWS Nitro System ハードウェアに組み込まれた暗号化機能の両方を使用して、暗号化を確実に強制適用します。
モニターモードは、トラフィックフローの暗号化ステータスについての可視性を提供し、非準拠のリソースを特定するのに役立つほか、VPC フローログに暗号化ステータス情報を入力します。モニターモードをオンにすると、Network Load Balancer、Application Load Balancer、Fargate クラスター、EKS コントロールプレーンなどのリソースは、暗号化をネイティブにサポートするハードウェアに自動的かつ段階的に移行されます。
方法:
- VPC フローログの暗号化ステータスフィールド
- コンソールダッシュボード
- GetVpcResourcesBlockingEncryptionEnforcement コマンド
いいえ。encryption-status フィールドを手動で追加して新しいフローログを作成する必要があります。また、traffic-path フィールドと flow-direction フィールドを追加することもお勧めします。
VPC が強制適用モードになると、VPC 境界内で暗号化されていないトラフィックを許可するリソースの作成またはアタッチができなくなります。ネイティブ Nitro 暗号化をサポートしていないインスタンスの実行はブロックされます。
いいえ。まず次を行う必要があります:
- モニターモードを有効にする
- 非準拠のリソースを特定する
- 非準拠のリソースの除外を変更または作成する
- その後、強制適用モードに切り替える
サポートされている 8 つの除外タイプから、そのリソースの除外を作成する必要があります。その他のサポートされていないリソースは、強制適用モードをオンにする前に、VPC から移行するか、または削除する必要があります。暗号化コントロールによってサポートされているリソースは、強制適用をオンにする前に、暗号化準拠インスタンスに移行する必要があります。
以下のステップに従ってください:
- フローログとリソースコンプライアンスを確認する
- 必要なリソース移行を計画する
- 強制適用モードに切り替える際に必要な除外を設定する
はい。ただし、2 つの VPC 間に除外なしで VPC ピアリングが確立されている場合を除きます。この場合、2 つの VPC 間の VPC ピアリングを削除してから、モニターモードに切り替える必要があります。
GetVpcResourcesBlockingEncryptionEnforcement コマンドを使用して、強制適用をブロックするリソースを特定してください。あるいは、コンソールを使用して暗号化されていないリソースを見つけることもできます。
サポートされている除外は 8 つあります:
- インターネットゲートウェイ
- NAT ゲートウェイ
- Egress-Only インターネットゲートウェイ
- 暗号化が強制適用されていない VPC への VPC ピアリング接続
- 仮想プライベートゲートウェイ
- Lambda 関数
- VPC Lattice
- Elastic File System
0: 暗号化なし
1: Nitro 暗号化
2: アプリケーション暗号化
3: Nitro とアプリケーションの両方で暗号化
(-): 不明/VPC 暗号化コントロールがオフ
暗号化コントロールが有効になっている VPC 間のトラフィックを暗号化するために、VPC ピアリングまたは Transit Gateway を使用できます。Transit Gateway を使用する場合は、コンソールまたは modify-transit-gateway コマンドを使用して暗号化サポートを明示的にオンにする必要があります。Transit Gateway で暗号化をオンにしても別途料金は発生しませんが、Transit Gateway に関連付けられているすべての VPC について、標準の VPC 暗号化コントロール料金が発生します (これらの VPC で暗号化コントロールをオンにするかどうかにかかわらず)。
「modify-transit-gateway」コマンドを使用するか、または AWS コンソールを通じて有効にしてください。暗号化コントロールがオンになっている VPC 間のトラフィックを暗号化するには、Transit Gateway で暗号化サポートを明示的に有効にする必要があります。
既存の TGW で暗号化を有効にしても、既存のトラフィックフローは中断されません。VPC アタッチメントは暗号化レーンにシームレスかつ自動的に移行されます。Transit Gateway で暗号化サポートを有効にして、VPC 間のトラフィックを暗号化できます。強制適用モード (除外なし) の 2 つの VPC 間のトラフィックは、TGW 経由でエンドツーエンドで暗号化されます。また、Transit Gateway での暗号化により、異なる暗号化コントロールモードの 2 つの VPC を接続することもできます。
状況により異なります。強制適用モード (除外なし) の 2 つの VPC 間のトラフィックは、TGW 経由でエンドツーエンドで暗号化されます。また、Transit Gateway での暗号化により、異なる暗号化コントロールモードの 2 つの VPC を接続することもできます。暗号化が適用されていない VPC に接続された VPC で暗号化コントロールを強制適用する場合に使用してください。このようなシナリオでは、暗号化が強制適用されている VPC 内のすべてのトラフィック (VPC 間トラフィックを含む) が暗号化されます。VPC 間トラフィックは、暗号化が強制適用されている VPC 内のリソースと Transit Gateway 間で暗号化されます。さらに、暗号化は、暗号化が強制適用されていない VPC 内のトラフィックの送信先となるリソースに依拠し、暗号化が保証されるわけではありません (VPC が強制適用モードではないため)。すべての VPC は同じリージョンに存在する必要があります。
はい。トラフィックは、強制適用されていない VPC の TGW アタッチメントに到達するまで暗号化されたままとなります。送信先 VPC の暗号化ステータスにかかわらず、トラフィックは送信元から送信先 VPC の TGW アタッチメントに到達するまで暗号化されたままとなります。
既存の接続を維持しながら TGW で暗号化を有効にします。移行は自動的に処理されます。TGW で暗号化を有効にしても、既存のトラフィックフローは中断されません。
はい。TGW は、移行中に暗号化されたトラフィックと暗号化されていないトラフィックの両方を処理することで、段階的な移行をサポートしています。
いいえ。VPC 暗号化コントロールを備えた Private Link は、AWS のサービスでのみサポートされています。AWS 以外のサービスへの VPC エンドポイントは、暗号化を強制適用する VPC 内に残すことはできません。VPC を強制適用モードに移行する前に、これらのエンドポイントを削除する必要があります。強制適用モードで実行されている VPC は、エンドツーエンドの暗号化を保証するために、VPC ピアリングまたは Transit Gateway に接続できます。