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 ピアリング接続経由)

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

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

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

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

プライマリ 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 ユーザーガイドを参照してください。

自身の 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 を利用できるリージョンの詳細については、のドキュメントを参照してください。

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 の料金をご覧ください。コスト割り当てタグを使用して、フローログの発行から料金を追跡することもできます。

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

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

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

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

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 の利用状況を確認したうえで、今後の対応についてご連絡いたします。

この変更の影響を受けるのは、いずれかの 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 のサービスを使用停止にするため、徐々にアクセスできなくなります。

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

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

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

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

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

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

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

お客様はサービスのユーザーとして、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 マネジメントコンソール、またサードパーティー製のさまざまなユーティリティから利用できます。