VPC の概要とコンポーネント
- 仮想プライベートクラウド (VPC) は、AWS アカウント専用の仮想ネットワークです。これは、AWS クラウド内の他の仮想ネットワークから論理的に分離されます。
- VPC を使用すると、ユーザーは IP アドレス範囲の選択、サブネットの作成、およびルートテーブル、ネットワークゲートウェイ、およびセキュリティ設定の構成を行うことができます。
- VPC のサイジング
- VPCは、2 ^ 16(65536)の IP アドレスを使用可能にする、10.0.0.0/16などのクラスレスインタードメインルーティング (CIDR) ブロックの形式で IP アドレスのセットを必要とする。
- 許可された CIDR ブロックサイズは
- /28 ネットマスク (2 ^ 4-16 利用可能な IP アドレスで最小)
- /16 ネットマスク (最大 2 ^ 16-65536 IP アドレス)
- プライベート (非パブリックルーティング可能) IP アドレスからの CIDR ブロックを割り当てることができます
- 10.0.0.0 – 10.255.255.255 (10/8 プレフィックス)
- 172.16.0.0-172.31.255.255 (172.16/12 プレフィックス)
- 192.168.0.0 – 192.168.255.255 (192.168/16 プレフィックス)
- パブリックにルーティング可能な IP アドレスの範囲を指定できます。ただし、インターネットへの直接アクセスは、現在、VPC 内のパブリックルーティング可能な CIDR ブロックからはサポートされていません
- VPC のサイズを変更できるようになりました。(AWS ブログ記事を読んでください。)
- 各 VPC は、同じ CIDR ブロックで作成された他の VPC とは別のものであり、同じ AWS アカウント内に存在する場合でも
VPC は、同じまたは異なる
- AWS アカウント内の他の VPC との VPC ピア接続を許可します。
- VPC と企業ネットワークまたはホームネットワークとの間の接続は確立することができるが、CIDR ブロックは、例えば、 CIDR
10.0.0.0/16 の VPC は 10.1.0.0/16 企業ネットワークと通信できますが、10.0.37.0/16 企業ネットワークに接続しようとすると接続が切断され、IP アドレスが重複しています。 - VPC では、その中で起動されたインスタンスのテナントオプションを設定できます。既定では、テナントオプションは共有されます。専用オプションが選択されている場合、その中のすべてのインスタンスは、個々のインスタンスのテナント設定をオーバーライドする専用のハードウェア上で起動されます。
- VPC の削除は、VPC 内のすべてのインスタンスを終了し、サブネット、セキュリティグループ、ネットワーク ACL、ルートテーブル、インターネットゲートウェイ、VPC ピア接続、および DHCP オプションなどの VPC を持つすべてのコンポーネントを削除した後でのみ可能です。
IP アドレス
VPC で起動されるインスタンスには、プライベート、パブリック、および Elastic IP アドレスが割り当てられ、ENI (ネットワークインターフェイス) のプロパティがあります。
- プライベート IP アドレス
- プライベート IP アドレスはインターネット経由では到達できず、VPC 内のインスタンス間でのみ通信に使用されます。
- すべてのインスタンスには、サブネットの IP アドレス範囲内のプライベート IP アドレスが既定のネットワークインターフェイスに割り当てられます。
- プライマリ IP アドレスは、インスタンスが停止して再起動され、インスタンスが終了したときにのみ解放される場合でも、その有効期間のネットワークインターフェイスに関連付けられます。
- セカンダリプライベート IP アドレスと呼ばれる追加のプライベート IP アドレスはインスタンスに割り当てることができ、これらは1つのネットワークインターフェイスから別のものに再割り当てできます。
- パブリック IP アドレス
- パブリック IP アドレスはインターネット経由でアクセス可能であり、インスタンスとインターネット間の通信、またはパブリックエンドポイントを持つ他の AWS サービスとの間で使用できます。
- インスタンスへのパブリック IP アドレスの割り当ては、サブネットに対してパブリック IP アドレッシングが有効になっている場合に依存します。
- パブリック IP アドレスは、インスタンスの作成時にパブリック IP アドレッシングを有効にすることによってインスタンスに割り当てることもできますが、これはサブネットのパブリック IP アドレッシング属性を上書きします。
- パブリック IP アドレスは、IP アドレスの AWS プールから割り当てられ、AWS アカウントに関連付けられていないため、インスタンスが停止して再起動または終了したときに解放されます。
- Elastic IP アドレス
- Elastic IP アドレスは、必要に応じてインスタンスに関連付けられ、解除できる静的で永続的なパブリック IP アドレスです。
- Elastic IP アドレスは、リリースされない限り、VPC で割り当てられ、アカウントが所有します。
- ネットワークインターフェイスには、パブリック IP または Elastic ip のいずれかを割り当てることができます。インスタンスを割り当てた場合、既にパブリック IP、Elastic IP、パブリック IP が公開されています。
- Elastic IP アドレスは、同じアカウント内の同じまたは異なる VPC 内にあるインスタンス間で移動できます。
Elastic ネットワークインタフェース (ENI)
- 各インスタンスはデフォルトの Elastic ネットワークインターフェイス (プライマリネットワークインターフェイス eth0) で接続されており、インスタンスからデタッチすることはできません。
- ENI には次の属性を含めることができます
- プライマリプライベート IP アドレス
- 1つまたは複数のセカンダリプライベート IP アドレス
- プライベート IP アドレスごとに1つの Elastic IP アドレス
- 1つのパブリック IP アドレスは、インスタンスを起動すると eth0 のネットワークインターフェイスに自動的に割り当てられますが、デフォルトの ENI を使用する代わりに eth0 用のネットワークインターフェイスを作成する場合にのみ
- 1つ以上のセキュリティグループ
- MAC アドレス
- 送信元/送信先のチェックフラグ
- 説明
- ENI の属性は、インスタンスからアタッチまたはデタッチされ、別のインスタンスに再アタッチするときに、ENI に従います。ENI を別のインスタンスに移動すると、ネットワークトラフィックは新しいインスタンスにリダイレクトされます。
- 複数の ENI をインスタンスにアタッチすることができ、ユースケースに役立ちます。
- 管理ネットワークを作成します。
- VPC でネットワークとセキュリティアプライアンスを使用します。
- 個別のサブネット上にワークロード/ロールを持つデュアルホームインスタンスを作成します。
- 低予算の高可用性ソリューションを作成します。
ルートテーブル
- ルートテーブルは、ルートと呼ばれるルールを定義し、サブネットからのネットワークトラフィックをルーティングする場所を決定します。
- 各 VPC には、ネットワークトラフィックをルーティングするための暗黙のルーターがあります。
- 各 VPC にはメインルートテーブルがあり、複数のカスタムルートテーブルを作成できます。
- VPC 内の各サブネットは一度に1つのルートテーブルに関連付けられている必要がありますが、ルートテーブルには複数のサブネットを関連付けることができます。
- サブネットは、ルートテーブルに明示的に関連付けられていない場合、メインルートテーブルに暗黙的に関連付けられます。
- すべてのルートテーブルには、変更または削除できない VPC 内の通信を可能にするローカルルートが含まれています。
- ルート優先順位は、トラフィックに一致するルートテーブル内の最も特定のルートを照合することによって決定されます。
- ルートテーブルは、インターネットゲートウェイ、仮想プライベートゲートウェイ、VPC ピアリング、VPC エンドポイント、NAT デバイスなどのために定義されたルートに更新する必要があります。
インターネットゲートウェイ – IGW
- インターネットゲートウェイは、VPC とインターネットのインスタンス間の通信を可能にする、水平方向にスケーリングされ、冗長で可用性の高い VPC コンポーネントです。
- IGW は、ネットワークトラフィックに可用性のリスクや帯域幅の制約を課しません。
- インターネットゲートウェイは、次の2つの目的を果たす。
- インターネットでルーティング可能なトラフィックの VPC ルートテーブルにターゲットを提供する
- パブリック IP アドレスが割り当てられているインスタンスのネットワークアドレス変換 (NAT) を実行します。
- インスタンスへのインターネットアクセスを有効にする必要がある
- VPC へのインターネットゲートウェイの接続
- サブネットには、インターネットゲートウェイを指すルートに関連付けられたルートテーブルが必要です
- インスタンスにはパブリック IP または Elastic IP アドレスが割り当てられている必要があります
- インスタンスに関連付けられたセキュリティグループと NACLs は、関連するトラフィックを許可する必要があります
NAT
NAT デバイスは、プライベートサブネット内のインスタンスがインターネットまたは他の AWS サービスに接続できるようにしますが、インターネットがインスタンスとの接続を開始できないようにします。
VPC NAT についての私のブログの記事を参照してください
VPC セキュリティ
VPC 内のセキュリティは以下の要素で提供される。
- セキュリティグループ: 関連する EC2 インスタンスのファイアウォールとして機能し、インスタンスレベルでの受信トラフィックとアウトバウンドの両方を制御
- ネットワークアクセス制御リスト (ACL): 関連するサブネットのファイアウォールとして機能し、サブネットレベルでの受信トラフィックとアウトバウンドの両方を制御
- フローログ: VPC 内のネットワークインターフェイスとの間で送受信される IP トラフィックに関する情報をキャプチャします。
セキュリティグループとNACL
AWS セキュリティグループとNACLについての私のブログの記事を参照してください。
フローログ
- VPC フローログは、VPC 内のネットワークインターフェイスとの間で送受信される IP トラフィックに関する情報を取得できる機能であり、トラフィックの監視や接続の問題のトラブルシューティングに役立ちます。
- フローログデータは Amazon CloudWatch ログを使用して保存されます
- フローログは、VPC 全体、サブネット、または各ネットワークインターフェイスに対して作成できます。有効にすると、VPC またはサブネット全体に対してすべてのネットワークインターフェイスが監視されます。
- フローログは、ネットワークインターフェイスのリアルタイムログストリームをキャプチャしません。
- フローログは、他の AWS サービスによって作成されたネットワークインターフェイス用に作成できます。たとえば、Elastic Load Balancing 、RDS、ElastiCache、Redshift、および WorkSpaces
サブネット
- サブネットは1つのアベイラビリティーゾーンにまたがっており、他の AZ の障害から分離されるように設計した別個の場所で、AZ にまたがることはできません。
- インターネットゲートウェイを使用してサブネットを構成し、インターネット経由で通信を有効にしたり、仮想プライベートゲートウェイ (VPN) 接続を使って企業ネットワークとの通信を有効にしたりできます。
- サブネットは、パブリックまたはプライベートすることができ、それはインターネット接続を持っているかどうかに依存するすなわち、IGW を介してインターネットへのトラフィックをルーティングすることができます。
- パブリックサブネット内のインスタンスには、インターネットと通信できるようにするパブリック IP または Elastic IP アドレスを割り当てる必要があります。
- インターネットに接続されていないが、VPN(Virtual Private Gateway)経由でのみルーティングされているサブネットについては、VPN 専用サブネットと呼ばれます。
- サブネットは、デフォルトでは、インスタンスの作成時にオーバーライドすることができます、すべてのインスタンスには、ネット内で起動するパブリック IP アドレスの割り当てを有効にするように構成することができます。
- サブネットのサイジング
- サブネットに割り当てられた CIDR ブロックは VPC CIDR と同じにすることができ、この場合、VPC 内で1つのサブネットのみを起動できます。
- サブネットに割り当てられた CIDR ブロックは VPC CIDR のサブセットであり、VPC 内で複数のサブネットを起動できます。
- サブネットに割り当てられた CIDR ブロックは重複してはいけません
- 許容される CIDR ブロックサイズは、
- /28 ネットマスク (2 ^ 4-16 利用可能な IP アドレスで最小)
- /16 ネットマスク (最大 2 ^ 16-65536 IP アドレス)
- AWS は、使用できない各サブネットの5つの IP アドレス (最初の4番目と最後の1アドレス) を予約し、インスタンスに割り当てることはできません。例えば、CIDR ブロック 10.0.0.0/24 のサブネットの場合、次の5つの IP が予約されています。
- 10.0.0.0: ネットワークアドレス
- 10.0.0.1: VPC ルーターの AWS によって予約されています
- 10.0.0.2: Amazon が提供する DNS へのマッピングのために AWS によって予約
- 10.0.0.3: 将来の使用のために AWS によって予約
- 10.0.0.255: ネットワークブロードキャストアドレス。AWS は VPC でブロードキャストをサポートしていないため、アドレスは予約されています。
- サブネットルーティング
- 各サブネットは、トラフィックを制御するルートテーブルに関連付けられています。
- サブネットセキュリティ
- サブネットセキュリティは、セキュリティグループと NACLs を使用して構成できます。
- セキュリティグループはインスタンスレベルで動作し、サブネットレベルで NACLs 作業を行います。
VPC エンドポイント
[VPCエンドポイント][6]についての私のブログ記事を参照してください。
VPC ピアリング
VPC ピアリングについての私のブログの投稿を参照してください。
VPC VPN 接続と CloudHub
[AWS VPC VPN CloudHubの接続][7] についての私のブログの記事を参照してください。
AWS認定試験の練習問題
- 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます(これはあなたと異なる場合があります)。
- AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
- AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
- さらなるフィードバック、ディスカッション、修正を可能にします。
- Elastic Load Balancer(ELB)、Web サーバー、アプリケーションサーバー、およびデータベースで構成される VPC で実行される B2B(business-to-business) Web アプリケーションがあります。 Web アプリケーションは、あらかじめ定義された顧客の IP アドレスからのトラフィックのみを受け入れる必要があります。 このセキュリティ要件を満たす2つのオプションはどれですか? 2つの回答を選択
- Web サーバーの VPC セキュリティグループを構成して、顧客の IP からのトラフィックを許可する (Web サーバーが ELB の背後にあり、顧客の IP アドレスが Web サーバーに到達しない)
- ELB の “X-forwarded-for” ヘッダーに基づいてトラフィックをフィルタリングするように Web サーバーを構成します(顧客の IP アドレスを取得し、アクセスを制限するカスタムフィルターを作成します。リンク参照)
- ELB セキュリティグループを構成して、お客様の IP からのトラフィックを許可し、すべてのアウトバウンドトラフィックを拒否する (ELB は顧客の IP アドレスを見るので、アクセスを制限することができます。すべてのトラフィックは基本的にアウトバウンドトラフィックに暗黙のルールはない)
- VPC NACL を構成して、顧客の IP からの Web トラフィックを許可し、すべてのアウトバウンドトラフィックを拒否する (NACL はステートレスであり、すべてを拒否する)
- ユーザーは、VPC ウィザードを使用してパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。 VPC の CIDR は 20.0.0.0/16 です。 プライベートサブネットは CIDR 20.0.0.0/24 を使用します。 VPC内のインスタンスが互いに通信できるようにするために、メインルートテーブルに必要なエントリはどれですか?
- 宛先:20.0.0.0/24 およびターゲット:VPC
- 宛先:20.0.0.0/16 およびターゲット:ALL
- 宛先:20.0.0.0/0 およびターゲット:ALL
- 宛先:20.0.0.0/16 およびターゲット:Local
- ユーザは、1つのパブリックと1つのプライベートの2つのサブネットを持つ VPC を作成しました。ユーザーは、プライベートサブネット内のインスタンスのパッチ更新を実行する予定です。プライベートサブネット内のインスタンスは、どのようにインターネットに接続できますか?
- プライベート IP でインターネットゲートウェイを使用する
- ポート80のセキュリティグループ内の送信トラフィックを許可して、インターネット更新を許可する
- プライベートサブネットがインターネットに接続できない
- Elastic IP で NAT を使用する
- ユーザーは EC2 インスタンスを起動し、Apache Web サーバーに Web サイトをインストールしました。 Web サーバーは稼働していますが、ユーザーはインターネットから Web サイトにアクセスできません。この失敗の理由は何でしょうか?
- インスタンスのセキュリティグループが正しく構成されていません。
- インスタンスは、適切なキーペアで構成されていません。
- インターネットから Apache のウェブサイトにアクセスすることはできません。
- インスタンスは Elastic IP で構成されていません。
- ユーザーは、VPC ウィザードを使用してパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。このシナリオでは、次の文のどちらが当てはまりますか?
- AWS VPC は、マイクロサイズの NAT インスタンスを自動的に作成します。
- VPC は、メインルートテーブルにプライベートサブネットと、パブリックサブネットを持つカスタムルートテーブルをバインドします。
- ユーザーが手動で NAT インスタンスを作成する
- VPC は、メインルートテーブルにパブリックサブネットと、プライベートサブネットを持つカスタムルートテーブルをバインドします。
- ユーザがパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。 VPC の CIDR は20.0.0.0/16です。 プライベートサブネットは CIDR 20.0.1.0/24 を使用し、パブリックサブネットは CIDR 20.0.0.0/24 を使用します。 ユーザーはパブリックサブネット(ポート80)に Web サーバーを、プライベートサブネット(ポート3306)に DB サーバーをホストする予定です。 ユーザーは NAT インスタンスのセキュリティグループを設定しています。 NATセキュリティグループには以下のエントリのどれが必須ではないのですか?
- インバウンド許可 ソース:20.0.1.0/24(ポート80)
- アウトバウンド許可 宛先:0.0.0.0/0(ポート80)
- インバウンド許可 ソース:20.0.0.0/24(ポート80)
- アウトバウンド許可 宛先:0.0.0.0/0(ポート443)
- ユーザーがCIDR 20.0.0.0/24 の VPC を作成しました。ユーザーは CIDR のすべての IP を使用しており、VPC のサイズを増やしたいと考えています。ユーザーには、public(20.0.0.0/25) と private(20.0.0.128/25)の2つのサブネットがあります。ユーザーはどのようにして VPC のサイズを変更できますか?
- ユーザーは、サブネットのすべてのインスタンスを削除できます。サブネットのサイズをそれぞれ 20.0.0.0/32 および 20.0.1.0/32 に変更します。次に、ユーザーは、CLI を使用して VPC のサイズを増やすことができます
- VPC の作成後にサイズを変更することはできません (NOTE-VPC サイズを増やすことができるようになりました。記事を読む)
- ユーザーは、より高い範囲のサブネットを追加して、VPC のサイズを自動的に増やすことができます。
- ユーザーは、最初にサブネットを削除してから、VPC のサイズを変更できます。
- ユーザーは、VPC ウィザードを使用してパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。 VPC の CIDR は20.0.0.0/16です。 パブリックサブネットは CIDR 20.0.1.0/24 を使用します。 ユーザーはパブリックサブネット(ポート80)にWeb サーバーを、プライベートサブネット(ポート3306)にDBサーバーをホストする予定です。 ユーザーは、パブリックサブネット(WebSecGrp)とプライベートサブネット(DBSecGrp)のセキュリティグループを構成しています。 Webサーバのセキュリティグループ(WebSecGrp)には、以下の項目のどれが必要ですか?
- ポート 3306 の宛先として DB セキュリティグループID(DbSecGrp)を構成します
- アウトバウンド 宛先 0.0.0.0/0(ポート80) を設定する
- インバウンド ソース 20.0.0.0/24(ポート3306)を設定する
- インバウンド ソース 20.0.0.0/16(ポート80)を設定する
- ユーザーが CIDR 20.0.0.0/16 の VPC を作成しました。誤って CIDR 20.0.0.0/16 のサブネットを1つ作成しました。ユーザーが CIDR 20.0.0.1/24の別のサブネットを作成しようとしています。ユーザーは2番目のサブネットをどのように作成できますか?
- VPC が2番目のサブネットの CIDR に基づいて最初のサブネットの CIDR を自動的に調整するので、サブネットを更新する必要はありません。
- ユーザーは、コンソールから最初のサブネット CIDR を変更できます。
- VPC が作成されたのと同じ CIDR を持つ1つのサブネットとして2番目のサブネットを作成することはできません。
- ユーザーは、AWS CLI を使用して最初のサブネット CIDR を変更できます。
- ユーザは、CIDR 20.0.0.0/16の VPC をセットアップしています。 VPC にはプライベートサブネット(20.0.1.0/24) とパブリックサブネット(20.0.0.0/24)があります。 ユーザーのデータセンターの CIDR は 20.0.54.0/24 および 20.1.0.0/24 です。 プライベートサブネットがデータセンターと通信したい場合はどうなりますか?
- これは、データセンターの両方の CIDRs のトラフィック通信を可能にする
- CIDR 20.1.0.0/24 のデータセンターではトラフィックを許可しませんが、20.0.54.0/24 でのトラフィック通信が可能
- これは、データセンター CIDRs のいずれかのトラフィック通信を許可されません
- CIDR 20.1.0.0/24 のデータセンターでのトラフィックを許可しますが、20.0.54.0/24 では許可されません (CIDR ブロックが重複しているため)。
- ユーザーは、VPC ウィザードを使用してパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。 VPC の CIDR は 20.0.0.0/16 です。 プライベートサブネットは CIDR 20.0.0.0/24 を使用します。 NAT インスタンス ID は i-a12345
です。 インスタンスをインターネットに接続できるようにプライベートサブネットに割当てられているメインルートテーブルには、以下のエントリのどれが必要ですか?- 宛先:0.0.0.0/0、ターゲット:i-a12345
- 宛先:20.0.0.0/0、ターゲット:ポート80
- 宛先:20.0.0.0/0、ターゲット:i-a12345
- 宛先:20.0.0.0/24、ターゲット:i-a12345
- ユーザーは、ウィザードを使用して CIDR 20.0.0.0/16 の VPC を作成しました。 ユーザーは、パブリックサブネット
CIDR(20.0.0.0/24) および VPN 専用サブネット CIDR(20.0.1.0/24) を VPN ゲートウェイ(vgw-12345)と共に作成して、ユーザーのデータセンターに接続しました。 ユーザーのデータセンターの CIDR は 172.28.0.0/12 です。 また、ユーザは、VPN
サブネットからインターネットへのトラフィックを許可する NAT インスタンス(i-123456)を設定しています。 次のうち、このシナリオでメインルートテーブルに有効なエントリはどれですか?- 宛先:20.0.1.0/24およびターゲット:i-12345
- 宛先:0.0.0.0/0、ターゲット:i-12345
- 宛先:172.28.0.0/12およびターゲット:vgw-12345
- 宛先:20.0.0.0/16およびターゲット:ローカル
- ユーザーが CIDR 20.0.0.0/16 の VPC を作成しました。ユーザはこの VPC で CIDR 20.0.0.0/16 のサブネットを1つ作成しました。ユーザーは、CIDR 20.0.0.1/24 と同じ VPC を持つ別のサブネットを作成しようとしています。このシナリオではどうなりますか?
- VPC は、最初のサブネット CIDR を自動的に変更して、2番目のサブネット IP 範囲を許可します。
- VPC と同じ CIDR を持つサブネットを作成することはできません。
- 2番目のサブネットが作成されます
- CIDR オーバーラップエラーをスローします
- ユーザーは、ウィザードを使用して CIDR 20.0.0.0/16 の VPC を作成しました。 ユーザーは、パブリック VPN と VPN 専用サブネットの両方をハードウェア VPN アクセスと共に作成して、ユーザーのデータセンターに接続しました。 ユーザーはまだインスタンスを起動しておらず、セットアップを変更または削除していません。 彼はこの VPC をコンソールから削除したいと思っています。 コンソールでユーザーは VPC を削除できますか?
- はい、コンソールは、すべてのセットアップを削除し、また、仮想プライベートゲートウェイを削除します
- いいえ、コンソールは、最初に仮想プライベートゲートウェイを手動でデタッチし、次に VPC の削除を許可するようユーザーに要求します
- はい、コンソールはすべてのセットアップを削除し、仮想プライベートゲートウェイをデタッチします。
- いいえ、NAT インスタンスが実行されているため
- ユーザーは、VPC ウィザードを使用してパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。 VPC の CIDR は 20.0.0.0/16 です。 パブリックサブネットは CIDR 20.0.1.0/24 を使用します。 ユーザーはパブリックサブネット(ポート80)に Web サーバーを、プライベートサブネット(ポート3306)に DB サーバーをホストする予定です。 ユーザーは、パブリックサブネット(WebSecGrp)とプライベートサブネット(DBSecGrp)のセキュリティグループを構成しています。 サブプライベート・データベース・セキュリティ・グループ(DBSecGrp)には、次の項目のどれが必要ですか。
- ソース Web サーバーセキュリティグループ (WebSecGrp) のポート3306のインバウンドを許可する
- ソース 20.0.0.0/16 からポート3306へのインバウンドを許可する
- 宛先 Web サーバーセキュリティグループ (WebSecGrp) のポート3306でのアウトバウンドを許可します。
- 宛先 NAT インスタンス IP のポート80でのアウトバウンドを許可する
- ユーザがサブネットとセキュリティグループを持つ VPC を作成しました。 ユーザーはそのサブネットでインスタンスを起動し、パブリック IP を添付しました。 ユーザーは引き続きインスタンスに接続できません。 インターネットゲートウェイも作成されました。 エラーの原因は何でしょうか?
- インターネットゲートウェイがルートテーブルで設定されていません
- プライベート IP は存在しません
- セキュリティグループのアウトバウンドトラフィックは無効になっています
- インターネットゲートウェイがセキュリティグループで設定されていません
- ユーザーは VPC にサブネットを作成し、その中に EC2 インスタンスを起動しました。 ユーザーは、インスタンスを起動する際に
IP アドレスを割り当てるオプションを選択していません。 インターネットへのアクセスを必要とするインスタンスに関して以下の記述のどれが当てはまるか?- デフォルトでは、インスタンスには常にパブリック DNS がインスタンスにアタッチされます
- ユーザーは、インスタンスに Elastic IP を直接アタッチできます。
- パブリック IP が割り当てられていない場合、インスタンスは起動されません。
- ユーザーはインターネットゲートウェイを作成し、インターネットから接続するために Elastic IP をインスタンスにアタッチする必要があります。
- ユーザーは、VPC ウィザードを使用して、パブリックサブネットとプライベートの両方を持つ VPC を作成しました。このシナリオでは、以下のステートメントのどれが当てはまりませんか。
- VPC はルーティングインスタンスを作成し、パブリックサブネットにアタッチします。
- VPC は2つのサブネットを作成します
- VPC は1つのインターネットゲートウェイを作成し、それを VPC にアタッチします。
- VPC は、Elastic IP を使用して1つの NAT インスタンスを起動します。
- ユーザがパブリックサブネットを持つ VPC を作成しました。ユーザーは、その VPC のセキュリティグループを作成しました。セキュリティ・グループが作成されたときに、以下のうちどれが当てはまりますか?
- これは、デフォルトでは、S3 や RDS などの AWS サービスに接続することができます
- デフォルトでは、すべてのインバウンドトラフィックがあります。
- デフォルトでは、すべてのアウトバウンドトラフィックがあります
- デフォルトでは、インターネットゲートウェイへのトラフィックを許可する
- ユーザーは、VPC ウィザードを使用して CIDR 20.0.0.0/16 の VPC を作成しました。 ユーザーは、パブリック
CIDR(20.0.0.0/24) と VPN 専用サブネット CIDR(20.0.1.0/24) をハードウェア VPN アクセスと共に作成して、ユーザーのデータセンターに接続しました。 VPC がウィザードでセットアップされているときに、次のコンポーネントのどれが表示されないのですか?- VPN のみのサブネットで接続されたメインルートテーブル
- VPN サブネットインスタンスがインターネットに接続できるように構成された NAT インスタンス
- パブリックサブネットにアタッチされたカスタムルートテーブル
- パブリックサブネット用のインターネットゲートウェイ
- ユーザーは、VPC ウィザードを使用してパブリックサブネットとプライベートサブネットを持つ VPC を作成しました。 ユーザーは手動でインスタンスを起動しておらず、VPC を削除しようとしています。 このシナリオではどうなりますか?
- ルートテーブルを持つサブネットがあるため、VPC を削除することはできません。
- 実行中のルートインスタンスがあるため、VPC を削除することはできません。
- これは、ウィザードによって起動されたすべてのインスタンスと共に VPC を終了します。
- 実行中の NAT インスタンスがあるため、VPC を削除することはできません。
- ユーザーが VPC を使用してパブリックサブネットを作成し、その中に EC2 インスタンスを起動しました。ユーザーがサブネットを削除しようとしています。このシナリオではどうなりますか?
- サブネットを削除し、EC2 インスタンスをデフォルトのサブネットの一部として作成します。
- インスタンスが終了するまで、ユーザーはサブネットを削除することはできません。
- これは、サブネットを削除するだけでなく、インスタンスを終了します
- サブネットは独立して削除することはできませんが、ユーザーは最初に VPC を削除しなければなりません
- ユーザーが CIDR 20.0.0.0/24 の VPC を作成しました。 ユーザーは、CIDR 20.0.0.0/25 のパブリックサブネットと、
CIDR 20.0.0.128/25 のプライベートサブネットを作成しました。 ユーザーは、プライベートおよびパブリックサブネットでそれぞれ1つのインスタンスを起動しました。 以下のうち、パブリックまたはプライベートサブネット内のインスタンスに割り当てられた正しい IP アドレス(プライベートIP)を選択できないものはどれですか?- 20.0.0.255
- 20.0.0.132
- 20.0.0.122
- 20.0.0.55
- ユーザーが CIDR 20.0.0.0/16 の VPC を作成しました。 ユーザーは、パブリックおよび VPN のみのサブネットと、ハードウェア VPN アクセスを作成して、ユーザーのデータセンターに接続しました。 ユーザーは、パブリックサブネットに到着するすべてのトラフィックが組織のプロキシポリシーに従うようにする必要があります。 ユーザーはどのようにこれを実現できますか?
- プロキシプロトコルを使用して NAT を設定し、パブリックサブネットが NAT からトラフィックを受信するように構成する
- パブリックサブネットに接続されたインターネットゲートウェイでのプロキシポリシーの設定
- パブリックサブネットのプロキシポリシーを設定することはできません。
- 仮想プライベートゲートウェイからのトラフィックを受信するパブリックサブネットのルートテーブルとセキュリティグループの設定
- ユーザーは、ウィザードを使用して CIDR 20.0.0.0/16 の VPC を作成しました。 ユーザーは、パブリックサブネット CIDR(20.0.0.0/24) および VPN 専用サブネット CIDR(20.0.1.0/24) を VPN ゲートウェイ(vgw-12345)と共に作成して、ユーザーのデータセンターに接続しました。 このシナリオでメインルートテーブルに有効なエントリは、次のうちどれですか?
- 宛先: 20.0.0.0/24 とターゲット: vgw-12345
- 宛先: 20.0.0.0/16 とターゲット: ALL
- 宛先: 20.0.1.0/16 とターゲット: vgw-12345
- 宛先: 0.0.0.0/0 とターゲット: vgw-12345
- どの2つのコンポーネントが外部ネットワークとの接続を提供しますか? 2つのコンポーネントが外部ネットワークとの接続を提供する
Amazon VPC に接続されている場合2つの回答を選択- Elastic IP(EIP)(接続を提供しない、公開IPアドレスも同様)
- NATゲートウェイ(NAT)(VPC には接続されておらず、依然として IGW が必要)
- インターネットゲートウェイ(IGW)
- 仮想プライベートゲートウェイ(VGW)
- Amazon VPC のインスタンスに正常に接続しようとしています VPC にインターネットゲートウェイ(IGW)があり、インスタンスに関連付けられた Elastic IP(EIP) があり、適切なセキュリティグループルールが設定されていることを確認済みです。 次にどの VPC コンポーネントを評価する必要がありますか?
- NAT インスタンスの構成
- ルーティングテーブルの構成
- インターネットゲートウェイ (IGW) の構成
- SRC/DST チェックの構成
- Amazon エラスティックコンピューティングクラウド (EC2) インスタンスを起動し、各インスタンスに所定のプライベート IP アドレスを割り当てる必要がある場合、何をするべきですか?
- インスタンスへのグループまたはシーケンシャルな Elastic IP アドレスの割り当て
- プレイスメントグループ内のインスタンスを起動する
- Amazon 仮想プライベートクラウド (VPC) でインスタンスを起動する
- 各インスタンスがプライベートドメインネームサービス (DNS) を既に取得しているため、標準の EC2 インスタンスを使用する
- プライベート Amazon マシンイメージ (AMI) からインスタンスを起動する
- ユーザーは最近 EC2 を使用し始めました。ユーザーは EC2-VPC のデフォルトサブネットに1つの EC2 インスタンスを起動しました。以下のオプションのいずれかが EC2 インスタンスに接続されていないものはどれか
- パブリックIP
- インターネットゲートウェイ
- Elastic IP
- プライベートIP
- ユーザーが CIDR 20.0.0.0/24 の VPC を作成しました。ユーザーは、CIDR 20.0.0.0/25 のパブリックサブネットを作成しました。ユーザーが CIDR 20.0.0.128/25 のプライベートサブネットを作成しようとしています。このシナリオでは、次の文のどちらが当てはまりますか?
- CIDR が重複しているため、ユーザーがプライベートサブネットを作成することはできません
- これにより、ユーザーは 20.0.0.128/25 として CIDR を持つプライベートサブネットを作成できるようになります。
- このステートメントは、AWS が CIDR 20.0.0.0/25 を許可しないため、間違っています
- CIDR 範囲が間違っているため、ユーザーがプライベートサブネットを作成することはできません。
- ユーザーは、VPC ウィザードを使用してプライベートサブネットと VPN 接続のみを持つ CIDR 20.0.0.0/16 の VPC を作成しました。ユーザーは、SSH 経由でプライベートサブネット内のインスタンスに接続する必要があります。ユーザーは SSH のセキュリティルールをどのように定義する必要がありますか?
- ユーザーのネットワークからポート 22 のインバウンドトラフィックを許可する
- ユーザーは、Elastic IP を使用して EC2 クラシックでインスタンスを作成し、プライベートサブネットのセキュリティグループを構成して、その Elasttic IP から SSH を許可します。
- ユーザーは、NAT インスタンスを使用してプライベートサブネット内のインスタンスに接続できます。
- ポート80 および 22 のインバウンドトラフィックを許可して、ユーザーがインターネット経由でプライベートサブネットに接続できるようにする
- 企業は仮想プライベートクラウド(VPC)に Web サイトを実装しようとしています。 Web 層は、複数の Availability Zone(AZ) にわたって Auto Scaling グループを使用します。 データベースは Multi-AZ RDS MySQL を使用し、一般にアクセスできないようにする必要があります。 VPC で設定する必要のあるサブネットの最小数はいくらですか?
- 1
- 2
- 3
- 4 (複数の AZ の Web インスタンス用の2つのパブリックサブネットと RDS Multi-AZ の2つのプライベートサブネット)
- 次のうち Amazon VPC サブネットの特徴はどれですか? 2つの回答を選択
- 各サブネットは1つのアベイラビリティーゾーンにマップされます。
- /25 の CIDR ブロックマスクは、サポートされている最小範囲です。
- プライベートサブネット内のインスタンスは、Elastic IP がある場合にのみインターネットと通信できます。
- デフォルトでは、すべてのサブネットは、プライベートまたはパブリックであるかどうかに関係なく、相互にルーティングできます。
- 各サブネットは2つ以上のアベイラビリティーゾーンにまたがるため、高可用性環境を提供します。
- Elastic Load Balancer(ELB)で構成される Web アプリケーションの VPC を設計する必要があります。 Web/アプリケーションサーバー群、および RDS データベースインフラストラクチャ全体を2つの可用性ゾーンに分散する必要があります。 インターネットからデータベースを入手できないことを保証するために、どの VPC 設定が機能しますか?
- ELB の1つのパブリックサブネットは、web サーバーの1つのパブリックサブネット、およびデータベースの1つのプライベートサブネット
- web サーバー用の2つのプライベートサブネット、RDS 用の2つのプライベートサブネットを ELB するための1つのパブリックサブネット
- web サーバー用の2つのプライベートサブネットと RDS 用の2つのプライベートサブネットを ELB ための2つのパブリックサブネット
- web サーバー用の2つのパブリックサブネット、および RDS 用の2つのパブリックサブネットを ELB ための2つのパブリックサブネット
- CIDR ブロックが 10.0.0.0/28 の VPC に3層 Web アプリケーションを配備しました。 最初に、2つの Web サーバー、2つのアプリケーションサーバー、2つのデータベースサーバー、1つの NAT インスタンス、合計7つの EC2 インスタンスを展開します。 アプリケーションサーバーとデータベースサーバーは、2つの可用性ゾーン(AZ)に展開されます。 また、ELB を2つの Web サーバーの前に配置し、配備後の最初の数日間は Route53 for DNS Webを使用して徐々に増加させるため、新しい負荷を処理するためにアプリケーションの各ティアのインスタンス数を倍増させようとします 残念ながら、これらの新しいインスタンスの一部は起動できません。 次のうち根本原因はどれですか? (2つの回答を選んでください)[PROFESSIONAL]
- VPC のインターネットゲートウェイ (IGW) は、トラフィックスパイクを処理するためのインスタンスを追加してスケールアップし、新しいインスタンスの起動に使用できるプライベート IP アドレスの数を減らしました。
- AWS は、Route53 の各サブネットの CIDR ブロックに1つの IP アドレスを予約し、新しい EC2 インスタンスをすべて起動するための十分なアドレスが残っていないようにします。
- AWS は、各サブネットの CIDR ブロックに最初と最後のプライベート IP アドレスを確保するため、新しい EC2 インスタンスをすべて起動するための十分なアドレスが残っていません。
- ELB はスケールアップしています。トラフィックを処理するインスタンスを追加して、新しいインスタンスの利用可能なプライベート IP アドレスの数を減らす
- AWS は、各サブネットの CIDR ブロックの最初の4つと最後の IP アドレスを確保するため、新しい EC2 インスタンスをすべて起動するための十分なアドレスが残っていません。
- ユーザーは、IP アドレスを使用して EC2 インスタンスから RDS にアクセスする必要があります。 RDS と EC2 は同じリージョンにありますが、異なるAZです。次のオプションのどれが、インスタンスにすぐにアクセスできるように設定するのに役立ちますか?
- RDS セキュリティグループ内のインスタンスのプライベート IP を構成する (データが Amazon ネットワーク内で転送され、インターネット経由ではなく、リンクを参照することをお勧めします)
- RDS セキュリティグループで許可されている EC2 のセキュリティグループ
- RDS セキュリティグループのインスタンスの Elastic IP の構成
- RDS セキュリティグループのインスタンスのパブリック IP を構成する
- VPCに関しては、正しいステートメントを選択してください
- 複数のサブネットを同じルートテーブルに関連付けることができます。
- 複数のサブネットを同じルートテーブルに関連付けることはできますが、サブネットを1つのルートテーブルにのみ関連付けることは出来ません。
- 複数のサブネットを同じルートテーブルに関連付けることはできません。
- これらのどれも違う
- ELB と複数の Web アプリケーションサーバーと RDS DB で構成される Web アプリケーション用の VPC を設計する必要があります。 インフラストラクチャ全体を2つの AZ に分散する必要があります。 DB がインターネットから利用できないことを保証するのに、どの VPC 設定が機能しますか?
- ELB の1つのパブリックサブネット、web サーバー用のパブリックサブネット、および DB の1つのプライベートサブネット
- ELB の1つのパブリックサブネット、web サーバー用の2つのプライベートサブネット、および RDS 用の2つのプライベートサブネット
- ELB 用の2つのパブリックサブネット、web サーバー用の2つのプライベートサブネット、および RDS 用の2つのプライベートサブネット
- ELB の2つのパブリックサブネット、web サーバーの2つのパブリックサブネット、および RDS の2つのパブリックサブネット
- 1つのプライベートサブネットを持つ Amazon VPC と、NAT(Network Address Translator) サーバーを持つ1つのパブリックサブネットがあります。 GIT 経由でアプリケーションをデプロイする Amazon Simple Storage Service(S3) からブートストラップスクリプトをダウンロードすることで、スタートアップ時に自分自身を構成する Amazon Elastic Cloud Compute(EC2) インスタンスのグループを作成しています。 どの設定が最高レベルのセキュリティを提供しますか?
- プライベートサブネット内の Amazon EC2 インスタンス、EIP なし、NAT 経由での送信トラフィックのルーティング
- パブリックサブネットの Amazon EC2 インスタンス、EIP なし、インターネットゲートウェイ (IGW) 経由での送信トラフィックのルーティング
- プライベートサブネットの Amazon EC2 インスタンスは、EIP を割り当て、インターネットゲートウェイ (IGW) 経由で送信トラフィックをルーティングします。
- パブリックサブネットの Amazon EC2 インスタンス、EIP の割り当て、NAT 経由での送信トラフィックのルーティング
- プライマリプライベート IP アドレスが割り当てられ、インターネットゲートウェイが VPC に接続され、パブリックルートテーブルがすべてのインターネットベースのトラフィックをインターネットに送信するように設定されている場合、Amazon Elastic Compute Cloud(EC2) インスタンスをパブリックサブネットに開始しました。 ゲートウェイ。 インスタンスセキュリティグループは、すべての送信トラフィックを許可するように設定されていますが、インターネットにアクセスすることはできません。 このインスタンスからインターネットにアクセスできないのはなぜですか?
- インスタンスにパブリック IP アドレスがありません
- インターネットゲートウェイセキュリティグループは、すべての送信トラフィックを許可する必要があります。
- インスタンスセキュリティグループは、すべての受信トラフィックを許可する必要があります。
- インスタンス “ソース/デスティネーションチェック” プロパティを有効にする必要があります。
- Amazon VPC を使用するパブリックサブネットとこのサブネットで実行されている3つのインスタンスで構成される環境があります。 これらの3つのインスタンスは、インターネット上の他のホストと正常に通信できます。 同じサブネットで4番目のインスタンスを起動し、他のインスタンスで使用したのと同じ AMI およびセキュリティグループの設定を使用しますが、インターネットからこのインスタンスにアクセスすることはできません。 インターネットにアクセスできるようにするにはどうすればよいですか?
- NAT インスタンスをパブリックサブネットに展開します。
- 4番目のインスタンスに Elastic IP アドレスを割り当てる
- 4番目のインスタンスのホスト OS で、パブリックにルーティング可能な IP アドレスを構成します。
- パブリックサブネットのルーティングテーブルを変更します。
- VPC 用に設定されたロードバランサがあり、すべてのバックエンドの Amazon EC2 インスタンスが稼動しています。 ただし、ロードバランサの DNS 名に接続すると、Web ブラウザがタイムアウトします。 この動作の原因として考えられるのはどのオプションですか? 2つの回答を選択
- ロードバランサーは、インターネットゲートウェイが構成されたパブリックサブネットを使用するように構成されていません
- Amazon EC2 インスタンスには、動的に割り当てられたプライベート IP アドレスがありません
- セキュリティグループまたはネットワーク ACL は、web トラフィック用に構成されたプロパティではありません。
- ロードバランサーは、NAT インスタンスを持つプライベートサブネットで構成されていません。
- VPC には VGW が構成されていません。
- Elastic IP アドレス (EIP) でコストが発生するのはいつですか。
- EIP が割り当てられている場合。
- それが割り当てられ、実行中のインスタンスに関連する場合。
- それが割り当てられ、停止したインスタンスに関連する場合。
- EIP が実行中のインスタンスに関連付けられているかどうかに関係なく、コストが発生します。
リファレンス
- AWS VPC ユーザーガイド
- AWS Black Belt Online Seminar 2017 Amazon VPC (SlideShare / オンデマンドセミナー)
Jayendra’s Blog
この記事は自己学習用に「AWS Virtual Private Cloud – VPC – Certification(Jayendra’s Blogより)」を日本語に訳した記事です。
コメントを残す