管理グループ、サブスクリプション設計時の考慮すべき点はなに？
※この記事は実例などをベースに常に更新していく予定です。
エンタープライスシステムの場合、このあたり整理してきちんと設計しないとのちの保守運用で大変なことになるのでAzureサブスクリプションの設計を本気で考えようと思います。
そもそもサブスクリプションの管理対象スコープを明確にしたいと思いますが、MS社サイト情報でいい図がありました。著作権の問題もあるのでそのままコピーすることができませんが、URLは以下です。
なお、ベストプラクティスとしてMicrosoft担当者が作成したと思われる資料もありました。URLは以下です。
この図の情報と私が調査した結果サブスクリプションの管理対象は
・リソースをひとくくりにしたリソースグループ
・リソースに掛かる費用(こちらはタグレベルで管理するなども可能)
・リソースへのアクセス権限（当然リソースグループ単位でのアクセス制御も可）
のようでした。なのでそれらリソースを一括管理したい場合に便利です。どのように取り扱いしたいか、管理したいかで設計を纏めるのが良いかなと思います。
この設計の際、以下非機能要件が大事かと思います。特にNW。
【非機能要件】
・NW
やりたいこと
プライベートIPアドレスの有効活用、CIDR設計をあんまり考えすぎたくない
避けたいこと
AzureにプライベートIPアドレスを配分した結果社内で利用できるプライベートIPが枯渇すること
・セキュリティ
やりたいこと
決められた担当者が決められたリソースにしかアクセスできない環境にする。第三者にセキュリティを突破された場合に被害を最小限にする。なるべくシンプルな設計にしてアクセス許可を与える際に楽な運用になるよう設計する。システム担当者へある程度委任して担当者側で作業者のアカウント追加などが可能なようにする。
避けたいこと
複雑にしすぎてもはやよくわからない。管理がすごいめんどくさい。局地的でいい感じのシンプルなわかりやすいアクセス許可の委任ができないので、基本すごい偉い人が申請をメールとかで受けて、それをベースにちまちまやる。
・運用性
やりたいこと
担当者は与えられた環境で柔軟に素早くシステムリソースを用意できる。システム担当者はサブスクリプション上のシステムリソースを柔軟に作成、削除、変更対応可能。
避けたいこと
申請ベースにして承認を受けないとサーバが作れない。変更もできない。スピード感やDevOps前提のクラウドを申請ベースで作るのは良くないと思うので。
もちろん、サブスクリプションの括りで費用やアクセス権を管理しなくてもいいんでしょうけども、ある程度自由度の高い対応をシステムカットでシステム担当者の推進力を使ってやってもらうことを考えた場合にサブスクリプションをシステム側に引き渡せばそのなかでのサービスなど自由に使えるので上記要件を実現する場合にしっくりくるのかなという印象でした。
自分なら絶対にやること
a.社内システムとイントラでの接続が必要なサブスクリプション
b.社内システムとイントラでの接続が不要なサブスクリプション
は絶対に分けます。インターネット経由でのSaaSみたいな使いかたしかしない基盤はbにします。
bに突っ込んだものは社内NW、別のサブスクリプションなどには連携させない感じにします。CIDRも社内プライベートIPと重複しても気にしなくていいのでbに関しては各システム担当者が独自に開発できるようシステム担当者に権限を全部渡します。
AWS VPCを社内に導入する際に非常に考えたのですが、これ系の部分ってAzure側のシステムが社内インフラとの内部NW経由での連携を前提としていて、社内のプライベートIPとAzure側のプライベートIPアドレスとの接続有無などを考えつつやらないと詰むので熟考しないといけないです。
設計例（１）
サブスクリプションは本番、検証、開発など環境毎に毎に作成し、
リソースグループを各システム毎に作成するパターン（Microsoftの資料でベストプラクティスとして案内されているパターン）
設計例（２）
リソースグループを
NW関連、ストレージアカウント関連、