DevelopersIO 2023の登壇資料です。
https://event.classmethod.jp/developers-io/2023
AWS Ambassadorが考える個人的に最強のマルチアカウントハイブリッドネットワーク構成2023/7/8AWS事業本部 のんピ1
View Slide
自己紹介 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こんなことあると思います
4ハードウェアの保守切れの度にシステムの大規模更改面倒だな
5そうだ! AWS使っていくぞ!
そうしてこの世に新たなVPCが誕生 6よろしくVPCくん
7そしてn年後
無秩序に作られた大量のVPC 8よろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくんよろしくVPCくん
9もしくは
1つのVPCに何でも詰め込まれる 10よろしくVPCくん
というように 11AWS への移行が進んでいくとネットワークがカオスになりがち
なぜか 12どのようにしてAWS上でネットワークを拡張していくのか方針が決まっていない
13複雑なネットワークは運用への負荷が大きい
そこで 14AWS Ambassadorが考える最強のマルチアカウントハイブリッドネットワーク構成を紹介
紹介する要素 151. VPC 設計編2. アカウント分割編3. VPC 間接続編4. オンプレミスネットワーク接続編5. 名前解決編6. 通信集約編
161. VPC 設計編
VPC設計編まとめ 171. VPCはシステムと環境毎に分割しよう2. サブネットは役割とルーティング先で分割しよう3. サブネットは最低でも2AZ、できれば3AZ分作ろう4. CIDRはギリギリを攻める必要はないが、広すぎ注意5. VPCのCIDRは他のVPCと被らないようにしよう6. AWSで使いたいCIDRは大きく広めに確保しておこう
なぜ 18VPCをシステムと環境毎に分割するのか
19セキュリティと運用効率の向上のため
1つのVPCに何でも詰め込む方式 20VPCPrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstance
何らかの攻撃を受けた場合 21VPCPrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstanceVPC内の他のEC2インスタンスにも潜在的な脅威が
何か変更を加える場合 22VPCPrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstancePrivate subnetInstanceS3 VPC EndpointVPCエンドポイントのポリシーを変更する際全システムで調整する必要がある
つまりは 23影響範囲が広すぎ
なので 24VPCをシステムと環境毎に分割して管理の範囲を小さくしてあげよう
VPCの分割は分かった 25じゃあサブネットはどの粒度で分割する?
26役割とルーティング先で分割
役割とは? 27Virtual private cloud (VPC)WebサーバーPrivate subnetProxyサーバーPrivate subnetDBサーバーPublic subnet
なぜ役割で分割する? 28セキュリティグループでCIDR単位で許可したい場面があるから
Transit Gatewayでは 29セキュリティグループでセキュリティグループIDを使ってルールを制御できない
セキュリティグループIDで制御できない 30
Transit Gatewayを経由する場合は 31必然的にセキュリティグループはCIDRを指定して通信を制御する=送信元がAuto Scalingすると/32で許可しづらい=サブネットのCIDRで許可すると楽
ルーティング先とは? 32基本3種1. Public : インターネットと直接通信可能2. Egress : インターネットにNAT経由で通信可能3. Isolated : インターネットとの通信不可その他1. Internal : 別VPCやオンプレミスへの通信可能
VPCPublic subnet基本3種のイメージ 33VPCPrivate subnetVPCPrivate subnetPublic subnetIGW IGW IGWPublic Egress Isolated
なぜルーティング先で分割する? 34サブネットに割り当てられるルートテーブルは1つまでルーティング制御はセキュリティ対策の第一歩(個人の意見です)
じゃあサブネット分割しまくれば良い? 35あまり細かくサブネットを切りすぎると使えるIPアドレスが減るため注意最低限ルーティング先で分割しよう
サブネットは何セット作る? 363AZ分できれば作りたい最低でも2AZ分作る
なぜ? 37可用性向上のため
こんなことありましたよね 38ALB切り離せない問題
ALB切り離せない問題とは 39ALB自体が500エラーを返すようになった=> 最低2AZ分サブネットを指定する必要があるため切り離せない
つまりは 403AZ分のサブネットの余裕がないと対応できない
言い換えると 41VPCのCIDRには少し余裕が必要
VPCやサブネットのCIDRに余裕がないと 42リソースによってはIPアドレスが枯渇する
例) RDS Proxy 43DBインスタンスクラスによって必要なIPアドレスが変動https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/rds-proxy-setup.html
例) DataSync 44DataSyncタスクの数によってENIが作成されるhttps://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/datasync-network.html
ただし 45システムと環境毎に分離しているのに1つのVPCに /16 のCIDRは過剰=/20 ~ /24 ぐらいで十分なことがほとんど
うわ! もう空きがない!! 46大丈夫、VPCのCIDRは後から追加可能です※ サブネットのCIDRは追加不可
そんな時のために 47CIDRの割り当て状況は把握しておこう
CIDRが重複すると 48Transit GatewayやDirect Connect Gatewayには同じCIDRのVPCをアタッチできないぞ
加えて 49AWS全体で使いたいCIDRは広めに確保しておこう
なぜか 50DXGWでAWSからオンプレミスに広告できるネットワークアドレスの数は20個まで=ネットワークアドレスが分散すると集約できない=クォーターに引っかかりやすい
VPC設計編まとめ (再掲) 511. VPCはシステムと環境毎に分割しよう2. サブネットは役割とルーティング先で分割しよう3. サブネットは最低でも2AZ、できれば3AZ分作ろう4. CIDRはギリギリを攻める必要はないが、広すぎ注意5. VPCのCIDRは他のVPCと被らないようにしよう6. AWSで使いたいCIDRは大きく広めに確保しておこう
522. アカウント分割編
アカウント分割編まとめ 531. アカウントはシステムと環境毎に分離しよう
なぜ 54アカウントをシステムと環境毎に分割するのか
55権限分離と課金の可視性向上のため
1アカウントに複数システムが混在すると 56
1アカウントに複数システムが混在すると 57
58RBACやABACしようにもポリシーやタグの設計に時間がかかる
RBACやABACについては以下記事参照 59
アカウント分割をすることで 60
料金面においても問題が 61
アカウントを分割することで 62
アカウント分割編まとめ (再掲) 631. アカウントはシステムと環境毎に分離しよう
643. VPC間接続編
VPC間接続編まとめ 651. 基本はTransit Gatewaya. ただし、初めからTransit Gatewayで接続する必要はない2. どのVPC間で通信が必要なのか整理しよう3. VPC間で相互に接続が必要なのか整理しようa. 疎結合にできるなら疎結合にb. VPC LatticeやPrivateLinkで事足りることもある
大量のVPCを互いに接続する場合 66Transit Gatewayが超絶便利https://pages.awscloud.com/rs/112-TZM-766/images/20191113_AWS-BlackBelt_Transit_Gateway.pdf
ただし 67最初からTransit Gatewayを使う必要は全くない
理由 68小規模環境であればオーバースペック
Transit Gatewayの料金をご覧ください 69https://aws.amazon.com/jp/transit-gateway/pricing/
VPC10個をTransit Gatewayに接続する場合 70毎月 511.00 USD (通信料金を除く)
はい 71良いお値段
相互接続するVPCの数が少ないなら 72こんな構成だって良いじゃないか
そのためにも意識しよう 73どのVPC間で通信が必要なのか整理して不必要なルーティングを行わない
通信が必要な場合であっても 74Transit GatewayやVPCピアリングが不要なケースもある
例1) S3バケットでデータ連携 75
例2) VPC LatticeでAPI連携 76抜粋 : VPC Lattice クロスアカウント接続に必要な要素を図解してみた
例3) PrivateLinkでDBに接続 77抜粋 : PrivateLinkとNLBを使ったRDSクロスアカウントアクセスを試してみる
VPC間接続編まとめ (再掲) 781. 基本はTransit Gatewaya. ただし、初めからTransit Gatewayで接続する必要はない2. どのVPC間で通信が必要なのか整理しよう3. VPC間で相互に接続が必要なのか整理しようa. 疎結合にできるなら疎結合にb. VPC LatticeやPrivateLinkで事足りることもある
794. オンプレミスネットワーク接続編
オンプレミスネットワーク接続編まとめ 801. そのVPCは本当にオンプレミスネットワークとの通信が必要なのか整理しよう2. 必要な帯域を把握しよう3. 2つのロケーション or 方法で可用性を向上させよう4. サービス提供がオンプレミスとの通信に依存しないようにしよう
そもそも 81そのVPCは本当にオンプレミスネットワークと接続させる意味がありますか?
詳しくは 82
今回は 83はい! 接続したいです!ということにしておきます
続いて 84Transit VIF用意できますか?
Transit VIFを用意できない場合 8521個以上のVPCを接続したければ複数のDXGWで代用
Transit VIFを使う場合でも 86必要な帯域とVIFの帯域は把握しよう
大量のVPCとオンプレミスを接続すると 87その分通信が発生する
理解せずにVPCを増やしまくると 88Transit VIFが耐えられない
対応 89VIFを3本以上用意しよう
え？2本じゃなくて3本以上? 901本がダウンした場合に備える
VIFのロケーションは分割しよう 91ロケーションレベルの障害に耐えるため
Site-to-Site VPNでもいいじゃん 92はい、良いです
ただし 93その帯域、Site-to-Site VPNで捌けますか?
無駄ではないが 94DX障害時のサービスレベルを把握した上で対応
そもそもAWS側ばかり気にしているけど 95接続拠点が単一障害点(SPOF)じゃないよね？
こんな構成だと 96拠点A障害発生時は他の拠点もVPCに接続できなくなる
前提として 97サービス提供がオンプレミスとの通信に依存しないようにしよう
AWS側をいくら冗長化しても 98オンプレ側で冗長化されていなければ勿体無い通信速度やレイテンシーも気になる
密結合なものはセットでAWS上にリフト 99難しければキューやキャッシュで非同期通信
ということで 100「単一障害点があるのか」「どこがどのように冗長化されているか」「End-to-Endの帯域」を確認するのかは超重要
オンプレミスネットワーク接続編まとめ(再掲) 1011. そのVPCは本当にオンプレミスネットワークとの通信が必要なのか整理しよう2. 必要な帯域をチェックしよう3. 2つのロケーション or 方法で可用性を向上させよう4. サービス提供がオンプレミスとの通信に依存しないようにしよう
1025. 名前解決編
名前解決編まとめ 1031. どこでどのゾーンを管理しているか意識しよう2. どのネットワークからどのドメインの名前解決をできる必要があるか整理しよう3. 基本はRoute 53 Resolverで名前解決しよう4. オンプレミスで管理しているゾーンと互いに名前解決できるような環境を整えよう
何事も 104名前解決できないと通信できない
まずは 105どこでどのゾーンを管理しているのか把握する
例えばどこ？ 106インターネット上のどこかセルフマネージドのADやBINDRoute 53 Hosted Zone
そして 107どのリソースがどのゾーンに対してどうやって名前解決しに行くか整理
特に 108「インターネット上で公開されているのか」「オンプレミスやVPC内に閉じているのか」で経路は変わる
どちらも 109参照するフォワーダ / フルサービスリゾルバが名前解決できることが前提
インターネット上に公開されている場合 110あまり気にしなくて良い
111Route 53 Resolverでもオンプレのフルサービスリゾルバでもインターネットに抜けられるのであれば名前解決できる
問題は 112インターネットに公開されていないゾーンで管理されているドメインに対する名前解決
オンプレDNSサーバーで管理している場合 113どうする?
114Route 53 Resolver Outbound Endpoint
115Route 53 Resolverをフルサービスリゾルバとして指定しながらRoute 53 Hosted Zone管理外のドメインも名前解決できる
構成図 116
なぜRoute 53 Resolverを使いたいのか? 117VPCエンドポイントの名前解決&セルフマネージドのDNSサーバー自体とその経路の可用性が心配
VPCエンドポイントの名前解決 118基本そのVPCエンドポイントがあるVPCからでなければ名前解決できない
オンプレのフルサービスリゾルバだと 119DXが切れると何もできなくなる
じゃあ 120「オンプレのAD参加しているんだが」「Route 53 Private Hosted Zoneのドメインの名前解決をオンプレからしたいんだが」
そんな時は 121Route 53 Resolver Inbound Endpoint
ADのDNSサーバーを参照しながらも 122VPCエンドポイントを名前解決できる
加えて 123オンプレからRoute 53 Private Hosted Zoneで管理しているドメインの名前解決もできる
なんで必要? 124Route 53 Private Hosted Zoneは委任することも、されることもできないから
これはできない 125
Route 53 Resolver Endpointっていい値段 126https://aws.amazon.com/jp/route53/pricing/2 ENI x 0.125 USD x 730 時間 (1ヶ月)= 182.50 USD
なので 127ネットワーク管理アカウント上のVPCに集約しましょう
構成例 128
マルチアカウントだとこのような構成 129
オンプレミスからPrivate Hosted Zone 130
VPCからオンプレミスのドメイン 131
VPCから別VPCのドメイン 132
名前解決編まとめ (再掲) 1331. どこでどのゾーンを管理しているか意識しよう2. どのネットワークからどのドメインの名前解決をできる必要があるか整理しよう3. 基本はRoute 53 Resolverで名前解決しよう4. オンプレミスで管理しているゾーンと互いに名前解決できるような環境を整えよう
1346. 通信集約編
通信集約編まとめ 1351. Interface型のVPCエンドポイントは集約しよう2. インターネットのアウトバウンドは集約しよう3. ネットワーク間の通信の検査も集約しよう4. 集約時の注意点も理解しよう
なぜ集約するのか 136コスト最適化のため&ログの集中管理のため
パターン1 137VPCエンドポイントをShared VPCに集約(Transit Gatewayで接続)
パターン2 138VPCエンドポイントをVPC毎に作成(Transit Gatewayで接続)
VPCエンドポイントを集約することで 139VPC数, 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
NAT Gatewayも集約するとお安くなりがち 141詳細な集約手順は以下記事参照
加えて 142NAT Gatewayに複数のENIを割り当てることで最大同時接続 440,000件まで対応可能
アウトバウンドを集約するなら一緒に 143Network Firewallなどで通信を検査するのもオススメ
ただし 144集約のためだけにTransit Gatewayを使うのは勿体無いTransit Gatewayを経由してVPCやオンプレと通信する要件がない&NAT Gatewayが1つで十分であれば集約しない方が安い
集約するということは分散しないということ 145集約先や集約を実現している仕組みがダウンした時や設定ミスした場合の影響範囲も考えておこう
通信集約編まとめ (再掲) 1461. Interface型のVPCエンドポイントは集約しよう2. インターネットのアウトバウンドは集約しよう3. ネットワーク間の通信の検査も集約しよう4. 集約時の注意点も理解しよう
147まとめ
まとめ 148● いきなり最適解を見つけるのは不可能● 試行錯誤して徐々に自組織にあった構成やポリシーを見つけていく● 1回作って終わりではなく、常にアップデートをする● 定期的に抱えている課題を認識・整理する● 変更に強い組織・体制にする
149
non97
replu
yoshiitaka
smt7174
akkie76
niftycorp
kosui
k1style
knsg16
hhiroshell
ysasago
k1low
coconala_engineer
colly
denniskardys
tenderlove
morganepeng
lara
danielanewman
searls
lauravandoore
cassininazir
erikaheidi
holman
tammyeverts