はじめに

現在、Azure Security Engineer Associate (AZ-500) の取得に向けて勉強中です。今回は学習範囲の中で、特に概念理解が重要かつ誤解しやすいと感じたテナントとサブスクリプションの構造について、自分の理解整理のためにまとめます。
※普段はAWSを使用しているため、AWSの類似機能との比較も記載しています。

1. テナントとサブスクリプションとは

Azureのアイデンティティ基盤とリソース管理の階層構造は、以下の3要素で成り立っています。

Tenant (テナント): AzureやMicrosoft365の契約インスタンス。組織全体を包む最大の枠組み。「ビル（建物）」そのものとイメージすると分かりやすかったです。
Directory (Microsoft Entra ID): ユーザーやグループを管理する「ID台帳（ビルの住民台帳のようなイメージ）」。技術的にはTenantとDirectoryは1対1で対応しており、実体は同じもの（GUIDが同じ）。
Subscription (サブスクリプション): Azureリソース（VMやDBなど）を管理する「論理的なコンテナ」であり、ガバナンスと課金の境界線。
- 1つのテナントには、複数のサブスクリプションを紐付けられる。
- 信頼関係: 1つのサブスクリプションは、ある時点で、たった1つのテナント（Directory）だけを信頼（Trust）する。
- 設計指針: クォータ制限（vCPU数など）がサブスクリプション単位でかかるため、「環境（Prod/Dev）× ワークロード（システム）」単位で分割するのが一般的。
- 階層管理: 複数のサブスクリプションを Management Group で束ねることで、ポリシー（Azure Policy）や権限（RBAC）を一括適用できる（コスト集計も可能）。

2. AWS Organizations との違い（気づき）

AWSの Organizations / Accountに相当する構造だと考えていましたが、以下の点で決定的な違いがあると感じました。

AWSの場合： AWSアカウントは「独立したID境界（AWSアカウント内でID:IAMが、ほぼ独立）」を持つ。IAMユーザーやIAMロールはアカウント内部に実体が存在するため、アカウントを別のOrganizationへ移動しても、内部のIAM設定は基本的に維持される。
Azureの場合：サブスクリプションは「IDを持たないリソースコンテナ」。認証やIDの実態は、Tenant (Entra ID) に依存。そのため、サブスクリプションを別のテナントへ移行することは、認証基盤を丸ごとすげ替える破壊的な変更を意味する。

似ているようで「IDの実体の所在」が異なるため、移行戦略はAWSとAzureでは大きく異なると思います。

3. 実務での運用に関する考察（サブスクリプション移行）

M&Aや組織再編などで「サブスクリプションを別のテナントへ移行（Change Directory）する」場面では、以下の点に気をつける必要がありそうです。

リスクや注意点:
- RBACの完全消失: 旧テナントのユーザーは新テナントに存在しないため、移行時にすべての権限設定（RBAC）が削除される。移行直後は「誰もアクセスできない」状態になるため、新テナントのGlobal Adminによる救済措置（アクセス権限の昇格）が必要。
- Managed Identityの破損: リソースに紐付くManaged Identityが無効化される。再作成するとID（GUID）が変わるため、DBやStorage側での権限再設定が必要になり、システム停止のリスクが高い。
- Key Vaultの不整合: Key VaultはテナントIDを記憶しているため、移行後に手動でテナントIDを更新しないとアクセス不能になる。
- データ暗号化：データ暗号化を解除せずに移行した場合は、Key Valtが利用できないため、起動ができなくなり、データにアクセスできなくなる。
アーキテクト視点:
- 移行機能（Transfer）のリスク: AWSのアカウントのOrganization移行感覚で実行すると、「認証基盤のすげ替え」によりRBAC、Managed Identity、Key Vault等の依存関係が崩壊し、長期のシステム停止を招く恐れがある。
- 推奨戦略:
  - Re-build (IaC): Terraform/Bicep等で新テナントにクリーンな環境を構築し、データのみ移行する。（最も推奨）
  - Re-host (DR活用): IaC化が困難な場合、Azure Site Recovery (ASR) 等のDR機能を使い、新テナントへVM等を複製・移動させる。
  - Transfer (移行機能): 依存関係が極めて少ない、またはPoC環境の場合のみ検討するが、事前の影響調査（Managed Identityの再設定計画など）が必須。

移行においては、IaCの次点はDR機能の利用で、本当に無理な場合はSubscription移行になるかもしれない。ただし、BCP（事業継続：システムを止めない）やセキュリティを考慮すると、可能な限りはIaCを選択すべきだと感じた。

おわりに

今回はAzureの階層構造について整理しました。「ID管理がリソースの外にある」というAzureの設計思想を理解することが、セキュアなアーキテクチャへの第一歩だと感じました。AWSの知識をベースにしつつ、Azureならではの作法（Microsoft流のガバナンスの考え方など）に慣れていきたいと思います。

※本記事は、筆者の学習メモを元に、生成AIの支援を受けて執筆・構成しています。