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)で利用できる
- サブスクリプションへの接続方法
- アカウントへの接続
Connect-AzAccount
- Webブラウザが起動するので任意のアカウントでログインする
- 意図したサブスクリプションであることを確認する
Get-AzContext
- サブスクリプションを指定するとき
Set-AzContext-Subscription '00000000-0000-0000-0000-000000000000'
- アカウントへの接続
- リソースグループの作成方法
- サブスクリプション上のすべてのリソースグループの一覧を表示する
Get-AzResourceGroup
- 新しいリソースグループの作成
New-AzResourceGroup -Name RG-new -Location "Japan East"
- サブスクリプション上のすべてのリソースグループの一覧を表示する
- 仮想マシンの作成方法
- 仮想マシンを作成する
New-AzVm ` -ResourceGroupName 'RG-new' ` -Name 'newVM' ` -Location 'eastus' ` -Image UbuntuLTS
- 仮想マシンの状態を取得する
Get-AzVM-Status
- 仮想マシンを作成する
2-4. Azure CLI
- Azure CLIは、Azureのリソースとサービスを管理するためにマイクロソフトが提供するクロスプラットフォームのCLIツール
- Azure PowerShellと同様にクロスプラットフォームで利用できます。どちらも同様の機能を持ちますが、以下の使い分けが想定されます。
- Windows環境ではAzure PowerShellを利用する。
- LinuxやmacOS環境ではAzure CLIを利用する。
- サブスクリプションへの接続方法
- アカウントへの接続
az login
- Webブラウザが起動するので任意のアカウントでログインする
- 意図したサブスクリプションであることを確認する
az account show
- サブスクリプションを指定するとき
az account set --subscription '00000000-0000-0000-0000-000000000000'
- アカウントへの接続
- リソースグループの作成方法
- サブスクリプション上のすべてのリソースグループの一覧を表示する
az group list
- 新しいリソースグループの作成
az group create --name RG-AppService --location japaneast
- サブスクリプション上のすべてのリソースグループの一覧を表示する
- 仮想マシンの作成方法
- 仮想マシンを作成する
az vm create --resource-group <RG_NAME> --name <VM_NAME> --location japaneast --image UbuntuLTS
- 仮想マシンの状態を取得する
az vm list
- 仮想マシンを作成する
- App Service Planの作成
- App Service Planを作成する
az appservice plan create --name newAppPlan \ --resource-group RG-AppService --location japaneast --sku free
- App Service Planの状態を確認する
az appservice plan list
- App Service Planを作成する
- Webアプリケーションの作成
- Webアプリケーションを作成する
az webapp create \ --name new-webapp1 \ --resource-group RG-AppService \ --plan newAppPlan
- Webアプリケーションの状態を確認する
az webapp list
- Webアプリケーションを作成する
2-5. ARMテンプレート
- ARMテンプレートは、宣言型の方法でAzureリソースを定義およびデプロイするために使用されるJSONファイル
- 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('変数名')]
- パラメータ (parameters) の設定値を利用するときは
- ARMテンプレートのドキュメントは以下を参照:
- デプロイ方法:
- 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)
- Microsoft Entra IDの特徴:
- ユーザの管理:
- アカウント:Microsoft Entra IDのユーザID
- IDの認証とシングルサインオン (SSO)
- グループの管理:
- 動的グループ機能:設定したルールに応じて自動的にユーザ追加などのメンバーシップの変更が行われる機能
- ロールベースのアクセス制御 (RBAC)
- デバイスの登録(組織の管理下に置くことができる)
- 多要素認証 (MFA)
- アクティビティログの取得と監査
- クラウドアプリケーションの管理:他アプリケーションとの認証の連携ができる
- セルフサービス:ユーザーが自分自身でパスワードのリセットやグループの管理を行う機能が提供されている
- ユーザの管理:
- 条件付きアクセスポリシー:アクセス元の情報(端末情報やIPなど)から条件に従ってアクセス制御をしたり、追加の認証(MFAなど)を要求したりするための仕組み
表:Microsoft Entra ID と Active Directory の主な違い
Microsoft Entra ID | Active Directory | |
---|---|---|
ディレクトリサービス | 提供される | 提供される |
認証認可プロトコル | SAML 2.0, OpenID Connect | Kerberos, NTLM |
ディレクトリ情報アクセスプロトコル | HTTPS (Graph APIなど) | LDAPなど |
デバイス登録 | Microsoft Entra参加/登録 | Active Directoryドメイン参加 |
デバイス構成の管理 | Microsoft Intuneを利用 | グループポリシー |
- 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
- システム割り当て(System Managed ID):VM仮想マシンなどのリソースに自動的に割り当てられるID
- ユーザー割り当て(User Managed ID):ユーザがIDを作成してリソースに割り当てるとき
-
管理単位 (AU; Administrative Unit) :
- Microsoft Entra IDには組織単位(OU)が存在せず、ユーザーはフラットな空間で管理される
- 管理単位は、Microsoft Entra IDのユーザやグループのまとまり
- 管理単位を構成してユーザの管理スコープを設けることで、スコープ内のユーザー管理を他の管理者へ委任でる
-
セルフサービスパスワードリセット(SSPR):ユーザ自身でMicrosoft Entra IDユーザアカウントのパスワードをリセットできる機能
- SSRPが構成されている場合でも、セキュリティ管理者と課金管理者は管理者リセットポリシーが適用されるため、SSPRは適用されない
- 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へアカウントを同期し、一元管理するための機能
- ハイブリッド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つで、組織が強制させたいセキュリティポリシーや運用ルールをリソースに適用できる
- ポリシー (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でアクセスできる共有フォルダ
- 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のデータ暗号化:
- 暗号化の種類:
- マイクロソフトサービスにより管理されたマネージドキーによる暗号化(規定)
- Azure Key VaultやKey Vault HSMに保存されたカスタマーマネージドキーによる暗号化
- 暗号化の種類:
- Azure Key Vault:パスワードを保存して適切なアクセスポリシーを設定することでパスワードをプレーンテキストに保存せずに安全に利用できる
-
コンテナー:Azure Blob Storageではデータはコンテナー内に保存される。データをアップロードする前にコンテナーの作成が必要となる。
-
共有アクセス署名(SAS):特定のクライアントにSAS(Shared Access Signature)を生成することで、一時的なアクセスを付与できる。
- アドホックSAS:作成すると開始時刻、有効期限、およびアクセス許可がSAS URIで指定できる
- 保存されているアクセスポリシーによるサービスSAS:リソース側でアクセスポリシーが定義されており、それに基づいて作成されるサービスSAS
-
共有アクセス署名(SAS):特定のクライアントにSAS(Shared Access Signature)を生成することで、一時的なアクセスを付与できる。
- データ保護:
- 論理的な削除を有効化するか、不変性ポリシーを有効化することでデータ保護が実現できる
- 不変性ポリシー:削除と変更ができなくなる。追加と読み込みのみできる
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(クール):アーカイブストレージ
- Azure Filesのデータ保護:
- ストレージ冗長(Geo冗長性)
- 共有スナップショット(特定の時点のデータの読み取りコピー)
- バックアップ(Azure Backupサービスを利用)
- 論理的な削除
-
Azure File Syncは、オンプレからクラウドに拡張されたWindowsファイルサーバーを構築できる
- File Syncの要素:
- ストレージ同期サービス:同期グループを管理する最上位の管理単位
-
同期グループ:クラウド側のファイル共有
- 転送先:1つのクラウドエンドポイント(Azure Filesのファイル共有)を指定できる
- 転送元:複数のサーバーエンドポイントを含めることができる。ただし、同じサーバ内の複数エンドポイントは含められない。異なるサーバであれば問題なし
-
サーバーエンドポイント:オンプレ側(Windows Server)のファイル共有。Windows Server上にエージョントをインストールし、これをストレージ同期サービスに登録する。
- サーバー上の物理的なパスを指定する(例:D:\Data)
-
クラウドの階層化:
- 条件を指定してオンプレに残すファイルを選択できる(キャッシュとしての役割)
- 日付ポリシー:一定期間アクセスされていないファイルをクラウド上に階層化し、ローカルキャッシュから削除する。
- 複数のクライド/サーバーエンドポイントが存在するとき、同期グループ内のエンドポイントは相互に同期が維持される
- File Syncの要素:
ストレージ同期サービス
└── 同期グループ
├── サーバーエンドポイントA
└── サーバーエンドポイントB
4-5. Azure Storageのアクセス制御
- 共有キー(アクセスキー)は、ストレージへの管理者アクセスを持つ文字列で、HTTP/HTTPSのリクエストに含めて送信する(非推奨)
- Microsoft Entra IDアカウントで認証ができる
-
共有アクセス署名(SAS:Shared Access Signature)
- SASを使うことでストレージアカウント内のリソースに対する保護されたアクセスを委任できる
- 制限できる内容:
- クライアントがアクセスできるリソース
- リソースへのアクセス許可
- SASが有効な期間
- SASの種類:
- サービスSAS:BLOB、キュー、テーブル、Filesのいずれかにおいて、1つのリソースへのアクセスを提供する
- アカウントSAS:複数のストレージサービスへのアクセスに利用できる
- ユーザー委任SAS:Microsoft Entra IDの資格情報でセキュリティ保存されたSASで、BLOBでのみ使用できる
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
- 基本情報:
- 仮想マシン名:リソース識別子として使用される。初期作成時から変更できない
- ゲストホスト名:ホスト名。初期作成時から変更できる
- ディスク:
- Premium SSD、Standard SSD、Standard HDDから選択できる
- ネットワーク:
- ネットワークセキュリティグループ(NSG):NIC単位やサブネット単位のファイアウォール
- 可用性ゾーン(AZ):独立したデータセンタ、ネットワークなどを備えた高可用性確保のためのサービス。データセンター単位
-
可用性セット:ラック単位で仮想マシンを分散配置して冗長構成をとる方法。ラック単位
-
障害ドメイン:ネットワークスイッチと電源を共有するグループ(最大3つ)
- 例)障害ドメインが2の可用性セットに対して10台のVMを追加すると、障害ドメイン1に対してVMが5割り当てられるため、サーバラック障害時に最大5台のVMが停止する
-
更新ドメイン:メンテナンス時に同時に再起動するグループ(最大20個)
- 例)更新ドメインが5の可用性セットに対して10台のVMを追加すると、更新ドメイン1に対してVMが2割り当てられるため、計画メンテナンス時は最大2台のVMが停止する
-
障害ドメイン:ネットワークスイッチと電源を共有するグループ(最大3つ)
-
仮想マシンスケールセットは、複数の仮想マシンを1つのグループとして管理し、スケジュールもしくは負荷に応じて仮想マシンを自動でスケールアウト・スケールインできる
- スケールアウト
- スケールイン
- スケールインポリシー:スケールインの捜査中に仮想マシンが削除される順番を構成する。規定、NewestVM、OldestVM が選べる。
- Azureの計画的なメンテナンス中は、最低80%のVMのみが動作する(20%のVMは停止する)
- 近接配置グループ:仮想マシンがお互いに物理的に近くに配置されるように使用される論理的なグループ(Azureリソース)
-
仮想マシンの拡張機能:デプロイ後の構成と自動化を提供するアプリケーション
- カスタムスクリプト機能:ARMのextensionProfile属性と組み合わせて、初期の仮想マシンの構成後に、仮想マシンの停止やソフトウェアコンポーネントのインストールなどの簡単なタスクを自動的に実行できる
- Desired State Configuration (DSC) 拡張機能:適用対象のサーバにエージェントをインストールしておき、PowerShellによってデプロイやシステム構成の管理などができる
- vCPUクォータ:新しい仮想マシンをデプロイするときは、仮想マシンのvCPUがそのVMサイズファミリのvCPUクォータまたはリージョンのvCPUクォータの合計を超えてはいけない
- 仮想マシンのメンテナンス:
- 計画メンテナンス:再起動が必要。専用のメンテナンスコマンドからメンテナンスを実行できる(普通の再起動ではメンテナンスされない)
- 計画メンテナンスには2つのフェーズが存在する
- セルフサービスフェーズ:ユーザーがメンテナンス可能な期間で、通常4週間程度
- 予定メンテナンスフェーズ:Azureでメンテナンスを実行する期間。セルフサービスフェーズ終了後に開始される。
- 一時ディスクとしてのDドライブ (Temporary Storage)
- VM起動時にDドライブが自動的に作成される。このディスクおよびドライブは、一時ディスクと呼ばれているもので、OS上の一時的なデータの保管用途として作成される
- 一時ディスクに保存されているデータは、VMのメンテナンスイベント、再デプロイ時、またはVM停止時に消失する
5-2. Azure App Service
- Azure App Serviceは、WebアプリやAPIをホストするためのサービス
- IaaSで構成する場合:
Application Gateway <==> Webサーバ(VM) <==> Azure Load Balancer <==> SQL Server(VM)
- PaaSで構成する場合:
Application Gateway <==> Web Apps <==> SQL Database
- Azure App Serviceのカスタムドメインを設定できる(App Serviceドメイン)
-
スロット:
- 運用スロットとは別に専用のスロット(デプロイスロット)が利用できる。ステージング環境・検証環境としてデプロイできる
- スロットを入れ替える(スワップする)ことでバージョンに切り替えが素早くできる
- ただし、カスタムドメイン名やTLS証明書、スケールの設定などはスワップされない。それ以外のアプリの設定などがスワップされる
- App Serviceプランは、OSやリージョンに応じて作成する必要がある。
- OSはWindows環境、Linux環境、Docker環境の3種類のみ選択できる
- ログ記録:
- アプリケーションのログ記録:アプリケーションのコード実行にかかるメッセージのログが記録される
- Webサーバーのログ記録:HTTP要求データが取得される
- アプリのバックアップ・復元
- オンデマンドでカスタム バックアップを作成することや、スケジュールされたカスタムバックアップを構成することができる
- 既存のアプリを上書きするか、新しいアプリまたはスロットに復元することで、バックアップを復元できる
- バックアップ保持危険としては0〜30日間または無期限で設定が可能で、0に設定することで無期限にバックアップを保持可能となる
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と同様にコンテナの実行環境を提供するサービス
- 構成はAKSよりシンプルで、単一ポッドを提供するサービス
- 最上位のリソースは、コンテナグループ
- マルチコンテナグループ:1つの機能タスクを複数のコンテナーに分割する場合に利用する。Linuxコンテナーのみ対応
5-5. Azure Automation
-
Azure AutomationはAzure環境やAzure以外のクラウドサービス、オンプレミスに対して一貫した管理をサポートするサービス
- 構成管理:
- 変更履歴とインベントリ
-
Azure Automation State Configuration(PowerShell DSCのクラウドベースの実装)
- Azure AutomationにDSC構成をアップロードする
- DSC構成をコンパイルする
- Update Management:オンプレや仮想のOSの更新プログラムを管理する
- プロセスオートメーション:PowerShell、PowerShellワークフロー、グラフィカルRunbookを作成・管理できる
- 構成管理:
5-6. その他のコンピューティングサービス
- Azure Container Registryは、OSSのDocker Registry 2.0に基づくマネージドレジストリサービス
-
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内でリソースが安全に通信できる仮想のプライベートネットワーク
- 仮想マシンが利用するDNSサーバは、VNETのDNSサーバを指定する。
- VNETのアドレス空間は、作成後にも追加可能
-
ネットワークインターフェイス(NIC)は、仮想マシン(VM)が仮想ネットワーク(VNET)へ通信するためのインターフェイス
- 仮想マシンのNICの接続先VNETは変更できない
6-2. ネットワークセキュリティグループ (NSG)
- ネットワークセキュリティグループ (NSG) は、仮想ネットワーク(VNET)のサブネットや、仮想マシンのNICに設定するネットワークフィルター処理(ファイアウォール)
- 送受信トラフィックに対して、送信元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)の一覧を設定する。
-
DNAT規則:Azure FirewallのパブリックIPアドレスとポートを、プライベートIPアドレスに変換するDNATを構成できる。
6-4. Azure DNS
- Azure DNSは、AzureでDNSドメインをホストし、DNSドメインの名前解決を提供するサービス
- パブリックなDNSドメインに加えて、プライベートネットワーク内でのDNSレコード管理を提供するプライベートDNSゾーンもサポートされている。
- Azureサブスクリプションを作成すると、Microsoft Entra Domain Servicesのドメインが自動的に生成され、初期ドメインは Domain Name の後に「.onmicrosoft.com」が続く形式となる。
- カスタムドメインを登録するには、Microsoft Entra IDからカスタムドメインの追加を行う。
- 利用したいカスタムドメイン名をディレクトリに追加する
- ドメインレジストラーにDNS情報を追加する(DNSドメインの有効性確認用DNSレコードは、MXレコードかTXTレコードのどちらかを選択する)
- 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 VPN Gatewayの種類:
- サイト間VPN(S2S):オンプレのネットワークをVNETに接続する。複数拠点と接続するにはIKEv2トンネリングプロトコルが使用される。
- ポイント対サイトVPN(P2S):個々のデバイスをVNETに接続する
- VNet対VNet:VNETとVNETを接続する
6-7. Azure ExpressRouteとAzure Virtual WAN
- Azure ExpressRouteは、パブリックなインターネットを経由せずに接続プロバイダーが提供する専用線接続を経由して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リソースへ負荷分散させるサービス
- パブリックロードバランサー:インターネットからの通信を負荷分散する(例:Web用VMへの接続)
- 内部ロードバランサー:VNET内で通信を負荷分散する(例:DB用VMへの接続)
- セッション永続化:Webサービスへのアクセスをクライアントごとに同じWebサーバで処理させるときに有効化する。設定なし、クライアントIP、クライアントIPとプロトコル の3種類から指定する
-
正常性プローブ:アプリケーションの状態を監視する機能。
- 正常性チェックの応答結果に基づいて、自動でバックエンドインスタンスへの要求のルーティングを停止する。
-
インバウンドNAT規則(受信NAT規則):特定のポート番号宛の通信をバックエンドプールの特定のインスタンスへポート転送する機能
- インバウンドNAT規則を設定するときは、事前にフロントエンドIPアドレスの作成が必要
- バックエンドプールエンドポイント:
- Standard SKUのとき、「単一のVNET内の任意のVM」または「VMスケールセット」を転送先に指定できる
- Basic SKUのとき、「単一の可用性セット」または「VMスケールセット内のVM」を転送先に指定できる
- フロントエンドIPアドレス:
- 負荷分散規則を作成するときは、フロントエンドIPアドレスとバックエンドプールを事前に準備して、それらをバックエンドプールに設定する
-
HAポート(高可用性ポート):
- すべてのポートですべてのプロトコルフローを同時に負荷分散できる。ポートごとに1つずつ負荷分散規則を適用する必要がなくなる
- Azure Standard Load Balancerでのみ使用可
6-10. Azure Application Gateway
- Azure Application Gatewayは、WebアプリへのHTTP/HTTPS通信用のロードバランサ
- パスベースのルーティング:異なるURLパスの要求を異なるバックエンドサーバーのプールに送信できる
- マルチサイトのルーティング:同じApplication Gatewayのインスタンス上に複数のWebアプリケーションを構成できる
- Application Gatewayの構成要素
クライアント ==> Application Gateway ==> Web Application ==> HTTP/HTTPS ==> ルーティング ==> バックエンドプール フロントエンドIP Firewall リスナー 規則
6-11. その他のネットワークサービス
-
Azure Bastion:SSHやRDP接続できる踏み台サーバー
- Webブラウザーを使ったAzure Portalの画面経由でVMに接続できる
- ネイティブクライアント機能を有効化すると、ローカルコンピューターのネイティブクライアント(RDPやSSH)を使ってVNET内のVMに接続できる
- Azure Traffic Manager:DNSベースの負荷分散サービス。ドメインレベルで負荷分散する
- Azure Front Door:コンテンツ配信ネットワーク(CDN)、グローバルロードバランサー、Web Application Firewall (WAF) の機能を持つサービス
Azureの負荷分散サービスの比較:
サービス | グローバル/リージョン | 推奨トラフィック |
---|---|---|
Azure Front Door | グローバル | HTTP/HTTPS |
Traffic Manager | グローバル | HTTP/HTTPS以外 |
Application Gateway | リージョン | HTTP/HTTPS |
Azure Load Balancer | リージョン | HTTP/HTTPS以外 |
-
Azure NAT Gateway:フル マネージドで回復性の高いネットワーク アドレス変換 (NAT) サービス
- プライベートネットワーク内にあるVMからアウトバウンドインターネット接続が可能となる
7. Azureリソースの監視と管理
7-1. Azure Backup
- Azure Backupサービスは、Azure上のVMのデータやDBだけでなく、オンプレのデータもAzureにバックアップできるマネージドサービス
- バックアップデータは、Recovery Servicesコンテナ(Recovery Services Vault)もしくはBackup VaultというAzureのストレージに保存・管理する
- Recovery Serviceコンテナは保護対象の仮想マシンと同じリージョンである必要がある
- 1つのRecovery Serviceコンテナは複数のリソースからのバックアップに利用できる
- バックアップできるデータの概要:
- 仮想マシン(VM):
- 全体バックアップ(復元時は「VMの復元」を選択する)
- VMの復元先はバックアップ元VMか新規VMのいずれかを選択する。OLR (元の場所への復旧) または ALR (別の場所への復旧)を選択する
- フォルダー・ファイル単位(復元時は「ファイルの回復」を選択する)
- ファイルの復元方法は、Azure Portalからファイルを参照して回復するためのスクリプトをダウンロードし、そのスクリプトを実行しディスクを任意のPCのドライブにマウントすることでファイルを復元できる
- 仮想マシン上で実行されているDB
- 全体バックアップ(復元時は「VMの復元」を選択する)
- ディスク(Azureディスク)
- ストレージ:
- Azureファイル共有
- Azure BLOB
- オンプレミス(オンプレ上のサーバー)
- 仮想マシン(VM):
- 仮想マシンのバックアップ:
- 最初のバックアップ時に仮想マシンに拡張機能がインストールされる
- VMは起動中でも停止中でもどちらでもバックアップが実行できる
- ストレージレプリケーションの設定:
- ローカル冗長(LRS):1つの物理的な場所でデータを同期的に3回コピー
- ゾーン冗長(ZRS):リージョンの3つの可用性ゾーン間でデータを同期的にコピー
- Geo冗長(GRS):LRSを使用してリージョンに1つの物理的な場所でデータを同期的に3回コピーし、その後、セカンダリリージョン内の1つの物理的な場所にデータを非同期にレプリケートする
-
バックアップポリシーは、バックアップを定期的に取得するバックアップスケジュール設定。
- バックアップの頻度は「毎日」か「毎週」から選択できる
- オンデマンドバックアップは、任意のタイミングでバックアップを取得できる。一方で、定期的にバックアップするときはバックアップポリシーを設定する
- RPOとRTO:
- RPO(目標復旧時点)は最短でも24時間
- RTO(目標復旧時間)は数時間(データに依存する)
- データを保護したいだけであればAzure Backupを使用する
- バックアップデータの整合性対策として、Linuxの場合はスナップショット作成前後に任意のスクリプトでサービスの停止・再開を実行できる。
- Recovery Servicesコンテナは、仮想マシンなどのバックアップするデータソースと同じリージョンに作成する
- バックアップに必要な権限として、バックアップ共同作成者またはバックアップオペレーターのロールが必要
- 拡張ポリシーを使用してVMをバックアップする場面:
- 暗号化された仮想マシンのとき
- トラステッド起動の仮想マシンのとき
- 「既存の復元構成を置き換える」オプション:
- ファイル復元時に、既存の復元構成を復元して、それを使用して既存のVM上のディスクの内容を置き換えることができる
- 「ディスクを復元する」とは異なり、ディスク上のファイルを直接置き換えるため、VMの再起動が不要となる
7-2. Azure Site Recovery
- Azure Site Recoveryは、データセンターの大規模災害や障害から仮想マシンを保護し、セカンダリリージョンへのワークロードをレプリケートできるDR(ディザスターリカバリー)サービス
- 復旧するセカンダリリージョンにRecovery Servicesコンテナを作成する必要がある。
- RPOとRTO:
- RPO(目標復旧時点)は最短で1時間
- RTO(目標復旧時間)は数分(SLA上では2時間)
- サイトの稼働率を維持したいときはAzure Site Recoveryを使用する
7-3. Azure Monitor
- Azure Monitorは、オンプレおよびクラウド環境の性能を監視、アプリ監視、ログ監視などの機能が統合されたフルマネージドサービス
-
メトリックとは、リソースの健全性を測定するための使用される指標のこと。
- 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リソース、メトリック、ログの監視など)に特化した監視・確認を行うためのネットワーク診断ツール
- Network Watcherの機能:
- 監視:
- トポロジー
-
接続モニター:仮想マシン(VM)間の通信を監視できる。
- 接続モニターは仮想マシンを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のコストの確認・監視と最適化を行うツール
- 「アドバイザーの推奨事項」にはコスト削減に役立つ推奨事項が提示される。例えば、VMのサイズ変更や未使用VMのシャットダウンなど
- 割引特典:
- Azure Reserved Instances:1年または3年の利用をコミットすること予約割引によるコスト削減ができるオプション
- Azureハイブリット特典:ソフトウェアアシュアランス(SA)のある既存のオンプレのWindows Server、SQL ServerおよびLinuxのライセンスをAzureで利用することで、仮想マシンの実行コストを大幅に削減できる特典
- スポットVM:Azureにおいてその時点で未使用となっているため安価で提供される仮想マシン
- Azure開発 / テスト価格:Visual Studioのサブスクリプションの所有者限定で開発・テスト用の従量課金プランが用意されている