AWS Ambassadorが考える個人的に最強のマルチアカウントハイブリッドネットワーク構成

DevelopersIO 2023の登壇資料です。

https://event.classmethod.jp/developers-io/2023

Transcript

1. AWS Ambassadorが考える 個人的に最強のマルチアカウント ハイブリッドネットワーク構成 2023/7/8 AWS事業本部 のんピ 1
2. 自己紹介 2 { "本名": "山本 涼太 (覚えなくて良い定期)", "部署": "AWS事業本部 コンサルティング部", "前職": "インフラエンジニア in データセンター", "興味のあること": "面白そうなブログネタ探し", "好きなAWSサービス": [ "AWS Transit Gateway", "AWS Step Functions" "Amazon FSx for NetApp ONTAP" ], "称号" : [ "2023 Japan AWS All Certifications Engineer", "2023 Japan AWS Ambassador", ] }
3. さて 3 こんなことあると思います
4. 4 ハードウェアの保守切れの度に システムの大規模更改面倒だな
5. 5 そうだ! AWS使っていくぞ!
6. そうしてこの世に新たなVPCが誕生 6 よろしく VPCくん
7. 7 そしてn年後
8. 無秩序に作られた大量のVPC 8 よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん よろしく VPCくん
9. 9 もしくは
10. 1つのVPCに何でも詰め込まれる 10 よろしく VPCくん
11. というように 11 AWS への移行が進んでいくと ネットワークがカオスになりがち
12. なぜか 12 どのようにしてAWS上でネットワークを 拡張していくのか方針が決まっていない
13. 13 複雑なネットワークは 運用への負荷が大きい
14. そこで 14 AWS Ambassadorが考える 最強のマルチアカウント ハイブリッドネットワーク構成を紹介
15. 紹介する要素 15 1. VPC 設計編 2. アカウント分割編 3. VPC 間接続編 4. オンプレミスネットワーク接続編 5. 名前解決編 6. 通信集約編
16. 16 1. VPC 設計編
17. VPC設計編まとめ 17 1. VPCはシステムと環境毎に分割しよう 2. サブネットは役割とルーティング先で分割しよう 3. サブネットは最低でも2AZ、できれば3AZ分作ろう 4. CIDRはギリギリを攻める必要はないが、広すぎ注意 5. VPCのCIDRは他のVPCと被らないようにしよう 6. AWSで使いたいCIDRは大きく広めに確保しておこう
18. なぜ 18 VPCをシステムと環境毎に分割するのか
19. 19 セキュリティと運用効率の向上のため
20. 1つのVPCに何でも詰め込む方式 20 VPC Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance
21. 何らかの攻撃を受けた場合 21 VPC Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance VPC内の他のEC2インスタンスにも潜在的な脅威が
22. 何か変更を加える場合 22 VPC Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance Private subnet Instance S3 VPC Endpoint VPCエンドポイントのポリシーを変更する際 全システムで調整する必要がある
23. つまりは 23 影響範囲が広すぎ
24. なので 24 VPCをシステムと環境毎に分割して 管理の範囲を小さくしてあげよう
25. VPCの分割は分かった 25 じゃあサブネットはどの粒度で分割する?
26. 26 役割とルーティング先で分割
27. 役割とは? 27 Virtual private cloud (VPC) Webサーバー Private subnet Proxyサーバー Private subnet DBサーバー Public subnet
28. なぜ役割で分割する? 28 セキュリティグループで CIDR単位で許可したい場面があるから
29. Transit Gatewayでは 29 セキュリティグループで セキュリティグループIDを使って ルールを制御できない
30. セキュリティグループIDで制御できない 30
31. Transit Gatewayを経由する場合は 31 必然的にセキュリティグループは CIDRを指定して通信を制御する = 送信元がAuto Scalingすると /32で許可しづらい = サブネットのCIDRで許可すると楽
32. ルーティング先とは? 32 基本3種 1. Public : インターネットと直接通信可能 2. Egress : インターネットにNAT経由で通信可能 3. Isolated : インターネットとの通信不可 その他 1. Internal : 別VPCやオンプレミスへの通信可能
33. VPC Public subnet 基本3種のイメージ 33 VPC Private subnet VPC Private subnet Public subnet IGW IGW IGW Public Egress Isolated
34. なぜルーティング先で分割する? 34 サブネットに割り当てられる ルートテーブルは1つまで ルーティング制御はセキュリティ対策の第一歩 (個人の意見です)
35. じゃあサブネット分割しまくれば良い? 35 あまり細かくサブネットを切りすぎると 使えるIPアドレスが減るため注意 最低限ルーティング先で分割しよう
36. サブネットは何セット作る? 36 3AZ分できれば作りたい 最低でも2AZ分作る
37. なぜ? 37 可用性向上のため
38. こんなことありましたよね 38 ALB切り離せない問題
39. ALB切り離せない問題とは 39 ALB自体が500エラーを返 すようになった => 最低2AZ分サブネットを 指定する必要があるた め切り離せない
40. つまりは 40 3AZ分のサブネットの余裕がないと 対応できない
41. 言い換えると 41 VPCのCIDRには少し余裕が必要
42. VPCやサブネットのCIDRに余裕がないと 42 リソースによってはIPアドレスが枯渇する
43. 例) RDS Proxy 43 DBインスタンスクラスによって必要なIPアドレスが変動 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/rds-proxy-setup.html
44. 例) DataSync 44 DataSyncタスクの数によってENIが作成される https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/datasync-network.html
45. ただし 45 システムと環境毎に分離しているのに 1つのVPCに /16 のCIDRは過剰 = /20 ~ /24 ぐらいで十分なことがほとんど
46. うわ! もう空きがない!! 46 大丈夫、VPCのCIDRは後から追加可能です ※ サブネットのCIDRは追加不可
47. そんな時のために 47 CIDRの割り当て状況は把握しておこう
48. CIDRが重複すると 48 Transit GatewayやDirect Connect Gateway には同じCIDRのVPCをアタッチできないぞ
49. 加えて 49 AWS全体で使いたいCIDRは 広めに確保しておこう
50. なぜか 50 DXGWでAWSからオンプレミスに広告できるネット ワークアドレスの数は20個まで = ネットワークアドレスが 分散すると集約できない = クォーターに引っかかりやすい
51. VPC設計編まとめ (再掲) 51 1. VPCはシステムと環境毎に分割しよう 2. サブネットは役割とルーティング先で分割しよう 3. サブネットは最低でも2AZ、できれば3AZ分作ろう 4. CIDRはギリギリを攻める必要はないが、広すぎ注意 5. VPCのCIDRは他のVPCと被らないようにしよう 6. AWSで使いたいCIDRは大きく広めに確保しておこう
52. 52 2. アカウント分割編
53. アカウント分割編まとめ 53 1. アカウントはシステムと環境毎に分離しよう
54. なぜ 54 アカウントをシステムと環境毎に分割するのか
55. 55 権限分離と課金の可視性向上のため
56. 1アカウントに複数システムが混在すると 56
57. 1アカウントに複数システムが混在すると 57
58. 58 RBACやABACしようにも ポリシーやタグの設計に時間がかかる
59. RBACやABACについては以下記事参照 59
60. アカウント分割をすることで 60
61. 料金面においても問題が 61
62. アカウントを分割することで 62
63. アカウント分割編まとめ (再掲) 63 1. アカウントはシステムと環境毎に分離しよう
64. 64 3. VPC間接続編
65. VPC間接続編まとめ 65 1. 基本はTransit Gateway a. ただし、初めからTransit Gatewayで接続する必要はない 2. どのVPC間で通信が必要なのか整理しよう 3. VPC間で相互に接続が必要なのか整理しよう a. 疎結合にできるなら疎結合に b. VPC LatticeやPrivateLinkで事足りることもある
66. 大量のVPCを互いに接続する場合 66 Transit Gatewayが超絶便利 https://pages.awscloud.com/rs/112-TZM-766/images/20191113_AWS-BlackBelt_Transit_Gateway.pdf
67. ただし 67 最初からTransit Gatewayを 使う必要は全くない
68. 理由 68 小規模環境であればオーバースペック
69. Transit Gatewayの料金をご覧ください 69 https://aws.amazon.com/jp/transit-gateway/pricing/
70. VPC10個をTransit Gatewayに接続する場合 70 毎月 511.00 USD (通信料金を除く)
71. はい 71 良いお値段
72. 相互接続するVPCの数が少ないなら 72 こんな構成だって良いじゃないか
73. そのためにも意識しよう 73 どのVPC間で通信が必要なのか整理して 不必要なルーティングを行わない
74. 通信が必要な場合であっても 74 Transit GatewayやVPCピアリングが 不要なケースもある
75. 例1) S3バケットでデータ連携 75
76. 例2) VPC LatticeでAPI連携 76 抜粋 : VPC Lattice クロスアカウント接続に必要な要素を図解してみた
77. 例3) PrivateLinkでDBに接続 77 抜粋 : PrivateLinkとNLBを使ったRDSクロスアカウントアクセスを試してみる
78. VPC間接続編まとめ (再掲) 78 1. 基本はTransit Gateway a. ただし、初めからTransit Gatewayで接続する必要はない 2. どのVPC間で通信が必要なのか整理しよう 3. VPC間で相互に接続が必要なのか整理しよう a. 疎結合にできるなら疎結合に b. VPC LatticeやPrivateLinkで事足りることもある
79. 79 4. オンプレミスネットワーク接続編
80. オンプレミスネットワーク接続編まとめ 80 1. そのVPCは本当にオンプレミスネットワークとの通信が必 要なのか整理しよう 2. 必要な帯域を把握しよう 3. 2つのロケーション or 方法で可用性を向上させよう 4. サービス提供がオンプレミスとの通信に依存しないように しよう
81. そもそも 81 そのVPCは本当にオンプレミスネットワークと接続 させる意味がありますか?
82. 詳しくは 82
83. 今回は 83 はい! 接続したいです! ということにしておきます
84. 続いて 84 Transit VIF用意できますか?
85. Transit VIFを用意できない場合 85 21個以上のVPCを接続したければ複数のDXGWで代用
86. Transit VIFを使う場合でも 86 必要な帯域とVIFの帯域は把握しよう
87. 大量のVPCとオンプレミスを接続すると 87 その分通信が発生する
88. 理解せずにVPCを増やしまくると 88 Transit VIFが耐えられない
89. 対応 89 VIFを3本以上用意しよう
90. え？2本じゃなくて3本以上? 90 1本がダウンした場合に備える
91. VIFのロケーションは分割しよう 91 ロケーションレベルの障害に耐えるため
92. Site-to-Site VPNでもいいじゃん 92 はい、良いです
93. ただし 93 その帯域、Site-to-Site VPNで捌けますか?
94. 無駄ではないが 94 DX障害時のサービスレベルを把握した上で対応
95. そもそもAWS側ばかり気にしているけど 95 接続拠点が単一障害点(SPOF)じゃないよね？
96. こんな構成だと 96 拠点A障害発生時は他の拠点もVPCに接続できなくなる
97. 前提として 97 サービス提供がオンプレミスとの通信に 依存しないようにしよう
98. AWS側をいくら冗長化しても 98 オンプレ側で冗長化されていなければ勿体無い 通信速度やレイテンシーも気になる
99. 密結合なものはセットでAWS上にリフト 99 難しければキューやキャッシュで非同期通信
100. ということで 100 「単一障害点があるのか」 「どこがどのように冗長化されているか」 「End-to-Endの帯域」 を確認するのかは超重要
101. オンプレミスネットワーク接続編まとめ(再掲) 101 1. そのVPCは本当にオンプレミスネットワークとの通信が必 要なのか整理しよう 2. 必要な帯域をチェックしよう 3. 2つのロケーション or 方法で可用性を向上させよう 4. サービス提供がオンプレミスとの通信に依存しないように しよう
102. 102 5. 名前解決編
103. 名前解決編まとめ 103 1. どこでどのゾーンを管理しているか意識しよう 2. どのネットワークからどのドメインの名前解決をできる必 要があるか整理しよう 3. 基本はRoute 53 Resolverで名前解決しよう 4. オンプレミスで管理しているゾーンと互いに名前解決でき るような環境を整えよう
104. 何事も 104 名前解決できないと通信できない
105. まずは 105 どこでどのゾーンを管理しているのか把握する
106. 例えばどこ？ 106 インターネット上のどこか セルフマネージドのADやBIND Route 53 Hosted Zone
107. そして 107 どのリソースがどのゾーンに対して どうやって名前解決しに行くか整理
108. 特に 108 「インターネット上で公開されているのか」 「オンプレミスやVPC内に閉じているのか」 で経路は変わる
109. どちらも 109 参照するフォワーダ / フルサービスリゾルバが 名前解決できることが前提
110. インターネット上に公開されている場合 110 あまり気にしなくて良い
111. 111 Route 53 Resolverでもオンプレのフルサービスリゾルバでも インターネットに抜けられるのであれば名前解決できる
112. 問題は 112 インターネットに公開されていないゾーンで 管理されているドメインに対する名前解決
113. オンプレDNSサーバーで管理している場合 113 どうする?
114. 114 Route 53 Resolver Outbound Endpoint
115. 115 Route 53 Resolverをフルサービスリゾルバ として指定しながらRoute 53 Hosted Zone 管理外のドメインも名前解決できる
116. 構成図 116
117. なぜRoute 53 Resolverを使いたいのか? 117 VPCエンドポイントの名前解決 & セルフマネージドのDNSサーバー自体と その経路の可用性が心配
118. VPCエンドポイントの名前解決 118 基本そのVPCエンドポイントがあるVPCから でなければ名前解決できない
119. オンプレのフルサービスリゾルバだと 119 DXが切れると何もできなくなる
120. じゃあ 120 「オンプレのAD参加しているんだが」 「Route 53 Private Hosted Zoneのドメインの名 前解決をオンプレからしたいんだが」
121. そんな時は 121 Route 53 Resolver Inbound Endpoint
122. ADのDNSサーバーを参照しながらも 122 VPCエンドポイントを名前解決できる
123. 加えて 123 オンプレからRoute 53 Private Hosted Zoneで 管理しているドメインの名前解決もできる
124. なんで必要? 124 Route 53 Private Hosted Zoneは 委任することも、されることもできないから
125. これはできない 125
126. Route 53 Resolver Endpointっていい値段 126 https://aws.amazon.com/jp/route53/pricing/ 2 ENI x 0.125 USD x 730 時間 (1ヶ月) = 182.50 USD
127. なので 127 ネットワーク管理アカウント上の VPCに集約しましょう
128. 構成例 128
129. マルチアカウントだとこのような構成 129
130. オンプレミスからPrivate Hosted Zone 130
131. VPCからオンプレミスのドメイン 131
132. VPCから別VPCのドメイン 132
133. 名前解決編まとめ (再掲) 133 1. どこでどのゾーンを管理しているか意識しよう 2. どのネットワークからどのドメインの名前解決をできる必 要があるか整理しよう 3. 基本はRoute 53 Resolverで名前解決しよう 4. オンプレミスで管理しているゾーンと互いに名前解決でき るような環境を整えよう
134. 134 6. 通信集約編
135. 通信集約編まとめ 135 1. Interface型のVPCエンドポイントは集約しよう 2. インターネットのアウトバウンドは集約しよう 3. ネットワーク間の通信の検査も集約しよう 4. 集約時の注意点も理解しよう
136. なぜ集約するのか 136 コスト最適化のため & ログの集中管理のため
137. パターン1 137 VPCエンドポイントを Shared VPCに集約 (Transit Gatewayで接続)
138. パターン2 138 VPCエンドポイントをVPC毎 に作成(Transit Gatewayで 接続)
139. VPCエンドポイントを集約することで 139 VPC数, VPCエンドポイント数の組み合わせ VPCエンドポイントをShared VPCに集約 (Transit Gatewayで接続)の固定費 VPCエンドポイントをVPC毎に作成 (Transit Gatewayで接続)の固定費 VPCエンドポイントの集約の有 無による課金額の差 VPC数, VPCエンドポイント数 = 3, 3 246.3 USD 285.3 USD 13.67% VPC数, VPCエンドポイント数 = 3, 5 276.1 USD 374.7 USD 26.31% VPC数, VPCエンドポイント数 = 3, 10 350.6 USD 598.2 USD 41.39% VPC数, VPCエンドポイント数 = 5, 3 347.1 USD 475.5 USD 27.00% VPC数, VPCエンドポイント数 = 5, 5 376.9 USD 624.5 USD 39.65% VPC数, VPCエンドポイント数 = 5, 10 451.4 USD 997.0 USD 54.72% VPC数, VPCエンドポイント数 = 10, 3 599.1 USD 951.0 USD 37.00% VPC数, VPCエンドポイント数 = 10, 5 628.9 USD 1249.0 USD 49.65% VPC数, VPCエンドポイント数 = 10, 10 703.4 USD 1994.0 USD 64.72% 集約するVPCエンドポイントの数が 多ければ多いほどコストメリットが出てくる
140. 詳細な集約手順は以下記事参照 140
141. NAT Gatewayも集約するとお安くなりがち 141 詳細な集約手順は以下記事参照
142. 加えて 142 NAT Gatewayに複数のENIを割り当てることで 最大同時接続 440,000件まで対応可能
143. アウトバウンドを集約するなら一緒に 143 Network Firewallなどで通信を検査するのもオススメ
144. ただし 144 集約のためだけにTransit Gatewayを使うのは勿体無い Transit Gatewayを経由してVPCや オンプレと通信する要件がない & NAT Gatewayが1つで十分 であれば集約しない方が安い
145. 集約するということは分散しないということ 145 集約先や集約を実現している仕組みがダウンした時や 設定ミスした場合の影響範囲も考えておこう
146. 通信集約編まとめ (再掲) 146 1. Interface型のVPCエンドポイントは集約しよう 2. インターネットのアウトバウンドは集約しよう 3. ネットワーク間の通信の検査も集約しよう 4. 集約時の注意点も理解しよう
147. 147 まとめ
148. まとめ 148 • いきなり最適解を見つけるのは不可能 • 試行錯誤して徐々に自組織にあった構成やポリシーを見 つけていく • 1回作って終わりではなく、常にアップデートをする • 定期的に抱えている課題を認識・整理する • 変更に強い組織・体制にする