TT Lab
はじめる
学ぶ 学習パス コース

クラウドネットワーク設計

VPCを紙の上で設計する

TT Labで続きを見る

目標

クラウドネットワークは、作る前に決めることがほぼすべてです。アドレス範囲を間違って選ぶと、あとから直せません。すでに動いているサービスのIPを変えなければならないからです。

このラボは、クラウドアカウントなしで、実際に行う計算をそのまま行います。

条件

計算は手でしない

python3 - <<'PY'
import ipaddress as i
vpc = i.ip_network('10.42.0.0/16')
print(list(vpc.subnets(new_prefix=22))[:4])
print(vpc.overlaps(i.ip_network('10.0.0.0/12')))
PY

ipaddressモジュールで十分です。人間の目では、10.42.4.0/22と10.42.6.0/24が重なっているかわかりません。

ファイル

ファイル 内容
01-range.txt 選んだVPCアドレス範囲の1行
plan.csv 이름,CIDRで9行(プレースホルダーは名前です)
check.py 重なりの検査。重なれば終了コード1
04-growth.txt 4つ目のAZに使う空きブロック
route.csv 계층,기본경로대상で3行(プレースホルダーは階層とデフォルト経路の宛先です)
06-nacl.txt NACLのルール
07-egress.txt コスト計算
08-notes.md まとめ

参考

ステップ3のcheck.pyは、採点ツールがわざと重ねた計画で実行してみます。見つけられなければ合格できません。検査が本当に検査しているかを確認することも、ラボの一部です。

重ならないアドレス範囲を選ぶ

オンプレミスがすでに10.0.0.0/12を使っています。ここと重ならない/16のVPCアドレス範囲を選んで、01-range.txtに1行で書いてください(例: 10.42.0.0/16)。

/12は10.0.0.0から10.15.255.255までです。第3オクテットではなく第2オクテットを見てください。確認はPythonで行います: python3 -c "import ipaddress as i; print(i.ip_network('10.42.0.0/16').overlaps(i.ip_network('10.0.0.0/12')))"。

アドレス範囲が重なると、あとでVPN・ピアリングをつなぐときに元に戻せません。すでに動いているサービスのIPを変えなければならないからです。

3つのAZに3層を敷く

3つのAZのそれぞれに、public /24、app /22、db /24を配置して、plan.csvに이름,CIDR(プレースホルダーは名前です)の形式で9行書いてください。

名前はpublic-a、app-a、db-a、public-b…のように付けてください。互いに重なってはならず、すべてVPCの中にある必要があります。/22は/244つ分の大きさです。アプリ層が最も大きくなければならない理由は、Podやタスクがそれぞれ1つずつIPを消費するからです。

計算は手でしないでください。python3 -c "import ipaddress as i; print(list(i.ip_network('10.42.0.0/16').subnets(new_prefix=22))[:4])"で確認します。

重なりの検査を自分で書く

check.pyを作成してください。plan.csvを読み、重なる組があればその組を出力して終了コード1、なければ0で終わる必要があります。

ipaddress.ip_network(x).overlaps(y)で十分です。人間の目では、10.42.4.0/22と10.42.6.0/24が重なっているかわかりません。だから、この検査をCIにかけます。

採点ツールは、check.pyをわざと重ねた計画で実行してみます。見つけられなければ合格できません。

4つ目のAZの場所を残す

今の計画で、AZをもう1つ追加できるかを確認し、使える空きブロックを04-growth.txtに書いてください。

必要なのは、public /24 + app /22 + db /24の1セットです。VPCから、すでに使ったものを引いて、残りのブロックを求めてください。

最初から/16をぎっしり使い切る設計が、最もよくあるミスです。AZは増えるのに、アドレス範囲は増やせません。

どこへ出ていくかを決める

route.csvに、層ごとに계층,기본경로대상(プレースホルダーは階層とデフォルト経路の宛先です)を3行書いてください。public / app / dbです。

publicはインターネットゲートウェイ(igw)、appはNAT(nat)、dbは外へ出ません(none)。この3行が、そのままセキュリティ境界です。

「プライベートサブネット」という言葉は、デフォルト経路がIGWではないという意味にすぎません。NATを付ければ、外へは出ていきます。出られなくするには、デフォルト経路をそもそも置かないようにします。

NACLはなぜルールが2倍になるのか

appサブネットから外へのHTTPS(443)で出る必要があります。NACLだけでこれを許可するために必要なルールを、06-nacl.txtに方向とポートまで書いてください。

セキュリティグループは状態を記憶していて、出ていったリクエストの応答が自動的に戻ってきます。NACLは記憶しません。出ていく443を開け、戻ってくる応答のために、インバウンドのエフェメラルポート範囲(1024–65535)も開ける必要があります。

これを知らずに、「SGは開けたのに、なぜ通らないのか」で半日を費やします。

出ていくデータにお金がかかる

appサブネットが毎月、オブジェクトストレージへ500GBを送っています。NATを通るときと、ゲートウェイエンドポイントを使うときの月のコスト差を計算して、07-egress.txtに数字とともに書いてください。

NATゲートウェイは、時間あたりの料金と処理量あたりの料金が別々にかかります(おおよそGBあたり$0.045)。ゲートウェイエンドポイントには、処理量の料金がありません。500GB × $0.045 = ? そして、NATの常駐コスト(730時間 × $0.045)も一緒に書いてください。

料金は事業者・リージョンごとに違います。重要なのは桁数です。トラフィックは同じなのに、経路を変えるだけでコストが消える構造があるということです。

3つをまとめる

08-notes.mdに3行以上。アドレス範囲を間違って選ぶとなぜ元に戻せないのか、プライベートサブネットの本当の意味、SGとNACLの違い。

本文に겹、기본 경로、상태が含まれている必要があります(韓国語で、順に「重なる」の語幹、「デフォルト経路」、「状態」を意味する語です)。