[Azure] Microsoft Azure Administrator (AZ-104) 勉強ノート

1. AZ-104試験

• 試験時間は合計140分
• 問題数は50問
  • 見直しができる問題が40問
  • 見直しができずに一回のみ回答が許されている問題が5問
  • ケーススタディの問題が5問
• 合格ラインは1000点満点中700点

2. Azureの概要と管理者の基本

2-1. Azureの概要

• Azureの地理的な概念
  • ジオ：Azureのサービスが使える地域の総称
  • リージョン：データセンターが存在する地域
  • リージョンペア：同じジオ内に複数のリージョンが存在するときの構成。リージョン障害への対応に利用する
    • 例）東日本リージョンと西日本リージョンはリージョンペア
• Azureの提供するサービス
  • コンピューティングサービス：VM, App Service, Azure Functions, Kubernetes Serviceなど
  • ストレージサービス：Azure Blob Storage, Azure Files, Azure Disk Storageなど
  • ネットワークサービス：VNet, Azureロードバランサー, アプリケーションゲートウェイ, Azure VPNゲートウェイなど
  • データベース：Azure SQL Database, Azure Cosmos DB (NoSQL), Azure Databaseなど
  • IDおよびアクセス管理：Microsoft Entra ID
  • セキュリティとコンプライアンス：Microsoft Defender for Cloud, Azure Key Vault, Azure Policyなど
  • AIと機械学習：Azure Machine Learning, Azure AI Services, Azure AI Bot Services, Azure OpenAIなど
  • IoT：Azure IoT Suite, Azure IoT Hub, Azure IoT Central, Azure IoT Edge
  • Analyticsとビッグデータ：Azure Synapse Analytics（データウェアハウス）, Azure HDInsight（ビッグデータ用）、Azure Data Lage Storageなど
  • 開発者・運用者ツール：Azure DevOps, Azure Monitor

2-2. Azure Resource Manager (ARM)

• ARMは、Azureリソースのデプロイおよび管理フレームワーク
  • 目的（なぜ必要なのか）：複数のリソースをグループ化し、テンプレートを使った自動デプロイや、統一されたアクセス制御・タグ付けを一元的に行うため。
• JSONまたはYAML形式のテンプレートを使用したIaCによるデプロイができます。
• リソース：Azureによって管理されるエンティティ（仮想マシン、仮想ネットワーク、ストレージアカウントなど）
  • 各リソースは必ずリソースグループに属している必要がある。
• リソースグループ：ライフサイクルとセキュリティに基づいて1つのエンティティとして管理できるように複数のリソースを関連づける論理コンテナ
  • 目的（なぜ必要なのか）：システムやプロジェクトごとに関連するリソースをまとめ、アクセス権限の一括付与や、不要になった際の一括削除（ライフサイクル管理）を容易にするため。
  • リソースグループを削除することで、その中に含まれるすべてのリソースを削除できる
• リソースプロバイダー：Azureリソースを提供するサービス。例えば、仮想マシンリソースを提供するMicrosoft.Computeなどがある
  • クライアントが特定のリソースの管理を要求すると、ARMはそのリソースの種類のリソースプロバイダに接続して要求を完了させる
• ロック：ARMのロック機能を利用すると、Azure内のリソースを誤って削除・変更することを防げる
  • サブスクリプション、リソースグループ、リソースの3種類に対してロックすることができる
  • 上位のスコープでロックを適用すると、そのスコープ内のすべてのリソースも同じロックを継承する
• タグ：タグはリソースに適用できるメタデータラベル
  • サブスクリプション、リソースグループ、リソースの3種類に対して適用できる
  • 上位のスコープでタグを適用しても、そのスコープ内の各リソースはタグを継承しない

2-3. Azure PowerShell

• Azure PowerShellは、Azureを操作するために使用されるCLIツール
  • PowerShellスクリプト言語を利用して、コマンドレットとAPIへのアクセスを提供する
• Azure PowerShellはクロスプラットフォーム（Windows, macOS, Linux）で利用できる
• サブスクリプションへの接続方法
  1. アカウントへの接続

      Connect-AzAccount
     

  2. Webブラウザが起動するので任意のアカウントでログインする
  3. 意図したサブスクリプションであることを確認する

      Get-AzContext
     

  4. サブスクリプションを指定するとき

      Set-AzContext-Subscription '00000000-0000-0000-0000-000000000000'
     

• リソースグループの作成方法
  1. サブスクリプション上のすべてのリソースグループの一覧を表示する

      Get-AzResourceGroup
     

  2. 新しいリソースグループの作成

      New-AzResourceGroup -Name RG-new -Location "Japan East"
     

• 仮想マシンの作成方法
  1. 仮想マシンを作成する

      New-AzVm `
          -ResourceGroupName 'RG-new' `
          -Name 'newVM' `
          -Location 'eastus' `
          -Image UbuntuLTS
     

  2. 仮想マシンの状態を取得する

      Get-AzVM-Status
     

2-4. Azure CLI

• Azure CLIは、Azureのリソースとサービスを管理するためにマイクロソフトが提供するクロスプラットフォームのCLIツール
• Azure PowerShellと同様にクロスプラットフォームで利用できます。どちらも同様の機能を持ちますが、以下の使い分けが想定されます。
  • Windows環境ではAzure PowerShellを利用する。
  • LinuxやmacOS環境ではAzure CLIを利用する。
• サブスクリプションへの接続方法
  1. アカウントへの接続

      az login
     

  2. Webブラウザが起動するので任意のアカウントでログインする
  3. 意図したサブスクリプションであることを確認する

      az account show
     

  4. サブスクリプションを指定するとき

      az account set --subscription '00000000-0000-0000-0000-000000000000'
     

• リソースグループの作成方法
  1. サブスクリプション上のすべてのリソースグループの一覧を表示する

      az group list
     

  2. 新しいリソースグループの作成

      az group create --name RG-AppService --location japaneast
     

• 仮想マシンの作成方法
  1. 仮想マシンを作成する

      az vm create --resource-group <RG_NAME> --name <VM_NAME> --location japaneast --image UbuntuLTS
     

  2. 仮想マシンの状態を取得する

      az vm list
     

• App Service Planの作成
  1. App Service Planを作成する

      az appservice plan create --name newAppPlan \
          --resource-group RG-AppService --location japaneast --sku free
     

  2. App Service Planの状態を確認する

      az appservice plan list
     

• Webアプリケーションの作成
  1. Webアプリケーションを作成する

      az webapp create \
          --name new-webapp1 \
          --resource-group RG-AppService \
          --plan newAppPlan
     

  2. Webアプリケーションの状態を確認する

      az webapp list
     

2-5. ARMテンプレート

• ARMテンプレートは、宣言型の方法でAzureリソースを定義およびデプロイするために使用されるJSONファイル
  • 目的（なぜ必要なのか）：インフラの構成をコード（IaC）として管理し、人的ミスを排除しつつ、一貫性のある環境を何度でも自動的かつ反復可能にデプロイするため。
• ARMテンプレートの構成要素：
  • $schema 文字列（必須）：テンプレートが準拠するARMテンプレートスキーマファイルのURLを定義する
  • contentVersion 文字列（必須）：テンプレートのバージョンを定義し、バージョン管理などができるようにする
  • parameters 辞書型（任意）：デプロイ中の入力パラメータを定義する
  • variables 辞書型（任意）：テンプレート内で再利用可能な式や値を変数化する
  • resources 配列（必須）：デプロイするAzureリソースを定義する
  • outputs 辞書型（任意）：デプロイ完了後に返される値を指定する
• ARMテンプレートの例：

    {
        "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
        "contentVersion": "1.0.0.0",
        "parameters": {
            "location": {
                "type": "string",
                "defaultValue": "[resourceGroup().location]"
            }
        },
        "variables": {
            "stringVar": "myVariable",
            "concatToVar": "[concat(variables('stringVar'), '-addtovar') ]",
            "concatToParam": "[concat(variables('stringVar'), '-addtoparam')]"
        },
        "resources": {
            "mystore": {
                "type": "Microsoft.Storage/storageAccounts",
                "apiVersion": "2023-04-01",
                "name": "mystorageaccount",
                "location": "[parameters('location')]",
                "sku": {
                    "name": "Standard_LRS"
                },
                "kind": "StorageV2",
                "tags": {
                    "Name": "[variables('concatToParam')]"
                },
            }
        }
    }
  

  • パラメータ (parameters) の設定値を利用するときは [parameters('変数名')]
  • 変数 (variables) の設定値を利用するときは [variables('変数名')]
• ARMテンプレートのドキュメントは以下を参照：
  • https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/templates/
• デプロイ方法：
  • Azure Portal : 「カスタムテンプレートのデプロイ」の「ファイルの読み込み」でARMテンプレートのJSONファイルをアップロードする。
  • Azure PowerShell :

      New-AzResourceGroupDeployment `
          -Name <デプロイメント名> `
          -ResourceGroupName <リソースグループ名> `
          -TemplateFile <ARMテンプレートのファイル名>
    

  • Azure CLI :

      az deployment group create `
          --name <デプロイメント名> `
          --resource-group <リソースグループ名> `
          --template-file <ARMテンプレートのファイル名>
    

• デプロイ結果は「リソースグループ」メニューの「デプロイ」から確認できる。
• デプロイ時に使用されたARMテンプレートは「リソースグループ」メニューの「デプロイ」の中の「テンプレート」から確認できる。
• デプロイモード：
  • 完全モード（Complete）：リソースグループに存在するが、テンプレートに存在しないリソースは削除します（冪等性）。
  • 増分モード（Increment, 規定値）：リソースグループに存在するが、テンプレートに存在しないリソースは変更せずにそのまま残す。

2-6. Bicep

• Bicep（バイセップ）は、Azureリソースのデプロイに使用される高レベルの宣言型構文
• Bicepをトランスパイル（変換）するとARMテンプレートになる
• Bicepテンプレートの構成要素：

    metadata <キー> = <値>
  
    targetScope = '<Bicepテンプレートのスコープ>'
      
    @<decorator>(<値>)
    param <パラメータ名><パラメータデータ型> = <値>
  
    var <変数名> = <変数値>
  
    resource <リソースシンボル名> '<リソースタイプ>@<APIバージョン>' = {
        <リソースプロパティ>
    }
  
    output <アウトプット名><アウトプットデータ型> = <アウトプット値>
  

• Bicepテンプレートを使ったリソースのデプロイ

    New-AzResourceGroupDeployment `
        -Name StorageDeploy-1 `
        -ResourceGroupName RG-new `
        -TemplateFile StorageAccountDeploy.bicep
  

2-7. Azure Cloud Shell

• Azure Cloud Shellは、Azureによって提供されるWebベースの対話型CLI
• BashまたはPowerShellが利用可能
• 使用するには事前にリソースグループとストレージアカウント（ファイルを保持するため）の準備が必要

3. Microsoft Entra IDとガバナンス

3-1. ゼロトラスト

• ゼロトラストの考え方：
  • 明示的に確認する：アクセス元のIDや端末を無条件に信頼せず、利用可能な情報を元に検証する
  • 必要最小限のアクセス権を利用する：リソースを利用するときは必要最小限の権限を必要な時間のみ付与する
  • 侵害を想定する：攻撃者に侵入されることを想定し、データの暗号化やアクセス可能な範囲の細分化（セグメント化）をする
• Microsoft Entra IDを利用してゼロトラストを構築する。

3-2. Microsoft Entra ID

• Microsoft Entra IDは、マイクロソフトが提供するクラウドベースのID管理サービス（IDaaS）
  • 目的（なぜ必要なのか）：組織のユーザー、グループ、デバイスの認証・認可を一元管理し、各種クラウドアプリ（M365やAzureなど）への安全なアクセス基盤（SSO、多要素認証など）を提供するため。
• Microsoft Entra IDの特徴：
  • ユーザの管理：
    • アカウント：Microsoft Entra IDのユーザID
  • IDの認証とシングルサインオン (SSO)
  • グループの管理：
    • 動的グループ機能：設定したルールに応じて自動的にユーザ追加などのメンバーシップの変更が行われる機能
  • ロールベースのアクセス制御 (RBAC)
  • デバイスの登録（組織の管理下に置くことができる）
  • 多要素認証 (MFA)
  • アクティビティログの取得と監査
  • クラウドアプリケーションの管理：他アプリケーションとの認証の連携ができる
  • セルフサービス：ユーザーが自分自身でパスワードのリセットやグループの管理を行う機能が提供されている
• 条件付きアクセスポリシー：アクセス元の情報（端末情報やIPなど）から条件に従ってアクセス制御をしたり、追加の認証（MFAなど）を要求したりするための仕組み
  • 目的（なぜ必要なのか）：アクセス元の場所やデバイスの状態を評価し、リスクが高いと判断された場合のみ多要素認証（MFA）を要求するなど、利便性とセキュリティ（ゼロトラスト）を両立するため。

表：Microsoft Entra ID と Active Directory の主な違い

• Microsoft Entra IDのエディション：
  • Freeエディション : 無料で提供される。必要最小限の機能
  • P1 (Plan 1) : 動的グループや条件付きアクセス、セルフサービスパスワードリセットが使えるようになる
  • P2 (Plan 2) : P1に加えて、特権保護機能、IDガバナンス機能、検出されたIDリスクの自動修復機能が提供される
• セキュリティ規定値群（Security Defualts）：Microsoft Entra ID P1, P2 ライセンスを持たない組織でも、必要なID保護機能が自動的に有効化される。
  • 環境構築初期におけるセキュリティ向上のために使用するケースが一般的
• ライセンス：マイクロソフトもしくはCSP（クラウドソリューションプロバイダー）を経由して購入する。Microsoft 365 E3ライセンスなど
  • Microsoft Entra ID > ユーザ > ライセンスの割り当て から設定可能
• Microsoft Entraロール：Microsoft Entra IDリソースを管理するために使用するアクセス権のセット
  • ※Azureリソースを管理するロールとは別のため注意！
  • 主なMicrosoft Entraビルドインロール：
    • グローバル管理者：最も強力な管理者ロール。他のユーザに管理者ロールを割り当てることが可能
    • 特権ロール管理者：Microsoft Entra IDでのロールの割り当てと、Privileged Identity Management (PIM) 構成を管理できる。他のユーザに管理者ロールを割り当てることが可能
    • ユーザー管理者：管理者以外のユーザとグループを管理できる
    • ヘルプデスク管理者：管理者以外のユーザのパスワードをリセットできる
    • アプリケーション管理者：テナント内のアプリケーション登録とエンタープライズアプリケーションを作成・管理・削除できる
    • ライセンス管理者：ユーザおよびグループの製品ライセンスを管理できる
• Microsoft Entra PIM (Privileged Identity Management) は、Microsoft Entra IDの特権ロールを持つアカウントとAzureリソースの管理権限を持つユーザーを管理・監視するためのガバナンス機能
  • Microsoft Entraの組織においてロールの割り当て時やロールがアクティブ化された場合などのイベント発生時にメールなどの通知を受けることができる
  • 管理者による承認フローもしくは自己でのアクティブ化によって特権を付与できる
  • アクセスレビュー：Microsoft Entra ID P2で利用できるガバナンス機能。定期的にアクセス権の要否をレビューし、不要な場合はアクセス権を削除できる
• Microsoft Entra IDのアプリケーション向けID：
  • サービスプリンシパル（アプリケーションID）：アプリやサービスが使用するID
  • マネージドID（Managed ID）：Azureリソースで利用可能なアプリケーションID
    • 目的（なぜ必要なのか）：Azureリソース（VMなど）から他のリソース（Key VaultやStorageなど）へアクセスする際に、ソースコード内にパスワード等のシークレットをハードコードせずに安全に認証を行うため。
    • システム割り当て（System Managed ID）：VM仮想マシンなどのリソースに自動的に割り当てられるID
    • ユーザー割り当て（User Managed ID）：ユーザがIDを作成してリソースに割り当てるとき
• 管理単位 (AU; Administrative Unit) ：
  • Microsoft Entra IDには組織単位（OU）が存在せず、ユーザーはフラットな空間で管理される
  • 管理単位は、Microsoft Entra IDのユーザやグループのまとまり
  • 管理単位を構成してユーザの管理スコープを設けることで、スコープ内のユーザー管理を他の管理者へ委任でる
• セルフサービスパスワードリセット（SSPR）：ユーザ自身でMicrosoft Entra IDユーザアカウントのパスワードをリセットできる機能
  • 目的（なぜ必要なのか）：パスワード忘れ時の対応をユーザー自身で行えるようにし、ヘルプデスクの負担軽減とユーザーのダウンタイム削減を実現するため。
  • 管理者向けポリシー：一般ユーザーの設定に関わらず、管理者は既定でSSPRが有効化されており、かつ強力な2ゲートの管理者パスワードリセットポリシー（2つの認証方法を要求）が強制的に適用される。セキュリティ質問などは利用できない。
• Microsoft Entra IDP (Identity Protection)：ユーザーリスクやサインインリスクの検出と自動修正をする機能
• Microsoft Entra IDのグループの種類：
  • セキュリティグループ：アプリケーションの割り当てやアクセス権を付与・管理するために利用するグループ。ユーザ、デバイス、サービスプリンシパル、他のグループを追加できる
  • Microsoft 365グループ：Microsoft 365コラボレーション機能のために利用するグループ。ユーザのみ追加できる
  • 動的ユーザーグループ：グループメンバーシップルールを作成することで、ルールに合致したユーザを自動的にグループメンバーに追加・削除できるグループ
  • 動的デバイスグループ：自動的にデバイスを追加するためのグループ。主にMicrosoft Intuneでのデバイス管理に利用される
• Microsoft Entra IDへのデバイス参加と登録の違い：
  • Microsoft Entra登録：個人所有のデバイスを、Microsot Entra IDの管理下に置くこと
  • Microsoft Entra参加：組織（企業）所有のデバイスを、Microsot Entra IDの管理下に置くこと
• Microsoft Entra Connect：オンプレミスのActive DirectoryからMicrosoft Entra IDへアカウントを同期し、一元管理するための機能
  • 目的（なぜ必要なのか）：ユーザーが同じパスワードでクラウド（Entra ID）とオンプレミスの両方のリソースへシームレスにアクセスできるようにするため（ハイブリッドIDの実現）。
  • ハイブリッドID：オンプレとMicrosoft Entra IDの両方で単一のユーザアカウントを利用できる構成
  • Microsoft Entraパススルー認証：ユーザーはオンプレミス環境などのパスワードを使用して、オンプレミスのアプリケーションとクラウドベースのアプリケーションの両方にサインインできる
• Microsoft Entraクラウド同期（Cloud Sync）：Microsoft Entra Connectより動作が軽量だが、利用できる機能は限定的
• ユーザーアカウントの種類：
  • クラウドID：Microsoft Entra IDのアカウント。Azure PortalやPowerShellコマンドで作成する
  • 同期ID：オンプレのActive Directoryから同期されたアカウント。Microsoft Entra ConnectもしくはMicrosoft Entraクラウド同期で作成される。
  • 外部ユーザー（ゲストユーザ）外部のIDソースのアカウント。Azure PortalやMicrosoft Teamsなどから組織のユーザが外部ユーザーを招待する。
    • Microsoft Entra External ID（外部ID）：他のテナントのユーザを招待する機能
    • Microsoft Entra B2Bコラボレーション：同上
    • 「ユーザ設定」ブレードの「外部コラボレーションの設定」の「ゲスト招待設定」を変更することで、誰がゲストを組織に招待できるかを変更できる
    • 「ユーザーの一括招待」機能は、リダイレクトURLと電子メールアドレスを含むCSVをアップロードして一括招待ができる
    • New-AzureADMSInvitation コマンドで上記CSVファイルを指定して一括招待する方法もある
• Microsoft Entra DS (Domain Services)：Azure上でオンプレのActive Directoryの機能を提供できるマネージドサービス
  • Microsoft Entra Connect経由でオンプレミスActive Directoryとユーザアカウントを統合できる
• パスワードライトバック：オンプレのActive DirectoryとハイブリッドIDを構成しているとき、Microsoft Entra ID上で変更もしくはリセットしたパスワードをオンプレのActive Directoryにも反映できる機能。追加の設定で有効化できる

3-3. サブスクリプションの構成

• サブスクリプションは、Azureリソースの管理および課金の単位となる論理ユニット
• サブスクリプションを管理できる主なロール：
  • エンタープライズ管理者：Azure上の管理者ではなく、EA契約のみで使用するEAポータルという独立した管理ポータルで使用するロール。組織の支出やEAポータル内の管理ができる
  • アカウント所有者：EAポータルで使用するロール。Azureサブスクリプションの作成と管理ができる
  • 所有者（Owner）：Azure Portal上のロール。サブスクリプションの所有者で、サブスクリプション配下の全Azureリソースに対するフルアクセス権限を持つ
  • 共同作成者（Contributor）：サブスクリプションの所有者によって追加された管理者。リソースに対するアクセス権を除く全ての管理者権限を持つ
  • Microsoft Entra全体管理者（グローバル管理者）：Microsoft Entra IDのロールで、最も強力な管理者ロール
  • ユーザーアクセス管理者ロール：Azureロールの割り当て権限を持つ
• 管理グループ：複数のサブスクリプションをまとめて管理するための機能
  • Microsoft Entraテナント直下にはルート管理グループが規定で存在する

3-4. ロールベースのアクセス制御

• Azure RBACの3要素：
  • 目的（なぜ必要なのか）：「誰が」「どのリソースに対して」「何を行えるか」を最小特権の原則に基づいて細かく制御し、セキュリティを保つため。
  • ロール：Azureリソースに対して実行できる操作。組み込みロールの他に独自のカスタムロールを作成できる。
  • スコープ：アクセス権を適用するAzureリソースのセット
  • セキュリティプリンシパル：アクセス権を割り当て可能なオブジェクト（ユーザ、グループ、サービスプリンシパル、マネージドID）のこと
• カスタムロール：組み込みロールを利用せずに、アクセス許可を独自に構成したロール
  • Azure Portal上で権限を選択するか、Azure PowerShellやAzure CLIを使ってJSON形式で定義する。
• JSON形式での要素：
  • Name : カスタムロールの表示名
  • IsCustom : カスタムロールかどうかを表す
  • Description : カスタムロールの説明
  • Actions : このカスタムロールで許可されるアクションを指定する。形式は以下の通り
    • {Company}.{ProviderName}/{リソースタイプ}/{アクション}
  • NotActions : このカスタムロールで許可しないアクションを指定する。NotActionの方が優先される
  • DataActions : データの操作・変更に関する権限を設定する（一部のロールでのみ使用）
  • AssignableScopes : このロールを割り当て可能なスコープを指定する
• カスタムロールの例：

    {
        "Name": "Virtual Machine Operator",
        "Id": "88888888-8888-8888-8888-888888888888",
        "IsCustom": true,
        "Description": "Can monitor and restart virtual machines.",
        "Actions": [
            "Microsoft.Storage/*/read",
            "Microsoft.Network/*/read",
            "Microsoft.Compute/*/read",
            "Microsoft.Compute/virtualMachines/start/action",
            "Microsoft.Compute/virtualMachines/restart/action",
            "Microsoft.Authorization/*/read",
            "Microsoft.ResourceHealth/availabilityStatuses/read",
            "Microsoft.Resources/subscriptions/resourceGroups/read",
            "Microsoft.Insights/alertRules/*",
            "Microsoft.Insights/diagnosticSettings/*",
            "Microsoft.Support/*"
        ],
        "NotActions": [],
        "DataActions": [],
        "NotDataActions": [],
        "AssignableScopes": [
            "/subscriptions/{subscriptionId1}",
            "/subscriptions/{subscriptionId2}",
            "/providers/Microsoft.Management/managementGroups/{groupId1}"
        ]
    }
  

• タグ：Azureリソースに付与できるメタデータ。リソース管理のために任意で使用できる
  • 親リソースのタグは子リソースに継承されない
  • 必要に応じて、Azure Policyで新規リソース作成時にタグ付けを強制することができる
• リソースのロック：リソースやリソースグループやサブスクリプションをロックすることで誤って削除・変更されることを防ぐ
  • 目的（なぜ必要なのか）：本番環境などの重要なリソースを、人為的なミス（誤削除や予期せぬ変更）から物理的に保護するため。
  • ロックの種類：
    • CanNotDelete : リソースの削除を禁止する
    • ReadOnly : リソースの変更を禁止する

3-5. Azure Policy

• Azure Policyは、Azureガバナンス機能の1つで、組織が強制させたいセキュリティポリシーや運用ルールをリソースに適用できる
  • 目的（なぜ必要なのか）：リソースの作成・更新時に企業のルールやコンプライアンス要件（特定のリージョンへの作成制限、特定VMサイズの禁止など）を満たしているかを強制・評価するため。
• ポリシー (Policy)：Azureにはビルドインのポリシー定義が数多く存在する。また、ユーザー独自のポリシーを定義することもできる
• イニシアチブ (Initiative)：複数の関連するポリシー定義をまとめてグループ化したもの
• ポリシー定義またはイニシアチブ定義の割り当て先は、管理グループ、サブスクリプション、リソースグループのいずれかを指定できる
• Azure Blueprintsは、以下の構成をまとめた繰り返し利用可能なテンプレートを作成できる。
  • Azure RBACによるロールの割り当て
  • Azure Policyの割り当て
  • ARMテンプレート
  • リソースグループ
  • ※頻繁にサブスクリプションの作成を行うときに組織の要件を遵守したセットアップを組み込むことができ、効率よく繰り返し適用できる。
• Azure Policyを割り当てると、全ての子リソースへも継承される。
  • 子リソースのAzure Policyは親リソースのAzure Policyで上書きされる。

4. Azureストレージサービス

4-1. Azure Storage

• Azure Storageは、様々なデータ形式とその利用目的により最適化されたサービスの総称。入出力IFとして以下の種類がある：
  • Azure Blob Storage : テキストやバイナリデータなどを格納するオブジェクトストレージ
    • 目的（なぜ必要なのか）：画像、動画、バックアップファイルなどの大量の非構造化データを、安価かつスケーラブルに保存するため。
  • Azure Files : SMBやNFSでアクセスできる共有フォルダ
    • 目的（なぜ必要なのか）：複数の仮想マシンやオンプレミスから、SMB/NFSプロトコルで同時にマウントして共有できるファイルサーバーをクラウド上に構築するため。
  • Azureキュー : メッセージングキュー
  • Azureテーブル : 構造化データ形式（NoSQL）を保管するための領域
  • Azure Disk Storage : Azure上のVMから利用される仮想ハードディスク（VHD）形式
• 冗長オプション：
  • ローカル冗長ストレージ（LRS）：1つのリージョン内の1つのデータセンター内に3つのコピー
  • ゾーン冗長ストレージ（ZRS）：1つのリージョン内の3つの可用性ゾーン（AZ）にコピー
  • Geo冗長ストレージ（GRS）：プライマリリージョンの1つのデータセンター内に3つ、セカンダリーリージョンの1つのデータセンター内に3つ、合計6つのコピーを作成する
  • 読み取りアクセスGeo冗長ストレージ（RA-GRS）：セカンダリーリージョンへの読み取りができる（通常はプライマリーリージョンへの読み書きのみ）
  • Geoゾーン冗長ストレージ（GZRS）：プライマリリージョンではゾーン冗長ストレージ、セカンダリーリージョンの1つのデータセンター内に3つ、合計6つのコピーを作成する
  • 読み取りアクセスGeoゾーン冗長ストレージ（RA-GZRS）：セカンダリーリージョンへの読み取りができる（通常はプライマリーリージョンへの読み書きのみ）
• 暗号化スコープ：
  • 暗号化スコープを使用することで個々のBLOBまたはコンテナーレベルで暗号化を管理できる
  • 暗号化スコープは異なるユーザーが所有する、同じストレージアカウントに存在するデータの間にセキュリティで保護された境界を作成して、暗号化を管理できる

4-2. Azureストレージアカウント

• ストレージアカウントの種類：
  • Standard汎用v2（BLOB、キュー、テーブル、Azure Files）
  • PremiumブロックBLOB（BLOB）
  • Premiumファイル共有（Azure Files）
    • 速度面の観点からgeo冗長性はサポートされていない
  • PremiumページBLOB（ページBLOBのみ）
• レガシーストレージアカウントの種類
  • Standard汎用v1（BLOB、キュー、テーブル、Azure Files）… 最新の機能が利用できないものもある
  • Blob Storage（BLOB）… 可能であればStandard汎用v2の利用を検討してください
• Azure Storage Accountのネットワークルーティング：
  • ネットワークアクセス：
    • パブリックエンドポイント（インターネットからアクセス可能とするURL）を許可するか、プライベートアクセスのみを許可するか
  • ルーティングの優先順位：
    • Microsoftネットワークルーティング：ポイントオブプレゼンス（POP、エッジルーターのポイント）の中から、クライアントから一番近いものへアクセスさせ、マイクロソフトのネットワーク内を通り各リージョンのストレージアカウントへアクセスされる
    • インターネットルーティング：ストレージアカウントの場所に一番近いPOPを選択し、インターネットを経由して接続するようになる
• Azure Storage Accountのデータ暗号化：
  • 保存時の暗号化 (Encryption at Rest)：
    • Azure Storageに書き込まれるすべてのデータ（Blob、Files、Queue、Table）は、物理ディスクに保存される前に自動的に暗号化（256ビットAES）され、読み取り時に復号される。
    • この暗号化は規定で有効になっており、無効化することはできない。
    • 暗号化のキーとして、以下を選択できる：
      • マイクロソフトサービスにより管理されたマネージドキーによる暗号化（規定）
      • Azure Key VaultやKey Vault HSMに保存されたカスタマーマネージドキーによる暗号化
  • 転送中の暗号化 (Encryption in Transit)：
    • クライアントとAzure Storage間の通信経路上のデータを保護する仕組み。
    • ストレージアカウントの設定で「安全な転送が必須 (Secure transfer required)」を有効にすることで、HTTP接続を拒否し、HTTPS接続（または暗号化がサポートされたSMB 3.0以降など）のみを許可することができる。
• Azure Key Vault：パスワードを保存して適切なアクセスポリシーを設定することでパスワードをプレーンテキストに保存せずに安全に利用できる
  • 目的（なぜ必要なのか）：パスワード、APIキー、証明書などの機密情報（シークレット）をソースコードから切り離して安全な一元管理基盤に保存し、漏洩リスクを防ぐため。
• コンテナー：Azure Blob Storageではデータはコンテナー内に保存される。データをアップロードする前にコンテナーの作成が必要となる。
  • 共有アクセス署名（SAS）：特定のクライアントにSAS（Shared Access Signature）を生成することで、一時的なアクセスを付与できる。
    • アドホックSAS：作成すると開始時刻、有効期限、およびアクセス許可がSAS URIで指定できる
    • 保存されているアクセスポリシーによるサービスSAS：リソース側でアクセスポリシーが定義されており、それに基づいて作成されるサービスSAS
• データ保護：
  • 論理的な削除を有効化するか、不変性ポリシーを有効化することでデータ保護が実現できる
  • 不変性ポリシー：削除と変更ができなくなる。追加と読み込みのみできる
• Microsoft Defender for Storage：
  • Azure Storage アカウントに統合されたクラウドネイティブのセキュリティインテリジェンス機能。
  • 目的（なぜ必要なのか）：ストレージへのマルウェアのアップロード、データ流出、異常なアクセス要求（通常とは異なる場所からのアクセスなど）といった脅威を検出し、アラートを上げるため。
  • コンピューティングリソースに影響を与えずに、Blob内にアップロードされたコンテンツのマルウェアスキャンを自動的に実行することができる。

4-3. Azure Blob Storage

• BLOB（Binary Large Object）：大量のテキストデータ、画像・動画ファイルなどのバイナリファイルなど
  • Blob StorageへのアクセスはHTTPかHTTPS経由で行われる
• BLOB管理のためのリソースの種類：
  • ストレージアカウント
  • ストレージアカウント内のコンテナ（ファイルシステムのディレクトリの役割）
  • BLOB（コンテナ内に保存されたデータ）

ストレージアカウント
└── コンテナー
    └── BLOB

• BLOBの種類：
  • ブロックBLOB：テキストとバイナリデータを格納できる。最大 190TB のデータを格納できる
  • 追加BLOB：追加操作用に最適化されたブロックBLOB。ログ記録などに利用する
  • ページBLOB：ランダムな読み取りと書き込みの操作に適したBLOB。最大 8TB のファイルを格納できる
    • 仮想ハードドライブ（VHD）ファイルを格納し、Azure仮想マシン用のディスクとして機能する
• BLOBのストレージアクセス層：
  • ホットアクセス層
  • クールアクセス層：最低30日間の保存が必要。リハイドレート不要で読み取り可能
  • コールドアクセス層：最低90日間の保存が必要。リハイドレート不要で読み取り可能
  • アーカイブアクセス層：最低180日間の保存が必要。読み取るためにはリハイドレート（別の層へのコピー）が必要
• サービスエンドポイント：
  • VNet内からストレージアカウントにアクセスするときは、プライベートエンドポイントの作成が必要
  • インターネットからストレージアカウントにアクセスするときは、パブリックエンドポイントの作成が必要
• BLOBデータの保護方法：
  • ストレージアカウントのロック
  • コンテナーの論理的な削除を有効にする
  • BLOBのバージョン管理を有効にする（削除されたBLOBの復旧ができるようになる）
  • BLOBの論理的な削除を有効にする
  • コンテナーのポイントインタイムリストアを有効にする（特定の日付の状態にコンテナやBLOBの状態を戻せる）
  • 変更フィードを有効にする（ファイルの変更をきっかけに動作するアプリケーションが作れる）
  • 不変ストレージと不変性ポリシーを定義する（ポリシーで特定の操作を禁止する）
• 冗長性とフェイルオーバーの管理：
  • 冗長オプション（レプリケーション方式）を変更する（ゾーン冗長やGeo冗長など）
  • Geo冗長ストレージの場合、フェイルオーバーすることで、セカンダリーエンドポイントがプライマリーエンドポイントに昇格する。その場合、書き込みもフェイルオーバー先の新しいプライマリーリージョンに行われる
  • Geo冗長では非同期にレプリケーションが行われているため、タイミングによってはデータがロストする可能性がある
• ライフサイクル管理ポリシー：
  • ルールベースのライフサイクル管理ポリシーを作成して、自動的にデータを別のアクセス層に移動したり、データを期限切れにしたりできる。
  • ライフサイクル管理ルールを使用できるストレージアカウントの種類：
    • 汎用v2
    • Premiumブロック BLOBのBlob Storage

4-4. Azure FilesとAzure File Sync

• Azure Filesは、SMBプロトコルやNFSプロトコルを用いて、様々なOSからファイル共有サービスとしてアクセスできるストレージサービス
  • SMB：Windows SMBファイル共有。NTLM v2とKerberosが利用できる
  • NFS：NFSファイル共有。Linux向け
  • Azure Filesのストレージ層：
    • Premium：SSDでホストされる高スペックストレージ
    • トランザクション最適化
    • Hot（ホット）：汎用的なファイル共有ストレージ
    • Cool（クール）：アクセス頻度の低いデータ向けのストレージ（※Blobとは異なりアーカイブ層は存在しない）
  • Azure Filesのデータ保護：
    • ストレージ冗長（Geo冗長性）
    • 共有スナップショット（特定の時点のデータの読み取りコピー）
    • バックアップ（Azure Backupサービスを利用）　
    • 論理的な削除
• Azure File Syncは、オンプレからクラウドに拡張されたWindowsファイルサーバーを構築できる
  • 目的（なぜ必要なのか）：オンプレミスのファイルサーバーの容量不足を解消しつつ、よく使うデータだけをローカルに残し、古いデータをAzure Filesに自動階層化して管理を効率化するため。
  • File Syncの要素：
    • ストレージ同期サービス：同期グループを管理する最上位の管理単位
    • 同期グループ：クラウド側のファイル共有
      • 転送先：1つのクラウドエンドポイント（Azure Filesのファイル共有）を指定できる
      • 転送元：複数のサーバーエンドポイントを含めることができる。ただし、同じサーバ内の複数エンドポイントは含められない。異なるサーバであれば問題なし
    • サーバーエンドポイント：オンプレ側（Windows Server）のファイル共有。Windows Server上にエージョントをインストールし、これをストレージ同期サービスに登録する。
      • サーバー上の物理的なパスを指定する（例：D:\Data）
  • クラウドの階層化：
    • 条件を指定してオンプレに残すファイルを選択できる（キャッシュとしての役割）
    • 日付ポリシー：一定期間アクセスされていないファイルをクラウド上に階層化し、ローカルキャッシュから削除する。
  • 複数のクライド/サーバーエンドポイントが存在するとき、同期グループ内のエンドポイントは相互に同期が維持される

ストレージ同期サービス
└── 同期グループ
    ├── サーバーエンドポイントA
    └── サーバーエンドポイントB

4-5. Azure Storageのアクセス制御

• ストレージアカウントキー（アクセスキー / 共有キー）：
  • ストレージアカウント作成時に自動的に2つのキー（Key1, Key2）が生成される。2つあるのは、アプリケーションを停止させずにキーのローテーション（再生成）を行うため。
  • ストレージアカウントのすべてのデータに対する完全な管理者権限（ルート権限）を持つ非常に強力なキー。
  • セキュリティのベストプラクティス：強力すぎるため日常的なアクセスには推奨されない（非推奨）。代わりにAzure RBAC（Entra ID）やSASを使用することが強く推奨される。
  • ストレージアカウントの設定で「ストレージ アカウント キー アクセスを許可する (Allow storage account key access)」を無効化することで、アクセスキーによる認証を完全に禁止し、Entra ID認証のみを強制することができる。
• ロールベースのアクセス制御 (Azure RBAC) と Microsoft Entra ID：
  • 目的（なぜ必要なのか）：アクセスキー（共有キー）のような強力すぎる権限を渡すことなく、最小特権の原則に基づき、特定のユーザーやマネージドIDに対して「BLOBの読み取りのみ」などの細やかなデータアクセス権限を付与するため。
  • ストレージアカウントの管理（コントロールプレーン）だけでなく、BLOBやキューのデータそのもの（データプレーン）へのアクセス制御に利用される。（※非推奨であるアクセスキー認証の強力な代替手段となる）
  • 代表的なデータアクセス用（データプレーン）組み込みロール：
    • ストレージ BLOB データ所有者：コンテナーと BLOB データへのフルアクセス。
    • ストレージ BLOB データ共同作成者：コンテナーと BLOB データの読み取り、書き込み、削除。
    • ストレージ BLOB データ閲覧者：コンテナーと BLOB データの読み取りと一覧表示。
• 共有アクセス署名（SAS：Shared Access Signature）
  • SASを使うことでストレージアカウント内のリソースに対する保護されたアクセスを委任できる
  • 制限できる内容：
    • クライアントがアクセスできるリソース
    • リソースへのアクセス許可
    • SASが有効な期間
  • SASの種類：
    • ユーザー委任 SAS (User Delegation SAS)
      • 署名に使用するキー：Microsoft Entra ID の資格情報
      • 対象サービス：Blob ストレージのみ
      • 特徴：ストレージアカウントキーを使用せずに作成できるため、最もセキュリティが高く、ベストプラクティスとして推奨される。
    • サービス SAS (Service SAS)
      • 署名に使用するキー：ストレージアカウントキー
      • 対象サービス：Blob, Queue, Table, Files のいずれか1つのサービス
      • 特徴：特定の一つのサービス内にある特定のリソース（特定のBlobやファイルなど）へのアクセスを許可する場合に使用する。
    • アカウント SAS (Account SAS)
      • 署名に使用するキー：ストレージアカウントキー
      • 対象サービス：Blob, Queue, Table, Files の1つ以上（複数サービス）
      • 特徴：複数のサービスにまたがるアクセス許可や、サービスレベルの操作（コンテナーの作成・削除など、サービスSASでは許可できない操作）を委任する場合に使用する。

4-6. Azure Storageとツール

• Azure Storage Explorerは、Windows、macOS、Linux上で動作するスタンドアローンのGUIクライアントツール
• AzCopyは、ストレージアカウント間のBLOBやファイルコピー、データのアップロードなどに利用可能なコマンドラインツール
  • azcopy make：コンテナーやファイル共有を作成する
  • azcopy copy：ファイルやディレクトリをコピーする
  • azcopy sync：ファイルやディレクトリを同期する
• Azure Import/Exportは、データセンターにディスクドライブを物理的に送付し、安全にインポートやエクスポートを行うためのサービス
  • データ種別：
    • Azure BLOB：ImportとExportの両方使用可
    • Azure Files：Importのみ使用可
  • アカウント種別：
    • Azure Storage Standard汎用v2でのみ使用可
  • 使用するときの前準備として以下のファイルの作成が必要：
    • dataset.csv（ターゲットドライブにコピーするディレクトリの一覧またはファイルの一覧）
    • driveset.csv（ツールが準備するディスクの一覧を正しく選択できるように、ディスクとディスクに対応するドライブ文字の一覧）
• BLOBストレージへの認証時にはMicrosoft EntraまたはShared Access Signature (SAS) トークンを使用する

4-7. その他のストレージサービス

• Azureマネージドディスク（Azure Disk Storage）：仮想ハードディスク（VHD）とも表現されます。
  • OSディスク：仮想マシン作成時に接続される
  • データディスク：SCSIドライブ（外付けHDD）として認識される
  • 一時ディスク：仮想マシンが再起動されるときにデータが削除される（デフォルトはWindows ServerのDドライブに割り当てられる）
• Azureキュー
• Azureテーブル

5. コンピューティングサービス

5-1. Azure Virtual Machines

• 目的（なぜ必要なのか）：OSレベルの完全な制御が必要な場合や、既存のオンプレミスサーバーをそのままクラウドに移行（リホスト）するために使用。
• 基本情報：
  • 仮想マシン名：リソース識別子として使用される。初期作成時から変更できない
  • ゲストホスト名：ホスト名。初期作成時から変更できる
• ディスク：
  • Premium SSD、Standard SSD、Standard HDDから選択できる
• ネットワーク：
  • ネットワークセキュリティグループ（NSG）：NIC単位やサブネット単位のファイアウォール
• 可用性ゾーン（AZ）：リージョン内の、独立した電源、冷却手段、ネットワークを備えた物理的に分離されたデータセンター群。データセンター単位の保護。
  • 目的（なぜ必要なのか）：データセンター全体の大規模な障害（火災、水害、広域停電など）が発生しても、別のデータセンター（ゾーン）でシステムを稼働させ続けるため。
  • SLAと条件：同じリージョン内の2つ以上の可用性ゾーンに2台以上のVMをデプロイした場合、99.99% の可用性SLAが保証される。
  • リソースの配置タイプ：
    • ゾーナルリソース (Zonal)：特定の1つのゾーン（例：Zone 1）に固定して作成されるリソース。（例：仮想マシン、マネージドディスク、パブリックIPアドレス）
    • ゾーン冗長リソース (Zone-redundant)：複数のゾーンをまたがって自動的に分散・複製されるリソース。（例：ゾーン冗長ストレージ(ZRS)、Standard Load Balancer）
  • 制約・注意点：
    • すべてのAzureリージョンで可用性ゾーンがサポートされているわけではない。
    • 異なる可用性ゾーン間（例：Zone 1とZone 2のVM間）でのデータ通信にはネットワークトラフィック料金が発生する。
• 可用性セット：同一データセンター内で、ラック単位で仮想マシンを物理的に分散配置して冗長構成をとる機能。ラック単位の保護。SLAは 99.95%（可用性ゾーンの99.99%より一段下がる）。
  • 目的（なぜ必要なのか）：同じデータセンター内でのラックの電源障害や、Azure側の計画メンテナンスによる再起動時に、すべてのVMが同時にダウンするのを防ぐため。
  • 構築時の制約：仮想マシンを可用性セットに配置するには、VMの作成時（デプロイ時）に指定する必要がある。既存のVMを後から可用性セットに追加することはできない（VMを再作成する必要がある）。
  • 障害ドメイン (Fault Domain)：ネットワークスイッチと電源を共有するハードウェアのグループ（物理ラック）。予期しないハードウェア障害から保護する。最大3つ。
    • 例）障害ドメインが2の可用性セットに対して10台のVMを追加すると、障害ドメイン1に対してVMが5台割り当てられるため、1つのサーバラックで障害が起きても最大5台のVMしか影響を受けない。
  • 更新ドメイン (Update Domain)：Azure側の計画メンテナンス時に、同時に再起動される論理的なグループ。最大20個。
    • 例）更新ドメインが5の可用性セットに対して10台のVMを追加すると、1つのドメインに2台ずつ割り当てられる。計画メンテナンス時は1つの更新ドメインずつ順に処理されるため、同時に再起動（ダウン）するのは最大2台のみとなる。
• 仮想マシンスケールセット (Azure Virtual Machine Scale Sets) は、複数の仮想マシンを1つのグループとして管理し、スケジュールもしくは負荷に応じて仮想マシンを自動でスケールアウト・スケールインできる
  • 目的（なぜ必要なのか）：トラフィックの増減に合わせてVMを自動的に増減（オートスケール）させ、可用性とコスト効率を両立するため。
  • オーケストレーション モード（VMの管理方式）：
    • 均一 (Uniform) モード：同一のOSイメージ、同一サイズのVMを一括管理する、従来からの方式。同一構成のVMを大量にデプロイするのに適している。
    • フレキシブル (Flexible) モード：異なるサイズや構成の標準VM（単一VM）やスポットVMなどを、同じスケールセット内に混在させて管理できる柔軟な方式。個々のVMに対する細やかな制御が可能。
  • 水平方向と垂直方向のスケーリングの違い：
    • 水平方向のスケーリング (Horizontal Scaling / スケールアウト・イン)：
      • リソースの「台数」を増減させる。仮想マシンスケールセットのオートスケール機能で主に使用される。
      • ダウンタイムなしでシステム全体の処理能力をシームレスに拡張・縮小できる。
    • 垂直方向のスケーリング (Vertical Scaling / スケールアップ・ダウン)：
      • リソース自体の「サイズ（CPUやメモリのスペック）」を増減させる。
      • 適用するには仮想マシンの再起動が必要（ダウンタイムが発生する）。
  • オートスケール（自動スケーリング）のトリガー：
    • メトリックベースのスケーリング：CPU使用率やメモリ、ネットワークトラフィックなどのパフォーマンス指標のしきい値に基づいて自動的に増減させる。
      • 例：過去10分間の平均CPU使用率が75%を超えたらVMを2台追加し、25%を下回ったら1台減らす。
      • クールダウン期間 (Cooldown)：スケール操作の実行後、次のオートスケール評価を行うまで「待機」する時間。短期間に連続して増減を繰り返すこと（フラッピング）を防ぐための必須設定。
    • スケジュールベースのスケーリング：特定の日時、曜日、時間帯に基づいてあらかじめ指定した台数に変更する。
      • 例：アクセスの増える平日の朝9時にVMを10台に増やし、夜18時に2台に減らす。
  • スケールインポリシー：VMを減らす（スケールインする）際に、どのVMから削除するかを決定するルール。規定 (Default)、NewestVM (最も新しいVM)、OldestVM (最も古いVM) から選べる。
  • Azureの計画的なメンテナンス中は、最低80%のVMのみが動作する（20%のVMは停止する）
• 近接配置グループ：仮想マシンがお互いに物理的に近くに配置されるように使用される論理的なグループ（Azureリソース）
• 仮想マシンの拡張機能：デプロイ後の構成と自動化を提供するアプリケーション
  • カスタムスクリプト機能：ARMのextensionProfile属性と組み合わせて、初期の仮想マシンの構成後に、仮想マシンの停止やソフトウェアコンポーネントのインストールなどの簡単なタスクを自動的に実行できる
  • Desired State Configuration (DSC) 拡張機能：適用対象のサーバにエージェントをインストールしておき、PowerShellによってデプロイやシステム構成の管理などができる
• vCPUクォータ：新しい仮想マシンをデプロイするときは、仮想マシンのvCPUがそのVMサイズファミリのvCPUクォータまたはリージョンのvCPUクォータの合計を超えてはいけない
• 仮想マシンのメンテナンス：
  • 計画メンテナンス：再起動が必要。専用のメンテナンスコマンドからメンテナンスを実行できる（普通の再起動ではメンテナンスされない）
  • 計画メンテナンスには2つのフェーズが存在する
    1. セルフサービスフェーズ：ユーザーがメンテナンス可能な期間で、通常4週間程度
    2. 予定メンテナンスフェーズ：Azureでメンテナンスを実行する期間。セルフサービスフェーズ終了後に開始される。
• 一時ディスクとしてのDドライブ (Temporary Storage)
  • VM起動時にDドライブが自動的に作成される。このディスクおよびドライブは、一時ディスクと呼ばれているもので、OS上の一時的なデータの保管用途として作成される
  • 一時ディスクに保存されているデータは、VMのメンテナンスイベント、再デプロイ時、またはVM停止時に消失する

5-2. Azure App Service

• Azure App Serviceは、WebアプリやAPIをホストするためのサービス
  • 目的（なぜ必要なのか）：OSやインフラの管理（パッチ当てなど）をクラウドに任せ、開発者がWebアプリやAPIのコード・開発に専念できるようにするため（PaaS）。
• IaaSで構成する場合：

    Application Gateway <==> Webサーバ（VM） <==> Azure Load Balancer <==> SQL Server（VM）
  

• PaaSで構成する場合：

    Application Gateway <==> Web Apps <==> SQL Database
  

• Azure App Serviceのカスタムドメインを設定できる（App Serviceドメイン）
• デプロイ方法：
  • IDEからの発行：Visual StudioやVS Codeの「発行（Publish）」機能を使って、開発環境から直接ビルド・デプロイを行う
  • CI/CDパイプライン：Azure DevOpsやGitHub Actionsを使用して、ソース管理の更新時に自動デプロイを自動化する
  • コマンドライン / スクリプト：Azure CLI (az webapp deploy) を使用してデプロイする
  • コンテナーレジストリからのプル：コンテナー版を利用する場合、Azure Container Registry等からDockerイメージを取得してデプロイする
• スロット：
  • 運用スロットとは別に専用のスロット（デプロイスロット）が利用できる。ステージング環境・検証環境としてデプロイできる
  • スロットを入れ替える（スワップする）ことでバージョンに切り替えが素早くできる
    • ただし、カスタムドメイン名やTLS証明書、スケールの設定などはスワップされない。それ以外のアプリの設定などがスワップされる
• App Serviceプランは、OSやリージョンに応じて作成する必要がある。
  • OSはWindows環境、Linux環境、Docker環境の3種類のみ選択できる
• ログ記録：
  • アプリケーションのログ記録：アプリケーションのコード実行にかかるメッセージのログが記録される
  • Webサーバーのログ記録：HTTP要求データが取得される
• アプリのバックアップ・復元
  • オンデマンドでカスタム バックアップを作成することや、スケジュールされたカスタムバックアップを構成することができる
  • 既存のアプリを上書きするか、新しいアプリまたはスロットに復元することで、バックアップを復元できる
  • バックアップ保持期間としては0〜30日間または無期限で設定が可能で、0に設定することで無期限にバックアップを保持可能となる
• WebJobs：
  • App ServiceのWebアプリと同じインスタンス（VM）上で、バックグラウンドプログラムやスクリプト（.cmd, .ps1, .sh, .py, .js など）を実行する機能。
  • 実行モード：
    • 連続 (Continuous)：開始直後からバックグラウンドで常に実行され続けるモード。途切れることなく安定して実行するためには、App Serviceの設定で「常時接続 (Always On)」を有効にする必要がある（※無効のままだとアイドル時にタイムアウトでプロセスが停止してしまう）。
    • トリガー (Triggered)：手動実行、またはスケジュール（CRON式）をきっかけに実行されるモード。「常時接続」を有効にする必要はない。

5-3. Azure Kubernetes Service (AKS)

• Azure Kubernetes Service (AKS) はAzure基盤上でKubernetesクラスターを構築、管理できるマネージドサービス
  • 目的（なぜ必要なのか）：大規模で複雑なマイクロサービス型のコンテナアプリケーションを、自動復旧やオートスケールを備えた環境で運用・管理するため。
• Kubernetesクラスター：オーケストレーションエンジン
  • コントロールプレーン：ワークロードをオーケストレーションする
  • ノード：ワークロードを実行する
• オートスケール：
  • クラスターオートスケーラー：ノードの数を自動制御する
  • 水平オートスケーラー：ポッドの数を自動制御する
• AKSのネットワーク：
  • Azure CNI（Azure Container Networking Interface）を使用すると、Podは仮想ネットワークのサブネットからIPアドレスを取得し、Podに対して直接アクセスできる。
  • KubenetはAKSクラスターの規定の構成

5-4. Azure Container Instances

• Azure Container InstancesはAKSと同様にコンテナの実行環境を提供するサービス
  • 目的（なぜ必要なのか）：VMの起動やクラスター（AKSなど）の構築なしで、単一のコンテナを数秒で手軽にサクッと起動・実行するため。
  • 構成はAKSよりシンプルで、単一ポッドを提供するサービス
  • 最上位のリソースは、コンテナグループ
  • azコマンドの主な使用例：
    • az container create --resource-group <RG名> --name <コンテナ名> --image <イメージ名> --dns-name-label <DNSラベル> --ports 80：指定したコンテナイメージを使用してACIを素早く起動し、公開用DNS名でアクセスできるようにする
• マルチコンテナグループ：1つの機能タスクを複数のコンテナーに分割する場合に利用する。Linuxコンテナーのみ対応

5-5. Azure Automation

• Azure AutomationはAzure環境やAzure以外のクラウドサービス、オンプレミスに対して一貫した管理をサポートするサービス
  • 構成管理：
    • 変更履歴とインベントリ
    • Azure Automation State Configuration（PowerShell DSCのクラウドベースの実装）
      1. Azure AutomationにDSC構成をアップロードする
      2. DSC構成をコンパイルする
  • Update Management：オンプレや仮想のOSの更新プログラムを管理する
  • プロセスオートメーション：PowerShell、PowerShellワークフロー、グラフィカルRunbookを作成・管理できる

5-6. その他のコンピューティングサービス

• Azure Container Registryは、OSSのDocker Registry 2.0に基づくマネージドレジストリサービス
  • azコマンドの主な使用例：
    • az acr create --resource-group <RG名> --name <ACR名> --sku Basic：新しいコンテナーレジストリを作成する
    • az acr login --name <ACR名>：ローカルマシンのDocker CLIを使ってACRにログインする
    • az acr build --registry <ACR名> --image <イメージ名>:<タグ> .：ローカルにDocker環境がなくても、ソースコードからイメージをビルドしてACRに直接プッシュする
    • az acr repository list --name <ACR名> --output table：レジストリ内のリポジトリ（イメージ）の一覧を表示する
• Azure Container Appsは、AKSやAzure Container Instancesと同様にコンテナーの実行環境を提供するサービス
  • トラフィックによるスケーリングや実行時間の長いプロセスをサポートする
• Azure Functionsは、Azure上で提供されるサーバーレスコンピューティングサービス
• Azure Virtual Desktop (ADV) は、Azure上で仮想デスクトップ（VDI）環境を利用できるサービス
• Azure Batchは、大規模な並列実行のバッチジョブを管理・実行するための環境を提供するサービス
• Azure Logic Appsは、コードを使用せずに自動化されたワークフローを作成し実行できるサービス
• Azure Service Busは、メッセージキューと、パブリッシュとサブスクライブのトピックを備えたフルマネージドエンタープライズメッセージブローカー
  • Azure Service Busキュー：単一のコンシューマーがメッセージを消費する必要がある場合で他のコンシューマーから重複処理がされないようにするために利用する
  • Azure Service Busトピック：複数のコンシューマーがメッセージを消費する必要がある場合に利用する

6. ネットワークサービス

6-1. Azure Virtual Network (VNET)

• Azure Virtual Network (VNET) とは、Azure内でリソースが安全に通信できる仮想のプライベートネットワーク
  • 目的（なぜ必要なのか）：Azure上に論理的に分離されたプライベートなネットワーク空間を作成し、リソース間の安全な通信基盤を提供するため。
• 仮想マシンが利用するDNSサーバは、VNETのDNSサーバを指定する。
• VNETのアドレス空間は、作成後にも追加可能
• ネットワークインターフェイス（NIC）は、仮想マシン（VM）が仮想ネットワーク（VNET）へ通信するためのインターフェイス
  • 仮想マシンのNICの接続先VNETは変更できない
• Azure PaaSへの安全な接続方法：
  • 仮想ネットワーク サービス エンドポイント (Service Endpoint)：
    • VNETのサブネットからAzure PaaS（Azure StorageやSQL Databaseなど）に対して、インターネットを経由せずAzureのバックボーン ネットワーク経由で直接、安全にルーティングするための機能。
    • PaaSサービスは引き続きパブリックIPを持つが、PaaS側のファイアウォール設定と組み合わせて「特定のサブネットからのみアクセスを許可」することができる。
  • プライベート エンドポイント (Private Endpoint / Private Link)：
    • VNETのサブネット内のプライベートIPアドレスをPaaSサービスに直接割り当てる機能。これにより、PaaSサービスがVNET内のリソースであるかのように閉域網で通信できるようになり、サービスエンドポイントよりもさらに高いセキュリティを実現できる。

6-2. ネットワークセキュリティグループ (NSG)

• ネットワークセキュリティグループ (NSG) は、仮想ネットワーク（VNET）のサブネットや、仮想マシンのNICに設定するネットワークフィルター処理（ファイアウォール）
  • 目的（なぜ必要なのか）：サブネットやVMのNICレベルでトラフィックの送受信をIPアドレスやポート番号でフィルタリングし、不正なアクセスをブロックするため。
• 送受信トラフィックに対して、送信元IP、送信先IP、ポート、プロトコルで、許可または拒否するセキュリティ規格を設定できる。
• サービスタグは、AzureサービスのIPアドレスプレフィックスのグループを表す。
  • Azureサービスのアドレスが変わると自動的にサービスタグも更新される。
  • AzureサービスをNSGのルールのソース（送信元）や宛先として設定するときは、IPアドレスではなくサービスタグを使用する。
• アプリケーションセキュリティグループ（ASG）を実装すると、仮想マシンを利用用途に合わせて論理的にグループ化してNSGを定義できる。
  • ASGを利用することで明示的なIPアドレスを管理することなく、セキュリティ規則に利用できる

6-3. Azure Firewall

• Azure Firewallは、仮想ネットワーク（VNET）上で動作するクラウドベースのファイアウォールサービス
• Azure Firewallはハブアンドスポークネットワークトポロジーを実装してデプロイすることが推奨される。
• Azure Firewallの規則
  • DNAT規則：Azure FirewallのパブリックIPアドレスとポートを、プライベートIPアドレスに変換するDNATを構成できる。
    • 実際に通信を通すためには、NSGのトラフィック許可と合わせて設定する必要があるため注意
  • ネットワーク規則：HTTP/S以外のプロトコル（RDPやSSHなど）のトラフィックを許可するための設定
  • アプリケーション規則：HTTP/Sのトラフィックを許可するための設定。
    • VNETからAzure Firewallを経由してインターネットにアクセスする場合に、アクセスを許可するドメイン名（FQDN）の一覧を設定する。

6-4. Azure DNS

• Azure DNSは、AzureでDNSドメインをホストし、DNSドメインの名前解決を提供するサービス
• パブリックなDNSドメインに加えて、プライベートネットワーク内でのDNSレコード管理を提供するプライベートDNSゾーンもサポートされている。
• Azureサブスクリプションを作成すると、Microsoft Entra Domain Servicesのドメインが自動的に生成され、初期ドメインは Domain Name の後に「.onmicrosoft.com」が続く形式となる。
• カスタムドメインを登録するには、Microsoft Entra IDからカスタムドメインの追加を行う。
  1. 利用したいカスタムドメイン名をディレクトリに追加する
  2. ドメインレジストラーにDNS情報を追加する（DNSドメインの有効性確認用DNSレコードは、MXレコードかTXTレコードのどちらかを選択する）
  3. AzureがDNSレコードの存在をDNSドメインに照会し、ドメインの検証が完了する
• Azure DNSゾーン：特定のドメインのDNSレコードをホストするために使用する。
  • 例えば「contoso.com」に「mail.contoso.com」や「www.contoso.com」などの複数のDNSレコードを作成できる。
• AzureプライベートDNSゾーン：独自のカスタムドメイン名を使ってDNSに登録できる。
  • DNSゾーンにDNSレコードをホストすることで、VNET内やVNET間で仮想マシンなどのIPアドレスの名前解決ができる
• Azure仮想ネットワークリンク：VNETとプライベートDNSゾーンをリンクさせる機能
  • リンクされると、VNETにホストされているVMがプライベートDNSゾーンにアクセスできるようになる
• 自動登録：
  • 自動登録がオンの場合、VNET内に仮想マシンなどのリソースを作成した際に、そのリソースのプライベートIPがプライベートDNSゾーンに自動的に登録される

6-5. Azure Virtual Network (VNET) ピアリング

• VNETピアリングは、同じリージョンや異なるリージョン間のVNETを接続し、VNET間の通信をできるようにする仕組み
• ピアリングする2つのVNETは、アドレス空間を重複させることができない。この場合、どちらかのアドレス空間を修正する必要がある。
• ゲートウェイの転送を有効にすると、ピアリング先の仮想ネットワーク（ハブVNET）内にあるVPNゲートウェイを利用して、オンプレミスネットワークと通信することができる。

6-6. Azure VPN Gateway

• Azure VPN Gateway（VPNゲートウェイ）は、VNETとオンプレ間をインターネット経由で暗号化されたVPN接続の構成に使用します。
  • 目的（なぜ必要なのか）：オンプレミス環境とAzureをインターネット経由で安全に暗号化接続し、ハイブリッドクラウド環境を手軽に構築するため。
• Azure VPN Gatewayの種類：
  • サイト間VPN（S2S）：オンプレのネットワークをVNETに接続する。複数拠点と接続するにはIKEv2トンネリングプロトコルが使用される。
  • ポイント対サイトVPN（P2S）：個々のデバイスをVNETに接続する
  • VNet対VNet：VNETとVNETを接続する

6-7. Azure ExpressRouteとAzure Virtual WAN

• Azure ExpressRouteは、パブリックなインターネットを経由せずに接続プロバイダーが提供する専用線接続を経由してAzureに接続する仕組み
  • 目的（なぜ必要なのか）：オンプレミス環境とAzureを専用線で接続し、インターネットを経由しない高品質・高セキュリティ・低遅延なハイブリッドクラウド環境を構築するため。
• Azure Virtual WANを使用すると、Azureバックボーンを使って、オンプレ拠点やVNETを相互に接続するネットワーク環境を構築できます。
  • Virtual WANは、S2S VPN、P2S VPN、ExpressRoute、Azure Firewallなどを1つの操作インターフェイスにまとめたもの
  • 仮想WANと仮想ハブを組み合わせてハブアンドスポークアーキテクチャを構成することにより、データセンター間のネットワーク待ち時間を最小限に抑えることができる

6-8. ネットワークルーティングとエンドポイント

• ルーティングテーブルの種類：
  • システムルート：規定のルーティングテーブル。サブネット単位で作成される
  • ユーザー定義ルート（UDR）：ユーザが独自にルートを定義できる
    • ※同じ仮想ネットワーク内の異なるサブネットに属したリソース間はデフォルト設定で通信できる
• サービスエンドポイント：Azureサービスに対してインターネット経由のアクセスを制限し、VNETからの通信に制限する機能
• プライベートエンドポイント：VNETのプライベートIPアドレスでAzure PaaSに接続する機能。
• Azure Private Link：VNETのプライベートエンドポイント経由で、Azure PaaS（Azure StorageやSQL Databaseなど）とのプライベート接続が可能になる仕組み

6-9. Azure Load Balancer

• Azure Load Balancerは、受信トラフィックをバックエンドの仮想マシンやAzureリソースへ負荷分散させるサービス
  • 目的（なぜ必要なのか）：複数のVMにトラフィックを分散させ、特定のVMへの負荷集中を防ぐとともに、一部のVMがダウンしてもシステム全体が停止しないようにするため（レイヤー4分散）。
  • パブリックロードバランサー：インターネットからの通信を負荷分散する（例：Web用VMへの接続）
  • 内部ロードバランサー：VNET内で通信を負荷分散する（例：DB用VMへの接続）
• セッション永続化：Webサービスへのアクセスをクライアントごとに同じWebサーバで処理させるときに有効化する。設定なし、クライアントIP、クライアントIPとプロトコル の3種類から指定する
• 正常性プローブ：アプリケーションの状態を監視する機能。
  • 正常性チェックの応答結果に基づいて、自動でバックエンドインスタンスへの要求のルーティングを停止する。
• インバウンドNAT規則（受信NAT規則）：特定のポート番号宛の通信をバックエンドプールの特定のインスタンスへポート転送する機能
  • インバウンドNAT規則を設定するときは、事前にフロントエンドIPアドレスの作成が必要
• バックエンドプールエンドポイント：
  • Standard SKUのとき、「単一のVNET内の任意のVM」または「VMスケールセット」を転送先に指定できる
  • Basic SKUのとき、「単一の可用性セット」または「VMスケールセット内のVM」を転送先に指定できる（※Basic Load Balancerは2025年9月30日で廃止予定のため、今後はStandardを使用する）
• フロントエンドIPアドレス：
  • 負荷分散規則を作成するときは、フロントエンドIPアドレスとバックエンドプールを事前に準備して、それらをバックエンドプールに設定する
• HAポート（高可用性ポート）：
  • すべてのポートですべてのプロトコルフローを同時に負荷分散できる。ポートごとに1つずつ負荷分散規則を適用する必要がなくなる
  • Azure Standard Load Balancerでのみ使用可

6-10. Azure Application Gateway

• Azure Application Gatewayは、WebアプリへのHTTP/HTTPS通信用のロードバランサ
  • 目的（なぜ必要なのか）：Webアプリ（HTTP/HTTPS）に対する高度なルーティング（URLパスごとの振り分け等）や、Webアプリケーションファイアウォール(WAF)による保護を提供するため（レイヤー7分散）。
• パスベースのルーティング：異なるURLパスの要求を異なるバックエンドサーバーのプールに送信できる
• マルチサイトのルーティング：同じApplication Gatewayのインスタンス上に複数のWebアプリケーションを構成できる
• Application Gatewayの構成要素

    クライアント ==> Application Gateway ==> Web Application ==> HTTP/HTTPS ==> ルーティング ==> バックエンドプール
                     フロントエンドIP            Firewall          リスナー　　　　　  規則
  

6-11. その他のネットワークサービス

• Azure Bastion：SSHやRDP接続できる踏み台サーバー
  • 目的（なぜ必要なのか）：VMにパブリックIPを持たせることなく、ブラウザ経由で安全にRDP/SSH接続を行い、外部からの攻撃リスクを最小化するため。
  • Webブラウザーを使ったAzure Portalの画面経由でVMに接続できる
  • ネイティブクライアント機能を有効化すると、ローカルコンピューターのネイティブクライアント（RDPやSSH）を使ってVNET内のVMに接続できる
• Azure Traffic Manager：DNSベースの負荷分散サービス。ドメインレベルで負荷分散する
• Azure Front Door：コンテンツ配信ネットワーク（CDN）、グローバルロードバランサー、Web Application Firewall (WAF) の機能を持つサービス

Azureの負荷分散サービスの比較：

• Azure NAT Gateway：フル マネージドで回復性の高いネットワーク アドレス変換 (NAT) サービス
  • プライベートネットワーク内にあるVMからアウトバウンドインターネット接続が可能となる

7. Azureリソースの監視と管理

7-1. Azure Backup

• Azure Backupサービスは、Azure上のVMのデータやDBだけでなく、オンプレのデータもAzureにバックアップできるマネージドサービス
  • 目的（なぜ必要なのか）：誤削除、ランサムウェア被害、データの破損に備え、データを定期的に保存して確実に復元できる仕組みを提供するため。
• Recovery Servicesコンテナー（Recovery Services Vault）は、バックアップデータやAzure Site Recoveryのレプリケーション情報を保存・管理するための保管庫。
  • 目的（なぜ必要なのか）：データバックアップやディザスターリカバリーのためのデータを、元のリソースから分離された安全な場所に一元管理するため。
  • 【用語の注意点】（コンテナー＝Vault/金庫）：Azureの日本語UIでは「Vault（金庫、保管庫）」という単語が「コンテナー」と翻訳されるため、非常に紛らわしいです（Key Vault ＝ キー コンテナー など）。DockerコンテナーやストレージのBLOBコンテナーとは全く無関係であり、単なる「データを守るための頑丈な金庫（Vault）」だとイメージしてください。現場や公式ドキュメントでは英語のまま「Vault (ボールト)」と呼ばれることも多いです。
  • 作成場所（リージョン）のルール：
    • Azure Backupで使用する場合：保護対象のリソース（VMなど）と同じリージョンに作成する必要がある。
    • Azure Site Recoveryで使用する場合：保護対象のリソースとは異なるリージョン（フェールオーバー先のセカンダリリージョン）に作成する必要がある。
  • サブスクリプションのルール：
    • 保護対象のリソースと同じサブスクリプションに存在する必要がある。（※リソースグループは異なっていてもよい）
  • 削除のルール：
    • コンテナー内に保護されたアイテム（バックアップデータ等）が1つでも存在する場合、そのコンテナーは削除できない。先に保護の停止とデータの削除が必要。
  • 1つのRecovery Servicesコンテナーは、複数のリソースからのバックアップにまとめて利用できる。
• バックアップできるデータの概要：
  • 仮想マシン（VM）：
    • 全体バックアップ（復元時は「VMの復元」を選択する）
      • VMの復元先はバックアップ元VMか新規VMのいずれかを選択する。OLR (元の場所への復旧) または ALR （別の場所への復旧）を選択する
    • フォルダー・ファイル単位（復元時は「ファイルの回復」を選択する）
      • ファイルの復元方法は、Azure Portalからファイルを参照して回復するためのスクリプトをダウンロードし、そのスクリプトを実行しディスクを任意のPCのドライブにマウントすることでファイルを復元できる
    • 仮想マシン上で実行されているDB
  • ディスク（Azureディスク）
  • ストレージ：
    • Azureファイル共有
    • Azure BLOB
  • オンプレミス（オンプレ上の物理サーバーやVM）：
    • MARS (Microsoft Azure Recovery Services) エージェント：オンプレミスのWindowsマシンからファイル、フォルダー、システム状態を直接Azure上のRecovery Servicesコンテナーにバックアップするための専用エージェント。利用するには、対象マシンに手動でインストールし、資格情報（コンテナーの資格情報コンテキスト）を使って登録を行う必要がある。
    • ※Azure VMをバックアップする際の「スナップショット拡張機能（VMSnapshot）」とは別の機能（MARSはファイル/フォルダー単位、拡張機能はVM全体単位）。
• 仮想マシンのバックアップとスナップショット：
  • 最初のバックアップ時に、Azure Backupによって仮想マシンにスナップショット拡張機能（Windowsの場合は VMSnapshot、Linuxの場合は VMSnapshotLinux）が自動的にインストールされる。
  • 整合性のレベル：
    • アプリケーション整合性（規定）：メモリ内のデータや保留中のI/O操作を含む完全なバックアップ。WindowsのVSS（ボリュームシャドウコピーサービス）、Linuxのカスタムスクリプトを利用する。
    • ファイルシステム整合性：アプリケーション整合性が失敗した場合やVMがシャットダウンしている場合に取得される。ファイル自体は整合性が保たれるが、メモリ上のデータは含まれない。
    • クラッシュ整合性：ディスク上にすでに存在するデータのみをキャプチャする（電源ケーブルを突然抜いた状態と同じ）。
  • インスタント復元 (Instant Restore)：取得したスナップショットはRecovery Servicesコンテナーに転送されるだけでなく、ローカル（ディスク側）でも最大5日間（デフォルト2日間）保持される。これにより、コンテナーからのデータ転送を待たずに、スナップショットから直接極めて高速な復元が可能になる。
  • VMは起動中でも停止中でもどちらでもバックアップが実行できる。
• 仮想マシンのバックアップ プロセス（流れ）：
  1. ジョブのトリガー：バックアップポリシーに基づくスケジュール、または手動でジョブが開始される。
  2. 拡張機能のトリガー：対象VMが稼働している場合、Azure Backupがスナップショット拡張機能をインストールまたはトリガーする。
  3. スナップショットの取得：拡張機能がVSS等と連携し、ディスクのポイントインタイム スナップショットを取得する（規定ではアプリケーション整合性）。
  4. コンテナーへのデータ転送：スナップショットが取得された後、バックアップデータがRecovery Servicesコンテナーに転送される。転送は増分のみ（前回のバックアップから変更されたブロックのみ）送られるため非常に効率的。
  5. 完了とインスタント復元：転送が完了すると復旧ポイントが作成される。また、取得されたスナップショット自体はローカルに最大5日間保持され、「インスタント復元」として即時復旧に利用可能となる。
• ストレージレプリケーションの設定：
  • ローカル冗長（LRS）：1つの物理的な場所でデータを同期的に3回コピー
  • ゾーン冗長（ZRS）：リージョンの3つの可用性ゾーン間でデータを同期的にコピー
  • Geo冗長（GRS）：LRSを使用してリージョンに1つの物理的な場所でデータを同期的に3回コピーし、その後、セカンダリリージョン内の1つの物理的な場所にデータを非同期にレプリケートする
• バックアップポリシーは、バックアップの「スケジュール（頻度）」と「保持期間」を定義する設定。
  • 1つのポリシーを同じRecovery Servicesコンテナー内の複数のVMに一括適用できる。
  • ポリシーの種類：
    • 標準ポリシー (Standard Policy)：バックアップ頻度は「毎日」または「毎週」（最短で1日1回・RPO 24時間）。
    • 拡張ポリシー (Enhanced Policy)：1日に複数回（最短4時間ごと・RPO 4時間）のクラッシュ整合性バックアップ等が可能。以下のような特殊な要件を持つVMをバックアップする場合は拡張ポリシーの利用が必須となる。
      • トラステッド起動 (Trusted Launch) の仮想マシン
      • コンフィデンシャル (Confidential) 仮想マシン
      • 特定の暗号化要件を持つ仮想マシン
  • 保持期間 (Retention)：日次、週次、月次、年次それぞれのバックアップポイントをどれだけ長く保持するかを設定する。
• オンデマンドバックアップ：スケジュールに関係なく、任意のタイミングで手動で取得するバックアップ。
• RPOとRTO：
  • RPO（目標復旧時点）は標準ポリシーのVMバックアップでは1日。VM内のSQL Server等（DBレイヤーのバックアップ）は最短15分。
  • RTO（目標復旧時間）は数時間（データ量に依存する）。
• バックアップデータの整合性対策として、Linuxの場合はスナップショット作成前後に任意のスクリプトでサービスの停止・再開を実行できる。
• バックアップに必要な権限として、「バックアップ共同作成者」または「バックアップオペレーター」のロールが必要。
• 「既存の復元構成を置き換える」オプション：
  • ファイル復元時に、既存の復元構成を復元して、それを使用して既存のVM上のディスクの内容を置き換えることができる
  • 「ディスクを復元する」とは異なり、ディスク上のファイルを直接置き換えるため、VMの再起動が不要となる

7-2. Azure Site Recovery

• Azure Site Recoveryは、データセンターの大規模災害や障害から仮想マシンを保護し、セカンダリリージョンへのワークロードをレプリケートできるDR（ディザスターリカバリー）サービス
  • 目的（なぜ必要なのか）：リージョン全体の大規模災害などでメインシステムが停止した場合に、別のリージョン（セカンダリ）へ素早くフェールオーバーし、ビジネスを継続（DR）するため。
• 復旧するセカンダリリージョンにRecovery Servicesコンテナを作成する必要がある。
• RPOとRTO：
  • RPO（目標復旧時点）は継続的レプリケーションにより最短数秒〜数分（クラッシュ整合性で5分など）
  • RTO（目標復旧時間）は数分（SLA上では2時間）
• サイトの稼働率を維持したいときはAzure Site Recoveryを使用する

表：Azure Backup と Azure Site Recovery の違い

7-3. Azure Monitor

• Azure Monitorは、オンプレおよびクラウド環境の性能を監視、アプリ監視、ログ監視などの機能が統合されたフルマネージドサービス
  • 目的（なぜ必要なのか）：Azure環境全体のリソースのパフォーマンスやログを継続的に収集・分析し、異常発生時の迅速なアラート発報やトラブルシューティングを実現するため。
• メトリックとは、リソースの健全性を測定するための使用される指標のこと。
  • Azureリソース：リソースの種類ごとにAzureが生成するメトリック
  • アプリケーション：Application Insightsによって生成されたメトリック
  • 仮想マシンのOSメトリック：仮想マシンにエージェントをインストールして収集されたメトリック
  • カスタムメトリック
• Azure Monitorログは、監視ソリューションからアクティビティログ、診断ログ、テレメトリ情報を生成します。
• Azure Diagnostics拡張機能は、仮想マシンから監視データを収集するAzure Monitorのエージェントです（Azure Diagnosticsエージェント）
  • Linux VMのときは、Linux Diagnostic ExtensionをVMにインストールする
• Azure Monitor Application Insightsの自動インストルメンテーション：
  • ソースコードを修正することなく、アプリケーションログを収集できる
• Azure Monitorアラート：
  • 通知すべき情報が収集されたときにアラートを発するようにAzure Monitorを設定できる
  • アラートルールで設定する監視先のリソースはLog Analyticsワークスペースとなる
  • 送信の上限：
    • SMS：5分ごとに1件以下のSMSを送信するように制限される
    • 音声：5分ごとに1件以下の音声通話を送信するように制限される
    • SMS：1分ごとに2件以下のメールを送信するように制限される
  • Azure Monitorアラートに対するユーザー応答：
    • 「新規」「確認済み」「終了」の3種類のステータスを設定できる（新規アラート発報時は「新規」に設定されている）
  • アラートルールはアクティビティに応じて1つのアラートを作成する
  • アラートルールは複数メトリック（複数条件）で複数の条件を1個のアラートルールで監視できる
• アクショングループ：アラート通知設定などの通知先となるユーザーグループのこと
  • Azure Monitor、Service Health、Azure Advisor のアラート通知先として指定する
• Azureリソースの変更をトリガーとする処理：
  • Azureのリソースで発生する特定のイベントを監視してアクションを実施するワークフローを作成するためには、Azure Event GridおよびAzure Logic Appsを使用する
• パフォーマンスモニター機能：
  • 各リソースのパフォーマンス状況を可視化できる。VMのCPU使用率などのパフォーマンスなど
• Azure Monitor Network Insights機能：
  • ネットワークトポロジ、依存関係、正常性、関連するネットワークリソースの他の主要なメトリックを可視化する単一のダッシュボードが利用できる
  • また、接続モニター、NSG フローログ、および Traffic Analytics などのネットワーク監視機能へのアクセスもできる

7-4. Azure Service Health

• Azure Service Healthは、Azure内の計画メンテナンスや大規模障害が発生した場合に、利用者が通知を受け取ることができるサービス
• 確認できる情報：
  • Azureの状態：Azureサービスの停止に関するリージョンレベルの情報
  • サービス正常性：利用しているAzureのサービスとリージョンの正常性に関する情報。例えば、計画メンテナンス、正常性の勧告、セキュリティアドバイザリなど
  • リソース正常性：利用しているサブスクリプションの特定の仮想マシンやApp Serviceなど、ここのクラウドリソースの正常性に関する情報

7-5. Azure Advisor

• Azure Advisorは、利用しているAzure環境とMicrosoftのベストプラクティスに従って、リソース構成と利用統計情報を分析する
  • コスト、セキュリティ、信頼性、運用性、パフォーマンス の観点で推奨事項を提示してくれる

7-6. Log Analytics

• Log Analyticsは、Azure Monitorログのデータに対するログクエリの編集と分析を実行できる
• Azure Monitorから収集したログは、Log Analyticsに取り込まれる
• 過去31日間に取り込まれたログについては、無料の範囲でデータを保有できる
• Log Analyticsのクエリでログを分析するKQL（Kusto Query Language）という独自のクエリ言語が存在する
  • T | where Predicate : 条件によるデータ抽出
  • T | project ColumnName : 列名の選択（SQLのselect句相当）
  • T | summarize : 集約処理
  • T | render Visualization : グラフ化（描画）
  • その他：KQL quick reference - Kusto | Microsoft Learn

7-7. Azure Network Watcher

• Azure Network Watcherは、ネットワーク（仮想マシンなどのIaaSリソース、メトリック、ログの監視など）に特化した監視・確認を行うためのネットワーク診断ツール
  • 目的（なぜ必要なのか）：NSG（ファイアウォール）のルールで通信がブロックされていないか、ルーティングが正しいかなど、ネットワーク特有の通信トラブルを迅速に特定・診断するため。
• Network Watcherの機能：
  • 監視：
    • トポロジー
    • 接続モニター：Azureおよびハイブリッド環境のネットワーク接続を継続的に監視できる。
      • 接続モニターは仮想マシンを1つ選択して、別の仮想マシンの宛先に指定して、その接続状況を確認できる（ping相当）
      • 現在の新しい接続モニターでは、クロスリージョン（異なるリージョン間）やクロスサブスクリプションの監視がサポートされている。（※古い「接続モニター(クラシック)」では同一リージョンのみの制限があった）
    • ネットワークパフォーマンスモニター
  • ネットワーク診断ツール：
    • IPフロー検証：仮想マシン（VM）から送受信されるパケットの許可または拒否の状況を検証できる（NSGの動作確認）
    • NSG診断
    • ネクストホップ：特定のトラフィックがAzure仮想マシンに到達できないようにしているセキュリティ規則を特定できる（ルーティングの検証）
    • 有効なセキュリティルール
    • VPNのトラブルシューティング
    • パケットキャプチャ：仮想マシン (VM) またはスケールセットとの間で送受信されるトラフィックを追跡するパケットキャプチャセッションを作成できる
    • 接続のトラブルシューティング：ネットワーク接続の問題を診断して原因がプラットフォーム側なのかユーザ側の設定なのか調査できる
  • メトリック：
    • 使用量＋クォータ
  • ログ：
    • フローログ
    • 診断ログ
    • トラフィック分析
• ポート一覧：
  • 445/tcp：SMB, NFS
  • 3389/tcp：RDP

7-8. コスト管理

• Azureのコスト変動要因：
  • リージョン
  • 仮想マシンのスペック
  • ストレージ
  • ネットワーク通信量
  • パブリックIPアドレス
  • 仮想マシンの実行時間
• Azureコストの見積もり方法：
  • 料金計算ツール：Azureの利用料金のシミュレーションができるツール
  • 総保有コスト（TCO）計算ツール：オンプレからAzureへ移行を検討するときに、どの程度コストメリットがあるか計算できるツール
  • Cost Management：現在利用しているAzureのコストの確認・監視と最適化を行うツール
    • 目的（なぜ必要なのか）：利用中のAzureリソースのコストを可視化・分析し、予算アラートの設定や、無駄なリソース（未使用VMなど）の削減によるコスト最適化を行うため。
    • 「アドバイザーの推奨事項」にはコスト削減に役立つ推奨事項が提示される。例えば、VMのサイズ変更や未使用VMのシャットダウンなど
• 割引特典：
  • Azure Reserved Instances：1年または3年の利用をコミットすること予約割引によるコスト削減ができるオプション
  • Azureハイブリット特典：ソフトウェアアシュアランス（SA）のある既存のオンプレのWindows Server、SQL ServerおよびLinuxのライセンスをAzureで利用することで、仮想マシンの実行コストを大幅に削減できる特典
  • スポットVM：Azureにおいてその時点で未使用となっているため安価で提供される仮想マシン
  • Azure開発 / テスト価格：Visual Studioのサブスクリプションの所有者限定で開発・テスト用の従量課金プランが用意されている