SkillBuilder の無料模試

講座 URL

試験内容

• 前提資格有。持ってるから大丈夫
  • AWS Certified Cloud Practitioner
  • AWS Certified Solutions Architect - Associate
• 特殊なワークロード向けの設計も考えさせられる

AWS ネットワークの設計と実装

• 同リージョンの AZ 間通信は低レイテンシー
• ネットワークの冗長化は中国以外の全リージョンで実現されてる
• AZ から他の AZ/リージョンとの通信はトランジットセンターを介して行われる

VPC（仮想プライベートクラウド）

• VPC はリージョン単位
  • サブネットを AZ 単位に配置する
• IPv4, IPv6 の両方をサポート
  • IPv6 非対応サービスに注意
• サブネット用に CIDR ブロックを切り出していく感じ
  • IPv4 の場合、/16 から/28 まで
  • IPv6 の場合、/64
• IPv4 の場合、各サブネットに予約済みアドレスが 5 つ
  • ホスト部
    • 全部 0
    • 1-3
    • 全部 1
  • 例：10.0.0.0/24の予約済み IP
    • 10.0.0.0（ネットワークアドレス）
    • 10.0.0.1, 10.0.0.2, 10.0.0.3が AWS が予約済み
    • 10.0.0.255（ブロードキャストアドレス）
      • 実質利用できないだけのアドレス。VPC ではブロードキャストをサポートしていないため
• IPv6 のアドレス指定
  • デュアルスタック
    • IPv4 と IPv6 を併用
  • GUA（グローバルユニキャストアドレス）を利用可能
    • VPC あたり/56のプレフィックスが割り当てられる
    • サブネットのサイズは/64
    • EC2 インスタン等に自動割り当て
  • 【利用不可】LLA（リンクローカルアドレス）、ULA（ユニークローカルアドレス）
  • VPC DHCP
    • ネットワーク接続に必要な情報を自動で設定する（ローカル IP アドレスの設定とか）
    • 基本的には Amazon provided DHCP サーバを使う
  • セキュリティグループ（SG）
    • ステートフルなファイアウォール
      • 1 方向を定義すれば、その応答トラフィック（逆方向）も許可される
    • 1 つの SG を複数の AWS リソース（インスタンス）にアタッチ可能
    • 許可リスト形式”だけ”
      • 評価順序は気にしないで良い
      • 50 ルールまで
      • アウトバウンドルールでは別の SG の ID を指定したルールも作れる
        • マルチ AZ 構成の 3 層アプリケーションの場合、各層で SG を作成し、SG の ID 指定で許可
        • FE サーバーのインバウンドルールで、ELB にアタッチした SG の ID を Source に指定
        • 画像の 8443 は開発環境での HTTPS ポートでよく使うらしい
  • ネットワーク ACL
    • ステートレス
      • インバウンド、アウトバウンドの両方を定義する必要がある
    • サブネット単位で適用
    • デフォルトではすべて許可
    • Rule #=”*“の場合、最後に評価
      • デフォルトだと”*“なルールですべてのトラフィックを拒否
        • 「該当するルールがない場合は拒否する」という意味合いのルール
  • ルートテーブル
    • 全サブネットに作成される
    • VPC にはメインルートテーブル
    • サブネットごとにルートテーブル
    • ホスト部が.1 なのはサブネットへのルーター
    • サブネット間の通信はデフォルトでルート作成済み
      • メインルートテーブルに作成され、削除もできない
    • インターネット宛の通信
      • ルートテーブルでグローバル IP アドレスを意識する必要はない。
        • 例えば EC2 インスタンスにグローバル IP アドレスがある状態でも、グローバル IP アドレスとの照合は IGW で行うため、
  • ゲートウェイ
    • IGW
      • VPC 内のインスタンスがインターネットと通信するためのゲートウェイ
    • Egress 専用 IGW
      • IPv6 用
      • NAT 機能不要だから？
    • NAT GW
      • プライベートサブネットに配置したインスタンス用
      • パブリック IP を持たないインスタンスとか
      • パブリックインターネットからの通信は許可しない
    • VPC ピアリング
      • 別アカウントとか別リージョンの VPC との接続
    • VPC エンドポイント
      • インスタンスだけ別の VPC と接続したいとか
    • 仮想プライベートゲートウェイ
      • VPC とオンプレミスネットワークを接続するためのゲートウェイ
      • VPN 接続を確立するために必要
• パブリックサブネットのルーティング
  • 
  • デフォルトルート（0.0.0.0/0）としてインターネットゲートウェイ
    • 厳密にはこのルートを作ったからパブリックサブネットと言える
  • ローカルルートとして個別の送信先
  • VPC 内部の通信
  • デフォルトルートより優先されるので、この通信はインターネットには出ない
• NAT GW のルーティング
  • 
  • プライベートサブネットにあるインスタンスがインターネットや他の AWS サービスと通信
  • インターネットからの通信はできない
  • インターネットと通信したいとき
    • IGW

    • EIP を NAT GW にアタッチ。変更不可

    • NAT GW への同時接続とか帯域とかで足りなくなるかも
    • NAT GW をマルチ AZ 配置して AZ 障害に備えることがある
      • 各 AZ 出る 0 と設定するのが大変
• EC2 インスタンス A のインターネット接続時に、EC2 インスタンス B を経由させる例
  • 
  • A はプライベートサブネット。図が間違えてる
  • デフォルトルートを経由させる EC2 B の ENI にする
  • EC2 B はデフォルトルートを IGW にすることでインターネット通信
  • プロキシとかで
• VPC エンドポイント
  • インターフェイス(Provate Link がベース)
    • Kinesys, ELB, EC2, Systems Manager, SNS, KMS…
    • VPC 内のプライベートアドレスに対し、対象サービスのエンドポイントが VPC 内に作成される感じ
    • エンドポイントごとに指定できる AZ は 1 つ
    • 他の VPC のエンドポイントも可
    • IPv4 TCP のみ
    • AZ ごとに 1 つ
    • SG 使える
    • DX 経由、VPN 経由可
    • スケールする上限がある
    • エンドポイントポリシーでアクセス制御ができる
      • IAM リソースポリシーでサービス制限とか
  • ゲートウェイ
    • S3, DynamoDB
    • ルートテーブルで指定されたサービスへのターゲットになる感じ
    • 複数の AZ に対して作成可能
    • DX, VPN 不可
    • S3, DynamoDB のみ。使用量に応じた課金を抑えられる
    • IPV4 のみ
    • エンドポイントポリシー可
• プレフィックスリスト
  • 自由に作れる
  • IP アドレスが変わりうる AWS サービスのプレフィックスリストも提供されている
    • S3
• EC2 ネットワーク
  • ENI （Elastic Network Interwace）
    • VPC エンドポイントでも必要
    • EC2 インスタンスに複数アタッチすれば、複数のサブネットに所属している状態にできる
      • 起動中にアタッチ/デタッチできるが、プライマリ ENI は取れない
    • 他の EC2 との通信とか
    • インスタンスタイプに応じた最適化をしてくれるらしい
      • EBS 最適化インスタンスとか
  • ネットワークパフォーマンス
    • インスタンスタイプに応じて考慮が必要
    • iperf によるテスト
    • バースト可能なインストタンスでは
  • ネットワーク拡張
    • デバイスパススルー
      • SR-IOV で PCIe デバイスを仮想化
      • パケット数のスループットとかを拡張できる
    • ENA
      • “次世代の拡張ネットワーク”
      • プレイスメントグループ内で 25Gbps
      • オープンソースのドライバーも提供されている
    • DPDK
      • Intel の NIC 向けっぽい
      • ユースケース的にはファイアウォール、リアルタイム通信処理、HPC、ネットワークアプライアンスとか
  • EC2 プレイスメントグループ
    • 基本的にインスタンス間のレイテンシを抑えたい。帯域幅も確保したい
      • 遅い方のインスタンスに律速される
    • ピアリングされた VPC にまたがることができる
    • 複数のインスタンスタイプを使える
    • 制約
      • グループ名はリージョン内でユニークな名前
      • グループ同士のマージ不可（作り直し？）
      • 同じインスタンスを複数グループで使うのはできない
    • ジャンボフレーム
      • MTU をデカくできる
      • 標準：1522 MTU
      • ジャンボ: 9001 MTU
      • 効率的なデータ転送
      • 他システムと通信するときに注意が必要
        • フラグメントされがちで、パフォーマンスにめちゃ影響ある
        • VPC 外に向かうのに特に注意

例題

• EC2 インスタンスの IPv4 アドレスを、同リージョン内の別のインスタンスに移動可能にしたい。最も少ない労力で達成するには？
  • ⭕️： 既存のインスタンスにセカンダリ IP アドレスを追加する。
    • アタッチし直すことができる
  • ❌： 2 番目の ENI をアタッチする
    • 同 AZ 内なら有効
• VPC CIDR のサイズを 192.168.1.0/24 で作成したが、IP アドレスが足りなくなった。運用オーバーヘッドを最小限に、追加コストをゼロにしてブロックを拡張するには？
  • ⭕️： セカンダリ CIDR（192.168.2.0/24）を追加する
  • ❌： CIDR サイズを変更（できない）
  • ❌： 新しい VPC とピアリング（可能だが、コストがかかる）