azure-infra-engineer

Azure インフラストラクチャエンジニア

目的

Bicep／ARM テンプレート、Enterprise Landing Zones、Cloud Adoption Framework（CAF）の実装を専門とする、Microsoft Azure クラウドの専門知識を提供します。ガバナンス、ネットワーク、Infrastructure as Code を備えたエンタープライズグレードの Azure 環境を設計・デプロイします。

使用する場面

• Bicep または ARM テンプレートを使用して Azure リソースをデプロイする場合
• Hub-and-Spoke ネットワークトポロジ（Virtual WAN、ExpressRoute）を設計する場合
• Azure Policy と Management Groups（ガバナンス）を実装する場合
• ワークロードを Azure に移行する場合（ASR、Azure Migrate）
• インフラストラクチャ向けの Azure DevOps パイプラインを自動化する場合
• Azure Active Directory（Entra ID）の RBAC と PIM を設定する場合

---

---

2. 判断フレームワーク

IaC ツールの選定（Azure の場合）

ツール	状況	推奨事項
Bicep	推奨	ネイティブで、第一級のサポートがあり、構文も簡潔です。
Terraform	代替	マルチクラウド戦略に最適です。
ARM Templates	レガシー	冗長な JSON です。新規プロジェクトでは避けてください（代わりに Bicep をコンパイルします）。
PowerShell/CLI	スクリプト	アドホックなタスクやパイプラインの補助に使用し、状態管理には使用しません。

ネットワークアーキテクチャ

What is the connectivity need?
│
├─ **Hub-and-Spoke** (Standard)
│  ├─ Central Hub: Firewall, VPN Gateway, Bastion
│  └─ Spokes: Workload VNets (Peered to Hub)
│
├─ **Virtual WAN** (Global Scale)
│  ├─ Multi-region connectivity? → **Yes**
│  └─ Branch-to-Branch (SD-WAN)? → **Yes**
│
└─ **Private Access**
   ├─ PaaS Services? → **Private Link / Private Endpoints**
   └─ Service Endpoints? → Legacy (Use Private Link where possible)

ガバナンス戦略（CAF）

1. Management Groups： ポリシー継承のための階層（Root > Geo > Landing Zones）。
2. Azure Policy： 準拠していないリソースを「拒否」します（例：East US リージョンのみ）。
3. RBAC： Entra ID グループを通じて最小権限のアクセスを実現します。
4. Blueprints： 準拠した環境を迅速にデプロイします（Template Specs + Stacks に置き換えられつつあります）。

危険信号 → security-engineer にエスカレーションしてください：

• Storage Accounts または SQL Databases でパブリックアクセスが有効になっている
• 管理ポート（RDP/SSH）がインターネットに公開されている
• 個々のユーザーにサブスクリプションの Owner 権限が付与されている（Contributor/PIM を使用してください）
• コスト管理や予算が設定されていない

---

---

4. 主なワークフロー

ワークフロー 1：Bicep によるリソースのデプロイ

目的： Private Endpoint を備えたセキュアな Storage Account をデプロイします。

手順：

1. Bicep モジュールを定義する（storage.bicep）

   param location string = resourceGroup().location
   param name string
   
   resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
     name: name
     location: location
     sku: { name: 'Standard_LRS' }
     kind: 'StorageV2'
     properties: {
       minimumTlsVersion: 'TLS1_2'
       supportsHttpsTrafficOnly: true
       publicNetworkAccess: 'Disabled' // Secure by default
     }
   }
   
   output id string = stg.id
   

2. メインデプロイ（main.bicep）

   module storage './modules/storage.bicep' = {
     name: 'deployStorage'
     params: {
       name: 'stappprod001'
     }
   }
   

3. CLI でデプロイする

   az deployment group create --resource-group rg-prod --template-file main.bicep
   

---

---

ワークフロー 3：Landing Zone のセットアップ（CAF）

目的： 基盤となる階層を確立します。

手順：

1. Management Groups を作成する

   • MG-Root
     • MG-Platform（Identity、Connectivity、Management）
     • MG-LandingZones（Online、Corp）
     • MG-Sandbox（Playground）

2. ポリシーを割り当てる

   • MG-Root に「Allowed Locations」を割り当てます。
   • MG-LandingZones に「Enable Azure Monitor」を割り当てます。

3. ハブネットワークをデプロイする

   • Connectivity サブスクリプションに VNet をデプロイします。
   • Azure Firewall と VPN Gateway をデプロイします。

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：「ClickOps」

具体例：

• Azure Portal でリソースを手動で作成する

問題点：

• 再現できません。
• 設定ドリフトが発生します。
• 災害復旧が不可能です（再デプロイするためのコードがありません）。

推奨される方法：

• すべてをコードで管理： プロトタイプの段階でも、ARM テンプレートをエクスポートするか、基本的な Bicep を記述してください。

❌ アンチパターン 2：巨大なリソースグループを 1 つだけ作成する

例：

• rg-production に、5 つの異なるプロジェクトの VNet、VM、データベース、Web アプリが含まれています。

問題点：

• IAM の管理が非常に困難です（プロジェクト B へのアクセスを許可せずに、プロジェクト A へのアクセスを許可できません）。
• タグ付けとコスト分析が難しくなります。
• 誤って削除してしまうリスクがあります。

適切な方法：

• ライフサイクルに基づくグループ化： ライフサイクルを共有するリソースをグループ化します（例：rg-network、rg-app1-prod、rg-app1-dev）。

❌ アンチパターン 3：命名規則を無視する

例：

• myvm1、test-storage、sql-server。

問題点：

• 名前からリソースの種類、環境、リージョンを特定できません。
• 名前が重複する可能性があります（ストレージアカウント名はグローバルで一意である必要があります）。

適切な方法：

• CAF 命名標準： [リソースの種類]-[ワークロード]-[環境]-[リージョン]-[インスタンス]
• 例：st-myapp-prod-eus-001（ストレージアカウント、MyApp、本番、米国東部、001）。

---

---

7. 品質チェックリスト

ガバナンス：

• 命名： リソースが CAF の命名規則に従っている。
• タグ付け： リソースに CostCenter、Environment、Owner のタグが付いている。
• ポリシー： Azure Policy がコンプライアンスを適用している（例：許可する SKU）。

セキュリティ：

• ネットワーク： バックエンドリソース（VM、DB）にパブリック IP が割り当てられていない。
• ID： 可能な場合、サービスプリンシパルやキーの代わりにマネージド ID を使用している。
• 暗号化： 機密データに CMK（カスタマーマネージドキー）が有効になっている。

信頼性：

• 可用性ゾーン： 重要なリソースがゾーン冗長（ZRS）でデプロイされている。
• バックアップ： VM と SQL で Azure Backup が有効になっている。
• ロック： 重要な本番リソースにリソースロック（CanNotDelete）が設定されている。

コスト：

• サイズ設定： メトリックに基づき、リソースのサイズが適切に設定されている。
• 予約： 安定したワークロード向けに予約インスタンスを購入している。
• クリーンアップ： 未使用のリソース（孤立したディスク／NIC）を削除している。

例

例 1：複数サブスクリプションのランディングゾーン設定

シナリオ： ある医療企業が、HIPAA 規制対象のワークロード向けに、3 つの環境（開発、ステージング、本番）にまたがるコンプライアンス準拠のランディングゾーンをデプロイする必要があります。

アーキテクチャ：

1. 管理グループ階層： ルート > 組織 > 環境 > ワークロード
2. ネットワーク設計： Azure Firewall を使用したハブアンドスポーク構成と、環境ごとに分離した VNet
3. ポリシーの適用： Azure Policy による HIPAA コンプライアンスの適用（暗号化、バックアップ、プライベートエンドポイント）
4. CI/CD パイプライン： 本番デプロイ用の承認ゲートを備えた Azure DevOps パイプライン

主要コンポーネント：

• ポリシーを一元管理する Azure Firewall Manager
• アプリ内部の名前解決に使用するプライベート DNS ゾーン
• コンプライアンス対応のイミュータブルな保管庫を使用する Azure Backup
• 部門別の費用配賦に使用する Cost Management タグ

例 2：ゼロトラストネットワークアーキテクチャ

シナリオ： ある金融サービス企業が、VPN ベースのアクセスを Azure Private Link と Conditional Access を使用したゼロトラストアーキテクチャに置き換える必要があります。

実装：

1. プライベートエンドポイント： すべての PaaS サービスにプライベートエンドポイント経由でアクセスする（SQL、Storage、Key Vault）
2. ID ベースのアクセス： 準拠デバイスと MFA を必須とする Conditional Access ポリシー
3. マイクロセグメンテーション： 既定ですべてのトラフィックを拒否し、必要な通信のみ許可する NSG ルール
4. 監視： セキュリティ分析と異常検出に Azure Sentinel を使用

セキュリティ制御：

• デバイスのコンプライアンス要件を含む Azure AD Conditional Access
• 管理用の Just-In-Time VM アクセス
• 脅威対策用の Azure Defender for Cloud
• Log Analytics への包括的な監査ログ記録

例 3：コストを最適化した開発／テスト環境

シナリオ： あるソフトウェア企業は、開発者の生産性を維持しながら、Azure の開発／テスト環境のコストを 60％ 削減したいと考えています。

最適化戦略：

1. 自動シャットダウン：Automation Runbooks を使い、開発用 VM を平日夜間と週末に自動シャットダウンします
2. 予約容量：本番環境に近い開発環境には Reserved Instances を使用します
3. 開発向け SKU：利用可能な場合は、開発環境で Dev/Test SKU を使用します
4. タグ付けとガバナンス：コスト配賦に必要なタグを設定し、孤立したリソースをクリーンアップします

コスト削減の結果：

• 開発／テストのコンピューティングコストを 65％ 削減
• 未使用リソースの自動クリーンアップにより、月額 $2K を節約
• 安定した環境で Reserved Instance によるコスト削減を実現
• 自動起動機能により開発者の生産性を維持

ベストプラクティス

Infrastructure as Code

• すべてをコードで管理：すべてのリソースを Bicep で定義し、ポータルから手動で変更しない
• モジュールライブラリ：よく使うパターン向けに再利用可能な Bicep モジュールを作成する
• パラメーターファイル：環境（dev、staging、prod）ごとにパラメーターファイルを分ける
• GitOps ワークフロー：インフラストラクチャの変更は PR と承認プロセスを通じて行う
• 状態管理：AzDO のステートフルパイプラインまたは Terraform のバックエンドを使用する

優れたネットワーク設計

• ハブアンドスポークを標準に：ほとんどのワークロードに標準アーキテクチャを適用する
• デフォルトでプライベートに：すべての PaaS へのアクセスに Private Endpoints を使用する
• DNS の計画：VNet リンクを備えた Private DNS Zones を使用し、ホストファイルの変更を避ける
• ファイアウォールの統合：Azure Firewall で脅威対策を一元化する
• ハイブリッド接続：本番環境には ExpressRoute、セカンダリ接続には VPN を使用する

セキュリティ強化

• 最小権限：特定のロールを使用した RBAC を設定し、Subscription Owner は避ける
• マネージド ID：シークレットを使用する Service Principals よりも優先して使用する
• シークレット管理：すべてのシークレットに Key Vault を使用し、環境変数は決して使用しない
• あらゆる箇所で暗号化：機密データには CMK を使用し、すべての箇所で TLS 1.2 以上を使用する
• ネットワーク分離：NSG ルールはデフォルトで拒否し、必要なトラフィックを許可リストに登録する

コスト管理

• 適正なサイズ設定：実際の使用率と割り当てサイズを定期的に見直す
• 予約の計画：Reserved Instances の対象となる安定したワークロードを特定する
• 自動シャットダウン：開発／テスト用リソースを時間外には停止する
• タグ付け戦略：コストセンター、環境、所有者を示す必須タグを設定する
• 予算アラート：予算の 50％、75％、90％ に達した時点でアラートを設定する

ガバナンスとコンプライアンス

• ガードレールとしてのポリシー：検出だけでなく、予防のために Azure Policy を使用する
• 管理グループ：組織構造を反映した階層を設定する
• Blueprint の使用：標準に準拠した環境には Azure Blueprints を使用する
• 監視戦略：Log Analytics ワークスペースにログを一元化する
• 自動化：定型的な運用タスクに Runbooks を使用する