Amazon VPC のよくある質問

VPC 自体の作成・使用には追加料金はかかりません。Amazon EC2 などの他のアマゾン ウェブ サービスの利用料金が、データ転送料金を含めこれらのリソースに指定レートで適用されます。お客様の VPC を貴社のデータセンターに接続するために、ハードウェア VPN 接続 (オプションのサービス) を使用する場合、ご利用料金は VPN 接続時間 (VPN 接続が「利用可能」状態である時間の長さ) 単位となります。 1 時間未満の消費時間は、1 時間分として請求されます。VPN 接続経由で転送されたデータは、標準の AWS データ転送料金で課金されます。VPC-VPN の料金情報については、Amazon VPC 製品ページの料金セクションをご覧ください。

Amazon EC2 など、他のアマゾン ウェブ サービスの利用料金も、これらのリソースの発行料金として適用されます。VPC インターネットゲートウェイを介して Amazon S3 のようなアマゾン ウェブ サービスへアクセスする場合は、データ転送料は発生しません。

VPN 接続を介して AWS リソースにアクセスする場合は、インターネットデータ転送料金が発生します。

Amazon VPC は以下に接続できます。

• インターネット (インターネットゲートウェイ経由)
• AWS サイト間 VPN 接続を使用する、お客様の自社データセンター (仮想プライベートゲートウェイ経由)
• インターネットとお客様の自社データセンターの両方 (インターネットゲートウェイと仮想プライベートゲートウェイの両方を利用)
• (インターネットゲートウェイ、NAT、仮想プライベートゲートウェイ、VPC エンドポイント経由での) その他の AWS のサービス
• その他の Amazon VPC (VPC ピアリング接続経由)

Amazon VPC はインターネットゲートウェイの作成をサポートしています。このゲートウェイにより、VPC 内の Amazon EC2 インスタンスは直接インターネットにアクセスすることができます。また、ステートフルゲートウェイである送出専用インターネットゲートウェイを使用して、VPC からインターネットへの IPv6 に送出専用のアクセスを提供することもできます。

インターネットゲートウェイは水平にスケーリングされるため、冗長性と高可用性を達成できます。帯域幅制限はありません。

VPC 内のインスタンスは、Elastic IP アドレス (EIP) や IPv6 Global Unique アドレス (GUA) などのパブリック IP アドレスを使って、直接インターネットへ発信することも、インターネットからのトラフィックを受信 (例えば、ウェブサーバー) することもできます。次の質問に対する回答も参考になるでしょう。

VPC でホストされているインスタンスやサービスに割り当てられ、インターネット経由でアクセス可能な IP アドレスはすべてパブリック IP アドレスとみなされます。インターネットでルーティング可能なのは、Elastic IP アドレス (EIP) や IPv6 GUA を含むパブリック IPv4 アドレスのみです。そのためには、まず VPC をインターネットに接続し、ルートテーブルを更新してインターネットから/に到達可能な状態にする必要があります。

パブリック IP アドレスがないインスタンスは、2 つの方法のうちのいずれかでインターネットにアクセスすることができます。

1. パブリック IP アドレスがないインスタンスは、NAT ゲートウェイや NAT インスタンスを通してトラフィックをルーティングし、インターネットにアクセスできます。こういったインスタンスは、NAT ゲートウェイや NAT インスタンスのパブリック IP アドレスを使って、インターネットに接続します。NAT ゲートウェイや NAT インスタンスは外向きの通信を許可しますが、インターネットのマシンがプライベートにアドレスを付与されたインスタンスへの接続を開始することは許可しません。
2. ハードウェア VPN 接続や Direct Connect 接続を使用する VPC の場合、インスタンスからのインターネットトラフィックは、仮想プライベートゲートウェイ経由でお客様の既存のデータセンターにルーティングできます。そこから (必要があれば) 既存のネットワークセキュリティ/モニタリングデバイスを経由してインターネットにアクセスすることができます。

はい。サードパーティ製のソフトウェア VPN を使用して、インターネットゲートウェイを介する VPC により、サイトからサイトのまたはリモートアクセスの VPN 接続を作成できます。

いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。

さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。 

AWS サイト間 VPN 接続では、VPC をお客様のデータセンターに接続します。Amazon では、インターネットプロトコルセキュリティ (IPSec: Internet Protocol security) VPN 接続をサポートしています。VPC とデータセンター間で転送されるデータは、転送中データの機密性と整合性を維持するために、暗号化された VPN 接続を介してルーティングします。インターネットゲートウェイで、AWS サイト間 VPN 接続を確立する必要はありません。

プライマリ 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 に割り当てることができます。

デフォルトの VPC は CIDR 範囲 172.31.0.0/16 に割り当てられます。デフォルト VPC 内のデフォルトサブネットは、その VPC の CIDR 範囲内の /20 ネットブロックに割り当てられます。 

はい、お客様のパブリック IPv4 アドレスと IPv6 GUA アドレスを AWS VPC に取り入れて、スタティックにサブネットや EC2 インスタンスに割り当てることができます。インターネットからこれらのアドレスにアクセスするには、ご自身のオンプレミスネットワークにアドバタイズしなければなりません。AWS DX または AWS VPN 接続を利用してお客様の VPC とオンプレミスネットワーク間でこれらのアドレスにトラフィックをルーティングする必要もあります。Virtual Private Gateway を用いてお客様の VPC からトラフィックをルーティングできます。同様に、お客様のルーターを用いてお客様のオンプレミスネットワークからお客様の VPC までトラフィックを戻すこともできます。

現在、Amazon VPC では 5 つの IP アドレス範囲 (IPv4 の 1 つのプライマリと 4 つのセカンダリ) がサポートされています。これらの各範囲のサイズは、CIDR 表記で /28～/16 となります。VPC の IP アドレス範囲と既存ネットワークの IP アドレス範囲を重複させることはできません。

IPv6 の場合、VPC のサイズは /56 (CIDR 表記法) に固定されています。IPv4 と IPv6 両方の CIDR ブロックを同じ VPC に関連付けることができます。

はい。既存の VPC を拡張するには、4 つのセカンダリ IPv4 IP 範囲 (CIDR) を VPC に追加します。VPC を縮小するには、VPC に追加したセカンダリ CIDR ブロックを削除します。  同様に、追加で最大 5 つの IPv6 IP レンジ (CIDR) を VPC に追加することができます。  これらの追加した範囲を削除することで、VPC を縮小することができます。

現在、VPC ごとに 200 のサブネットを作成できます。さらに作成する場合は、サポートセンターにケースを送信します。

IPv4 の場合、サブネットの最小サイズは /28 (または 14 個の IP アドレス) です。サブネットを、それらが作成された VPC より大きくすることはできません。

IPv6 の場合、サブネットのサイズは /64 に固定されています。サブネットに割り当て可能なのは IPv6 CIDR ブロック 1 つのみです。

いいえ。各サブネットにおいて、Amazon が先頭の 4 つの IP アドレスを確保し、最後の 1 つの IP アドレスは、IP ネットワーキングの目的で確保されます。

IPv6 専用ではないサブネット内で Amazon EC2 インスタンスを起動する際に、インスタンスのプライマリプライベート IPv4 アドレスをオプションで指定できます。プライマリプライベート IPv4 アドレスを指定しない場合は、お客様が指定したサブネットの IPv4 アドレス範囲から AWS が自動的にアドレスを割り当てます。セカンダリプライベート IPv4 アドレスは、インスタンスを起動する際、Elastic Network Interface を作成する際、またはインスタンス起動後やインターフェイス作成後に割り当てることができます。IPv6 のみのサブネット内で Amazon EC2 インスタンスを起動した場合、AWS は自動的にそのサブネットの Amazon 提供の IPv6 GUA CIDR からアドレスを取得します。インスタンスの IPv6 GUA は、適切なセキュリティグループ、NACL、およびルートテーブルの設定でインターネットから/に到達可能にしない限り、プライベートなままです。

IPv4 またはデュアルスタックのサブネットで起動されたインスタンスの場合、プライマリプライベート IPv4 アドレスは、インスタンスまたはインターフェイスのライフタイムの間保持されます。セカンダリプライベート IPv4 アドレスはいつでも、割り当て、割り当て解除、またはインターフェイスやインスタンスの間で移動可能です。IPv6 のみのサブネットで起動されたインスタンスの場合、インスタンスのプライマリネットワークインターフェイスの最初の IP アドレスでもある割り当てられた IPv6 GUA は、新しい IPv6 GUA を関連付けたり、既存の IPv6 GUA を削除したりして、いつでも変更することができます。

いいえ。実行中のインスタンスに割り当てられている IPv4 アドレスは、実行中のインスタンスが「終了」状態になってから別のインスタンスでのみ再利用できます。ただし、実行中のインスタンスに割り当てられた IPv6 GUA は、最初のインスタンスから削除された後、別のインスタンスで再び使用することができます。

いいえ。インスタンスを起動する時は、1 つのインスタンスに対してのみ IP アドレスを指定できます。

インスタンスが以下の条件を満たしていれば、どのような IP アドレスでも割り当てることができます。

• サブネットの IP アドレス範囲の一部である
• IP ネットワーク用に Amazon がリザーブしていない
• 別のインターフェイスに割り当てられていない

はい。Amazon VPC の Elastic Network Interface や EC2 インスタンスに、1 つまたは複数のセカンダリプライベート IP アドレスを割り当てることができます。割り当て可能なセカンダリプライベート IP アドレスの数は、インスタンスタイプにより異なります。インスタンスタイプごとの割り当て可能なセカンダリプライベート IP アドレスの数については、EC2 ユーザーガイドを参照してください。

はい。しかし、EIP アドレスはインターネットからのみアクセスできます (VPN 接続ではできません)。EIP アドレスはそれぞれ、インスタンスの一意のプライベート IP アドレスに関連付けられる必要があります。EIP アドレスは、インターネットゲートウェイに直接トラフィックをルーティングするように構成されたサブネット内のインスタンスでのみ使用する必要があります。NAT ゲートウェイまたは NAT インスタンスを使用してインターネットにアクセスするよう設定されたサブネット内にあるインスタンスでは、EIP を使用できません。これは IPv4 にのみ適用されます。現時点で、Amazon VPC で IPv6 の EIP はサポートされていません。

Bring Your Own IP (BYOIP) は、お客様が既存のパブリックルーティング可能な IPv4 または IPv6 アドレス空間の一部または全体を、AWS リソースとの使用のために AWS に移動させることを可能にします。お客様は引き続き IP 範囲を所有します。お客様は、AWS に持ち込む IPv4 空間から Elastic IP を作成でき、それらを EC2 インスタンス、NAT ゲートウェイ、および Network Load Balancers で使用できます。AWS に持ち込む IPv6 空間から最大 5 つの CIDR を VPC に関連付けることもできます。お客様は、引き続き Amazon 提供の IP にアクセスでき、BYOIP Elastic IP、Amazon 提供の IP、またはその両方の使用を選択できます。

自身の IP アドレスを AWS に持ち込むには以下の理由があります:
IP レピュテーション: お客様の多くは、その IP アドレスのレピュテーションを戦略的資産と見なし、これらの IP をそのリソースと共に AWS で使用したいと考えておられます。例えば、アウトバウンドメール MTA などのサービスを提供して評価の高い IP をお持ちの顧客は、その IP スペースを持ち込んで既存の送信成功率を維持できるようになりました。

お客様のホワイトリスト登録: BYOIP は、お客様が新しい IP アドレスでホワイトリストを再確立する必要なく、IP アドレスのホワイトリスト登録に依存するワークロードを AWS に移させることも可能にします。

ハードコーディングされた依存関係: お客様の中には、デバイスにハードコーディングされた IP がある、またはアーキテクチャ面でその IP に依存するお客様がおられます。BYOIP は、このようなお客様が AWS に簡単に移行できるようにします。

規制とコンプライアンス: 規制およびコンプライアンス上の理由により、多くのお客様に特定の IP の使用が義務付けられています。これらも、BYOIP で解決できます。

オンプレミス IPv6 ネットワークポリシー: 多くのお客様は、オンプレミスネットワークで IPv6 のみをルーティングできます。これらのお客様は、独自の IPv6 範囲を VPC に割り当て、インターネットまたは Direct Connect を使用してオンプレミスネットワークにルーティングすることを選択できるため、BYOIP によってロック解除されます。

BYOIP Elastic IP を解放すると、その IP は割り当て元の BYOIP IP プールに戻されます。

BYOIP を利用できるリージョンの詳細については、のドキュメントを参照してください。

はい。BYOIP プレフィックスは、同じアカウント内の任意の数の VPC で使用できます。

最大 5 つの IP 範囲をお使いのアカウントに持ち込めます。

BYOIP を介して取得できる最も具体的な IPv4 プレフィックスは、/24 IPv4 プレフィックスと /56 IPv6 プレフィックスです。IPv6 プレフィックスをインターネットにアドバタイズする場合、最も具体的な IPv6 プレフィックスは /48 です。

ARIN、RIPE、および APNIC 登録のプレフィックスをご使用いただけます。

現時点では再配置または再割り当てされてプレフィックスは受け付けていません。IP 範囲はネットタイプの直接割り当てまたは直接配置である必要があります。

はい。これは、BYOIP プレフィックスを現在のリージョンからプロビジョニング解除して、その後新しいリージョンにプロビジョニングすることによって実行できます。

Amazon VPC IP アドレス Manager (IPAM) は AWS ワークロードの IP アドレスの計画、追跡、モニタリングを簡単にするマネージドサービスです。VPC IPAM を使用すれば、ルーティングやセキュリティのニーズに基づいて IP アドレスを簡単に整理し、IP アドレスの割り当てを管理するためのシンプルなビジネスルールを設定できます。また、VPC への IP アドレスの割り当てを自動化することにより、保守が困難で時間のかかるスプレッドシートベースのアプリケーションや IP アドレスの使用を計画する自社開発アプリケーションを使う必要はなくなります。IPAM は統一された運用ビューを提供し、単一の真実のソースとして使用できるため、IP 利用率の追跡、トラブルシューティング、監査などの日常の IP アドレス管理活動を迅速かつ効率的に行うことができます。

IPAM を使用して、IP アドレスの管理を効率化する必要があります。表計算ソフトや自作ツールを活用した既存の仕組みでは、手作業が必要で、ミスが発生しやすいです。例えば、IPAM を使えば、開発者は中央の IP アドレス管理チームが IP アドレスを割り当てるのを待つ必要がなくなるので、アプリケーションをより迅速に展開することができます。また、重複する IP アドレスを検出し、ネットワーク障害が発生する前に修正することも可能です。さらに、IPAM のアラームを作成し、アドレスプールが枯渇しそうになった場合や、リソースがプールに設定された割り当てルールに従わなかった場合に通知することができます。これらは、IPAM を使用すべき多くの理由の一部です。

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 は VPC の割り当てのために連続した IPv6 CIDR ブロックを提供します。連続した CIDR ブロックは、ネットワークとセキュリティのコンストラクト (アクセスコントロールリスト、ルートテーブル、セキュリティグループ、ファイアウォールなど) で CIDR を単一のエントリに集約します。Amazon IPv6 CIDR をパブリック・スコープ・プールにプロビジョニングし、IPAM の全機能を使用して IP の使用状況を管理および監視することができます。これらの CIDR ブロックの割り当ては、/52 単位で開始され、要望に応じてより大きなブロックが利用可能です。例えば、Amazon から /52 CIDR を割り当て、IPAM を使用してアカウント間で共有し、そのアカウントに VPC を作成することができます。

いいえ、Amazon Provided Contiguous IPv6 CIDR ブロックは、現在 IPAM でのみサポートされています。

AWS Resource Access Manager(RAM) を使用して、AWS 組織内の他のアカウントと IPAM プールを共有することができます。また、プライマリ AWS 組織以外のアカウントと IPAM プールを共有することも可能です。そのようなアカウントの例として、社内の別の事業部門を代表するアカウントや、パートナー企業が他の AWS 組織で自社の代わりにホストするマネージドサービスを代表するアカウントが挙げられます。

はい。各サブネットごとにデフォルトルートを作成することができます。このデフォルトルートによって、VPC から出るトラフィックをインターネットゲートウェイ、仮想プライベートゲートウェイ、または NAT ゲートウェイ経由で送信できます。

Amazon EC2 セキュリティグループを、Amazon VPC 内のセキュリティで保護されたインスタンスをよりセキュアにするために使用することができます。VPC 内のセキュリティグループにより、各 Amazon EC2 インスタンスにおける着信および発信両方のネットワークトラフィックを指定することができます。明示的に許可されていないトラフィックは自動的に拒否されます。

セキュリティグループに加えて、各サブネットに出入りするネットワークトラフィックは、ネットワークアクセスコントロールリスト (ACL) を使用して許可または拒否することができます。

VPC 内のセキュリティグループは、どのトラフィックが Amazon EC2 インスタンスへ、または Amazon EC2 インスタンスから許可されるかを指定します。ネットワーク ACL は、サブネットレベルで動作し、サブネットへ出入りするトラフィックを検証します。ネットワーク ACL は、許可ルールと拒否ルールの両方を設定するのに使用することができます。ネットワーク ACL は、同じサブネット内のインスタンス間のトラフィックをフィルタリングしません。加えて、ネットワーク ACL はステートレス フィルタリングを実行する一方、セキュリティグループはステートフル フィルタリングを実行します。

ステートフルフィルタリングでは、リクエスト元を追跡し、リクエストに対する応答が自動的に元のコンピュータに戻るようにできます。例えば、ウェブサーバーで tcp ポート 80 の着信トラフィックを許可するステートフルフィルタでは、通常、さらに若い番号のポート (例: 送信先 tcp ポート 63、912) でクライアントとウェブサーバー間のステートフルフィルタを通過するリターントラフィックが許可されます。フィルタリングデバイスでは、送信元ならびに送信先ポート番号と IP アドレスを追跡するステートテーブルが維持されます。フィルタリングデバイスで必要とされるルールは、tcp ポート 80 でウェブサーバーへの着信トラフィックを許可することのみです。

一方ステートレスフィルタリングは、トラフィックが新しいリクエストであるか、またはリクエストへの応答であるかにかかわりなく、送信元または送信先 IP アドレスおよび送信先ポートのみを確認します。上記の例ではフィルタリングデバイスに、tcp ポート 80 でウェブサーバーへの着信トラフィックを許可するルールと、ウェブサーバーからの発信トラフィックを許可するルール (tcp ポート範囲 49、152 から 65、535) の、2 つのルールを実装する必要があります。

はい。インターネットゲートウェイが設定されている場合は、VPC 内にない Amazon EC2 インスタンス宛ての Amazon VPC 内からのトラフィックは、インターネットゲートウェイを通過して、パブリック AWS ネットワークに入り EC2 インスタンスへ到達します。インターネットゲートウェイが設定されていない場合や、インスタンスが属するサブネットが仮想プライベートゲートウェイを介してルーティングするように設定されている場合は、トラフィックは VPN 接続を通過し、お客様のデータセンターから出て、パブリックの AWS ネットワークに再び入ります。

はい。あるリージョンのインスタンスは、インターリージョン VPC ピアリング、パブリック IP アドレス、NAT ゲートウェイ、NAT インスタンス、VPN 接続、または Direct Connect 接続を使用して相互に通信できます。

はい。VPC 内のリソースが Amazon S3 と通信するためのオプションは複数あります。S3 用 VPC エンドポイントを使うと、すべてのトラフィックが確実に Amazon のネットワーク内に残り、Amazon S3 トラフィックに他のアクセスポリシーを適用できます。インターネットゲートウェイを使うと、VPC からのインターネットアクセスが可能となり、VPC のインスタンスと Amazon S3 の通信が可能となります。また、Amazon S3 へのすべてのトラフィックが Direct Connect または VPN 接続を通過し、データセンターを出てから再びパブリック AWS ネットワークに入るようにできます。

はい。Amazon VPC トラフィックミラーリングと Amazon VPC フローログの機能を使用して、Amazon VPC 内のネットワークトラフィックをモニタリングできます。

VPC フローログは、VPC 内のネットワークインターフェイス間で送信される IP トラフィックに関する情報を取得できるようにする機能です。フローログデータは、Amazon CloudWatch Logs または Amazon S3 のいずれかに発行できます。VPC フローログをモニタリングし、ネットワークの依存関係とトラフィックパターンの運用上の可視性を取得したり、異常を検出してデータ漏洩を防止したり、ネットワーク接続と設定の問題をトラブルシューティングしたりできます。フローログの強化されたメタデータは、TCP 接続を開始したユーザー、および NAT ゲートウェイなどの中間層を流れるトラフィックの実際のパケットレベルの送信元と送信先に関する洞察をさらに得るのに役立ちます。コンプライアンス要件を満たすためにフローログをアーカイブすることもできます。VPC フローログに関する詳細については、ドキュメントを参照してください。

VPC、サブネット、またはネットワークインターフェイスのフローログを作成できます。サブネットまたは VPC のフローログを作成すると、そのサブネットまたは VPC 内の各ネットワークインターフェイスがモニタリングされます。フローログサブスクリプションの作成中に、キャプチャするメタデータフィールド、最大集計間隔、およびログの優先的な送信先を選択できます。すべてのトラフィックをキャプチャするか、承認または拒否されたトラフィックのみをキャプチャするかを選択することもできます。CloudWatch Log Insights や CloudWatch Contributor Insights などのツールを使用して、CloudWatch Logs に配信された VPC フローログを分析できます。Amazon Athena や AWS QuickSight などのツールを使用して、Amazon S3 に配信された VPC フローログをクエリして視覚化できます。カスタムダウンストリームアプリケーションを構築してログを分析したり、Splunk、Datadog、Sumo Logic、Cisco StealthWatch、Checkpoint CloudGuard、New Relic などのパートナーのソリューションを使用したりすることもできます。

はい、Transit Gateway または個々の Transit Gateway アタッチメントの VPC フローログを作成することができます。この機能により、Transit Gateway を経由するネットワークフローについて、送信元/送信先 IP、ポート、プロトコル、トラフィックカウンター、タイムスタンプ、各種メタデータなどの詳細情報をエクスポートできます。Transit Gateway の Amazon VPC フローログのサポートについては、ドキュメントを参照してください。

フローログデータはネットワークトラフィックのパスの外部で収集されるため、ネットワークのスループットやレイテンシーには影響しません。ネットワークパフォーマンスに影響を与えるリスクなしに、フローログを作成または削除できます。

フローログを CloudWatch Logs または Amazon S3 に発行する場合、Vended Logs のデータ取得とアーカイブ料金が適用されます。詳細と例については、Amazon CloudWatch の料金をご覧ください。コスト割り当てタグを使用して、フローログの発行から料金を追跡することもできます。

Amazon VPC トラフィックミラーリングを使用すると、お客様は Amazon EC2 インスタンスとの間のネットワークトラフィックをレプリケートし、帯域外のセキュリティおよびモニタリングアプライアンスに転送して、コンテンツ検査、脅威のモニタリング、トラブルシューティングなどのユースケースを実現できるようになります。こうしたアプライアンスは、個々の Amazon EC2 インスタンス、または User Datagram Protocol (UDP) リスナーを使用する Network Load Balancer (NLB) の後ろにあるインスタンスフリートにデプロイできます。

トラフィックミラーリングでは、EC2 インスタンスの Elastic Network Interface (ENI) レベルでネットワークパケットをキャプチャします。Amazon VPC トラフィックミラーリングをサポートする EC2 インスタンスについては、トラフィックミラーリングのドキュメントを参照してください。

お客様はオープンソースのツールを使用することも、AWS Marketplace で入手できる幅広いモニタリングソリューションの中から選ぶこともできます。トラフィックミラーリングを使用すると、任意のネットワークパケットコレクタ/ブローカーまたは分析ツールへのレプリケートされたトラフィックストリームが可能になります。この際、ベンダー指定のエージェントをインストールする必要はありません。

Amazon VPC フローログでは、ネットワークフローログを収集、保存、分析できます。フローログでキャプチャされる情報には、許可/拒否されたトラフィック、送信元と送信先の IP アドレス、ポート、プロトコル番号、パケット数とバイト数、アクション (許可または拒否) に関する情報などがあります。この機能を使用すると、接続やセキュリティの問題のトラブルシューティングを実行したり、ネットワークアクセスルールが正常に機能しているかを確認したりできます。

Amazon VPC トラフィックミラーリングでは、ペイロードといった実際のトラフィックコンテンツを分析できるため、ネットワークトラフィックに関する深い理解を得ることができます。対象となるユースケースには、実際のパケットを分析してパフォーマンスの問題の根本原因を究明したり、複雑なネットワーク攻撃のリバースエンジニアリング作業を行ったり、内部者による不正使用やワークロードの侵害を検出および阻止したりする必要がある場合が挙げられます。

Amazon VPC は現在、すべての Amazon EC2 リージョンにおいて、複数のアベイラビリティーゾーンでご利用になれます。

はい。 

いいえ。サブネットは、単一のアベイラビリティーゾーン内に存在している必要があります。

Amazon EC2 インスタンスを起動する際には、インスタンスを起動するサブネットを指定する必要があります。インスタンスは、指定されたサブネットに関連付けられているアベイラビリティーゾーンで起動します。

サブネットを作成する際には、サブネットを配置するアベイラビリティーゾーンを指定する必要があります。VPC ウィザードを使用する場合は、ウィザードの確認画面でサブネットのアベイラビリティーゾーンを選択します。API または CLI を使用する場合は、サブネットを作成する際にサブネットのアベイラビリティーゾーンを指定します。アベイラビリティーゾーンを指定しないと、デフォルトの「プレファレンスなし」のオプションが選択され、サブネットはリージョン内の利用可能なアベイラビリティーゾーンで作成されることになります。

インスタンスが異なるアベイラビリティーゾーン内のサブネットにある場合は、お客様にはデータ転送料として 1 GB あたり 0.01 USD が請求されます。

はい。DescribeInstances() は、実行中のすべての Amazon EC2 インスタンスを返します。EC2-Classic インスタンスと EC2-VPC インスタンスを区別するには、サブネットフィールドの内容を見ます。サブネット ID が記載されていれば、そのインスタンスは VPC 内にあります。

はい。DescribeVolumes() は、すべての EBS ボリュームを返します。

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 リージョンおよびアベイラビリティーゾーンのよくある質問で、詳細な情報をご覧いただけます。

はい。ただし、Amazon EBS-backed AMI を使用して VPC で起動されたインスタンスは、停止と再起動時に、同一の IP アドレスを維持します。これは、VPC の外で起動される同様のインスタンスが新しい IP アドレスを取得するのとは対照的です。サブネットの停止したインスタンスの IP アドレスは、利用不可能とみなされます。

はい。

はい。 

はい。Amazon VPC ではクラスターインスタンスをサポートしますが、インスタンスタイプによっては、一部のリージョンおよびアベイラビリティーゾーンで使用できない場合があります。

インスタンスを起動すると、そのインスタンスにはホスト名が割り当てられます。IP ベースの名前とリソースベースの名前の 2 つのオプションがあり、このパラメータはインスタンス起動時に設定可能です。IP ベースの名前はプライベート IPv4 アドレスの形式を使用し、リソースベースの名前は instance-id の形式を使用します。

はい、インスタンスを停止して、リソースベースの命名オプションを変更することで、IP ベースからリソースベース、またはその逆の形式でインスタンスのホスト名を変更できます。

はい、インスタンスホスト名は DNS のホスト名として使用できます。IPv4 のみまたはデュアルスタックのサブネットで起動されたインスタンスの場合、IP ベースの名前は常にインスタンスのプライマリネットワークインターフェイス上のプライベート IPv4 アドレスに解決され、これをオフにすることはできません。また、リソースベースの名前は、プライマリネットワークインターフェイス上のプライベート IPv4 アドレス、プライマリネットワークインターフェイス上の最初の IPv6 GUA のいずれか、または両方に解決するように設定できます。IPv6 のみのサブネットで起動したインスタンスでは、リソースベースの名前はプライマリネットワークインターフェイス上の最初の IPv6 GUA に解決するように設定されます。 

デフォルト VPC とは、AWS アカウントで初めて Amazon EC2 リソースをプロビジョニングするとき自動的に作成される、論理的に隔離された仮想ネットワークです。サブネット ID を指定せずにインスタンスを起動すると、そのインスタンスはデフォルト VPC 内に起動します。

リソースをデフォルト VPC 内に起動すると、Amazon VPC (EC2-VPC) の持つ先進的なネットワーキング機能の恩恵を、Amazon EC2 (EC2-Classic) の手軽さで得ることができます。例えば、実行中のインスタンスのセキュリティグループ変更、セキュリティグループによる出力フィルタリング、マルチ IP アドレス、マルチネットワークインターフェイスなどの機能を、明示的に VPC を作成してその VPC にインスタンスを起動するという手間をかけずに利用可能です。

2013 年 3 月 18 日以降に作成された AWS アカウントであれば、デフォルト VPC 内でリソースを起動できます。どのリージョンでデフォルト VPC の機能が有効になっているかを確認するには、こちらのフォーラムでのお知らせをご覧ください。また、上記の日時より前に作られたアカウントであっても、デフォルト VPC が有効なリージョンのうち、これまでに EC2 インスタンスの起動や Elastic Loadbalancing、Amazon RDS、Amazon ElastiCache、Amazon Redshift などのリソースのプロビジョニングをしたことがないリージョンの中であれば、デフォルト VPC を利用できます。

いいえ。デフォルト VPC 内で EC2 インスタンスなどの AWS リソースの起動や管理を行うには、AWS マネジメントコンソール、AWS EC2 CLI、Amazon EC2 API を使用できます。指定された AWS リージョンに対し、AWS が自動的にデフォルト VPC を作成し、各アベイラビリティーゾーンにデフォルトサブネットを作成します。デフォルト VPC はインターネットゲートウェイに接続され、お客様のインスタンスには、EC2-Classic と同様、自動的にパブリック IP アドレスが割り当てられます。

EC2 ユーザーガイドの EC2-Classic と EC2-VPC の違いをご覧ください。

いいえ。デフォルト VPC はインターネットに接続されており、デフォルト VPC のデフォルトサブネット内で起動するインスタンスにはすべて自動的にパブリック IP アドレスが割り当てられます。必要に応じて VPN 接続を追加することも可能です。

はい。デフォルトでない VPC にインスタンスを起動する場合は、インスタンスを起動する時にサブネット ID を指定してください。

はい。デフォルトでないサブネット内に起動する場合は、コンソール (または CLI、API、SDK から --サブネットオプション) を使って起動先を指定します。

Supported-Platforms の属性が「EC2-VPC」になっている AWS リージョンごとに 1 つ所有できます。

デフォルトサブネットはデフォルト VPC 内の各アベイラビリティーゾーンに 1 つ作成されます。

現時点では使用できません。

現時点では使用できません。

はい。デフォルト VPC を削除できます。削除したら VPC コンソールから直接、または CLI を使用して新しいデフォルト VPC を作成できます。これによりリージョン内に新しいデフォルト VPC が作成されます。削除された以前の VPC は復旧できません。

はい。デフォルトサブネットを削除できます。削除後、CLI または SDK を使用して、そのアベイラビリティーゾーンに新しいデフォルトサブネットを作成できます。こうして、指定されたアベイラビリティーゾーンに新しいデフォルトサブネットが作成されます。削除された以前のサブネットは復旧できません。

デフォルト VPC を利用する最も簡単な方法は、デフォルト VPC が有効なリージョンに新しくアカウントを作ることです。既存のアカウントでも、これまで利用したことがなく Supported-Platforms の属性が「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 の利用状況を確認したうえで、今後の対応についてご連絡いたします。

AWS アカウントがデフォルト VPC を使う設定になっている場合、その AWS アカウントに関連付けられた IAM アカウントはすべて、AWS アカウントと同じデフォルト VPC を使用します。

EC2-Classic とは、2006 年夏に EC2 とともに開始したフラットネットワークです。EC2-Classic では、インスタンスは、他のお客様と共有する単一のフラットなネットワーク上で実行されます。その後、お客様のニーズの高まりを受けて、2009 年に Amazon Virtual Private Cloud (VPC) を開始し、AWS アカウントから論理的に分離された仮想プライベートクラウドでインスタンスを実行できるようになりました。現在では、大半のお客様が Amazon VPC を利用していますが、EC2-Classic を利用しているお客様も少数ながらいらっしゃいます。

2022 年 8 月 15 日に Amazon EC2-Classic を使用停止にしますので、この日までに EC2-Classic 上で稼働している EC2 インスタンスやその他の AWS リソースを Amazon VPC に移行していただく必要があります。次のセクションでは、EC2-Class の使用停止に関する詳細情報と、移行を支援するツールやリソースをご紹介します。

この変更の影響を受けるのは、いずれかの AWS リージョンのアカウントで EC2-Classic を有効にしている場合のみです。AWS リージョンで EC2-Classic が有効になっているかどうかは、コンソールまたは describe-account-attributes コマンドを使用して確認することができます。詳細はこちらのドキュメントをご参照ください。

EC2-Classic 上で稼働している AWS リソースがない場合は、そのリージョンのアカウントから EC2-Classic をオフにするようお願いします。リージョン内の EC2-Classic をオフにすると、そこにデフォルト VPC を起動することができます。これを行うには、AWS Support Center console.thinkwithwp.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 のサービスを使用停止にするため、徐々にアクセスできなくなります。

はい。

ネットワークインターフェイスをアタッチできるインスタンスは、同じアベイラビリティーゾーンに存在するものに限られます。

ネットワークインターフェイスは、同じアカウント内の VPC のインスタンスにのみアタッチできます。

はい。ただし、これは複数インターフェイスの使い方として最適なものではありません。代わりに、追加のプライベート IP アドレスをインスタンスに割り当ててから、必要に応じて EIP をプライベート IP に関連付けます。

いいえ。EC2 インスタンスの 2 つ目のインターフェイス (eth1-ethn) はアタッチとデタッチができますが、eth0 インターフェイスのデタッチはできません。

はい。ピアリング接続は、異なるリージョンの VPC を使用して作成できます。 リージョン間の VPC ピアリングは、世界中すべての商用リージョンで利用できます (中国を除く)。

はい。相手の VPC のオーナーがピアリング接続要求を受け入れれば可能です。

VPC ピアリング接続の作成に費用はかかりませんが、ピアリング接続間のデータ転送には料金が発生します。データ転送料金については、EC2 料金ページのデータ転送セクションを参照してください。

いいえ。VPC ピアリング接続にインターネットゲートウェイは不要です。

いいえ。ピアリング接続された VPC 内のインスタンス間のトラフィックはプライベートであり隔離されています。同じ VPC 内の 2 つのインスタンス間のトラフィックがプライベートで隔離されているのと同じです。

いいえ。ピアリング接続のいずれか一方は、いつでもピアリング接続を停止できます。ピアリング接続を停止すると、その 2 つの VPC 間のトラフィックも停止します。

いいえ。推移的ピアリング関係には対応していません。

AWS では VPC の既存のインフラストラクチャを使用して VPC ピアリング接続を作成しています。これはゲートウェイでも VPN 接続でもなく、個別の物理ハードウェアに依存するものではありません。通信の単一障害点や帯域幅のボトルネックは存在しません。

インターリージョン VPC ピアリングは、現在 VPC に使用されているものと同じ、水平スケーリング、冗長化、高可用性を持ったテクノロジーを使って動作します。インターリージョン VPC ピアリングトラフィックは、冗長性と動的帯域幅割り当てを内蔵している AWS バックボーンを経由します。通信に単一の障害点はありません。

インターリージョンピアリング接続がダウンすると、トラフィックはインターネット経由でルーティングされません。

ピアリング接続されたインスタンス間の帯域幅は、同じ VPC 内のインスタンス間の帯域幅と同じです。注: プレイスメントグループをピアリング接続した VPC に設定することもできますが、ピアリング接続した VPC 内のインスタンス間では全二重帯域幅を使用できません。プレイスメントグループの詳細についてはこちらをご覧ください。

トラフィックは、最新の AEAD (Associated Data with Associated Data) アルゴリズムを使用して暗号化されます。キーの共有とキーの管理は AWS によって処理されます。

既定では、別のリージョンのピア VPC 内のインスタンスのパブリックホスト名のクエリはパブリック IP アドレスに解決されます。Route 53 プライベート DNS を使用して、インターリージョン VPC ピアリングでプライベート IP アドレスに解決できます。

いいえ。セキュリティグループは、インターリージョン VPC ピアリング接続で参照することはできません。

はい。インターリージョン VPC ピアリングは IPv6 をサポートしています。

いいえ。インターリージョンでの VPC ピア接続は EC2-ClassicLink ではできません。

Amazon Virtual Private Cloud (VPC) ClassicLink により、EC2-Classic プラットフォーム内の EC2 インスタンスがプライベート IP アドレスを使用して VPC 内のインスタンスと通信できるようになります。ClassicLink を使用するには、ユーザーのアカウントで ClassicLink を VPC に対して有効にし、VPC のセキュリティグループを EC2-Classic 内のインスタンスと関連付けます。VPC セキュリティグループのルールはすべて、EC2-Classic 内のインスタンスと VPC 内のインスタンスの間の通信に適用されます。 

ClassicLink を使用するのに追加料金はかかりませんが、現在設定されているアベイラビリティーゾーン間のデータ転送料金が適用されます。詳細については、EC2 の料金表のページをご覧ください。

ClassicLink を使用するには、まずユーザーのアカウントで少なくとも 1 つの VPC を ClassicLink に対して有効にする必要があります。次に、VPC のセキュリティグループを EC2-Classic インスタンスと関連付けます。これで、EC2-Classic インスタンスは VPC とリンクされ、VPC 内で選択されたセキュリティグループのメンバーになります。EC2-Classic インスタンスを複数の VPC と同時にリンクさせることはできません。

EC2-Classic インスタンスは VPC のメンバーにはなりません。代わりに、そのインスタンスに関連づけられた VPC セキュリティグループのメンバーになります。その VPC セキュリティグループに対するルールやリファレンスはすべて、EC2-Classic インスタンスと VPC 内のリソースの間の通信に適用されます。

いいえ。EC2-Classic インスタンスからクエリした場合、EC2 パブリック DNS ホスト名は EC2-VPC インスタンスのプライベート IP アドレスに解決しません。その逆も同様です。

はい。クラスレスドメイン間ルーティング (CIDR) が 10.0.0.0/8 の範囲内である場合、その VPC に対して ClassicLink を有効にすることはできません (ただし、10.0.0.0/16 と 10.1.0.0/16 を除く)。さらに、ルートテーブルに 10.0.0.0/8 CIDR 空間をポイントするエントリがある場合、その VPC に対しても ClassicLink を有効にすることができません (ただし、ターゲットが「ローカル」であるものを除く)。

EC2-Classic インスタンスからのトラフィックをルーティングできるのは、VPC 内のプライベート IP アドレスに対してのみです。インターネットゲートウェイ、仮想プライベートゲートウェイ、またはピア接続された VPC など、VPC の外の宛先にルーティングすることはできません。

EC2-Classic プラットフォームの既存のセキュリティグループにより EC2-Classic インスタンスに対して定義されたアクセス制御が、ClassicLink により変更されることはありません。

EC2-Classic インスタンスを停止して開始した場合、ClassicLink の接続は切断されます。そのため、EC2-Classic インスタンスを停止して再開した後に、インスタンスを再度 VPC にリンクさせる必要があります。ただし、インスタンスを再起動しても、ClassicLink の接続は切断されません。

ClassicLink では、EC2-Classic セキュリティグループのルールから VPC セキュリティグループへのリファレンスや、VPC セキュリティグループのルールから EC2-Classic セキュリティグループへのリファレンスが許可されていません。

AWS PrivateLink により、お客様は AWS にホストされたサービスに可用性が高くスケーラブルな方法でアクセスすることができ、どのようなネットワークトラフィックも AWS ネットワークの外に出ることはありません。このサービスのユーザーは、PrivateLink により、Amazon Virtual Private Cloud (VPC) または自社施設から AWS のサービスに、パブリック IP を使用せず、またインターネットを経由する必要なく、サービスにプライベートにアクセスできます。サービスの所有者はその Network Load Balancer を PrivateLink サービスに登録し、他の AWS の顧客にサービスを提供できます。

お客様はサービスのユーザーとして、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 をご覧ください。

はい。お客様施設内のデータセンターのアプリケーションは、AWS Direct Connect を使って Amazon VPC 内のサービスエンドポイントに接続できます。このサービスエンドポイントにより、トラフィックは AWS PrivateLink を使用した AWS のサービスに自動的に転送されます。

はい。AWS マネジメントコンソールを使って VPC、サブネット、ルートテーブル、インターネットゲートウェイ、IPSec VPN 接続などの Amazon VPC オブジェクトを管理できます。さらに、簡単なウィザードを使って VPC を作成できます。

VPC 制限数については、Amazon VPC ユーザーガイドを参照してください。

はい。AWS サポートの詳細については、こちらをクリックしてください。

Amazon VPC を管理するための ElasticFox はもう公式にはサポートされていません。Amazon VPC のサポートは、AWS API、コマンドラインツール、AWS マネジメントコンソール、またサードパーティー製のさまざまなユーティリティから利用できます。