AWSサービスの機能を調べる（Network）

皆さんは、AWSクラウドが持つ機能を調べるとき、どうしていますか？

また、使おうと考えているサービスの仕様をどのように調べていますか？

私はこのところ、AWSサービスの機能のホントのところを確認するために、AWS公式ホームページの「AWSサービス別資料」で確認を取っています。
（資料には、SlideShare 、PDF 、Youtube があります）

ちまたのインターネットでの技術ネタを調べることも過去多かったのですが、情報の鮮度もありますし、やっぱり本家の情報がしっくりと安心できます！！

今回は、この画面の左にあるカテゴリー分けから「Compute」を選んだときに、各資料にはどのような情報が含まれているかを箇条書きにします。（99-99 形式の数字はページを表します）

Networkカテゴリ

●●●資料【01_GatewayLoadBalancer】

12Page

　　Gateway Load Balancer 概要

15-16Page

　　今後のネットワークアプライアンスの展開モデル（VPC間、インターネット向け）

19-21Page

　　Gateway Load Balancerの操作
　　Routing設定の流れ（Ingress Routing）
　　Routing設定の流れ（Transit Gatewayと組合せ）

23-30Page
　　トラフィックフロー例1 Ingress Routing（行き)
　　トラフィックフロー例1 Ingress Routing（戻り）
　　トラフィックフロー例2 Transit Gatewayと組合せ（行き）
　　トラフィックフロー例2 Transit Gatewayと組合せ（戻り）
　　トラフィックフロー例3 Transit Gatewayと組合せ
　　トラフィックフロー例4 Transit Gatewayと組合せ（行き）
　　トラフィックフロー例4 Transit Gatewayと組合せ（戻り）
　　トラフィックフロー補足（Transit Gateway Appliance mode　前振り）

32-34Page
　　Transit Gateway Appliance mode disable（無効)
　　Transit Gateway Appliance mode enable（有効）⇒ (AZを跨ぐトラフィック)
　　Transit Gateway Appliance mode enable（有効）⇒ (同一AZ間トラフィック)

クロスゾーン負荷分散

36-40Page
　　クロスゾーン負荷分散設定
　　クロスゾーン負荷分散（Appliance正常時）
　　クロスゾーン負荷分散（AZ1 Appliance全障害）
　　クロスゾーン負荷分散無効の場合（AZ1 Appliance全障害）
　　クロスゾーン負荷分散 vs TGW Appliance mode

デモ 42-48Page

デモ1 　GWLBe-GWLB間はどのようなトラフィックが流れているのか？
デモ2 　TGW上でAppliance Modeを有効にした場合の動作（補足）

50-51 　　Amazon Linux 2をGWLBのターゲットにする
52Page　 他のアカウントにGWLBエンドポイントを作成するには
53Page 　Gateway Load Balancerのクォータ
54Page 　Gateway Load Balancerのご利用料金
57-61　　GWLB 設定画面

●●●資料【02_Elastic Load Balancing (ELB)】

33Page

　　ステッキーセッション

47Page

　　ALBのCognito認証／OIDC IdPによる認証

●●●資料【03_Amazon Virtual Private Cloud (VPC)】

36Page

　　サブネットで利用できないIPアドレス(/24の例)

49Page

　　カスタマーマネージドプレフィックスリスト

51-52Page

　　Ingress Routing 注意点
　　・ENIをターゲットにするのでAZ/インスタンス障害時にlambdaなどでルーティングテーブルを
　　　切り替える仕組みが必要（TGWのインライン監査と同じ）
　　・他のサブネットのIGW/VGW向けのルーティングは指定したENIに向けること（非対称になる）

54Page

　　サブネット内のDHCP
　　・プライベートIPを固定の場合、DHCP経由で該当のIPが割当てられる
　　　（EC2インスタンスのOS上のNIC設定はDHCP設定とする)

55-56Page

　　Route53 resolver(AmazonProvidedDNS)
　　・２つのアドレスが利用可能　①VPCのネットワーク範囲(CIDR)のアドレスに+2をプラスしたIP
　　　　　　　　　　　　　　　　　(10.0.0.0/16の場合は10.0.0.2)
　　　　　　　　　　　　　　　　②169.254.169.253
　　Route 53 Resolver for Hybrid Clouds
　　・オンプレミスからDirect　Connect/VPN経由によるVPCProvided DNSへの
　　　直接アクセス可能なDNSエンドポイント
　　・複数AZに跨ったエンドポイント設定による冗長

58Page

　　Amazon Time Sync Service：NTP時刻同期サービス（169.254.169.123を設定）

59Page

　　Egress-only Gateway(EGW) を利用してIPv6においてもプライベート利用が可能

68Page

　　Direct Connect Gatewayの接続例

71-73Page

　　AWS Transit Gateway、Multicast対応、リファレンスアーキテクチャ

75Page

　　VPC設計：100.64.0.0/10 CGNAT

78Page

　　VPC Endpoint

79Page

　　PrivateLink

80Page

　　アクセス制御：エンドポイントポリシー／セキュリティグループ

82Page

　　PrivateLinkはオンプレミスにネイティブ対応

84-87Page

　　VPCの接続バリエーション：VPC peering、PrivateLink、Transit Gateway
　　Transit Gateway と PrivateLinkはスケーラブル
　　VPCシェアリング

95-97Page

　　VPC Traffic Mirroring：EC2インスタンスのENIから
　　　　　　　　　　　　ネットワークトラフィックをミラーリングする機能

101Page

　　Amazon VPC のクォータ関連

●●●資料【04_Site-to-Site_VPN】

14Page

　　VPN接続３パターン
　　①Client VPN　②Site-to-Site VPN 仮想プライベートゲートウェイ(VGW)接続
　　③Site-to-Site VPN トランジットゲートウェイ(TGW)接続

20Page

　　Site-to-Site VPNとは？
　　・VGW：特定のVPCのみと通信
　　・TGW：多くのVPCと通信（VPN料金の他にTGWの料金も発生する）
　　・事前共有キーによる認証方式：IPsec対応ルーターと固定Public IP
　　・プライベート証明書認証方式：非固定PublicIP

22Page

　　Site-to-Site VPNの準備
　　・カスタマーゲートウェイデバイス　お客様側にある物理デバイスまたはソフトウェアデバイス
　　・カスタマーゲートウェイ(CGW)

28Page

　　ルーティングのタイプ：動的（BGP） or 静的

29Page

　　設定時の注意：最大送信単位 (MTU)＝パケットサイズが1399以下となるよう、MTU設定推奨

33Page 　TGWメリット(1): 複数VPCと同時接続
34Page 　TGWメリット(2): 柔軟なルート設計
　　　　（VPC経由でインターネット接続可、セキュリティアプライアンスをクラウドに集約）
35Page 　TGWメリット(3): 複数のVPNによるAct-Act通信（ECMP←複数のVPN接続を束ねる)
36Page　 TGWメリット(4): Acceleratedサイト間VPNオプション

仮想プライベートゲートウェイ(VGW)の冗長化
40Page　 冗長化の考え方：1つのVPN接続で2つのIPsecトンネル
41Page 　冗長化の考え方：単一障害点となるルーターを冗長化
42Page 　VGWの優先制御：AWS→オンプレミス
　　　　（Active-Standby　ユーザルーターでAS Path PrependやMEDを設定して制御可能）
43Page　 VGWの優先制御：オンプレミス→AWS
　　　　（ユーザルーターがMED制御できる場合、AWS付与MED値によって
　　　　　各AWS接続ごとの優先IPsecトンネルが決定される）

トランジットゲートウェイ(TGW)の冗長化
44Page 　冗長化の考え方：1つのVPN接続で2つのIPsecトンネル
45Page　 冗長化の考え方：複数のVPN接続に通信を分散するECMP
46Page 　冗長化の考え方：ECMP利用時の考慮ポイント

Direct Connectとの併用によるSite-to-SiteVPN冗長化
49Page 　経路制御：Direct Connect/インターネットVPN(BGP):Standby
50-51 　 注意点：TGW接続のDirect Connect/VPN(Static):Staticが優先
52Page 　複数VPCに対するバックアップ用途のSite-to-Site VPN
　　　　（各サブネットのルートテーブルでオンプレミス向け経路をTGWへ変更）
53Page 　オンプレミスからAWSへ通信する際の経路選択
　　　　（「許可されたプレフィックス」でVPC側CIDRを指定）
54Page　 オンプレミスから同じCIDRが広報され、1つのルートテーブル内で重複
　　　　　⇒　Direct Connect Gatewayアタッチメントからの経路が優先される
55-56 　経路制御：ルート設計上の課題

60-62 　Site-to-Site VPNを利用した拠点間通信

65-68 　運用時の確認ポイント

●●●資料【05_Amazon VPC VPN 接続設定 参考資料】

●●●資料【06_Amazon_CloudFront_deep_dive】

28Page

　　ACM証明書とSNI証明書

30Page

　　8つの追加メトリクス: 追加費用！！

40Page

　　OAIはS3ホスティングが使えなくなる！

49Page

　　Cache Policy / Origin Request Policy の使用例

　　Behavior の Origin Reuest Policy:
　　指定なし：Referer 含めない
　　Managed-UserAgentRefererHeaders　Referer を送る

54Page

　　Brotli圧縮

69Page

　　※ 4XX 系 / ５XX 系のエラーキャッシュ期間 (Error Caching Minimum TTL) は デフォルト 10 秒
　　　　07_Amazon_CloudFrontの概要.pdf　の内容から変更になっている。

●●●資料【07_Amazon_CloudFrontの概要】

24Page

RangeGETリクエスト

大きなオブジェクトの場合、複数のGETリクエストを、Rangeリクエストヘッダーを使用して、小さい単位でダウンロードする場合があります。
部分的なダウンロードの効率、および部分的に失敗した転送からの回復の効率が向上します。

CloudFront は RangeGETリクエストを受け取ると、エッジロケーションのキャッシュをチェックし、
オブジェクト全体または要求部分がすでに含まれている場合、
CloudFront は要求された範囲をキャッシュから直ちに提供します。

要求された範囲がキャッシュに含まれていない場合、リクエストをオリジンに転送します。
(パフォーマンスを最適化するために、CloudFront はRangeGETで要求された範囲よりも大きい範囲を要求する場合があります)。

次に実行される処理は、オリジンが RangeGETリクエストをサポートするかどうかによって異なります。

①オリジンがRangeGETリクエストをサポートする場合:
　要求された範囲が返されます。CloudFrontは要求された範囲を提供し、今後のためにその範囲を
　キャッシュします。
　(Amazon S3 は RangeGETリクエストをサポートしますが、Apache および IISなどの
　 HTTP サーバーもこのリクエストをサポートします。
　お使いのHTTPサーバーがこれらをサポートするかどうかについては、
　HTTP サーバーのドキュメントを参照してください。)

②オリジンがRangeGETリクエストをサポートサポートしない場合:
　オブジェクト全体が返されます。CloudFront はオブジェクト全体を送信して現在のリクエストを
　処理し、今後のためにオブジェクトをキャッシュします。
　CloudFront はオブジェクト全体をエッジキャッシュにキャッシュした後、要求された範囲を提供
　することで新しい RangeGETリクエストに応答します。

26Page

　　フォーワードオプション機能

27Page

　　キャッシュコントロールヘッダーの挙動

28Page

　　※オリジンが S3 で、オリジン側でヘッダー指定する場合は、Metadata に HTTPヘッダーを指定

30 – 36Page

　　キャッシュ動作: 動的コンテンツ機能

33Page

　　パラメータの順序を常に統一する
　　パラメータ名とパラメータ値の大文字と小文字を常に統一する

35Page

　　※エラーキャッシュ期間 (Error Caching Minimum TTL) はデフォルト5分
　　　06_Amazon_CloudFront_deep_dive.pdf　で変更になっている。

36Page

　　カスタムオリジンのタイムアウト

37Page

　　オリジンフェイルオーバー

42Page

　　ビューワー接続 SSL セキュリティポリシー

　　TLSバーションの指定によって、クライアントの接続はどうなるのか？
　　※　すべてのポリシーで TLS1.3 が有効　06_Amazon_CloudFront_deep_dive.pdf
　　　　で変更になっている。

44Page

　　オリジンカスタムヘッダー

　　Shared-Secret　→　CloudFrontからのアクセスのみに制御

　　リクエストヘッダーの調整　Cross-Origin Request Sharing(CORS) 通信時（要検討！）

46 – 49Page

　　署名付き URL/Cookie

50Page

　　フィールドレベル暗号化を使用した機密データの保護

51Page

　　オリジンサーバの保護

58Page

　　CloudFront Reports & Analytics

　　注意！　CloudFront の CloudWatch メトリクスは 米国北部 (バージニア北部) リージョンに
　　　　　　出力される

67Page

　　DNS名前解決の高速化：CNAME ではなく AレコードのAlias設定することでクエリの回数が削減

69Page

　　Amazon S3オリジン自動キャッシュの無効化

75Page

　　Lambda@Edge のユースケース　→クエリ文字列の順番に効く

78Page

　　Lambda@Edge 用の Lambda 関数を作成　ログはエッジのリージョンに作成される

85Page

　　CloudFront料金クラスを指定することで、安価なエッジロケーションのみを利用した配信が可能

●●●資料【08_Amazon_CloudFront _AWS_Lambda@Edge】

13Page

　　CloudFront のリージョナルエッジキャッシュ

●●●資料【09_CloudWatch Container Insights で始めるコンテナモニタリング入門】

12Page

　　コンテナ(群・スケジュール)
　　タスク
　　サービス（タスク数の維持・ELBとの連携・メトリクスに応じたオートスケール）
　　クラスタ（論理的なグループ）

15Page

　　Container Insights の前
　　メトリクスを拾うのに、カスタムメトリクス/サイドカー

19Page

　　※ 2019/11/27 AWS Batch Container Insights はサポート外（説明がへん）

29-36Page

　　タスクやコンテナを選択して、アクションから
　　①CloudWatch Logs Insights（アプリケーションログ・パフォーマンスログ）
　　　※　サンプルクエリ、クエリのヘルプ
　　②X-Ray
　　　※　コンテナのサイドカーとして、X-Rayデーモンを実行するコンテナを配置する
　　　　　をドリルダウンできる。

37-44Page

　　Container Insightsの開始方法

47Page

　　パフォーマンスログイベント資料のURL

49Page

　　パフォーマンスログ・クエリの確認方法

54-56Page

　　ユースケース１：コンテナリソースの配分を適切に配分する

59,60Page

　　ユースケース２：特定のコンテナだけで問題が発生している場合の調査

●●●資料【10_Route 53 Resolver】

13-18Page

　　●フルサービスリゾルバ：反復／再帰問い合わせ
　　●スタブリゾルバ
　　●フォワーダー
　　☆DNSサーバ構成

21-33Page

　　AWS・DNSサービス機能

36-39Page

　　※ TCP Fallback RFC 5966 TCP許可も注意！！（38Page）

43-45Page

　　Hybrid Clouds 設定ポイント

47-49Page

　　digコマンド

●●●資料【11_Route 53 Hosted Zone】

30Page

　　CNAME制約とZoneApex

33Page

　　NXDOMAINとネガティブキャッシュ

43Page

　　ルーティングポリシー
　　　①シンプル　②加重　③フェールオーバー　④複数回答
　　　⑤レイテンシー　⑥位置情報　⑦物理的近接性

49,50Page

　　トラフィックフロー

56-58Page

　　ネームサーバーの移行

●●●資料【12_Transit_Gateway】

39Page

　　Outbound Services VPC　戻りの経路を書く

59-63Page

　　Transit Gateway アタッチメントの設計
　　　TGWのアタッチメントENIに専用サブネットを作るのをオススメ
　　　インスタンス等と同居するとTGWからの経路の影響を受ける

　　Transit Gatewayの制限

　　Direct ConnectのTransit Gatewayに関する制限

　　クロスアカウントやVPN接続の場合の Transit Gateway におけるDNSクエリ
　　　⇒　Route 53 Resolver Endpoint が必要

68Page

　　戻りのENIが存在しないのでパケットが戻れない＞不通になる
　　アタッチメント時、すべてのAZにTGWのENIをつけること（必須）

73Page

　　VPC Peering/DXGWで通信制限する Route Domain(Direct Connect)
　　　Transit Gatewayを使わずともVPC PeeringとDXGWで通信制限は可能
　　　TGWに比べてコスト削減になる

●●●資料【13_NetworkFirewall入門】

東京／大阪リージョンで利用可能

10Page

　　利⽤開始までのステップ

12Page

　　料金体系
　　・ファイアウォールエンドポイントに対する時間課金 $0.395/hr
　　・トラフィック処理量に応じた課金 $0.065/GB

17,18Page

　　VPC内経路のPoint
　　①⾏き/戻りの通信が対称になるようにルート設定を⾏う
　　②NATしてからファイアウォールに到達するため、送信元ベースのフィルタルールの設計
　　　には注意が必要（送信元IPアドレスに注意）

　　マルチAZ構成のPoint
　　・各AZにFirewall subnetとエンドポイントを配置する
　　　①1AZにつき、1エンドポイント配置し、通信の対称性に留意必要
　　　②VPCを跨る事はできない（AZ事にFirewall配置が必要）

20-23Page

　　ステートレス5-tupleフィルタ
　　ステートフル5-tupleフィルタ
　　ステートフルドメインリストフィルタ
　　Suricata互換IPS

●●●資料【14_NetworkFirewall応用】

8Page

　　MSRによって、戻り経路のTargetに Firewall endpointを指定できるようになり、
　　NAT GatewayをFirewallの外側に配置できるようになった。
　　入門編では、NAT GatewayはFirewallの内側に配置するしかなかった。

12Page

　　様々な通信をNetwork Firewallに集約して監査する

　　トラフィックフロー
　　①VPC間通信
　　②オンプレミス(Direct Connect/VPN) とVPC間通信
　　③VPCやオンプレミス(Direct Connect/VPN)からインターネットへの通信

　　設計ポイント
　　・Transit Gatewayのルートテーブルを複数作成し、必ず監査⽤VPCを通るように制御する
　　・公開サーバ宛の通信を集約する：ALBまたはNLBを使ってインターネットからの通信を
　　　まとめて検査する
　　・監査⽤のVPCをマルチAZ構成にする場合、Transit Gatewayのアプライアンスモード有効にする
　　　　→　行き帰り経路を同一にする

●●●資料【15_Direct Connect】

13Page

　　DirectConnectロケーションでのキャリアとAWSの役割

16,17Page

　　DirectConnectロケーションでの接続作業＆手配
　　Direct Connectロケーションとお客様間の接続パターン
　　①お客様機器持ち込み
　　②パートナー様専用線接続
　　③パートナー様閉域網(IP-VPN網、モバイル網等)経由で接続

18-20Page

　　①Link Aggregation
　　②ベストプラクティス：クリティカルなワークロードの高い回復性
　　③ベストプラクティス：クリティカルなワークロードの最大回復性

●Transit Gateway

24Page　仮想インターフェイスVIF　①プライベートVIF　②パブリックVIF　③トランジットVIF
25Page　クロスアカウントVIF
26Page　プライベート接続：Direct Connectゲートウェイ(DXGW)タイプ
27Page　プライベート接続：仮想プライベートゲートウェイ(VGW)タイプ
28Page　複数のプライベートVIFによるマルチVPC接続
29Page　パブリック接続
30Page　パブリックVIFによるパブリックサービスへの接続
31Page　トランジットVIFによるTransit Gateway(TGW)への接続

34-36Page

トランジットVIF利用時の注意点(パートナー仕様に注意)
トランジットVIF＋TGW：利用時のポイント（柔軟に通信できる）
トランジットVIF＋TGW：マルチアカウント対応
（トランジットVIFとDXGWは同一アカウントが所有する必要がある）

●Direct Connectゲートウェイ（DXGW）

39-44Page

　　１．Direct Connectゲートウェイ利用時の注意
　　　　VPC間リージョン内であればPrivateLink、Transit Gatewayなど、リージョン跨ぐ場合、
　　　　VPCピアリングで対応
　　２．プライベートVIF＋DXGW：利用時のポイント
　　　　①1つのDXGWから最大10のVPCへ通信可能（必要であればDXGW２台目…）
　　　　②利用料は不要、特定のリージョンに属さないグローバルリソース
　　３．マルチアカウント対応
　　　　プライベートVIFとDXGWは同一アカウントが所有する必要がある
　　４．プライベートVIF(DXGW)とトランジットVIF(DXGW+TGW)の比較（処理要件を要検討）
　　Tips：①VGW数は10までだが、超える場合はVIFとDXGWのペアを追加
　　　　 ②VPC間の通信はTGWで経路を確保

●パートナー経由のDirect Connect

50-54Page

　　パートナーの提供サービス (占有型・共有型）
　　AWS Direct Connect サービスデリバリープログラム(SDP)
　　パートナーの提供サービス (ホスト接続: Hosted Connection）
　　パートナー経由のDirect Connectの注意点

●高い回復性/モニタリング

56Page 　デュアルロケーション (リージョン内で分散)
57Page 　デュアルロケーション (東京・大阪で分散)
58Page 　デュアルロケーション [東阪分散＋大阪リージョン(ローカル)]

59Page

　　冗長構成における経路制御
　　・BGPのパス属性を用いて経路を制御
　　・AWS上の設定ではなく、お客様ルータの設定により経路制御を行う

60Page 　BGPパス属性を用いた経路制御：LP+AS-Pathの例
61Page 　冗長構成における経路制御：注意点
62Page 　BGPコミュニティ（１）パブリック接続で使用可能なもの
63Page 　BGPコミュニティ（２）プライベート接続で使用可能なもの

64Page 　経路制御（Active/Active）
65Page 　経路制御（Active/Standby）
66Page 　経路制御（Direct Connect/VPN）

67Page 　非対称ルーティング時の注意
68Page 　障害時の経路切替時間の短縮：BFD非対応ルーター対策
　　　　　⇒　 BGPのkeepalive/Hold Timerのチューニング

70Page 　Amazon CloudWatchによるDirect Connectのモニタリング
71Page　 Direct Connect フェイルオーバーテスト（意図的にActive側BGPに障害を起こす）
72-76 　 Direct Connect フェイルオーバーテスト（実施例）

79Page 　各種クォータについて
80Page 　経路集約の必要性

●料金体系 86-90Page

●●●資料【16_Direct Connect オンプレミスと AWS 間の冗長化接続】

冗長化方法

１．複数のDirect Connectによる冗長化

19Page　エンタープライズのユースケースで多く取られる方法
20Page　何も設定しなければ、AWSからオンプレミス方向はActive-Activeとなる
　　　　①オンプレミス→AWS　トラフィック：ユーザネットワーク機器設定による。
　　　　　　　　　　　　　　　　　　　　　　非対称通信もありえる。
　　　　②ユーザ⇔ルーター：iBGPで経路交換し、ベストパスを選択
21Page　トラフィックを片寄する要件はユーザ・ネットワーク機器で設定
　　　　①ユーザ・ネットワーク機器で以下設定
　　　　　オンプレミス→AWS：Local Preference
　　　　　AWS→オンプレミス：AS Path Prepend
　　　　②現時点ではMEDによる指定で優先制御ができるが、サポート対象では無い
22Page　Virtual Private Gateway (VGW) について、利用者が冗長化を考える必要はありません
23Page　Tips:サブネットに関連ないルートテーブルに、VGWが持っている経路をコピー・保存できる
24Page　BGPパス属性を用いた経路制御
　　　　　⇒　LP(Local Preference)、AS-Path Prepend、BGPコミュニティ
25Page　BFDによる経路切替時間の短縮
26Page　Tips: BFDとGraceful Restartは併用しない（推奨）
27Page　BFD非対応ルーターでの対応方法

２．旧来の冗長化方法

32-33 　同一ロケーションで２つのDirect Connectで冗長化している場合
　　　　Connectionが別AWSデバイスにアサインされている事を
　　　　マネージメントコンソールで確認する方法
34Page　上記同一AWSデバイスにアサインしてしまった場合の対応方法
35Page　上記のように、結果としてAWSデバイスが重複してしまう例－①②③

３．コスト抑制条件に適用した冗長化

37Page　コスト抑制条件に適用した冗長化：異なるサービスを併用
38Page　コスト抑制条件に適用した冗長化：Site-to-SiteVPN接続を併用

４．パートナー網を経由した冗長化

40Page　パートナー網経由の冗長化
　　　　①ユーザネットワーク機器は、パートナー様網の仕様により、L2、L3による接続を行う
　　　　②L3接続の場合、AWSデバイスとのBGPピアはパートナー様機器が行う
　　　　③冗長化の設計についてはパートナー様の仕様によるところが大きいので、
　　　　　詳細はパートナー様窓口へ確認

５．Direct Connect Gatewayに対する冗長化

42Page　Direct Connect Gateway(DXGW)に対する冗長化
　　　　①Direct Connect Gatewayは単一のリソースに見えるが内部で冗長化されている
　　　　②構成上は1ホップ増えるように見えるが、オーバーヘッドの心配は不要
　　　　③同時にアタッチ可能なVIFは30(冗長化しても15拠点が収容可能)
43Page　Direct Connect Gateway(DXGW)に対する冗長化：注意点
　　　　①VGWは二つ目のDirect ConnectGatewayにアタッチできない
　　　　②内部的に冗長化されているため、DXGWを分ける必要はない

６．Transit Gatewayに対する冗長化

45Page

①ロケーション冗長は実装されている（DXGWとTGWは内部的に冗長化されているため、考慮不要）
②バックアップ用にもTransit VIFが必要（特性の異なる共有型サービス利用不可）
③DXGWから広報されるAWS側経路はDXGWの「許可されたプレフィックス」に登録のCIDRが
　両方のVIFに対して広報される

46Page　TGWを分ける必要が無い理由：HyperPlane
47Page　Tips: TGWを分ける必要がある場合　⇒　VPC CIDRごとに使う物理線を分割可能
　　　　例　1つしかVPCが利用できない AND 複数の接続がお互いに干渉しない要件を
　　　　　　クリアしたい場合など（別途冗長化要）

７．LAGによる広帯域確保

49Page　LAG(Link Aggregation)による高帯域確保

８．より高い可用性を求めるためには：マルチリージョン冗長（東京／大阪リージョン）

51-53Page

９．ベストプラクティス　AWS Well-Architected Framework

57-65Page

●●●資料【17_App_Mesh_Deep_Dive】

27Page　 AWS App Mesh の動作イメージ: ネットワークモデルとの関係
32Page 　トップレベルの概念まとめ
38Page　 例: Amazon ECS と Amazon EKS で稼働するサービス間通信
　　　　　①Amazon ECS と Amazon EKS それぞれでサービスが稼働している
　　　　　②Amazon ECS で稼働するサービスと Amazon EKS で稼働するサービスの
　　　　　　相互通信が必要に
　　　　　③[課題] アプリケーションコードの変更や対向サービスとの結合度が強くなってしまう
39Page　　AWS App Mesh の導⼊後のサービス間通信
　　　　　①アプリケーションコードの変更：リトライやタイムアウトの処理を Envoy proxy 側で
　　　　　　⾏うため、アプリケーション側の変更は最⼩限
　　　　　②対向サービスとの結合度：ルーティング設定は App Mesh 側で⾏うため、対向サービス
　　　　　　の状態や構成変更に依存しない
41Page　　AWS App Mesh の導⼊⼿順（１例）
　　　　　①Amazon EKS での設定：AWS App Mesh Controller For K8s による設定
　　　　　　1. AWS App Mesh Controller For K8s のインストール
　　　　　　　App Mesh／AWS Cloud Map を操作する権限付与
　　　　　　2. Namespace の変更　Mesh の指定、Sidecar Injector の有効化
　　　　　　3. Mesh の作成
　　　　　　4. AWS Cloud Map 名前空間の作成
　　　　　　5. Virtual node の作成
　　　　　　6. Virtual router の作成
　　　　　　7. Virtual service の作成
　　　　　　8. Virtual node の更新
　　　　　　9. Deployment の更新
　　　　　②Amazon ECS での設定：マネジメントコンソールによる設定
　　　　　　1. Virtual node の作成
　　　　　　2. Virtual router の作成
　　　　　　3. Route の作成
　　　　　　4. Virtual service の作成
　　　　　　5. Virtual node の更新
　　　　　　6. タスク定義の更新
　　　　　　7. サービスの更新
　　　　　③Amazon EKS での設定：Virtual node の更新

●●●資料【18_App_Mesh】

37-39Page

　　①サービスメッシュを管理するコントロールプレーンを提供する
　　　　→　ネットワークモデルをEnvoyの設定に変換して配信
　　②App Meshのネットワークモデル
　　③App Meshのモデルと実際のアプリケーションを紐付け

40-45Page　App Meshの動作イメージ

46Page　Virtual Node
47Page　Virtual Service
48Page　Virtual Router
49Page　Listener
50Page　Backend
51Page　Meshの構築

52-58Page　Amazon EC2での利用イメージ
60-61Page　Amazon ECS / AWS Fargateでの利用イメージ
62-68Page Amazon EKS / Fargate for EKS / Kubernetes on EC2での利用イメージ
　　　　　　※　App Mesh Controler に App Mesh Inject は現在、統合されている。

機能と活用方法

71-72Page AWS App Meshのセキュリティ機能
73Page 　　AWS App Meshで利用できる機能

74-90Page 　通信可観測性を確保する
　　　　　　※　CloudWatch Agentをサイドカーとしてデプロイし、
　　　　　　　　8125ポートで公開されているメトリクスを取得するよう設定する
　　　　　　※　X-Rayデーモンのコンテナ(amazon/aws-xray-daemon)
　　　　　　　　をサイドカーとしてデプロイ

91-92Page 　カナリアリリース

93Page 　AWS App Meshのロードマップ
　　　 　AWS Lambdaとの連携　LambdaをMeshに追加できるようにする
　　　　　(EnvoyからLambdaを起動する)
95Page 　利用料金