ネットワークとコンテンツ配信
VPC、サブネット、ルートテーブル、セキュリティグループ / NACL、NAT、エンドポイント、VPC 間およびオンプレミスとの接続、Route 53、CloudFront、Global Accelerator。
- 分野セキュアなアーキテクチャ
- 分野弾力性のあるアーキテクチャ
- 分野高性能なアーキテクチャ
- 分野コスト最適化
- 図 15
- 出題パターン 10
- サービス 13
5 分で押さえる要点
- VPC は 1 つのリージョン内に存在し、サブネットは必ず 1 つの AZ 内に存在します。1 つの AZ の障害に耐えるには、各階層 (ALB、アプリ、NAT、データベース) を少なくとも 2 つの AZ に配置する必要があります。
- サブネットが「パブリック」なのは、そのルートテーブルに 0.0.0.0/0 → Internet Gateway があるからにほかなりません。パブリック / プライベートを切り替える別のスイッチはありません。インスタンスがインターネットと直接通信するには、さらにパブリック IP (自動割り当てまたは Elastic IP) が必要です。
- VPC とサブネットの CIDR は /16 から /28 までです。各サブネットでは 5 個のアドレスが予約されます (先頭 4 つと末尾 1 つ)。/24 の使用可能アドレスは 251 個、/28 では 11 個です。作成済みの CIDR のサイズは変更できません。足りない場合はセカンダリ CIDR を追加します。
- セキュリティグループ：ENI にアタッチし、allow ルールのみ、ステートフルです。NACL：サブネットにアタッチし、allow と deny があり、ステートレスで、ルール番号順に評価されます。特定の IP をブロックするには NACL を使います (Web なら WAF も可)。NACL では戻りの方向も開ける必要があります (エフェメラルポート 1024–65535)。
- NAT Gateway は、プライベートサブネット内のマシンがインターネットへ出ることを許可し、外部からの接続は許可しません。zonal タイプ (デフォルト) はパブリックサブネットに置き、AZ ごとに 1 つ用意して、1 つの AZ が停止しても他の AZ のインターネット接続が失われないようにします。2025 年 11 月からは、AZ に自動で展開される regional タイプも利用できます。
- Gateway endpoint (S3 と DynamoDB のみ) は無料で、ルートテーブル内の宛先になります。Interface endpoint (PrivateLink) はプライベート IP を持つ ENI で、時間と GB 単位で課金されます。プライベートサブネットから NAT を経由せずに S3 へアクセスするには gateway endpoint を使います。安価で、インターネットにも出ません。オンプレミスや Transit Gateway 経由の場合は interface endpoint が必要です。
- VPC ピアリングは推移的ではなく、CIDR が重複する VPC 同士では使えません。A–B と B–C がピアリングされていても、A から C には到達できません。多数の VPC 同士の通信や、オンプレミスへの経路の共有には Transit Gateway を使います。
- Site-to-Site VPN：インターネット経由の IPsec 暗号化で、数分で構築でき、各トンネルは最大 1.25 Gbps (大容量帯域トンネルは最大 5 Gbps) です。一時的な接続や、Direct Connect のバックアップ経路に適しています。
- Direct Connect：専用線で、レイテンシーが安定しており、ポートは 1/10/100/400 Gbps、開通まで数週間かかります。デフォルトでは暗号化されません。暗号化が必要な場合：Direct Connect 上で VPN を使うか、対応ポートで MACsec を使います。
- Route 53 には 8 種類のルーティングがあります：simple、weighted、latency、failover、geolocation、geoproximity、IP-based、multivalue answer。試験では要件に応じてどれを選ぶかが問われます：active-passive の DR → failover、ユーザーの国別 → geolocation、最速 → latency。
- CloudFront はエッジでコンテンツをキャッシュします。S3 バケットは OAC (Origin Access Control) で保護し、CloudFront だけが読み取れるようにします。OAI は古い方式で、SSE-KMS や PUT/DELETE をサポートしません。AWS は OAC の利用を推奨しています。
- Global Accelerator は 2 つの静的 anycast IP を提供し、最寄りのエッジから TCP/UDP トラフィックを AWS ネットワークに入れ、エンドポイントが故障するとリージョンを切り替えます。顧客が許可リストに登録する固定 IP、UDP を使うゲームや VoIP、DNS キャッシュに依存しない高速なフェイルオーバーが必要な場合：CloudFront ではなく Global Accelerator です。
- パブリック IPv4 はすべて時間単位で課金されます。インスタンスにアタッチ済みの Elastic IP も同様です。古い試験問題では「稼働中のマシンにアタッチした EIP は無料」と言われがちですが、これはもう正しくありません。
構成図
2 つの AZ にまたがる VPC：パブリックサブネット、プライベートサブネット、AZ ごとの NAT
ステップ
- インターネットからのリクエストは Internet Gateway を通り、パブリックサブネットの ALB に届きます。
- ALB は両方の AZ のプライベートサブネットにあるアプリに負荷を分散します。アプリにはパブリック IP がありません。
- アプリは RDS primary に書き込み、RDS は別の AZ のスタンバイへ同期複製します (Multi-AZ)。
- アプリがパッチをダウンロードする：同じ AZ の NAT Gateway を通って外へ出て、Internet Gateway に到達します。逆方向は外部から開始できません。
1 つのリクエストが NACL とセキュリティグループを通る流れ
VPC ピアリングは推移的ではない。Transit Gateway を中心にする
ステップ
- ピアリングは 1 対 1 の接続です。A–B と B–C はピアリングされています。
- ピアリングは推移的ではありません。A は B を経由して C に到達できないため、必要なら A–C のピアリングを追加で作成します。
- Transit Gateway：各 VPC、VPN、Direct Connect が 1 つのアタッチメントになり、TGW のルートテーブルが通信可能な相手を決めます。
Direct Connect を主経路、Site-to-Site VPN をバックアップにする
ステップ
- 通常時：トラフィックは Direct Connect を通ります (レイテンシーが安定、高帯域、デフォルトでは暗号化なし)。
- DX が故障すると、BGP がインターネット経由の Site-to-Site VPN に切り替わります。IPsec で暗号化され、帯域は小さくなります。
- 複数の VPC や複数のリージョンを接続する場合は、virtual private gateway を Transit Gateway / Direct Connect gateway に置き換えます。
Gateway endpoint と interface endpoint
ステップ
- S3 / DynamoDB へ：ルートテーブルにサービスの prefix list があり、gateway endpoint に向きます。NAT を経由せず、エンドポイントの料金もかかりません。
- その他のサービス：interface endpoint は ENI です。プライベート DNS により、サービス名がこのプライベート IP に解決されます。
- オンプレミスから (または Transit Gateway、別リージョンとのピアリング経由で) は、interface endpoint しか使えません。
PrivateLink：顧客に自社サービスをプライベート IP で呼び出させる
ステップ
- 顧客のアプリは、自分の VPC 内にある interface endpoint のプライベート IP を呼び出します。
- トラフィックは AWS ネットワーク内を通ってお客様の NLB に到達します。ピアリング、IGW、NAT は不要で、CIDR が重複しても問題ありません。
プライベートな S3 (OAC) と ALB の前に置く CloudFront
ステップ
- ユーザーは最寄りのエッジロケーションに接続し、WAF がキャッシュに到達する前にリクエストをフィルタリングします。
- キャッシュミス：CloudFront が OAC でリクエストに署名します。バケットポリシーはこのディストリビューションだけを許可するため、バケットを直接読み取れる人はいません。
- /api/* のパスは ALB に向かいます。cache policy に応じてキャッシュすることも、しないこともできます。
2 つのリージョン間の Route 53 failover
ステップ
- 通常時：primary のヘルスチェックが正常で、Route 53 はメインリージョンのアドレスを返します。
- ヘルスチェックが失敗：Route 53 が secondary レコードを返し、DNS キャッシュの TTL が切れるとユーザーはセカンダリリージョンに移ります。
Global Accelerator：複数リージョンの前に 2 つの静的 anycast IP
ステップ
- 顧客は 2 つの静的 IP を許可リストに登録します。トラフィックはプレイヤーに近いエッジですぐに AWS ネットワークに入ります。
- Global Accelerator は、場所、ウェイト、traffic dial に基づいて正常なエンドポイントを選びます。エンドポイントが故障すると、新しい接続はすぐに別のリージョンへ向かいます。
Route 53 Resolver エンドポイントによる双方向 DNS
ステップ
- オンプレミスがプライベートホストゾーンの名前を問い合わせる：社内 DNS が inbound endpoint の IP に転送します。
- EC2 が corp.example の名前を問い合わせる：Resolver が forwarding rule を見つけ、outbound endpoint 経由で社内 DNS に送ります。
IPv6：egress-only Internet Gateway
ステップ
- IPv6 は egress-only IGW を通って外へ出ます。戻りの通信は自動で通ります (ステートフル)。
- IPv4 は従来どおり NAT Gateway を通ります。
- インターネットから開始された IPv6 接続はブロックされます。
ルートテーブルがパブリックかプライベートかを決める
ステップ
- パブリックサブネット内のマシン：0.0.0.0/0 が Internet Gateway を向いているため、パブリック IP があればインターネットと双方向に通信できます。
- プライベートサブネット内のマシン：0.0.0.0/0 は NAT Gateway (パブリックサブネット内) を向いており、外向きの通信のみ可能です。
- S3 へのトラフィックは prefix list に一致する (0.0.0.0/0 より具体的なルート) ため、NAT を経由せず gateway endpoint を通ります。
CloudFront：パスごとの cache behavior とバックアップの origin group
ステップ
- リクエストは最寄りのエッジに届き、キャッシュにヒットすればそのまま返されます。
- /static/* は 1 つ目の behavior に一致します：OAC 経由でプライベートな S3 バケットから取得し、長期間キャッシュします。
- /api/* は 2 つ目の behavior に一致します：API Gateway に向かい、通常はキャッシュしないか短時間だけキャッシュします。
- 残りはデフォルトの behavior を通って origin group に向かいます。プライマリオリジンが選択したエラーコード (例：502、503、504) を返すと、セカンダリオリジンを試します。
VPC Flow Logs：誰が誰と通信したかを記録する
ステップ
- ENI を通る接続ごとに 1 件のレコードが生成されます：アドレス、ポート、プロトコル、バイト数、ACCEPT か REJECT か。
- 出力先を選びます：CloudWatch Logs (素早いアラート)、S3 (長期保存で安価)、または Firehose (他のツールへ送信)。
- S3 上のログを Athena でクエリします。例：ポート 22 への REJECT された接続をすべて探す。
VPC の接続方法を選ぶ
ステップ
- プライベートサブネット内のアプリが S3 を読み取る場合：gateway endpoint を使います。NAT を経由せず、エンドポイントの料金もかかりません。
- 複数アカウントの 15 個の VPC がオンプレミスへの経路を共有する場合：Transit Gateway。
- 大量のトラフィックで、オンプレミスへの安定したレイテンシーが必要な場合：Direct Connect を使い、バックアップに VPN を追加します。
比較表
セキュリティグループとネットワーク ACL
| セキュリティグループ | ネットワーク ACL | |
|---|---|---|
| アタッチ先 | ENI (インスタンス、ALB、RDS など) | サブネット |
| ルールの種類 | allow のみ | allow と deny |
| 状態 | ステートフル：戻りの通信は自動で許可 | ステートレス：インバウンドとアウトバウンドの両方を開ける必要あり |
| 評価順 | すべてのルールを評価 | 番号順に評価し、一致したルールで終了 |
| デフォルト | 新規 SG：すべてのインバウンドを拒否、すべてのアウトバウンドを許可 | デフォルト NACL：すべて許可、自分で作成した NACL：すべて拒否 |
| 参照 | 別の SG を参照できる (例：ALB の SG からのみ許可) | IP 範囲のみ |
オンプレミスと AWS の接続
| 方式 | 経路 | 暗号化 | 帯域幅 | 構築期間 | 使いどころ |
|---|---|---|---|---|---|
| Site-to-Site VPN | インターネット | あり (IPsec) | トンネルあたり最大 1.25 Gbps (大容量帯域トンネル：5 Gbps) | 数分 | すぐに必要、安価、またはバックアップ経路にしたい場合 |
| Direct Connect | DX location への専用線 | なし (VPN や MACsec を追加しない限り) | ポート 1/10/100/400 Gbps | 数週間 | 大量データ、安定したレイテンシーが必要な場合 |
| DX + バックアップ VPN | 両方 | 経路ごとに異なる | DX と同じ | DX と同じ | 専用線が必要で、DX の障害時に接続を失えない場合 |
| Client VPN | インターネット経由、各ユーザーの端末から | あり (TLS) | ユーザーごと | 数分 | リモートワークの従業員が VPC にアクセスする場合 |
VPC エンドポイント
| Gateway endpoint | Interface endpoint (PrivateLink) | |
|---|---|---|
| サービス | S3 と DynamoDB のみ | 大半の AWS サービス、他社のサービス |
| 仕組み | ルートテーブル内の宛先 | お客様のサブネット内にあるプライベート IP を持つ ENI |
| コスト | 無料 | AZ ごとの時間料金 + GB 単位 |
| オンプレミス、別リージョンの VPC ピアリング、Transit Gateway からの利用 | 不可 | 可 |
| 制御 | エンドポイントポリシー + バケットポリシー (aws:sourceVpce) | エンドポイントポリシー + セキュリティグループ |
CloudFront と Global Accelerator
| CloudFront | Global Accelerator | |
|---|---|---|
| 目的 | HTTP(S) コンテンツのキャッシュと配信 | トラフィックを最も早く AWS ネットワークに入れ、正常なエンドポイントを選ぶ |
| プロトコル | HTTP、HTTPS、WebSocket | TCP、UDP |
| キャッシュ | あり | なし |
| アドレス | ドメイン名、IP は変動 | 2 つの静的 anycast IP (dual-stack：IPv6 を 2 つ追加) |
| フェイルオーバー | Origin group (オリジンのバックアップ) | 正常なエンドポイントへ自動で切り替え、DNS キャッシュの期限切れを待たない |
| 適した用途 | Web、画像、動画、キャッシュが必要な API | ゲーム、VoIP、IoT、許可リスト登録のために固定 IP が必要なアプリケーション |
Route 53：ルーティングポリシーの選択
| ポリシー | 応答の基準 | 試験での例 |
|---|---|---|
| Simple | 1 つのレコード (複数 IP も可、ランダムに返す、ヘルスチェックなし) | 単純な Web サイト |
| Weighted | 割合 (パーセント) | トラフィックの 10% を新バージョンへ段階的に移す |
| Latency | ユーザーに対してレイテンシーが最も低いリージョン | グローバルユーザー、複数リージョンで稼働するアプリ |
| Failover | ヘルスチェック：プライマリが故障したらセカンダリへ | active-passive の DR |
| Geolocation | ユーザーの大陸 / 国 / 州 | 国ごとの法規制に応じたコンテンツ、特定国のブロック |
| Geoproximity | リソースまでの距離 (bias で範囲を拡大可能) | 新しいリージョンにトラフィックを多く集める |
| IP-based | ユーザーの送信元 IP 範囲 (CIDR) | 通信事業者 X のユーザーをエンドポイント Y へ |
| Multivalue answer | 正常なレコード最大 8 件をランダムに選択 | ヘルスチェック付きの、DNS レベルのシンプルな負荷分散 |
よく出る出題パターン
1プライベートサブネット内の EC2 がインターネットからパッチをダウンロードする必要がありますが、インターネットからの接続は一切許可できません。どうしますか？
答えを見る
正解: パブリックサブネットに NAT Gateway を (AZ ごとに 1 つ) 配置し、プライベートサブネットの 0.0.0.0/0 を同じ AZ の NAT Gateway に向ける
NAT は内側から開始した接続だけを通します。1 つの NAT を複数 AZ で共有すると、NAT を持つ AZ が停止したときに他の AZ のインターネット接続が失われます。
不正解: EC2 に Elastic IP をアタッチする
EIP を使うにはサブネットに Internet Gateway へのルートが必要で、つまりパブリックになり、マシンがインターネットに公開されます。
不正解: Internet Gateway を作成し、プライベートサブネットから 0.0.0.0/0 のルートを向ける
サブネットがパブリックになってしまいます。
2プライベートサブネット内のアプリケーションが S3 に大量に読み書きしており、NAT Gateway の請求が急増しています。最も安価な方法は？
答えを見る
正解: S3 用の gateway endpoint を作成し、プライベートサブネットのルートテーブルに追加する
S3 へのトラフィックは NAT を経由せずエンドポイント経由で直接流れ、エンドポイントの料金もかかりません。
不正解: NAT Gateway を NAT instance に置き換える
多少安くなりますが、自分で運用する必要があり、データ転送料金もかかり、根本的な解決にはなりません。
不正解: S3 用の interface endpoint
利用はできますが、時間と GB 単位で課金されます。gateway endpoint なら同じことが無料でできます。
3公開 ALB を攻撃している IP 範囲をブロックする必要があります。
答えを見る
正解: ALB があるサブネットの NACL に deny ルールを追加する、または ALB にアタッチした IP セットを使う AWS WAF
NACL は IP 範囲での deny が可能です。WAF は HTTP レベルでブロックでき、他の多くの条件でもフィルタリングできます。
不正解: ALB のセキュリティグループに deny ルールを追加する
セキュリティグループには deny ルールがありません。
4複数アカウントにまたがる 15 個の VPC が互いに通信し、1 本の Direct Connect をオンプレミスへの経路として共有する必要があります。
答えを見る
正解: Transit Gateway を中心に置き (RAM でアカウント間共有)、Direct Connect gateway を Transit Gateway にアタッチする
ハブアンドスポーク：各 VPC に 1 つのアタッチメントを持たせ、Transit Gateway のルートテーブルで通信可能な相手を決めます。
不正解: VPC 間で 1 対 1 のピアリングを行う
15 個の VPC には 105 本のピアリング接続が必要です。また、ピアリングは推移的ではないため、オンプレミスへの経路を共有できません。
5オンプレミスへのプライベートで高帯域、安定したレイテンシーの接続が必要で、その経路が故障しても接続を失ってはならず、予算は限られています。
答えを見る
正解: Direct Connect を主経路、Site-to-Site VPN をバックアップ経路にする
DX を 2 本にするより安価です。最高の可用性が必要な場合は、2 つの異なる DX location に DX を 2 本用意します。
不正解: Direct Connect を 1 本だけ使う
単一障害点になります。
不正解: Site-to-Site VPN を 2 本使う
インターネット経由のためレイテンシーが不安定で、帯域にも制限があります。
6NLB の背後で動くサービスを数百の顧客に販売しています。顧客は自分の VPC 内のプライベート IP で呼び出したく、顧客の CIDR はお客様のものと重複する可能性があります。
答えを見る
正解: AWS PrivateLink：NLB に endpoint service を作成し、顧客が自分の VPC に interface endpoint を作成する
公開するのは当該サービスだけで、通信は顧客からお客様への一方向であり、CIDR が重複しても問題ありません。
不正解: 顧客ごとに VPC ピアリングを行う
CIDR の重複は許されず、数百の接続の管理が困難で、1 つのサービスではなくネットワーク全体を開放してしまいます。
7S3 上の静的 Web サイトを HTTPS でグローバルに配信する必要があり、バケットから直接読み取られてはいけません。
答えを見る
正解: プライベートな S3 バケットをオリジンにした CloudFront で OAC を有効にし、バケットポリシーでそのディストリビューションだけを許可する
ユーザーは CloudFront (キャッシュ、HTTPS、WAF あり) 経由でのみアクセスでき、バケットはプライベートのままです。
不正解: S3 の静的ウェブサイトホスティングを有効にし、バケットを公開する
誰でもバケットから直接読み取れてしまいます。また、S3 のウェブサイトエンドポイントは HTTPS をサポートしません。
不正解: OAI を使う
動作はしますが古い方式で、SSE-KMS と PUT/DELETE をサポートしません。
8アプリケーションが 2 つのリージョンで稼働しています。通常は全員がメインリージョンにアクセスし、メインリージョンが故障したら自動でセカンダリリージョンに切り替えます。
答えを見る
正解: Route 53 failover routing：primary レコードにヘルスチェックを設定し、secondary レコードをセカンダリリージョンに向ける
ヘルスチェックが失敗すると、Route 53 が secondary レコードを返します。
不正解: Latency routing
レイテンシーに応じてユーザーを両方のリージョンに振り分けるため、active-passive ではありません。
不正解: ヘルスチェックなしの Weighted 100/0
メインリージョンが故障しても自動で切り替わりません。
9マルチプレイヤーゲームが 3 つのリージョンで UDP を使っています。法人顧客がファイアウォールを開けるために固定 IP のリストを求めています。
答えを見る
正解: AWS Global Accelerator
2 つの静的 anycast IP、UDP に対応、最寄りの正常なエンドポイントを選択、DNS を待たずにフェイルオーバー。
不正解: CloudFront
HTTP(S)/WebSocket のみで、IP も変動します。
不正解: Route 53 latency routing
IP は各リージョン固有のもののままで、エンドポイントを変えると変わります。フェイルオーバーも DNS キャッシュに依存します。
10オンプレミスのサーバーが Route 53 のプライベートホストゾーンの名前を解決する必要があり、EC2 は社内の内部ドメイン名を解決する必要があります。
答えを見る
正解: Route 53 Resolver：inbound endpoint (オンプレミスから VPC への問い合わせ) と、outbound endpoint + forwarding rule (VPC からオンプレミス DNS への問い合わせ)
VPN または Direct Connect 経由のハイブリッドネットワークで、AWS が提供する双方向 DNS の方法です。
不正解: DNS レコードを双方に手作業でコピーする
ずれが生じやすく、自動で更新されません。
早見表
何と何を接続する必要がありますか？
| やりたいこと | 使うもの |
|---|---|
| プライベートサブネット内のマシンがインターネットへ出る必要がある (一方向) | NAT Gateway (zonal：AZ ごとに 1 つ、または regional モード) · 図を見る |
| VPC から S3 / DynamoDB へ、インターネットを経由しない | Gateway endpoint (無料) · 図を見る |
| VPC から他の AWS サービスへ、またはオンプレミスから S3 へ | Interface endpoint (PrivateLink) · 図を見る |
| 少数の VPC が直接通信する必要があり、CIDR が重複しない | VPC ピアリング · 図を見る |
| 複数の VPC、複数のアカウントで、オンプレミスへの経路を共有する | Transit Gateway · 図を見る |
| 顧客に自社のサービスを呼び出させる、CIDR が重複する可能性がある | PrivateLink (NLB 上の endpoint service) · 図を見る |
| オンプレミス ↔ AWS、すぐに必要、またはバックアップとして | Site-to-Site VPN · 図を見る |
| オンプレミス ↔ AWS、大量のトラフィック、安定したレイテンシー | Direct Connect (+ バックアップ VPN) · 図を見る |
| Web / 画像 / 動画をキャッシュ付きでグローバルに配信する | CloudFront (+ S3 には OAC) · 図を見る |
| グローバルな TCP/UDP、静的 IP が必要、高速フェイルオーバー | Global Accelerator · 図を見る |
| メインリージョン障害時にセカンダリリージョンへ切り替える (DNS) | Route 53 failover routing + ヘルスチェック · 図を見る |
落とし穴
- 1 つの NAT Gateway (zonal) をすべての AZ で共有する：NAT がある AZ が停止すると、他の AZ のインターネット接続が失われます。
- NAT Gateway をプライベートサブネットに置く：インターネットへ出られません (zonal タイプの NAT は、IGW へのルートがあるパブリックサブネットに置く必要があります)。
- NACL のインバウンドだけを開けて、エフェメラルポート 1024–65535 のアウトバウンドを忘れる：戻りのパケットがブロックされ、接続がハングします。
- A–B と B–C をピアリングすれば A から C に到達できると思い込む。
- CIDR が重複する 2 つの VPC をピアリングする：作成できません。
- セキュリティグループで IP を「ブロック」しようとする：SG には deny がありません。
- gateway endpoint なら無料でできるのに、プライベートサブネットから NAT 経由で S3 にアクセスする。
- オンプレミスや Transit Gateway 経由のトラフィックに gateway endpoint を使う：できません。interface endpoint が必要です。
- Direct Connect が自動で暗号化すると思い込む：されません。DX 上の VPN か MACsec が必要です。
- UDP トラフィックや静的 IP が求められる問題で CloudFront を選ぶ：正解は Global Accelerator です。
- active-passive の要件に latency routing を選ぶ：正解は failover routing です。
- 稼働中のマシンにアタッチした Elastic IP は無料だと思い込む。
このモジュールのサービス
VPCAWS 内の専用網
ELBリクエスト分散
Route 53DNS、ドメイン設定- Route 53 ResolverVPC向け内部DNS
CloudFrontCDN・エッジキャッシュ
Global Acceleratorグローバルなネットワーク高速化
Transit GatewayVPCをつなぐ中央ハブ
PrivateLinkサービスへのプライベート接続
Site-to-Site VPNオンプレミス接続用VPN
Client VPNリモートユーザー向けVPN
Direct ConnectAWSへの専用回線
VPC Latticeservice-to-serviceネットワーク
Network FirewallVPC 向けネットワーク firewall
変わりやすい数値 (AWS ドキュメントで確認済み)
- NAT Gateway は 5 Gbps に対応し、100 Gbps まで自動で拡張します。1 秒あたり 100 万パケットで、1,000 万まで自動で拡張します。セキュリティグループはアタッチできません。 2026-10-16 確認 ↗
- NAT Gateway には regional モードがあり、ワークロードのある AZ に自動で展開され、パブリックサブネットも不要です (2025 年 11 月提供開始)。 2026-10-16 確認 ↗
- パブリック IPv4 は 1 時間あたり 0.005 USD で課金されます。リソースにアタッチ済みの Elastic IP も同様です。 2026-10-16 確認 ↗
- Route 53 には 8 つのルーティングポリシーがあります：simple、failover、geolocation、geoproximity、latency、IP-based、multivalue answer、weighted。 2026-10-16 確認 ↗
- Transit Gateway：VPC アタッチメントあたり、AZ ごとに、各方向で最大 100 Gbps。 2026-10-16 確認 ↗
- Direct Connect の dedicated：ポートは 1、10、100、400 Gbps。 2026-10-16 確認 ↗
- Site-to-Site VPN：トンネルは通常最大 1.25 Gbps、大容量帯域トンネルは最大 5 Gbps、MTU は 1446。 2026-10-16 確認 ↗
- AWS は OAI ではなく OAC の利用を推奨しています。OAI は SSE-KMS、PUT/DELETE、新しいリージョンをサポートしません。 2026-10-16 確認 ↗
- IPv4 のサブネットは /28 から /16 までで、先頭の 4 アドレスと末尾の 1 アドレスは予約されます。 2026-10-16 確認 ↗
- IPv4 の VPC は /16 から /28 までで、既存の CIDR のサイズは変更できず、セカンダリ CIDR を追加することしかできません。 2026-10-16 確認 ↗
- Gateway endpoint は無料ですが、オンプレミス、別リージョンとのピアリング、Transit Gateway 経由では使えません。 2026-10-16 確認 ↗
- Global Accelerator は 2 つの静的 anycast IPv4 を割り当てます (dual-stack：IPv6 を 2 つ追加)。ヘルスチェックとエンドポイントの切り替えは自動です。 2026-10-16 確認 ↗
- CloudFront の origin group は 2 つのオリジン (プライマリとセカンダリ) で構成されます。フェイルオーバーは、プライマリオリジンが 400、403、404、416、429、500、502、503、504 のうち選択したコードを返したときに、GET、HEAD、OPTIONS リクエストに対してのみ行われます。 2026-10-19 確認 ↗
- VPC Flow Logs は CloudWatch Logs、S3、または Amazon Data Firehose に書き込まれます。データはトラフィックの経路の外で収集されるため、スループットやレイテンシーに影響しません。 2026-10-19 確認 ↗