🎬 はじめに
Azure のリソースを作るとき、「とりあえずポータルから作ってみた」という進め方をしていませんか。リソースを作る作業自体は簡単ですが、後から「リージョンを変えたい」「サブネットの設計がまずかった」「権限が整理できない」といった理由で作り直しになるケースは少なくありません。設計を最初に固めておかないと、リソースの数が増えるほど修正コストは膨らみます。
本記事では、Azure リソースの 設計段階で押さえるべきポイント を、リージョン・可用性、リソースグループ、ネットワーク・セキュリティ、コスト、IaC の 5 つの観点から解説します。すでに運用中の環境がある場合も、新規リソースから適用できる内容です。
目次
- 設計の前に：押さえるべき基本姿勢
- ポイント1：リージョンと可用性の設計
- ポイント2：リソースグループと管理境界の設計
- ポイント3：ネットワークとセキュリティの設計
- ポイント4：コストと規模の設計
- ポイント5：IaC で設計をコードに落とし込む
📌 設計の前に：押さえるべき基本姿勢
リソース設計を始める前に、押さえておきたい基本姿勢があります。それは「要件を先に決める」ことです。技術選定や構成は、要件から逆算して決めるのが基本です。
まず要件を整理する
設計の前に、次のような項目を整理しておくと、迷いが減ります。
- 機能要件：そのリソースは何を実現するのか
- 非機能要件：可用性、性能、セキュリティ、コストの水準
- 運用要件：誰がどのように運用・監視するのか
非機能要件は特に重要です。「99.9% の可用性が必要か」で冗長構成の設計は大きく変わります。過剰な要件はコスト増につながり、逆に不足した要件は障害時のリスクになります。
「作り直し」を防ぐ視点
設計が不十分だと、後から次のような「作り直し」が発生します。
- リソース名の変更
- リージョン変更によるデータ移行
- サブネット分割の修正によるネットワークの再構成
- 権限スコープの見直しによる再設定
作り直しは、工数だけでなくサービスの停止リスクも伴います。設計段階で「ここは後から変えにくい」箇所を意識することが大切です。Microsoft が公開している Well-Architected Framework は、可用性・性能・セキュリティ・コスト・運用の 5 つの柱から設計を評価するフレームワークで、設計のチェックリストとして活用できます。
📌 ポイント1：リージョンと可用性の設計
リージョン選定の考え方
Azure は世界の複数リージョンでサービスを提供しています。日本では東日本（japaneast）と西日本（japanwest）が利用できます。リージョン選定の主な基準は以下の通りです。
- ユーザーとの距離：レイテンシーに影響するため、利用者の近くを選ぶ
- 法令・コンプライアンス：データの保存場所に関する規制がある場合
- サービス提供状況：利用したいサービスがそのリージョンで提供されているか
可用性をどう確保するか
可用性要件に応じて、構成の選択肢が変わります。
- 可用性セット：同じデータセンター内で障害ドメインを分散させる
- 可用性ゾーン：異なるデータセンター（ゾーン）に分散させる
- ペアリージョン：遠隔地のリージョン間で冗長化する
要件が「99.9%」なのか「99.99%」なのかで、どの冗長構成を選ぶかが変わります。可用性を高めるとコストも増えるため、要件と予算のバランスを取ることが設計のポイントです。
📌 ポイント2：リソースグループと管理境界の設計
リソースグループの考え方
リソースグループは、リソースの論理的な入れ物です。「同じライフサイクルのリソースをまとめる」 ことが基本です。アプリケーションと一緒に作成・削除するリソース（アプリ、DB、ストレージ）を 1 つのグループにまとめると、まとめてデプロイ・削除でき、管理が楽になります。
分割のパターン
- 環境単位：本番・検証・開発で分ける
- システム単位：システムごとに分ける
- レイヤー単位：ネットワークとアプリケーションで分ける
多くの企業様では「環境 × システム」でリソースグループを分けるパターンが一般的です。また、リソースグループは権限（RBAC）やポリシーの適用単位にもなるため、「誰が管理するか」 という視点も含めて設計します。
管理グループと組み合わせる
複数のサブスクリプションを束ねる管理グループも、同じ考え方で設計します。環境ごとに管理グループを分け、ポリシーや予算を一括適用すると、リソースが増えても管理の負荷が増えにくくなります。
📌 ポイント3：ネットワークとセキュリティの設計
ネットワーク設計の基本
ネットワークは後からの変更が特に難しい領域です。仮想ネットワーク（VNet）とサブネットの分割は、次の点を意識して設計します。
- サブネットの役割ごとに分割する：Web 層、アプリ層、DB 層で分け、通信の制御をしやすくする
- セキュリティグループ（NSG）で通信を制限する：最小限の通信だけを許可する
- ハブスポーク型の検討：複数の VNet がある場合は、共通のハブ VNet に中継させる構成が管理しやすい
セキュリティ設計のポイント
- ID を起点にする：接続情報（パスワードなど）ではなく、マネージド ID や Microsoft Entra ID を使った認証を検討する
- シークレットは一元管理する：接続文字列や証明書は Key Vault に格納し、コードに埋め込まない
- 暗号化のデフォルト設定：Azure の多くのサービスは既定で暗号化されますが、要件に応じて設定を確認する
「設計の段階でセキュリティを組み込む」ことは、後から修正するよりも低コストで、リスクも抑えられます。セキュリティ要件は、Well-Architected Framework のセキュリティの柱を参考に整理すると漏れが少なくなります。
📌 ポイント4：コストと規模の設計
SKU 選定の考え方
リソースのサイズ（SKU）は、性能とコストのバランスを決める重要な設計ポイントです。
- 過剰なスペックを避ける：最初から大きな SKU を選ぶと、使われないままコストが発生し続けます
- 環境ごとにサイズを変える：本番と開発で同じ SKU にする必要はなく、開発は小さいサイズで十分なケースが多いです
- 見直しを前提にする：利用状況を確認し、サイズを調整できる余地を残しておきます
コスト設計の考え方
コストは「後で削る」より「設計時点で抑える」ほうが効率的です。次のような観点を取り入れます。
- 利用が確定している長期リソースは、予約（リザーブドインスタンス）を検討する
- 使わない時間帯があるリソースは、自動停止の仕組みを検討する
- コストの分類（タグ）を最初から付与する
コストの可視化と削減の具体的な進め方は、Azure コストの可視化 完全ガイド で詳しく解説しています。
📌 ポイント5：IaC で設計をコードに落とし込む
設計で決めた内容は、手作業ではなく IaC（Infrastructure as Code） でコード化すると、確実に反映されます。Bicep や Terraform を使うと、リソースの構成がコードとして残り、レビューや監査の対象にできます。
設計とコードを一致させる
- 命名規則やタグは、コードのテンプレートに組み込む
- ネットワークやセキュリティの設定も、コードとして定義する
- Pull Request によるレビューを経てからデプロイする
コード化のメリット
コード化された設計は、「属人化しない」「再現できる」「履歴が残る」という 3 つのメリットがあります。設計の意図をコメントやドキュメントで残しておくと、チームメンバーの引き継ぎもスムーズになります。
play infra でできること
本記事で紹介した 5 つの設計ポイントは、Azure の標準機能や手順として進められます。ただし、設計ルール（命名規則・タグ・ポリシー）が実際に守られているかを継続的に確認するには、リソースの「見える化」と「管理の仕組み化」が欠かせません。play infra は、Azure リソース管理 SaaS として、設計したルールの定着を支える機能を提供しています。
| 本記事のポイント | play infra でできること |
|---|---|
| ポイント1：リージョン・可用性 | リソースの配置状況を一覧で確認、リージョン単位の棚卸し |
| ポイント2：リソースグループ | サブスクリプション・リソースグループ単位のリソース台帳と一覧 |
| ポイント3：ネットワーク・セキュリティ | 権限・テナントの一元管理、監査に使える操作履歴 |
| ポイント4：コスト・規模 | タグ・命名規則の適用状況を一覧で確認、未設定リソースを検知 |
| ポイント5：IaC | Bicep / Terraform の変更を Pull Request でレビュー、ドリフトの監視 |
たとえば、「設計で決めた命名規則が現場で守られていない」という課題には、play infra のタグ・命名規則の確認機能を活用できます。未設定のリソースを一覧で把握し、設計ルールの定着を支えます。
各機能の詳細は機能一覧ページでご確認いただけます。まずは自社の Azure 環境で「設計ルールがどこまで守られているか」を把握するために、無料デモでリソースの可視化をご体験ください。
🥅 まとめ
Azure リソースの設計は、作り始める前の「要件整理」と「後から変えにくい箇所の意識」が鍵です。本記事のポイントは以下の通りです。
- 設計の前に要件を整理する：機能・非機能・運用の要件を先に決め、作り直しを防ぐ
- 後から変えにくい領域を固める：リージョン、ネットワーク、権限スコープは設計段階で慎重に決める
- ルールはコードで定着させる：命名規則・タグ・セキュリティ設定を IaC に組み込み、継続的に守る
まずは、自社の環境で「どの設計ポイントが未整備か」を棚卸しすることから始めてみてください。実際にどこから着手すればよいか迷われている場合は、現状のリソースを可視化して、設計ルールの適用状況を確認することから始めるとよいでしょう。無料デモでは、Azure 環境の可視化やタグ・ポリシーの適用状況の確認をご体験いただけます。