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