ダイアグラムで見るAWSネットワーキングの概念
(miparnisariblog.wordpress.com)- AWS VPCダッシュボードの複雑な項目を理解するため、AWSネットワーキングリソースの関係を一目で把握できるマインドマップを作成した
- Toni PasanenのAWS Networking Fundamentalsを主な参考資料として、ネットワーキング関連リソースを接続構造を中心に整理した
- AWSネットワーキングが複雑になる理由は接続タイプが多様であるためであり、アカウント-オンプレミス、アカウント-アカウント、VPC-VPC、サブネット-サブネット、VPC-インターネット、VPC-AWSサービス接続が含まれる
- 成果物はAWSネットワーキング構成要素を相互につないだマインドマップで、Lucidchartの原本もあわせて確認できる
- AWSネットワーキングを初めて整理する開発者は、複数のリソースがどのような関係で結び付くのかを視覚的に把握するのに活用できる
VPCダッシュボードから始まった混乱
- 2023年3月までは、AWS VPCダッシュボードで何が起きているのか理解するのが難しかった
- 左側パネルのスクロールバーが長くなるほど項目が多く、各リソースがどう接続されるのか把握しにくかった
参考にした資料と整理の方向性
- AWSネットワーキングに関わるさまざまなリソースを理解するため、Toni PasanenのAWS Networking Fundamentalsを大部分読んだ
- 本を読んだあと、AWSネットワーキングリソースが多い理由は、可能な接続方式が多いことにあると整理した
AWSネットワーキングで扱う接続タイプ
- AWSネットワーキングには複数種類の接続が含まれる
- AWSアカウントとオンプレミス間の接続
- アカウント間の接続
- VPC間の接続
- サブネット間の接続
- VPCとインターネット間の接続
- VPCと特定のAWSサービス間の接続
マインドマップの成果物
- 複数の要素をつなぎ合わせるため、AWSネットワーキングの概念をマインドマップとして作成した
- 元の編集版はLucidchartリンクで確認できる
- 役に立つかどうか、また誤りがないかについてフィードバックを求めている
1件のコメント
Hacker News のコメント
AWSで IAMポリシーと認証まわりのデバッグ がなぜここまでひどいのか分からない
競合になりたいなら、ここに注力すべき。権限なしエラーの原因を探すのに何時間も無駄にしたのに、公式ドキュメントは SCP、IAM、リソースポリシーなど、適用されうる8種類くらいのポリシーを手作業で調べろと言ってくる
結局 Athena と CloudTrail を使うドキュメントを見つけても、リクエストの半分は理由もなく抜け落ちているし、エラーメッセージにリクエスト ID があっても、それで簡単に検索できない。リクエスト ID で直接引けて、どのポリシーが拒否したのかを明確に表示すべきだ
最初から最後まで完全な混沌で、こういう状態を維持したほうが サポート契約 をもっと売れるのではないかと思えてくる
個人プロジェクトでは、ごくまれなケースを除けば、ほとんど常にもっと価値の高い別の選択肢を選ぶ。10年ほど前、AWS は「システムは我々が管理するからシステム管理者は全員解雇しろ」という感じで売られていたが、今では優秀な AWS DevOps エンジニアは高価で見つけにくく、特に大規模構成では AWS の推奨事項をきちんと守るとコストもとてつもなくかかる
Function App に SQL データベースへのアクセス権を与えるとき、Function App の実際の名前だけ使えばよく、別名があるならオブジェクト識別子に限定すればよかった。パスワードや証明書のようなものはもう不要で、ただ動く
認証パッケージや Application Insights のようなものを一緒に使えば、ログの見方が分かっている前提ではあるが、「いったい何が起きたんだ」で長時間詰まることはほとんどない
ただし Azure にも地雷原はあり、どこに地雷があるかを事前に知らなければ、同じような挫折を味わう。Microsoft は地雷の位置についてのヒントを AWS よりずっと上手く残してはいるが、最後のベールを突き破ってコストと複雑さが5〜10倍に膨れ上がるのを避けるには、20年の経験を持つ魔法使いのような人が必要になるほど、都合よく抜けているヒントもある
サービスアカウントのデバッグでは、ときにはマシンやクラスターの再起動まで必要になってさらに厄介だ。どこで問題が起きているのかを正確に突き止めてくれる「クラウド traceroute」のようなツールがあればすごいと思う
公平を期すと、まだ使ったことのない最小権限ツールはいくつかある: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
本当に腹立たしく、UX デザイナーとエンジニア を組ませて設計すべきなのに、そうしていない
そうしたサービスが顧客に提供されるなら、潜在的には攻撃者にも提供されうるし、実際にいくつかの企業のセキュリティ・コンプライアンスポリシーに違反する可能性もある
それでも、顧客が「AWS のルートユーザーで危険なことをする」といった大きなリスクを認める文書に署名すれば、選択できるようにはすべきだと思う
AWS のリクエストはあまりに分散しているので、概念的には GraphQL に似た構成 がこうしたシステムに合っていそうだ。OTEL のようなトレーシングシステムともそれほど遠くない
だからAWSを扱わなければならないのが嫌いだ。これを学ぶのは技術知識ではなく製品知識だからだ。
TCP/IP Illustratedシリーズは最初から最後まで読んで完全に身につけたし、その知識は何十年にもわたって役に立ってきた。
一方でAWSの知識はそれ自体かなり複雑で、毎回学ぶのを拒みたくなる。この図を見ると、目標が単純化だったとしてどれだけ成功したのかよく分からない。
たとえばエンタープライズ顧客に仮想エンタープライズネットワークや仮想データセンターネットワークを再現させるのが目標なら、それらはクライアントTCPスタックよりはるかに複雑だ。
単純な用途ではデフォルトも単純だ。複雑なケースではAWS専用の製品知識が必要になるが、土台となる概念の大半は他のクラウドやオンプレミスのネットワークと共通している。N個目のプログラミング言語を学ぶのに近い。
TCP/IPはネットワークプログラマにとって有用な知識だ。大学のネットワーキングの授業では、ネットワーク、サブネット、ルーティングテーブル、RIP・OSPF・BGPのようなルーティングプロトコル、NATなどを実機で扱い、Ciscoの支援も多かったので学期末にはCCNA認定レベルになっていた。
Cisco製品の動作のような「製品知識」も多く学んだが、その大半は忘れ、核心となる概念はAzure、AWS、GCPへとうまく移った。クラウドVPCは実際のネットワークの仮想的な対応物であり、仮想マシンが実際のマシンの対応物であるのと同じだ。
特にNATは本当に人を混乱させる。もっと基本的なところでは、多くのエンジニアがCIDR表記やTCPそのものにも苦労している。たとえば
send()が渡したバッファを1つの単位として送ると思っていたり、recv()が常に完全な「メッセージ」を受け取ると思っていたりする。接続タイムアウトとピアリセットの違いもかなり混同されている。ただ、こうした知識が不要であればよかったのにとは思う。IPv6はネットワークを非常に大きくし、サブネットサイズの計画のようなものをかなり不要にしてくれる。NATは冷たい地獄の中で消え去ってくれて構わない。VPNも二度と見なくていいし、単にTLSを使えばいい。IPアドレスを認証のように使うクラウドファイアウォールと、それによって生じる誤解を招くエラーもなくしたい。Azureはこの点がひどい。
多くのプロ向けソフトウェアと同じく、最初は必要に迫られて単純だったが、時間とともに複雑になり、AWSはフルマネージドなオンデマンドインフラサービスの魅力とAmazonが注ぎ込んだ資源によって急速に膨れ上がった。
ハードウェアを直接扱わなくてよい価値は今でも大きいが、表示価格のほかにも、移行しにくいベンダー固有の知識という代償を確実に払っている。
その代わりに「internet gateway」「NAT gateway」「egress only internet gateway」「transit gateway」のような使い捨ての概念が山ほどある。結局、「クラウド」だけ理解して実際にどう動作するのかは分からないエンジニアの世代が生まれそうだ。
「差別化にならない」構成要素をすべてAWSに渡し、自分たちが得意なビジネスに集中すればいい。
単に一般的なグローバルアドレッシングとファイアウォールを提供していれば、この複雑さの大半は消えていただろう。
私たちはIPレベルのインターネットが何のためにあるのか、エンドツーエンドアーキテクチャがどんな問題を解決するのかを簡単に忘れてしまう。
AWSが「Well-Architected™」なネットワーキングとして教えているものは、実際には収益性のあるカーゴカルトに近く、複雑さ、よく似た10.xネットワークの迷路、アドレス衝突、相互接続しようとしたときの雑なプロキシ、低下した実際のセキュリティ、ベンダーロックインにつながる。複雑さはセキュリティの敵だ。
昔のシステム管理者が私の報酬の半分や4分の1しかもらっていなかったわけでもなく、通常は1人で開発者100人分をカバーできるだけのハードウェアを管理していた。残りの人たちがこうした責務の拡大と脳へのダメージを避けるためのオーバーヘッドは0.5%程度だったわけだ。
AWSでは再び文字どおり専門性の死が起きている。
そしてグローバルアドレッシングとファイアウォールは、公開サブネットしかないVPCを作ってセキュリティグループをファイアウォールのように使えば、基本的には可能なのではないかとも思う。ベストプラクティスは公開/非公開サブネットとNATゲートウェイだが、セキュリティグループだけに依存するのが不可能というわけではない気がする。
それもグローバルanycast IPの背後にある。
そのため、クラウドネットワーキングで私たちが目にしている不要な複雑さの多くが生まれている。
このマインドマップは、いくつかのネットワーキング概念にまでさらに単純化できそう
そうすれば関係線や矢印の大半は消えて、AWSの概念を他のクラウドや家庭内ネットワークにも対応づけられる
https://news.ycombinator.com/item?id=18925350は基礎をとても上手く可視化した資料。ネットワークとは何か、内側と外側とは何か、というところから始めるとメンタルモデルがずっと作りやすくなり、細部を全部知らなくてもAWSの機能はかなり納得できる
結果として複雑なシステムを明快かつ簡潔に要約している。次にAWSの森をかき分けるときの参考資料になりそう
たとえばアベイラビリティゾーンの長方形の中にサブネットがあり、その外側にVPCがあり、その長方形がリージョンの中にある、といった形。だいたいこんな感じだが、もっと見やすい図: https://images.edrawsoft.com/articles/aws-diagram-examples/e...
クラウド初期の、AWSネットワーキングがシンプルだった高揚感のある時代を覚えている
それでも、こうなることは分かっていた。万人向けの何でも屋になろうとすれば、結局はレガシーIPv4データセンターネットワーキングの狂気を再現せざるを得ない
最近Azureで、概念的には単純なことをやろうとした。データベースのバックアップが入ったストレージアカウントをインターネットにさらして、誰でも突ける状態にしないことだ
ファイアウォールを有効にするだけで済むと思ったが、許可リストにはサブネットしか入れられず、しかも個別のサブネットを1つずつ追加しなければならなかった。仮想ネットワークは不可で、他の場所では使える「自分のすべての仮想ネットワーク」も使えなかった
Private Endpoint機能もあるが、性能を落とし、追加コストもかかる。ソフトウェア定義ネットワーク設定でアドレスを「public」から「private」に変えるのは大変だから、クラウドの妖精たちに報酬を払わねばならないらしい
しかも実際には動かない。クライアントが見つけられるようにDNSを上書きする必要があり、ADドメインにぶら下げたらPaaSサービスからアクセスできなくなった
結局、さらにコストのかかるプライベートDNSゾーンを作り、ハブネットワークに接続し、またコストのかかるDNS Resolverサービスを付け、ADドメインが動き続けるよう膨大なルールを設定していたら1週間が過ぎた
元々やりたかったのは、ストレージキーが漏れてもロシアのハッカーがバックアップにアクセスできないようにすることだけだった。来週には、DNS設定が更新された仮想ネットワークを再デプロイするようサブスクリプションテンプレートを更新できるかもしれない。冪等ではないって？ 来年あたりプレビューで出るかもね
そのうえで公開対象は public gateway や Front Door を使えばいい。好きではないが、昔からものすごく単純だったわけでもない。ただ、以前は厳密に運用チームの仕事だったエンタープライズネットワーキングの狂った混沌に、今は開発者がより多くさらされるようになっただけだ
DNS設定は自分で直接触らない領域なので、魔法と呼んでいる。特に App Service と複数サブスクリプションを使うと、サブネットを共有できず、アプリスロットを使っているうちにIPアドレス空間が不足しないよう事前に計画しなければならない
Azureで理解できないのは、なぜエンタープライズのデフォルトが「何もインターネット上にない」ではないのかということ。インターネットに出す必要があるときに開けるようにすべきだ。どうせロードバランサーなどいろいろ構成が必要なので、インターネット公開の工程は元から複雑だ。少なくともエンタープライズ設定では、デフォルトはインターネットの外であるべき
MicrosoftがAzure認定資格を売っているから難しくしておく必要があるのかもしれないが、2023年にもなってなぜデフォルトの時点でこの複雑さを気にしなければならないのか分からない。高度にカスタマイズ可能なのは構わない
この資料は本当に素晴らしい。Google Cloudのドキュメントは、こうした複雑さを必要になったときに比較的うまく紹介している印象はあったが、ここまで完全な概観は見たことがない
ただ、画像を見るにはかなり苦労した。ページ上では小さすぎてクリックもできず、新しいタブで開くとimgurのような役に立たないページに飛ばされて、やはり小さいままだった。結局、画像をダウンロードしてようやくちゃんと見られた
この資料はすごい。クラウド製品や他の概念を学ぶとき、マインドマップとダイアグラムがどれほど強力かをよく示している
AWS認定の勉強をしていたときによく使ったが、長々とノートを書くよりも、ページの連なりとして見るよりも、マップでつながったサービスを見るほうがずっと理解しやすかった。もちろん、人によって学び方は違う
このスレッドでの批判は全部は理解できない。AWSが提供するネットワーキングシステムの大半は、必要なときに使うものだ
洗練されてはいなくても、仕事はこなす。しかもAWS専用コンポーネントのかなりの部分は、実際のネットワーキング概念にそのまま対応している。AZはケージ、VPCはVLAN、PLはおおむねアカウント間P2P VPNに相当する
残りの大半も、一般的な大規模環境で見かける普通のネットワーク構成要素だ
私の勤め先はかなり複雑なグローバルネットワークを運用していて、複数のPoPからDX経由でAWSに接続している。この図にあるものはすべて使っており、各コンポーネントには明確に定義された目的がある
この図が過度に複雑に見えるなら、たぶんこれを全部使っていないか、意図された目的どおりに使っていないか、あるいはネットワークエンジニアではない可能性が高い
この画像、実際に読める人いる？ デスクトップでも読める解像度で見られない
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw...もやはりWebページで、画像自体は大きくなっているけれど読みやすくはなっていない
それでも保存すれば少なくとも動く。そのあとには大きな画面が必要。サイズは7,763 × 4,684ピクセル
とてつもなく複雑に見える。3大クラウド事業者の中では GCP しか知らないが、あちらでもネットワーキングが単純というわけではないものの、それでもある程度は直感的で一貫している。
マルチクラウドの経験がより豊富な人が、内部・外部通信の設定のしやすさ・難しさをビッグ3基準で比較してくれるとありがたい。
驚くようなことではなく、大半はネットワーキング標準そのものにも直接対応するものがある。どちらも本質的には ソフトウェア定義ネットワーキング の世界を見ている視点にすぎない。