新サービスに触る前に学び直す、AWSのネットワーク基礎知識まとめ

最近のAWSでは、Transit GatewayやDirect Connect Gatewayなど、ネットワークをよりシンプルに分かりやすくするための高度なネットワークサービスが増えてきました。
忙しくなってくると、ただでさえアップデートに追いつくのは大変ですが、既存のサービスの考え方を上書きするような高度なサービスが出てきたので、ワケワカラン！となる前に何とかしなければ、と不安に思っていました。

ただ、これらのサービスを腹落ちして使うためには、これらのサービスが登場する以前のAWSのネットワークについて、基本的な考え方であったり、概念や知識を今一度押さえておきたいところです。

そこで一念発起して、これまでの総復習として、AWSの公式ドキュメントを読みまくり、AWSのネットワークに関する基礎知識を調べ、これらの基礎知識をさらっとおさらいできるようにまとめてみました。
最初は自分の知識整理のためだったのですが、少しずつ整理していたところ、かなりの量がまとまってきたので、公開してしまおうと思い立ちました。
気軽にスマホで1時間くらいで総復習できるようにと、できるだけ短くまとめ、簡単な表現にしています。

これらの知識を総ざらいすることは、これからAWSのネットワークを学び始めたり、既存のAWSのネットワーク設計を高度化しようと考えている人だけでなく、AWS認定のネットワーク専門知識の試験対策にも良いかも知れません。

前提

• 2019年12月時点の情報です。
• AWSのネットワーク周りの基礎を振り返るためにまとめました。
• 以下の項目は入っていません。以下の項目に挑む前の知識整理と考えてまとめています。
  • Transit Gateway
  • Direct Connect Gateway
  • Global Accelerator

1. VPC

1-1. What is VPC?

• AWS上の仮想プライベートネットワーク
• 各リージョンに配置可能
• 複数のAvailability Zone (AZ) にまたぐ (Multi-AZ) が可能
  • AZは地理的に離れている
• VPC内に公開 (Public) と非公開 (Private) のネットワーク (Subnet) を配置可能
  • PublicとPrivateを別のAZに配置可能
• VPCにつき1つ、インターネットへの出口 (Internet Gateway) を配置可能
• 仮想ルータ (Route Table) を複数配置可能
  • SubnetごとにRoute Tableを設定可能
  • Internet Gatewayへのルートがあれば、インターネットと通信可能
• VPN接続が可能

1-2. Default VPC

• リージョン毎に最初からデフォルトで存在
  • リージョンに存在するAZにつき1つSubnetが存在
• Default VPCであるかどうかはマネジメントコンソールの属性を見れば分かる
• Subnetに作成したEC2には自動的にPublic IPが割り当てられる設定 (Auto-assign public IPv4がYes)
• Internet Gatewayはデフォルトで存在
• Route Tableのデフォルトゲートウェイ(0.0.0.0/0)はInternet Gateway
• Network ACLは全てのトラフィックを許可する設定
• Default VPCは削除可能
• Default VPCは1ボタンで再作成可能
  • Subnet、Internet Gateway等Default VPCにデフォルトで含まれる全てのものを再作成可能

1-3. Custom VPC

• リージョンを選んで独自の設定でVPCを作成可能
  • Launch VPC Wizardを使うと、4つのパターンから、Subnetも含まれている状態で、自動的にVPCを作成可能
  • 通常はVPCだけ作成
• VPC作成時にTenancyを選択可能
  • Defaultはアカウントを跨いだ共有領域に作成され、Dedicatedはアカウント専用領域に作成
• VPCを作成するとデフォルトでMain Network ACLとMain Route Tableが作成される
  • Main Network ACLはInbound/Outbound共に全てのトラフィックが許可
  • Main Route Tableでは、VPCにあるSubnet間であれば通信を許可 (local)
• VPC内にSubnetを作成可能
  • SubnetのネットワークアドレスはVPCのサブセット
  • AZをプルダウンで選択可能
  • Subnetを作成するとデフォルトでMain Network ACLとMain Route Tableがアタッチされる
    • 新しくNetwork ACLを作成してMain Network ACLと置換可能
    • 新しくRoute Tableを作成してRoute Tableと置換可能
  • Subnet作成直後は、Auto-assign public IPv4がNo
    • Yesに変更すると、EC2構築時にPublic IPを自動アサイン可能
    • Private SubnetではNoのままにしておく

1-4. VPC Limits

• リージョン毎に作成できるVPCは5個まで
  • 100個まで引き上げ可能
• VPC内のSubnetは200個まで
• Elastic IPは5個まで
• Network ACLは200個、ルールは20個まで
• Route tableは200個、ルートは50個、BGPルートは100個まで
• Security Groupは2500個、ルールはInbound/Outboundで各60個、Network Interface (ENI) 毎のSecurity Groupは5個まで

1-5. Data Transfer Costs

• Data Transfer Guideが分かりやすい (価格はUS基準で記載)
• Direct Connect経由とInternet Gateway経由はInが無料、Outに課金
  • Direct Connectの方がOutが安い傾向
• ロードバランサとインターネットの間の通信コストはIn/Outともに課金
  • EC2とロードバランサ間の通信コストは、同じAZなら無料、異なるAZではEC2→ロードバランサに課金
  • ALBとCLBでは、ALBの方が通信コストが安い
• CloudFrontからオリジンへの通信 (Out) に課金、CloudFrontへの通信 (In) は無料
• AZを跨いだEC2間の通信は、In/Outともに課金 (In/Out同時課金)
• VPC Peeringを挟んだEC2間の通信も、In/Outともに課金 (In/Out同時課金)
• リージョンを跨いだEC2間の通信は、Out側のみ課金され、Inは課金されない
• EC2同士、またEC2とRDS/RedShift/ElastiCache間の通信は同一AZでは無料
  • AZを跨いだ場合、In/Outともに課金
  • EC2間の通信がインターネット経由(Public IP等)となった場合、In/Outともに課金
• NAT Gatewayは、起動時間と通信データ量に応じて課金
  • 起動時間ごとに課金
  • NAT Gatewayを1GB通過する度に課金
  • NAT Gatewayの通信データ量の課金は、EC2の通信データ量の課金と同じ
    • AZを跨いだ場合に課金される点が重要

2. Subnet & Routing

2-1. Route Table

• Main Route Tableには、VPC内のいずれのSubnetとも通信できるlocalルールがデフォルトで存在
  • Subnet毎にCustom Route Tableを作成してアタッチ可能
• デフォルトゲートウェイ(0.0.0.0/0)をInternet Gatewayとするルートを追加すれば、直接インターネットと通信可能 = Public Subnet
• デフォルトゲートウェイ(0.0.0.0/0)をNAT Gatewayとするルートを追加すれば、NAT Gateway経由でインターネットと通信可能 = Private Subnet
• Custom Route Tableの作成はNameタグとVPCを指定するだけ
• Route Tableを作成後にSubnetをアサイン
• Route Tableを作成後にルートを追加
  • Targetが各種ゲートウェイやNetwork Interface (ENI) の場合、プルダウンでIDを選択可能
• Main Route Tableであるかどうかは属性で確認可能

2-2. Reserved IP Address

• SubnetのIPアドレスは先頭の4アドレスと最後の1アドレスが予約されている
  • サブネットの1番目のアドレスがネットワークアドレス
  • サブネットの2番目のアドレスがデフォルトVPCルータ
  • サブネットの3番目のアドレスがデフォルトDNSサーバ
  • サブネットの4番目のアドレスは将来のための予約アドレス
  • サブネットの最後のアドレスはブロードキャストアドレス

2-3. Dual-Homed Instance

• 同じVPCの複数のSubnetに属するEC2のこと
  • 例えばPublic SubnetとPrivate Subnetの両方に属し、両方のENIを持つ
• ENIはSubnet毎に存在し、Security GroupはENI毎に存在
• Elastic IP/Public IPは、Public SubnetのENIにアタッチ
• 通信ログを追う場合、VPC Flow LogsでENI毎にフィルタして分析できるため、ENIがPublicとPrivateで分かれていると分析が容易になる

2-4. Internet Gateway

• EC2がインターネットに通信する時、Internet Gatewayを通過する時にソースIPアドレスがPrivate IP→Public IP/Elastic IPにNATされる
• Internet GatewayはVPCのマネジメントコンソールから作成可能
  • VPCを指定して作成し、VPCにアタッチして使用する

2-5. Public Subnet/Private Subnet

• Public Subnetの特徴は以下の通り
  • Route TableのデフォルトゲートウェイがInternet Gateway
  • (広義) Auto-assign public IPv4 addressがYes

2-6. VPC Addressing

• VPCに複数のIPv4 CIDRをアサイン可能だが、最初にアサインしたCIDRは削除できない
• VPCにアサインできるIPv6 CIDRは1個まで
• 既存のSubnetにIPv6 CIDRを追加できるが、VPCにアサインしたサイズをそのまま追加

3. EC2 in VPC

3-1. Creating EC2

• VPC、Subnet、Auto-assign Public IPを指定
  • Auto-assign Public IPを指定すると、Public IPがアサインされてEC2が起動される
• ENIを設定
• Security Groupを新たに作成してアタッチ可能
  • OSを操作するためにSSHを許可する
• OS内部ではPublic IPは見えない
• Public IPはEC2をStopするとリリースされ、次にStartした時に新しいPublic IPが割り当てられる

3-2. Elastic IP

• Elastic IPアドレスは、EC2をStopしても削除されず固定される
• マネジメントコンソールで作成可能
• 作成後、InstanceまたはNetwork Interfaceを指定するとアサイン可能
• 不要になればEC2からデタッチして削除する

3-3. Elastic Network Interface (ENI)

• EC2は作成直後にeth0の1個だけENIを持つ
• ENIはマネジメントコンソールから新たに作成可能
• 作成したENIをEC2にアタッチするとeth1ができる
  • 以降eth2、eth3…
• ENI毎にSecurity Groupが異なるため注意
• この方法でPublic SubnetとPrivate Subnetの両方のENIを持つEC2などを作成可能
• 不要になればeth1以降のENIはデタッチして削除可能

3-4. Bastion Host

• 踏み台のこと
• まずは踏み台にSSH/RDPをして、他のサーバへのSSH/RDPは踏み台経由に限定するのがセキュア
  • 踏み台のみがPublic IP/Elastic IPを持ち、他はPrivate IPのみ持つようにする

3-5. Enhanced Networking

• ネットワーク仮想化
  • EC2 (仮想マシン) は物理ホスト上で稼働
  • その物理ホストに仮想スイッチが存在
  • ハイパーバイザーを介して無数のEC2が仮想スイッチを共有
• SR-IOV
  • EC2のENIが、直接物理ホストのネットワークアダプタに接続
• SR-IOVに対応したEC2インスタンスタイプは限られる
• 対応表を見て正しいドライバをインストールすること
  • ENAは最大100Gbpsをサポート
  • Intel VFは最大10Gbpsをサポート
  • ネットワーク性能はインスタンスタイプによるので要確認
• ドライバのロード状況はOS内部で確認可能
  • 対応するためにカーネルのアップデート、バッケージのアップデートが必要なケースあり

3-6. Placement Group

• 同じAZの中には複数のデータセンタがあり、さらにデータセンタ内には複数の物理ホストがある
• 通常、EC2を構築する時、どこのデータセンタと物理ホストが選ばれるかを制御できない
• Placement Groupで、全てのEC2の配置をある程度コントロールすることが可能
  • EC2初期構築時に、Placement Groupを指定して構築
  • 同じインスタンスタイプを一貫して使用する方が高速化
  • 後からEC2を追加できない可能性もあり
  • 既存のEC2は追加できない
  • Placement Groupでは、シングルフローのトラフィックが5Gbpsから10Gbps

Cluster Placement Group

• 単一AZ
• 同一リージョン内でVPC Peering経由でVPCをまたぐことが可能
• 10Gbps
• 低遅延で、ノンブロッキング、ノンオーバーサブスクライブ
• キャパシティエラーが出た場合、対応するには全てのEC2をStop→Startする必要がある

Partition Placement Group

• 単一AZ内で複数のパーティション
• 各パーティションが異なるラックに配置
• ワークロードを隔離したり複製する場合に有効
• 各AZにパーティションを持てる

Spread Placement Group

• 同一リージョンのAZにまたがって配置可能
• 全てのインスタンスを異なる電源/ネットワークを持つラックに配置
• 少数の重要なインスタンスを分散させる場合に有効
• 1グループあたり7インスタンスまで

3-7. EC2 Instance Metadata

• EC2インスタンスから http://169.254.169.254/latest/meta-data にアクセスするとメタデータを得る
• メタデータへの接続はSecurity GroupとNetwork ACLでフィルタできない
  • OSの外側かつSecurity Groupの内部にあると考える
  • OSのファイアウォール機能を使えば接続を遮断可能
• Proxyを経由してアクセスできないため、Proxyの設定からは除外する
  • NO_PROXYを設定

3-8. AWS Config

• AWS Configのマネージドルールを活用すれば、VPCのコストを最適化できる
• eip-attached
  • Elastic IPがEC2にアタッチされているか確認する
  • Elastic IPはEC2にアタッチされていないと課金されてしまう

4. Network Address Translation

4-1. NAT Instance

• Public SubnetはデフォルトゲートウェイがInternet Gateway
• NAT InstanceはPrivate SubnetのEC2にインターネット接続を提供
  • Public SubnetにNAT Instanceを起動
  • Private SubnetのデフォルトゲートウェイをNAT Instanceに指定
• NAT Instanceは手動でスケールしたり、フェールオーバーのための仕組みが必要
• NAT InstanceのSource/Destination Checkを無効にしないと通信できない
  • SourceまたはDestinationがNAT Instanceにはならないトラフィックを、NAT Instanceで送受信するため

4-2. NAT Gateway

• NAT Instanceの代わりにNAT Gatewayを採用
• Private SubnetのデフォルトゲートウェイをNAT Gatewayに指定
• 利点
  • EC2が不要
  • 完全マネージドサービスでスケールやパッチの管理が不要
  • 複数AZに跨いで構築可能
  • 複数NAT Gatewayを同一AZに構築可能
• 欠点
  • 踏み台にはならない (NAT Instanceは踏み台としても使える)
  • ポートフォワーディングを手動で設定できない
  • セキュリティグループを割り当てることができない
• NAT GatewayはVPCのマネジメントコンソールから作成可能
  • Subnetを指定し、Elastic IPを紐付けて作成
  • Elastic IPを新たに作成も可能
• NAT Gatewayの制限と特徴
  • 必ず1つの特定のAZに属する
  • 5Gbpsの帯域をサポートし、45Gbpsまで自動的にスケールアップする
  • Elastic IPを外すことはできない
  • Security Groupは適用できない
  • 1024-65535ポートを使用するため、Network ACLを開放する
  • 送信先別に最大55000の同時接続をサポート
    • 単一の送信先に1秒あたり約900の接続
    • 送信先IPアドレス、送信先ポート、またはプロトコル (TCP/UDP/ICMP) が変更された場合は、追加の55000の接続を作成可能

5. VPC Peering

5-1. What is VPC Peering?

• 同じアカウントまたは異なるアカウントにある2つのVPCを接続するための機能
• VPC AからVPC Bに接続リクエストし、VPC Bが承認すれば接続
• VPC AとVPC BでIPアドレスの重複は不可
• 接続先VPCのネットワークアドレス宛のTargetをVPC Peering(pcx-…)にするルートを、Route tableに追加
• VPC 1、 VPC 2、VPC 3とあって、1-3と3-2がつながっている構成の場合
  • 1と2は直接接続できない
  • 1と2でPeeringすれば接続可能
• アカウントとVPCが増えるほど、トポロジーは複雑となる

5-2. VPC Peering Design

• 3つ以上のVPCがあり、共有VPCを作る場合
  • 共有VPCと直接的に接続するVPC CIDRは、互いにユニークであること
  • 例えば共有-A、共有-Bという構成の場合、共有とA、共有とBのCIDRは重複不可
  • ただしAとBのVPCはCIDRが重複して良い
    • 共有VPCのRoute Tableで宛先が特定されており、Targetが分かれていれば良い
    • 共有VPCに2つSubnetがあり、各サブネットのSubnetのRoute TableでTargetが分かれていてもOK

5-3. Overlapping CIDR

• 例: VPC1-VPC2(共有VPC)-VPC3という構成
  • VPC1とVPC3のCIDRが重複
  • VPC1-VPC2、VPC1-VPC3のCIDRはユニーク
  • VPC1とVPC3に同じIPアドレスのEC2が構築されている
  • VPC2にEC2が2台あり、片方はVPC1、もう片方はVPC3と通信したい場合
• VPC1のSubnetと、VPC2のSubnetのCIDRを分けれは解決できる
  • VPC1とVPC3の各EC2を、作成したSubnetに移動する
  • VPC2では各SubnetのCIDRに応じてTargetを分ける

5-4. VPC Peering Connection

• リクエスタのVPCと、アクセプタのVPCを指定して作成する
  • リクエストが送られてPendingとなり、リクエストがAcceptされると接続される

5-5. DNS for VPC Peering

• VPC Peeringの設定で、アクセプタVPCのホスト名をPrivate IPに解決するようにDNSの設定を追加可能
  • この設定が有効になると、例えばアクセプタVPCのPublicホスト名をルックアップすると、プライベートIPアドレスが返るようになる
  • 逆方向の設定も可能

5-6. Delete VPC Peering

• VPC Peeringを削除しても、Route Tableのルールは自動で消えず、Blackholeとなる

5-7. Costs of VPC Peering

• In/Outの両方に課金される

6. VPC Security and Monitoring

6-1. Security Group

• ステートフルなファイアウォール
• Inboundルールがあれば、対応するOutboundルールは不要
• ENIあたり最大5個
• Inboundはデフォルトで全拒否、Outboundはデフォルトで全許可
  • Outboundのデフォルト全許可ルールは削除が可能
• 許可ルールのみ設定する
• EC2毎に異なるSecurity Groupをアタッチするのが王道
• EC2のIPアドレスではなく、Security GroupのIDを指定してアクセス許可が可能

6-2. Security Group vs Network ACL

• ENIに複数のSecurity Groupをアタッチ可能
  • 後からでもSecuriuty Groupのアタッチ状況を変更可能
• Network ACLはステートレスファイアウォール
  • Inboundルールに対応するOutboundルールが必要
  • ルール番号が若い順に評価
  • 宛先やポートを特定してDENYするルールは、ALLOWよりも先に入れるのがベストプラクティス
• Network ACLは、作成直後のデフォルトが全拒否
  • ルール番号が*のルールは削除できない
• 外部からアクセスがあると、まずNetwork ACLが判定され、パスするとSecurity Groupが判定される
• EC2インスタンスのメタデータへのアクセス制限
  • Security Groupでは制限できない (SGよりも内側にあると考えるべき)
  • メタデータへのアクセスはOSのファイアウォールで保護する

6-3. Virtual Private Gateway

• リージョン毎に5個まで
• VPCにアタッチして使用
• デフォルトで高可用性がある
• オンプレミスのデータセンタとVPN Connectionで接続
• オンプレミス→VPC
  • Next HopをVPN Routerに向ける
• ルートの伝播
  • VGWからRoute TableにBGP routeが自動で追加される
  • 最も具体的なプレフィックスが優先される
  • 手動で設定されたルートが優先される
  • ローカルのルートが優先される

6-4. VPC Endpoint

• S3とDynamo DBにプライベートアクセス
  • Gateway型エンドポイントと呼ばれる
• 通常、Internet Gateway経由で接続する
  • Private SubnetではNAT経由
• VPC Endpointがあると、Private SubnetからGatewayを通り直接アクセス
• Route Tableには「pl-…」宛の通信がGatewayを向くようにルートが設定される
• リージョン毎に存在
• 1つのVPCに対して1つのGatewayが紐づく
• VPC Peering経由、VPN Connection経由では接続不可
• VPC内でPublicアドレスをPrivateなEndpointアドレスに解決することが必要
• Endpointポリシーで、IAMポリシーのようにアクセス制御が可能

6-5. AWS WAF

• AWS MarketPlaceではサードパーティ製WAFアプライアンスを購入可能
• WAFサンドイッチ
  • WAFをスケールするためにAutoScalingポリシー下で実行する
  • 2つのロードバランサ (ELB) 間に配置
• AWS WAF
  • CloudFrontまたはELBにデプロイ可能
  • SQLインジェクションやクロスサイトスクリプティングなどに対応するマネージドルール
  • APIでコントロール可能
• CloudFrontでコンテンツのアクセス制限をかける方法
  • オリジンアクセスアイデンティティを使用
  • AWS WAFのIPホワイトリストを適用してアクセス制限

6-6. VPC Flow Logs

• VPCのネットワークログ
• CloudWatch Logsに保管
• VPC、Subnet、EC2 (ENI) で作成可能
• accepted、rejected、allを選んで記録可能
• 10分毎にログが公開される
• VPC Flow Logs用のIAM Roleが必要
  • VPC Flow Logsサービスとの信頼関係も必要
• ログではENI、Source、Destination、Source Port、Destination portを判断可能
• Flow Logsは作成後に変更できない
• AWS DNSサーバへのトラフィックは記録されない
• Windowsライセンス認証のためのAWSライセンスサーバへのトラフィックは記録されない
• DHCPトラフィックは記録されない
• 予約されたデフォルトVPCルータへのトラフィックは記録されない
• インスタンスメタデータへのトラフィックは記録されない
• リアルタイムには記録されない
• CloudWatch Logsに出力するためにIAM Roleが必要
• ENIごとにログストリームができる

6-7. Analyze Firewall Rules

• https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs-records-examples.html を参照

6-8. Proxy

• EC2からのインターネット接続にホストベースのアクセス制限をかけるにはProxy EC2が必須
• 可用性を持たせるには複数AZにまたぎ、ロードバランサと併用を検討する

6-9. Deep Packet Inspection

• 通常とは異なるトラフィックを検知して分析
  • AWS MarketPlaceでサードパーティ製アプライアンスを購入することで、多くの場合分析が可能
• モニタリングはCloudWatch、CloudWatch Logs、VPC Flow Logsでも可能

7. Elastic Load Balancer

7-1. What is ELB?

• EC2インスタンスのトラフィックを負荷分散
• 複数のAZに存在するインスタンスに負荷分散可能
• リージョンをまたぐには複数ELBを用意してRoute53を併用
• ELBはALB、NLB、CLBの3種類
• ヘルスチェック機能があり、応答しないEC2インスタンスにはリクエストを送らない
• Internet-Facing ELB
  • Route53でPublicホスト名をエイリアスレコードで解決
• Securuty GroupをELBにアタッチしてアクセス制御可能
• マネジメントコンソールからELBの種類を選択して作成
  • さらに分散するAZと、ターゲットにするEC2を選択

7-2. Listener and Encryption

• HTTP/HTTPSリスナー
  • port 1-65535でHTTPまたはHTTPSをサポート
  • HTTPSリスナーは暗号化と復号化をELBにオフロード
  • HTTPSはX.509 SSL証明書のデプロイが必要
    • AWS Certificate Managerがデプロイに使える
  • サードパーティー証明のためにCSRが必要
  • 複数の証明書を、複数のドメインに利用
• Fixed-Response Actions
  • 特定のターゲットグループにリクエストをforward可能 (リダイレクト)

7-3. Target Group

• TargetのTypeにEC2インスタンス、IPアドレス
• ALBの背後にLambdaを配置可能
• 同じインスタンスで複数のポートをTargetに指定可能
• slow_start.duaration_seconds
  • 新しく登録されたターゲットに対しトラフィックをリニアに増やすよう、時間を指定
• スティッキーセッション
  • Cookieを利用して同じターゲットと通信

7-4. Host Condition/Path Condition

• Host Conditions
  • example.com (APEXの例)
  • dev.example.com (特定ホストの例)
  • test.example.com (特定ホストの例)
  • *.example.com (ワイルドカードの例)
    • example.com以外のトラフィックを指す
• Path Conditions
  • /img/*
  • /js/*
  • .example.com/img/

7-5. Connection Draining

• ELBから登録解除したり、ヘルスチェック失敗したインスタンスへのリクエストを止める
• 止めつつも、処理中のリクエストはそのまま処理を続ける
• 期間は1秒から3600秒まで
• Auto ScalingはConnection Drainingを待つ
• 簡単に有効/無効を切り替えられる

7-6. X-Forwarded

• EC2から見るとELBのプライベートアドレスから全てのリクエストが来たように見える
  • 本当はELBの前にいるクライアントのIPアドレスが知りたい場合が多い
• リクエストヘッダのX-Forwardedを見ればクライアントのIPアドレスが分かる
  • ALB、CLBでサポート
  • 有効/無効の特別な操作は不要

8. DNS with Route 53

8-1. Route 53

• DNSレコードの種類
  • A: IPv4 IPアドレス
  • AAAA: IPv6 IPアドレス
  • CNAME: 別ホスト名 (APEXは指定不可)
  • MX: Eメール
  • NS: 別のネームサーバ
• Route 53
  • AWSのDNSサービス
  • エンドポイントのヘルスチェックに対応
  • DNSは53番ポートで稼働
• Route53 Health Check
  • 間隔は調整可能
  • システムが冗長構成を取る場合に使える
• Weighted Routing Policy
  • ホスト名に複数IPアドレスを紐付けておき、例えばWeb1に90%、Web2に10%などの重み付けをしてリクエストを振り分け
• Latency-Based Routing Policy
  • ホスト名に複数IPアドレスを紐付けておき、レイテンシに基づいて振り分け
• Failover Routing Policy
  • ホスト名に複数IPアドレスを紐付けておき、通常はActive EC2インスタンスにリクエストを振り分け
  • ヘルスチェックに失敗する場合には、Standby EC2にリクエストを振り分ける
  • ELBは複数のリージョンを跨いでリクエストを振り分けられず、リージョン跨ぎはRoute 53の出番
• GeoLocation Routing
  • リクエスタの地理的位置に基づいてリクエストを振り分け
• Alias Record
  • CNAMEによく似ている
  • ELBにAPEXレコードを紐付けるのに使える

8-2. Register Domains on Route 53

• マネジメントコンソールで可能
• 登録後、レコードセットが編集可能に

8-3. Simple Routing Policy

• AレコードでALIASレコードを登録するには、Aliasにチェック入れる
  • ELBの場合は、TargetにELBのホスト名を入れる
  • APEXにALIASを入れる場合、解決したいホスト名は空欄にする
• AレコードでALIASを使わない場合、ValueにIPアドレスを入力する

8-4. Weighted Routing Policy

• 同じホスト名に複数のターゲットを紐付け、割合を設定すれば良い
• 動作確認は、クライアントのキャッシュを削除しながら実施

8-5. Latency-Based Routing Policy

• 同じホスト名に複数のターゲットを紐付け、低レイテンシの方に振り分けられる

8-6. Failover Routing Policy

• ヘルスチェックを設定する
  • エンドポイントをモニターする設定にして、モニターするIPアドレスを指定すると、グローバルIP単位で監視可能
  • ドメイン名をモニターする設定にすれば、Webサイト全体の監視可能
• 同じホスト名に複数のターゲットを紐付け、片方をPrimary、もう片方をSecondaryにする
  • Primaryの方に、発動条件となるヘルスチェックを紐付ける
  • Primaryに紐付けたヘルスチェックが発動すると、リクエストはSecondaryに振り分けられる
  • PrimaryとSecondaryの両方がダウンすれば、もちろん接続できない

8-7. GeoLocation Routing Policy

• レコードに対してロケーションを指定
  • 指定したロケーションに近い位置からのリクエストの場合、当該レコードで解決

8-8. Private Hosted Zone

• インターネット経由で解決するホスト名はPublic Hosted Zoneで解決
• プライベートネットワークでしか使わないホスト名はPrivate Hosted Zoneで解決
• Hosted Zoneを作る時にPrivateを選択すれば作成可能
• 複数のVPCを1つのZoneに割り当て、複数のVPCでZoneを共有

8-9. Hybrid DNS

• オンプレミスにDNSがあるとき、VPCにRoute 53 DNS Resolverを作って、オンプレミスからフォワードすることが可能
  • Inbound Endpointを作れば良い

8-10. Route53 Alias Record for CloudFront

• 地理的に一番近いEdge locationにリクエストが割り振られる

9. CloudFront

9-1. What is CloudFront?

• CDN
• 例えばS3に置いてあるコンテンツを世界中に公開したいとき
  • レイテンシが問題となる
  • CloudFrontを使えばコンテンツのキャッシュを世界各地のエッジロケーションにばら撒ける
  • 各地のユーザは一番近いエッジロケーションからコンテンツを受信するため低レイテンシとなる
• 設定したTTLが経過すると、エッジロケーションのコンテンツを最新化する
• 署名付きURLを使って、アクセス期限を設けることも可能
• セキュリティ
  • AWS WAFとの併用
  • AWS Certificate Manager
  • オリジンアクセスアイデンティティ
• Distributionsはマネジメントコンソールで作成
• オリジンにS3、ELBまたはRoute53を指定可能
• Webディストリビューションで、シンプルなWebサイトのデータを配信

9-2. Distribution

• CloudFrontのマネジメントコンソールで、Distributionを作成
  • Webを選択
  • S3バケットのURLを指定
  • オリジンアクセスアイデンティティに基づき、S3側でアクセス制限可能

9-3. HTTPS with CloudFront

• Viewer Protocol Policy
  • Redirect HTTP to HTTPS
  • HTTPS Only
• Origin Protocol Policy
  • Match Viewer

10. Hybrid Cloud with Datacenter

10-1. Use Cases

• Disaster Recovery
  • AWSをオンプレミスのDRサイトとして利用
• Cloud (Dynamic) Bursting
  • ピーク時だけオンプレミスからAWSに拡張する
• Data Center Extension
  • VPNでAWS VPCに接続し、オンプレミスのデータセンタを常時AWSに拡張
  • 1つのデータセンタのように使う
• AWSはISOやPCIなどの多くのコンプライアンスを満たしたデータセンタである

10-2. Software VPN

• Public SubnetにVPN Softwareを導入したEC2を準備し、EIPを付与
• Route Tableでオンプレミス宛通信を上記EC2に向けるルートを作成
• Internet Gateway経由でオンプレミスとVPNを張る
• コンプライアンスに応じて準備できる
• EC2インスタンスを準備する必要があり、停止すれば接続断となってしまう
• 複数AZにまたがってVPN EC2を構築し、高可用性をもたせることは可能

10-3. Hardware (Managed) VPN

• オンプレミス側データセンタにVPNルータを置き、AWS VPC側のVirtual Private Gateway (VGW) との間でVPNを接続
• 設定が簡単
• 管理も不要
• 高い可用性
• DirectConnectと併用可能
• 通信データ量にかかる金額はDirectConnectの方が安い

10-4. Static Hardware VPN

• BGPがサポートされない環境ではStaticルーティング
• Customer Gateway (CGW) を作成
  • Staticを選び、オンプレミスのルータのグローバルIPを指定
• VGWを作成
• VPN Connectionをオンプレミスのルータ (GGW) とVGW間で作成
  • Site-to-Site VPN
  • Staticを選択
  • Static IP Prefixでオンプレミス側のネットワークアドレスを記入
  • VPN Tunnel Optionsで169.254.0.0/16から/30でアドレス指定
    • 予約されているアドレスは指定不可
• Route TableでVGWからのPropagateをONにする
• オンプレミスのルータに応じたコンフィグをダウンロードして、オンプレミス側で設定

10-5. BGP

• 各ネットワークをつなぐには、ルータ間でBGP PEERを結ぶ
  • 互いのネットワークの経路情報を交換 (共有)
• Weight and AS Path
  • Weight: 32768 (デフォルト)
  • 同じ宛先でもWeightを変えることで優先付けが変わる
  • Next HopとAS Pathを指定

10-6. BGP Hardware VPN

• VPNをAWS側の2つのエンドポイントとの間で張る
  • エンドポイントは異なるハードウェアであり冗長性がある
• Customer Gateway (CGW) を作成
  • Dynamicを選び、オンプレミスのルータのグローバルIPを指定
• VGWを作成
• Route TableでVGWからのPropagateをONにする
• VPN Connectionをオンプレミスのルータ (GGW) とVGW間で作成
  • Dynamicを選択
  • VPN Tunnel Optionsで169.254.0.0/16から/30でアドレス指定
    • 予約されているアドレスは指定不可
• オンプレミスのルータに応じたコンフィグをダウンロードして、オンプレミス側で設定

10-7. VPN BGP Routing

• 構成例
  • AWS側に2つのエンドポイントのグローバルIPアドレス
    • 各TunnelにAWSのネットワークアドレス
  • オンプレミス側ルータに1つのグローバルIPアドレス
  • Tunnelの両端にTunnelネットワークアドレスからIPアドレスをアサイン
• オンプレミス側ルータの設定例
  • 自身のプライベートネットワークに、Weight:32768、AS Path:i
  • AWS側ネットワークアドレスに、Weight:0、AS Path:64512,i
    • Next HopはTunnelの対向アドレス
• AWS側ルータは上記の逆となる

10-8. CloudHub

• 構成例
  • AWS側 (ASN 64512)
  • オンプレミスA (ASN 65000)
  • オンプレミスB (ASN 65001)
• AWS側では、オンプレミスAとBに対するルートを持つ
  • Next HopとAS Pathは適切に設定される
• オンプレミスBからAへのルート
  • 宛先がオンプレミスAの時のNext HopをVGWに向ける
  • AS Path: 64512,65000,i
• VGWを介してオンプレミスAとBが接続されるためCloudHubと呼ぶ
• AS番号は必ず分ける

10-9. Transit VPC

• 多くのVPCを接続するシチュエーション
• Transit VPCを作成し、中にSoftware VPNソリューション on EC2を作成
• その他多くのVPCでVGWを作成
• 全てのVGWとEC2の間でVPNを接続
  • BGPで接続
  • AS番号を適切に設定
• なぜVPC Peeringではだめなのか
  • VPC PeeringのGatewayがNext Hopとなってしまう

10-10. Security Group over Region

• リージョンをまたいでSecurity Group IDを参照不可
  • リージョンをまたぐ場合はIPアドレスレンジを指定してアクセス制御

10-11. Private EMR

• S3にデータを置く場合、S3 Endpointと併用する

10-12. Workspaces

• 異なるAZにある2つのPrivate Subnetと、1つのPublic Subnetの構成を推奨
• インターネット接続はNAT Gateway経由を推奨
• VPN経由で接続する場合1200 MTUを最低でも確保

11. Direct Connect

11-1. What is Direct Connect?

• VPC-VGW-Direct Conect location-オンプレミス
• Ditect Connect locationよりも左がAWS側のバックボーン
• VPNよりは複雑で、プロビジョニングには時間がかかる
• 冗長性を持たせるには、複数接続を作る必要あり
• 初期費用がVPNよりも高価
• ただしデータ通信量にかかる費用はVPNやInternet Gateway経由より安価
• 標準では暗号化されていない
• AWSのハードウェアVPNをDirect Connect上で利用可能
• 予測可能で低遅延なパフォーマンス
• DXと略される
• AWSサービスと接続するにはDX接続とVIFが必要

11-2. High Availability

• オンプレミスとAWSの間で高い冗長性を待たせる方法
  • 一番高性能なのは、異なるDirect Connect locationを経由して2本のDirect Connectを接続すること
    • 2本のDirect ConnectをVGWに接続
    • オンプレミス側ルータも2台用意
  • 副回線としてIPSec VPNを引くことでも冗長性を確保できる
• コストパフォーマンスはDXとVPNの併用の方が安価

11-3. Connection

• 構成
  • Direct Connect locationにAWS側のDXルータと顧客のルータが配置される
    • それぞれ別のラックに配置
  • オンプレミス側データセンタとDirect Connect location間はWAN接続
  • AWS側のDXルータとVGW間は、AWSのプライベートバックボーンで高速に接続
• 複数のVirual InterfaceとVLANを作成可能
• 設定の流れ
  • Direct Connectを、AWS VGWとAWS側DXルータ間で作成するため、接続を要求
  • AWSがリクエストを処理すると、Letter of Authorization and Connecting Facility Assignment (LOA-CFA) がダウンロード可能に
    • メールが届くので確認
    • AWSからの接続承認
    • LOA-CFAはAWSマネジメントコンソールでダウンロードする
  • LOA-CFAをコロケーションプロバイダと共有
    • コロケーションプロバイダと連絡を取り合う必要あり
  • AWS側DXルータと顧客ルータをクロスコネクト接続
  • (だいたい) 5営業日以内には接続完了 ※プロバイダによる
• 以上で接続は完了
• ただし実際にAWS VPCと接続するには次項のVirtual Interface (VIF) が必要

11-4. Private Virtual Interface

• 前項までの通りDX接続が完了したらVIFを作成
• マネジメントコンソールで新しくVIFを作成
  • VIFを作成すると、単一のVLANがVGWと顧客ルータの間に張られる
• VIFを作成するために必要なもの
  • VGW (VIFを終端)
  • 仮想インタフェースを保有するAWSアカウント
  • VLAN ID
  • BGP ASN
  • AWS側ルータのピアIP
  • オンプレミス側ルータのピアIP
• VIF作成後、オンプレミス側ルータ用の設定ファイルをダウンロード
• オンプレミス側ルータとVGWの間でBGPによる接続
  • Route Tableでルート伝播を有効化する

11-5. Public Virtual Interface

• S3やDynamo DBのようなAWSサービスにDirect Connectで接続する場合にPublic VIFを使用
• VIFを作成するために必要なもの
  • 仮想インタフェースを保有するAWSアカウント
  • VLAN ID
  • BGP ASN
  • AWS側ルータのピアIP
  • オンプレミス側ルータのピアIP
• VIF作成後、オンプレミス側ルータ用の設定ファイルをダウンロード

11-6. Hosted Connection

• Direct Connect locationに自社のルータを持たない場合、自社独自にクロスコネクト接続ができない
• そこでDirect Connectパートナー (日本では回線業者)の設備を利用して接続する
• 接続方法
  • Direct Connectパートナーとコンタクトを取る
  • 回線速度、ロケーションを指定
• ホスト型接続ではVLANは1つのみ
  • VLANの設定はコントロールできない
  • VIFも1つであり、接続ごとにPublic or Private
    • 別のVIFが必要となった場合は、新たにホスト型接続を作る
• 通常の接続と比べると、柔軟性が劣るものの、特にDirect Connect location周りの設備投資が不要であり、必要な接続に対して利用料を支払うだけで良く、低コストとなる

12. Disaster Recovery

12-1. Tactics

• オンプレミスのリカバリサイトとしてAWSを利用する
• RPOとRTOを考える
  • RTOは、どれだけの時間でシステムを復旧するか
  • RPOは、いつの状態に戻せるようにするか
• リストアは定期的にリハーサルしておく

12-2. Backup and Restore

• プライマリサイトとリカバリサイトを用意する
  • サーバ、ハイパーバイザー、ストレージを構成する各ハードウェアを物理的(地理的)にも分離させる
• プライマリサイトがダウンした時に、リカバリサイトで稼働を継続することを考える
• プライマリサイトがオンプレミスにある場合、リカバリサイトをAWSに配置することを考える
• ストレージのバックアップには、AWS MarketPlaceで販売されているサードパーティ製アプライアンスが使える
  • CloudBerry等が候補
  • オンプレミスからS3にバックアップ
  • S3のライフサイクルポリシーで、バックアップをGlacierに移動すれば低コストで管理
  • AWS上に新たなEC2を立て、S3からデータを復旧
• AWS上のリカバリサイト構築には手動の操作が多くなるため、すぐ起動できるようにCloudFormationを準備しておく
  • AWS上のCold Standbyコストを節約
  • EC2、ELB、RDS等を含み複雑な構成であってもすぐに起動できる

12-3. Pilot Light

• AWS上リカバリサイトでは、システムの重要なデータや機能 (例えばコンテンツ、RDS) だけを常にホストしておく
• コンテンツやデータベースは、AWS上に常に同期
• その他サーバ群はAMIを取り、セキュリティパッチ等を最新に維持しておく
• 災害時はAMIからEC2を起動し、コンテンツは同期していたもので置き換え、データベースは接続するだけ
• 都度の起動よりも手順を簡略化する方法としては、Auto Scaling Groupを設定して常時max=mix=0にしておき、有事に設定値を上げるのが良い
• 最後にDNSをプライマリサイトからリカバリサイトに切り替える

12-4. Warm Standby

• AWS側のリカバリサイトでも、常にプライマリサイトの構成を起動
  • AWS上リカバリサイトが低コストになるように、各層のEC2は低スペックにする
  • Auto Scaling Groupで起動しておくのが有効
  • 有事はAuto ScalingでEC2の台数を増やしてリクエストをさばく
• データベースやコンテンツは常にプライマリサイトとリカバリサイトで同期
• 有事にはRoute 53のFailover Routingで切り替える
• プライマリサイトとリカバリサイトでは性能差が出るため、Weighted Routingをする場合は90:10など差をつける

12-5. Multi-Site

• AWS側のリカバリサイトでも常時プライマリサイトと同性能を確保し、有事でも稼働を継続する
• Active/Activeで起動する
  • Route 53のWeighted Routingをプライマリサイトとセカンダリサイトで50:50にする
• AWS側のリカバリサイトをStandbyにする場合は、Failover Routingを使用
  • 切替直後からフル性能を発揮できる

最後に

AWSの東京リージョンがリリースされてから約10年が経過していますが、昔からあるAWSのサービスは続々と機能がアドオンされ、高機能化してきました。
また、新たにリリースされるサービスの中には、既存のサービスをより使いやすくする目的のものもあります。
なぜ新たにリリースされたサービスが有益であるかを理解するには、既存のサービスの概念や仕組みを理解する必要があるでしょう。
ただ、10年という年月の中で積み上がった概念や仕組みはさすがに巨大であり、何も考えなければ、振り返るのは大変だと感じていました。
そこで一念発起し、後からでも長年の積み重ねを少しでも短時間で振り返ることができるように、まとめてみました。

記事中にまとめた内容は、ほぼ公式サイトやホワイトペーパーを参考にしています。
万が一内容に誤りがあれば、お知らせいただければと思います。

参考文献

• AWS ドキュメント

  • Amazon Virtual Private Cloud ドキュメント
  • AWS Direct Connect ドキュメント
  • Amazon Route 53 ドキュメント
  • AWS Virtual Private Network Documentation (※英語版のみ)
  • Elastic Load Balancing ドキュメント
  • Amazon CloudFront ドキュメント
  • Amazon WorkSpaces のドキュメント

• AWS Whitepapers & Guides (※英語版の方が最新)

  • Hybrid Cloud DNS Options for Amazon VPC (※PDF)
  • Fault-Tolerant Components on AWS (※PDF)
  • AWS Well-Architected フレームワーク (※PDF)

• AWS 認定高度なネットワーキング – 専門知識

  • AWS 認定高度なネットワーキング – 専門知識 (ANS-C00) 試験ガイド (※PDF)

補足

Direct ConnectのことをDXと訳すことがありますが、DXレポートとは一切関係がありません。