azure-well-architected-review

Azure Well-Architected レビュー

このワークフローでは、ワークロードの IaC ファイルとデプロイ済みインフラストラクチャを対象に、Azure Well-Architected Framework（WAF）の体系的なレビューを実施します。WAF の 5 つすべての柱にわたってリスクを特定し、修正対応を追跡するための GitHub issue を作成します。

前提条件

• Azure CLI（az）が設定され、認証済みであること
• リポジトリに IaC ファイル（Bicep、Terraform、または ARM テンプレート）が存在すること
• GitHub MCP サーバーが設定され、認証済みであること

ワークフローの手順

ステップ 1：Well-Architected Framework のリファレンスを読み込む

最新の Azure WAF のベストプラクティスを取得します。

• https://learn.microsoft.com/en-us/azure/well-architected/
• 使用中の Azure サービスに関するサービスガイド（https://learn.microsoft.com/en-us/azure/well-architected/service-guides/）
• ワークロードの種類（SaaS、ミッションクリティカル、AI など）に関連するワークロード固有のガイダンス

microsoft.docs.mcp MCP サーバーを利用できる場合は、それを使用して最新の柱ごとのチェックリストとサービス固有の推奨事項を照会してください。

ステップ 2：IaC とアーキテクチャを調査する

レビューの対象範囲を確定したうえで、コードと稼働環境の両方を調査します。

1. Azure の対象範囲を確認する：対象となるサブスクリプションやリソースグループをユーザーに確認するか、IaC のパラメーターから推定して確認します。
2. リポジトリで IaC ファイルをスキャンする：
   • Bicep：**/*.bicep、bicepconfig.json
   • Terraform：**/*.tf（azurerm/azapi プロバイダー）
   • ARM テンプレート：**/azuredeploy*.json、**/*.template.json、または $schema に deploymentTemplate を含むファイル
3. 稼働中のリソースを常にインベントリ化する（IaC が存在する場合も同様）：az resource list --resource-group <rg> --output json（またはサブスクリプション全体を対象に実行）に加え、柱ごとのチェックに必要な構成の詳細を取得するため、対象を絞って az <service> show を実行します。
4. IaC と稼働中のインベントリを比較する：差分を記録します。Azure に存在するが IaC にないリソース（ポータルで作成されたリソース）、IaC で定義されているがデプロイされていないリソース、構成の不一致を特定します。差分の調査結果はステップ 3 用に記録します（通常は運用上の卓越性の柱に該当します）。

使用中の主要な Azure サービス（コンピューティング、データ、ネットワーク、セキュリティ、オブザーバビリティ）を特定し、Mermaid のアーキテクチャ図を作成します。

ステップ 3：柱ごとのレビュー

柱 1：信頼性

• ゾーン冗長サービス（VM、VMSS、AKS ノードプール、App Service、SQL、Storage ZRS）で可用性ゾーンが有効になっている
• 本番環境の SKU が必要な SLA を満たしている（重要な経路で Basic/Free レベルを使用していない）
• Azure SQL / Cosmos DB のバックアップとポイントインタイム リストアが、適切な保持期間で構成されている
• RPO 要件に応じて地理的冗長性が構成されている（GRS/RA-GRS ストレージ、SQL フェールオーバー グループ、Cosmos DB の複数リージョン）
• App Service プラン、VMSS、AKS に自動スケール ルールが構成されている（本番環境で単一インスタンスに固定していない）
• Load Balancer / Application Gateway / Front Door のバックエンドに正常性プローブが構成されている
• Service Bus のキューとサブスクリプション、および Event Grid のサブスクリプションで配信不能メッセージが有効になっている
• 一時的な障害への対応として、指数バックオフを伴う再試行ポリシーが実装されている
• 災害復旧計画が定義されている（RTO/RPO が文書化され、フェールオーバーがテスト済み）

柱 2：セキュリティ

• シークレットや接続文字列を使用するサービスプリンシパルではなく、マネージド ID を使用している
• IaC やコードに認証情報、キー、接続文字列をハードコードしていない
• シークレットは RBAC 認可を使用して Azure Key Vault に保存している（アクセス ポリシーは使用しない）
• ストレージ アカウントでパブリックな BLOB アクセスを拒否し、可能な場合は共有キー アクセスを無効にしている
• PaaS データ サービスにプライベート エンドポイント（または最低限、サービス エンドポイントとファイアウォール ルール）を使用している
• NSG で受信トラフィックを必要最小限のポート／CIDR に制限している（* → * の許可ルールはない）
• すべてのエンドポイントで TLS 1.2 以上を適用している（minimumTlsVersion、httpsOnly）
• Azure RBAC が最小権限の原則に従っている（ワークロード ID にサブスクリプション スコープの Owner／Contributor を割り当てていない）
• 関連するリソースの種類で Microsoft Defender for Cloud を有効にしている（az security pricing list）
• 公開 Web エンドポイントに Azure WAF（Application Gateway または Front Door）を構成している
• 診断設定でセキュリティ ログを Log Analytics／Microsoft Sentinel に送信している

柱 3：コスト最適化

• 安定したコンピューティング ワークロード（VM、App Service、SQL）に対して、予約または節約プランを評価している
• ストレージのライフサイクル管理ポリシーで、BLOB をクール層／アーカイブ層に移行している
• 実際の使用状況に基づいて SKU のサイズを適正化している（過剰に大きい VM／App Service プランはない）
• 開発／テスト環境で自動シャットダウン スケジュールを使用し、対象となる場合は Dev/Test 料金を利用している
• Azure Budgets とコスト アラートを構成している（az consumption budget list）
• 未接続のマネージド ディスクと孤立したパブリック IP を特定し、削除している
• 負荷の変動が大きい、または少量のワークロードに従量課金／サーバーレス層を使用している（Functions、Container Apps、SQL serverless）
• Log Analytics の保持期間とデータ上限の設定を調整し、データ取り込み量の超過を防いでいる

柱 4：運用上の優秀性

• すべてのインフラストラクチャを IaC で定義している（手動でのポータル変更はなく、可能な場合は拒否割り当てまたはポリシーを使用）
• すべてのリソースに一貫したタグ付け戦略を適用している（所有者、環境、コスト センター）
• 主要なメトリックとサービスの正常性について Azure Monitor のアラートを定義している
• 自動デプロイ パイプラインを用意している（GitHub Actions／Azure Pipelines を使用し、手動デプロイは行わない）
• Azure Activity Log とリソース診断設定を Log Analytics に送信している
• アプリケーションのワークロードに Application Insights（または同等の OpenTelemetry）を組み込んでいる
• Azure Policy の割り当てで組織の標準（許可されたリージョン、SKU、タグ）を適用している
• ランブックまたは運用ドキュメントを用意している

柱 5：パフォーマンス効率

• 負荷要件に照らして、コンピューティング SKU のサイズが適正であることを検証している
• 効果が見込める場合にキャッシュを実装している（Azure Cache for Redis、CDN／Front Door キャッシュ）
• グローバルな静的コンテンツ配信に Azure Front Door または CDN を使用している
• 固定のインスタンス数ではなく、負荷メトリックに基づいて自動スケールしている
• データベースのパフォーマンス層が適切である（DTU と vCore、エラスティック プール、Cosmos DB RU の自動スケール）
• レイテンシの影響を受けやすいディスク ワークロードに、Premium／ゾーン冗長ストレージを使用している
• データベースおよび HTTP クライアントにコネクション プーリングと非同期パターンを使用している

ステップ 4：リスク分類

各指摘事項を次のように分類します。

• 高リスク：セキュリティ上の脆弱性、単一障害点、バックアップ／復旧手段がない
• 中リスク：信頼性が最適でない、コスト効率が悪い、パフォーマンス上の懸念がある
• 低リスク：ベストプラクティスからの逸脱、軽微な最適化の機会

ステップ 5：ユーザーの確認

🏗️ Azure Well-Architected Review Summary

📊 Review Results:
• IaC Files Analyzed: X
• Azure Services Identified: Y
• Total Findings: Z
  • High Risk: A (immediate action required)
  • Medium Risk: B (should address soon)
  • Low Risk: C (nice to have)

🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]

💡 This will create Z individual GitHub issues + 1 EPIC issue.

❓ Proceed with creating GitHub issues? (y/n)

ゲート：ユーザーが明示的に肯定する回答（例：「y」、「yes」）をした場合に限り、ステップ 6～7 に進みます。否定的、曖昧、または回答がない場合は、GitHub issue を作成せず、書式設定した指摘事項全体を Markdown としてコンソールに出力して終了してください。

ステップ 6：指摘事項ごとの issue を作成する

「well-architected」と柱名（例：「security」、「reliability」）でラベルを付けます。

タイトル：[WAF-<PILLAR>] [Brief Finding] — [Risk Level]

本文：

## 🏗️ Well-Architected Finding: [Brief Title]

**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]

### 📋 Description
[Clear explanation of the finding and why it matters]

### 🔧 Remediation

**IaC Fix** (preferred):
```bicep
// Bicep example
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_ZRS' }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}
```

**Azure CLI fallback**:
```bash
az storage account update --name <name> --resource-group <rg> \
  --min-tls-version TLS1_2 --allow-blob-public-access false --https-only true
```

### 📚 Azure Reference
- [WAF Best Practice Link]
- [Microsoft Learn Documentation Link]

### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] Azure Policy compliance passes (if applicable)
- [ ] Microsoft Defender for Cloud recommendation resolved (if applicable)

**Well-Architected Recommendation**: [WAF checklist item this maps to]

ステップ 7：EPIC トラッキング Issue の作成

"well-architected" と "epic" のラベルを付けます。

タイトル：[EPIC] Azure Well-Architected Review — X findings across 5 pillars

本文：柱ごとの内訳テーブル（柱およびリスクレベルごとの検出事項数）、Mermaid アーキテクチャ図、個別の Issue すべてにリンクした優先順位付きチェックリスト（高 → 中 → 低）、および成功基準を含むエグゼクティブサマリー：

• 高リスクの検出事項をすべて解決する
• 中リスクの検出事項に、承認済みの緩和計画がある
• 既存の Azure Monitor アラートまたは Azure Policy のコンプライアンスに後退がない

エラー処理

• IaC ファイルが見つからない場合：Azure CLI（az resource list）による稼働中リソースの検出にレビューを限定し、この制約を記載します
• Azure のアクセス許可が不十分な場合：レビューに必要な読み取り専用ロール（Reader、Security Reader）を列挙します
• GitHub での作成に失敗した場合：検出事項をすべて、書式付き Markdown としてコンソールに出力します

成功基準

• ✅ IaC と稼働中のインフラストラクチャを対象に、5 つすべての WAF の柱をレビューする
• ✅ すべての検出事項をリスクレベルと柱ごとに分類する
• ✅ 各検出事項に、IaC の例を含む実行可能な修正手順がある
• ✅ チームで追跡するための GitHub Issue が作成されている
• ✅ EPIC のコンテキスト用にアーキテクチャ図が生成されている
• ✅ Microsoft Learn のドキュメントへの参照が含まれている