0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nvtomo1029

Microsoft Certified: Azure Administrator Associate(AZ-104)で求められる知識を整理する

0
Posted at

■0.はじめに

以下の資格を取得しました。

Microsoft Certified: Azure Administrator Associate(AZ-104)

Associateクラスの資格としては、Microsoft Certified: Azure AI Engineer Associateに続いて2つ目の取得となります。

本記事は、資格取得の過程で得た自身の知識の整理、定着化を狙って作成したものです。
今後、資格取得を目指している方のお役に立てれば幸いです。

記載しております内容は、資格を取得した2025年8月頃の情報を元にしておりますことご承知おきください。

■1.Microsoft Certified: Azure Administrator Associate(AZ-104)とは？

マイクロソフト認定: Azure管理者アソシエイト - Certifications | Microsoft Learn

■2.私が行った試験対策

1.Microsoft LearnのAZ-104のコースを一通り受講

コース AZ-104T00-A:Microsoft Azure 管理者 - Training | Microsoft Learn

こちらのコースを一通り読み込みました。
演習までは実施していません。

2.Udemyの試験対策講座、試験対策問題集を受講

Udemy Businessを所属会社で契約しており、無料で受講することができました。

  • まずは試験対策講座を1講座受講
  • 試験対策問題集を3講座受講し、内2講座は2周して仕上げ
  • 問題集の解説から理解が不足している箇所はMicrosoftサイトの該当ページで復習

■3.受験した感想

Udemyの試験対策問題集の口コミでも同じ感想がありましたが、同じ問題はほとんど出題されず、想定していたよりも難しく感じました。
ただ、似たような問題はそれなりにあり、出題内容としては似通ってなくても問題集を解いたことで得た知識で解ける問題も多かった印象です。

私は使わなかったので、どういう感じなのかは不明ですが、試験中にMicrosoft Learnで調べることができるようでした。
後で調べたい問題に見直しマークをつけておいて、一通り回答した後の残り時間を活用してという使い方もできそうでした。
ただ、最後のセクションに入ると戻れないので、その点は注意が必要です。

■4.学習メモ

試験 AZ-104 の学習ガイド: Microsoft Azure Administrator | Microsoft Learn

以下からまとめる学習メモの章立ては学習ガイドに準じております。

  • Azure ID とガバナンスを管理する (20 から 25%)
  • ストレージを実装して管理する (15 から 20%)
  • Azure のコンピューティング リソースをデプロイおよび管理する (20 - 25%)
  • 仮想ネットワークを実装および管理する (15 から 20%)
  • Azure リソースの監視と管理 (10 - 15%)

■1.Azure ID とガバナンスを管理する (20 から 25%)

■1.1.Microsoft Entra のユーザーとグループを管理する

■1.1.1.ユーザーとグループを作成する

■1.1.1.ユーザーとグループを作成する

https://learn.microsoft.com/ja-jp/entra/fundamentals/how-to-create-delete-users

https://learn.microsoft.com/ja-jp/training/modules/create-configure-manage-identities/

https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-mfa-mfasettings

  • 多要素認証（MFA）は、アプリケーションなどへのアクセスする前に、ユーザに2つ以上の認証要素の提供を求める認証方法のことである
  • 毎回、MFAを認証すると面倒なため、Azureの多要素認証を記憶する機能を使うと、ユーザーが一度MFA を使って正常にサインインした後は指定された日数の間、MFA認証をバイパス（認証を求められない）することができる
  • Azure portal の Microsoft Entra のMulti-Factor Authentication 設定ページにおいて、信頼できるデバイスが多要素認証をバイパスすることを強制する日数を設定することができる
■1.1.2.ユーザーとグループのプロパティを管理する

■1.1.2.ユーザーとグループのプロパティを管理する

https://learn.microsoft.com/ja-jp/entra/fundamentals/how-to-manage-groups

https://learn.microsoft.com/ja-jp/entra/identity/users/groups-dynamic-membership

■1.1.3.Microsoft Entra ID でライセンスを管理する

■1.1.3.Microsoft Entra ID でライセンスを管理する

https://learn.microsoft.com/ja-jp/entra/id-governance/entitlement-management-group-licenses

https://learn.microsoft.com/ja-jp/training/modules/understand-azure-active-directory/

Microsoft Entra Privileged Identity Management とは

Privileged Identity Management (PIM) は Microsoft Entra ID のサービスで、これにより、お客様の組織内の重要なリソースへのアクセスを管理、制御、監視できるようになる。
これらのリソースには、Microsoft Entra ID、Azure、および Microsoft 365 や Microsoft Intune などのその他の Microsoft Online Services 内のリソースが含まれる。

Privileged Identity Management (PIM) を使うと、Microsoft Entra 組織で、ロールが割り当てられたり、アクティブ化されたりした場合などの重要なイベントがいつ発生したかを知ることができる。
Privileged Identity Management では、自分やその他の参加者に電子メール通知が送信されるため、常に最新情報を取得できる。

Privileged Identity Management を使用するには、Microsoft Entra ID P2以上のライセンスが必要である。

Microsoft Entra IDライセンス別の機能

■1.1.4.外部ユーザーを管理する

■1.1.4.外部ユーザーを管理する

https://learn.microsoft.com/ja-jp/azure/role-based-access-control/role-assignments-external-users

https://learn.microsoft.com/ja-jp/entra/external-id/b2b-quickstart-add-guest-users-portal

■1.1.5.セルフサービス パスワード リセット (SSPR) を構成する

■1.1.5.セルフサービス パスワード リセット (SSPR) を構成する

https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-sspr-howitworks

https://learn.microsoft.com/ja-jp/training/modules/allow-users-reset-their-password/

■1.2.Azure のリソースへのアクセスの管理

■1.2.1.組み込みの Azure ロールを管理する

■1.2.1.組み込みの Azure ロールを管理する

  • Azure ロールベースのアクセス制御 (Azure RBAC) には、ユーザー、グループ、サービス プリンシパル、マネージド ID に割り当てることのできる Azure 組み込みロールがいくつか用意されている
  • ロールの割り当ては、Azure リソースへのアクセスを制御する方法である
  • 組み込みロールが組織の特定のニーズを満たさない場合は、独自の Azure カスタム ロールを作成することができる
  • Azure 組み込みロールの一覧は以下参照

https://learn.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles

■1.2.2.異なるスコープでロールを割り当てる

■1.2.2.異なるスコープでロールを割り当てる

https://learn.microsoft.com/ja-jp/azure/role-based-access-control/role-assignments-portal

  • Azure PowerShell を使用して Azure カスタム ロールを作成する

    • Azure の組み込みロールが組織の特定のニーズを満たさない場合は、独自のカスタム ロールを作成することができる
    • カスタム ロールを作成するには、組み込みのロールから始めて、そのロールを編集して新しいロールを作成するのが最も簡単である
    • Get-AzRoleDefinition コマンドを使用して、元にする組み込みロールを JSON 形式で出力
    • JSONファイルを編集し、カスタムロールを作成
      • AssignableScopes に、"/subscriptions/00000000-0000-0000-0000-000000000000" 形式でサブスクリプション ID を追加
      • Id プロパティ行を削除し、IsCustom プロパティを true に変更
      • Name プロパティと Description プロパティを、それぞれ今回作成するカスタムロールに合わせて変更
    • 新しいカスタム ロールを作成するには、New-AzRoleDefinition コマンドを使用して、JSON ロール定義ファイルを指定する

  • ユーザーは独自のAzure カスタム ロールを作成して管理グループ、サブスクリプション、リソースグループの範囲に割り当てることができる

  • また、カスタム ロールは Microsoft Entra ディレクトリに保存され、サブスクリプション間で共有することができる

  • Azure portalを利用してカスタムロールの割当スコープを変更する場合は、[割り当て可能なスコープ] タブで、管理グループ、サブスクリプション、リソース グループなど、カスタム ロールを割り当てることができる場所を指定し、そこでスコープの削除または追加を行う

■1.2.3.アクセス割り当てを理解する

■1.2.3.アクセス割り当てを理解する

https://learn.microsoft.com/ja-jp/azure/role-based-access-control/overview

https://learn.microsoft.com/ja-jp/training/modules/secure-azure-resources-with-rbac/

Azure ロールの定義について
  • ロール定義は、アクセス許可のコレクションである
  • 単にロールと呼ばれることもある
  • ロール定義には、実行できるアクション (読み取り、書き込み、削除など) が登録されている
  • また、許可されるアクション、あるいは基となるデータに関連するアクションから除外されるアクションを一覧表示することもできる
Azure PowerShell を使用して表示される場合のロールの定義のプロパティの例
Name
Id
IsCustom
Description
Actions []
NotActions []
DataActions []
NotDataActions []
AssignableScopes []
Condition
ConditionVersion

DataActions アクセス許可では、対象のオブジェクト内のデータに対して、ロールで実行できるデータ プレーン アクションを指定する。
たとえば、ユーザーがあるストレージ アカウントへの BLOB データの読み取りアクセス許可を持っている場合、そのユーザーはそのストレージ アカウント内の BLOB を読み取ることができる。

DataActionsの例

  • Microsoft.Compute/virtualMachines/login/action
    • この設定は、仮想マシンに通常のユーザーとしてログインするアクションを許可する
  • Microsoft.HybridCompute/machines/login/action
    • この設定は、通常のユーザーとして Azure Arc マシンにログインするアクションを許可する

■1.3.Azure のサブスクリプションとガバナンスを管理する

■1.3.1.Azure Policy を実装して管理する

■1.3.1.Azure Policy を実装して管理する

Azure Policy では、Azure 内のリソースのプロパティをビジネス ルールと比較して、それらのリソースとアクションを評価する。
JSON 形式で記述されるこれらのビジネス ルールは、ポリシー定義と呼ばれる。
管理を容易にするために、複数のビジネス ルールをグループ化して、ポリシー イニシアティブ (policySet とも呼ばれる) を作成できる。
ビジネス ルールを作成すると、ポリシーの定義またはイニシアティブは、Azure でサポートされているリソース (管理グループ、サブスクリプション、リソース グループ、個々のリソースなど) の任意のスコープに割り当てられる。
ルート管理グループ（テナントルートグループ）にも割り当てられる。
割り当ては、その割り当ての Resource Manager スコープ内のすべてのリソースに適用される。

Azure Policy では、リソースが準拠しているかどうかを特定するために評価で使用されるロジックの作成に、JSON 形式を使用する。
定義には、メタデータとポリシー規則が含まれている。
定義される規則では、目的とするシナリオに正確に合わせて関数、パラメーター、論理演算子、条件、プロパティの別名を使用できる。
ポリシー規則によって、割り当てのスコープ内のどのリソースが評価されるかが決定される。

https://learn.microsoft.com/ja-jp/training/modules/sovereignty-policy-initiatives/

■1.3.2.リソース ロックを構成する

■1.3.2.リソース ロックを構成する

管理者であれば、Azure サブスクリプション、リソース グループ、またはリソースをロックして、ユーザーの不注意による削除や変更から保護できる。
ロックは、すべてのユーザー アクセス許可をオーバーライドする。

削除または変更のいずれかを防止するロックを設定できる。
ポータルでは、これらのロックは [削除] と [読み取り専用] と呼ばれる。
コマンド ラインでは、これらのロックは CanNotDelete および ReadOnly と呼ばれる。

  • CanNotDelete：
    • 正規ユーザーはリソースの読み取りと変更を実行できるが、削除ができないことを示す
  • ReadOnly：
    • 正規ユーザーはリソースの読み取りを実行できるが、削除または更新ができないことを示す
    • このロックの適用は、すべての正規ユーザーのアクセス許可を、閲覧者ロールで指定されるアクセス許可に制限することに似ている

管理ロックを使用すると、ロールベースのアクセス制御 (RBAC) とは異なり、すべてのユーザーとロールに対して制限を適用できる。

親スコープでロックを適用すると、そのスコープ内のすべてのリソースは同じロックを継承する。
後で追加するリソースも、同じ親ロックを継承する。
継承チェーン中で最も制限の厳しいロックが優先される。

管理ロックを作成または削除するには、Microsoft.Authorization/* または Microsoft.Authorization/locks/* アクションにアクセスする必要がある。
所有者とユーザー アクセス管理者ロールに割り当てられているユーザーには、必要なアクセス権がある。
一部の特殊な組み込みロールにも、このアクセスが許可される。
必要な権限を含むカスタム ロールを作成することができる。

リソース ロックによって、サブスクリプションの取り消しはブロックされない。

管理グループにロックを追加することはできない。

■1.3.3.リソースに対するタグの適用と管理

■1.3.3.リソースに対するタグの適用と管理

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/tag-resources?tabs=json#inherit-tags

タグは、Azure リソースに適用するメタデータ要素である。
これらは、組織に関連する設定に基づいてリソースを識別するのに役立つキーと値のペアである。
リソースのデプロイ環境を追跡する場合は、Environment という名前のキーを追加する。
運用環境にデプロイされたリソースを識別するには、それらに Production という値を付与する。

Azure のリソース、リソース グループ、サブスクリプションにはタグを適用できるが、管理グループには適用できない。

タグ リソースへの必要なアクセスを取得するには、2 つの方法がある。

  • 1.Microsoft.Resources/tags リソースの種類に対する書き込みアクセス権を持つこと
    • このアクセス権により、リソース自体にアクセスできない場合でも、任意のリソースにタグを付けることができる
    • タグ共同作成者ロールでは、このアクセス権が付与される
  • 2.リソース自体に対する書き込みアクセス権を持つこと
    • 共同作成者ロールでは、任意のエンティティにタグを適用するために必要なアクセス権が付与される
    • 1 つのリソースの種類だけにタグを適用するには、そのリソースの共同作成者ロールを使用する
    • 仮想マシンにタグを適用するには、仮想マシン共同作成者ロールを使用する
    • リソースは、リソース グループまたはサブスクリプションに適用するタグを継承しない

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/tag-policies

■1.3.4.リソース グループの管理

■1.3.4.リソース グループの管理

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/manage-resource-groups-portal

■1.3.5.サブスクリプションの管理

■1.3.5.サブスクリプションの管理

https://learn.microsoft.com/ja-jp/azure/cost-management-billing/manage/add-change-subscription-administrator

https://learn.microsoft.com/ja-jp/azure/cost-management-billing/manage/manage-azure-subscription-policy

■1.3.6.アラート、予算、Azure Advisor 推奨事項を使用してコストを管理する

■1.3.6.アラート、予算、Azure Advisor 推奨事項を使用してコストを管理する

https://learn.microsoft.com/ja-jp/azure/cost-management-billing/understand/plan-manage-costs

https://learn.microsoft.com/ja-jp/azure/advisor/advisor-cost-recommendations

■1.3.7.管理グループを構成する

■1.3.7.管理グループを構成する

https://learn.microsoft.com/ja-jp/azure/governance/management-groups/manage

https://learn.microsoft.com/ja-jp/azure/governance/management-groups/overview

組織に多くの Azure サブスクリプションがある場合は、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要になることがある。
管理グループのガバナンス範囲は、サブスクリプションを上回る。
サブスクリプションを管理グループにまとめると、適用するガバナンス条件は関連付けられているすべてのサブスクリプションへの継承によりカスケード表示される。

管理グループを使うと、サブスクリプションの種類に関係なく、エンタープライズ レベルの管理を大規模に行うことができる。
ただし、単一の管理グループ内のすべてのサブスクリプションは、同じ Microsoft Entra テナントを信頼する必要がある。

管理グループを使用するもう 1 つのシナリオは、ユーザーに複数のサブスクリプションへのアクセスを提供する場合である。
管理グループの下に複数のサブスクリプションを移動することで、管理グループに 1 つの Azure ロールの割り当てを作成できる。
ロールは、そのアクセス権をすべてのサブスクリプションに継承する。

各ディレクトリには、"ルート" 管理グループと呼ばれる 1 つの最上位管理グループがある。
このルート管理グループは階層に組み込まれており、すべての管理グループとサブスクリプションはルート管理グループにまとめられる。
ルート管理グループは、ディレクトリ レベルで、グローバル ポリシーと Azure ロールの割り当てを適用できる。

■2.ストレージを実装して管理する (15 から 20%)

■2.1.ストレージへのアクセスを構成する

■2.1.1.Azure Storage ファイアウォールおよび仮想ネットワークを構成する

■2.1.1.Azure Storage ファイアウォールおよび仮想ネットワークを構成する

Azure Storage のファイアウォール規則

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security

Azure Storage ファイアウォール規則では、ストレージ アカウントのパブリック エンドポイントへのネットワーク アクセスをきめ細かく制御できる。
既定では、ストレージ アカウントは任意のネットワークからの接続を許可するが、ストレージ アカウントに接続できるソースを定義するネットワーク ルールを構成することで、アクセスを制限できる。

次の 4 種類のネットワーク 規則を構成できる。

  • 仮想ネットワークルール:
    • Azure Virtual Network 内の特定のサブネットからのトラフィックを許可する
  • IP ネットワーク規則:
    • 特定のパブリック IP アドレス範囲からのトラフィックを許可する
  • リソース インスタンス ルール:
    • 仮想ネットワークまたは IP 規則を使用して分離できない特定の Azure リソース インスタンスからのトラフィックを許可する
  • 信頼されたサービスの例外:
    • ネットワーク境界外で動作する特定の Azure サービスからのトラフィックを許可する
■2.1.2.Shared Access Signature (SAS) トークンを作成して使用する

■2.1.2.Shared Access Signature (SAS) トークンを作成して使用する

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-sas-overview

Shared Access Signature (SAS) を使用すると、ストレージ アカウント内のリソースへのセキュリティで保護された委任アクセスが可能になる。
SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できる。

  • クライアントがアクセスできるリソース
  • それらのリソースに対するアクセス許可
  • SAS が有効である期間

Azure Storage では、次の 3 種類の Shared Access Signature がサポートされている。

ユーザー委任 SAS

ユーザー委任 SAS は、Microsoft Entra 資格情報によって保護されるだけではなく、SAS に指定されたアクセス許可によっても保護される。
ユーザー委任 SAS は、Blob Storage と Data Lake Storage でサポートされており、blob エンドポイントと dfs エンドポイントへの呼び出しに使用できる。
現在、Queue Storage、Table Storage、または Azure Files ではサポートされていない。

Service SAS (サービス SAS)

サービス SAS は、ストレージ アカウント キーで保護される。
サービス SAS では、Blob Storage (Data Lake Storage および dfs エンドポイントを含む)、Queue Storage、Table Storage、または Azure Files のいずれかの Azure Storage サービスでのみリソースへのアクセスが委任される。

アカウント SAS

アカウント SAS は、ストレージアカウント キーで保護される。
アカウント SAS は、1 つ以上のストレージ サービスのリソースへのアクセスを委任する。
サービスまたはユーザー委任 SAS を介して実行できるすべての操作は、アカウント SAS を介しても実行できる。

以下へのアクセスを委任することもできる。

  • サービスレベルの操作 (Get/Set Service Properties および Get Service Stats 操作など)
  • サービス SAS で許可されていない読み取り、書き込み、削除の各操作
Shared Access Signature の形式
  • アドホック SAS
    • アドホック SAS を作成すると、開始時刻、有効期限、およびアクセス許可が SAS URI で指定される
    • 任意の種類の SAS を、アドホック SAS にできる
    • ユーザー委任 SAS またはアカウント SAS はアドホック SAS である必要がある
  • 保存されているアクセス ポリシーによるサービス SAS
    • 保存されているアクセス ポリシーは、リソース コンテナー (BLOB コンテナー、テーブル、キュー、ファイル共有など) で定義されている
    • 保存されているアクセス ポリシーを使用して、1 つ以上の Shared Access Signature の制約を管理できる
    • 保存されているアクセス ポリシーにサービス SAS を関連付けると、SAS が、保存されているアクセス ポリシーに定義されている制約 (開始時刻、有効期限、およびアクセス許可) を継承する
    • ユーザー委任 SAS またはアカウント SAS ではサポートされていない
■2.1.3.保存されているアクセス ポリシーを構成する

■2.1.3.保存されているアクセス ポリシーを構成する

保存されているアクセス ポリシーを使用すると、サーバー側でのサービス レベルの共有アクセス署名 (SAS) をさらに制御できる。
保存されているアクセス ポリシーを定義することで、共有アクセス署名をグループ化し、ポリシーにバインドされている共有アクセス署名に対して追加の制限を設定できる。
保存されているアクセス ポリシーを使用して、SAS の開始時刻、有効期限、アクセス許可の変更や、その発行後の取り消しを実行できる。

次の Azure Storage リソースでは、保存されているアクセス ポリシーがサポートされる。

  • BLOB コンテナー
  • ファイル共有
  • キュー
  • テーブル

保存されているアクセス ポリシーは、サービス SAS に対してのみサポートされる。
保存されているアクセス ポリシーは、アカウント SAS またはユーザー委任 SAS ではサポートされない。

■2.1.4.アクセス キーを管理する

■2.1.4.アクセス キーを管理する

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-account-keys-manage?tabs=azure-portal

■2.1.5.Azure Files の ID ベースのアクセスを構成する

■2.1.5.Azure Files の ID ベースのアクセスを構成する

https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-active-directory-overview

■2.2.ストレージ アカウントを構成して管理する

■2.2.1.ストレージ アカウントの作成および構成

■2.2.1.ストレージ アカウントの作成および構成

ストレージ アカウントの種類

  • Standard 汎用 v2
    • BLOB、ファイル共有、キュー、テーブル用の Standard タイプのストレージ アカウント
    • Azure Files の ネットワーク ファイル システム (NFS) のサポートが必要な場合は、Premium ファイル共有タイプのアカウントを使用する
  • Premium ブロック BLOB
    • ブロック BLOB と追加 BLOB 用の Premium タイプのストレージ アカウント
  • Premium ファイル共有
    • ファイル共有専用の Premium タイプのストレージ アカウント
  • Premium ページ BLOB
    • ページ BLOB に特化した Premium Storage アカウント

ストレージ アカウントの作成

■2.2.2.Azure Storage の冗長性を構成する

■2.2.2.Azure Storage の冗長性を構成する

Azure Storage は、計画的および計画外のイベントからデータを保護するために、データの複数のコピーを常に保存する。
これらのイベントの例には、一時的なハードウェア障害、ネットワークまたは停電、大規模な自然災害などが含まれる。
冗長性を確保することで、障害が発生した場合でも、ストレージ アカウントが可用性と耐久性に関する目標を確実に達成できる。

冗長性オプションを選択するかの判断に役立つ要因
  • プライマリ リージョンでのデータのレプリケート方法
  • 地域災害から保護するために、データをプライマリ リージョンから地理的に離れた 2 つ目のリージョンにレプリケートするかどうか (geo レプリケーション)
  • プライマリ リージョンで障害が発生した場合に、アプリケーションがセカンダリ リージョンのレプリケートされたデータへの読み取りアクセス権を必要とするかどうか (読み取りアクセス権付きの geo レプリケーション)
プライマリ リージョンでの冗長性
  • ローカル冗長ストレージ (LRS)
    • プライマリ リージョンの 1 つの物理的な場所 (データセンター) 内でデータを 3 回レプリケートする
    • 可用性ゾーン間ではレプリケートされない
  • ゾーン冗長ストレージ (ZRS)
    • プライマリ リージョンの 3 つの Azure 可用性ゾーン間でデータを同期的にコピーする
    • 高可用性を必要とするアプリケーションでは、プライマリ リージョンで ZRS を使用し、セカンダリ リージョンにもレプリケートすることを推奨している
セカンダリ リージョンでの冗長性
  • geo 冗長ストレージ (GRS)
    • LRS を使用してプライマリ リージョンにある 1 つ以上の Azure Availability Zones 内にデータを 3 回同期的にコピーする
    • その後、セカンダリ リージョンの 1 つの物理的な場所にデータを非同期的にコピーする
    • セカンダリ リージョン内のデータは、LRS を使用して同期的に 3 回コピーされる
  • geo ゾーン冗長ストレージ (GZRS)
    • ZRS を使用して、プライマリ リージョンの 3 つの Azure 可用性ゾーン間でデータを同期的にコピーする
    • その後、セカンダリ リージョンの 1 つの物理的な場所にデータを非同期的にコピーする
    • セカンダリ リージョン内のデータは、LRS を使用して同期的に 3 回コピーされる
セカンダリ リージョンのデータへの読み取りアクセス
  • geo 冗長ストレージ (GRS または GZRS を使用) は、リージョン障害から保護するために、セカンダリ リージョンの別の物理的な場所にデータをレプリケートする
  • GRS または GZRS 用に構成されたアカウントでは、プライマリ リージョンで障害が発生した場合、フェールオーバーが発生しない限り、セカンダリ リージョンのデータにはユーザーやアプリケーションから直接アクセスできなくなる
  • アプリケーションで高可用性が必要な場合は、セカンダリ リージョンへの読み取りアクセス用にストレージ アカウントを構成できる
  • セカンダリ リージョンへの読み取りアクセスを有効にすると、プライマリ リージョンが使用できなくなる状況を含め、読み取りにおいてセカンダリからのデータを使用することができる
  • 読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) 構成によって、セカンダリ リージョンへの読み取りアクセスが許可される
  • Azure Files では、読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) はサポートされていない
■2.2.3.オブジェクト レプリケーションの構成

■2.2.3.オブジェクト レプリケーションの構成

https://learn.microsoft.com/ja-jp/azure/storage/blobs/object-replication-configure?tabs=portal

  • オブジェクト レプリケーションを使用すると、ソース ストレージ アカウントと宛先アカウントの間でブロック BLOB を非同期にコピーできる
  • オブジェクト レプリケーションを構成するときに、ソース ストレージ アカウントと宛先アカウントを指定するレプリケーション ポリシーを作成する
  • ソース アカウントと宛先アカウントは、汎用 v2 ストレージ アカウントまたは Premium ブロック BLOB アカウントのいずれかにできる
  • オブジェクトのレプリケーションでは、ソース アカウントと宛先アカウントの両方で BLOB のバージョン管理が有効になっている必要がある
  • また、ソース アカウントで BLOB の変更フィードが有効になっている必要もある
■2.2.4.ストレージ アカウントの暗号化を構成する

■2.2.4.ストレージ アカウントの暗号化を構成する

Azure portal では、暗号化の種類を指定することで、Azure Storage の暗号化を構成する。
キーは自分で管理するか、Microsoft にキーの管理を任せることができる。
暗号化を実装する方法にはいくつかある。

  • インフラストラクチャの暗号化
    • ストレージ アカウント全体に対して、またはアカウント内の暗号化スコープに対して有効にすることができる
    • ストレージ アカウントまたは暗号化スコープに対してインフラストラクチャ暗号化を有効にすると、データは 2 つの異なる暗号化アルゴリズムと 2 つの異なるキーで 2 回 (サービス レベルで 1 回と、インフラストラクチャ レベルで 1 回) 暗号化される
  • プラットフォーム マネージド キー (PMK)
    • Azure によって完全に生成、保存、管理される暗号化キーである
    • 利用者が PMK を操作することはない
    • たとえば、 Azure Data Encryption-at-Rest に使用されるキーは、既定で PMK である
  • カスタマー マネージド キー(CMK)
    • 1 人以上の利用者によって読み取り、作成、削除、更新、管理が行われるキーである
    • 利用者所有のキー コンテナーまたはハードウェア セキュリティ モジュール (HSM) に保存されているキーは CMK である
    • Bring Your Own Key (BYOK) は、利用者が外部の保存場所からキーをインポートする (持ち込む) CMK シナリオである
    • カスタマーマネージドキーによる暗号化では、2048、3072、および 4096 のサイズの RSA および RSA-HSM キーがサポートされている
BLOB ストレージの暗号化スコープ

暗号化スコープを使用すると、コンテナーまたは個々の BLOB にスコープ設定されたキーで暗号化を管理できる。
暗号化スコープを使用すると、異なる顧客が所有する、同じストレージ アカウントに存在するデータの間にセキュリティで保護された境界を作成できる。

既定では、ストレージ アカウントは、そのストレージ アカウント全体をスコープとするキーで暗号化される。
暗号化スコープを定義するときは、コンテナーまたは個々の BLOB にスコープ設定できるキーを指定する。
暗号化スコープが BLOB に適用されると、BLOB はそのキーで暗号化される。
暗号化スコープがコンテナーに適用されると、そのコンテナー内の BLOB の既定のスコープとして機能する。

■2.2.5.Azure Storage Explorer と AzCopy を使用してデータを管理する

■2.2.5.Azure Storage Explorer と AzCopy を使用してデータを管理する

AzCopy は、ストレージ アカウント間の BLOB またはファイル コピーに利用できるコマンドライン ユーティリティである。

Azure Storage Explorerは、AzCopy を使用してすべてのデータ転送操作を実行する。
AzCopy のパフォーマンス上の利点を適用する場合は Storage Explorer を使用できるが、ファイルの操作にはコマンド ラインではなくグラフィカル ユーザー インターフェイスを使用することを推奨している。

Storage Explorer では、ご自分のアカウント キーを使用して、操作を実行するため、Storage Explorer にサインインした後は、追加の承認資格情報を提供する必要はない。

Azure Import/Export サービス

https://learn.microsoft.com/ja-jp/azure/import-export/storage-import-export-data-to-files?tabs=azure-portal-preview

  • Azure Import/Export サービスでは、Azure データセンターにディスク ドライブを送付することで、Azure Blob Storage と Azure Files に大量のデータを安全にインポートできる
  • また、このサービスでは、Azure Blob Storage からディスク ドライブにデータを転送し、オンプレミスのサイトに送付できる
  • 1 つまたは複数のディスク ドライブからのデータを、Azure Blob Storage または Azure Files にインポートできる
  • エクスポートはAzure Blob Storageのみ利用可能である
  • 手順
    • (1)OnVM-Aのホストサーバーに外付けディスクを取り付けて、waimportexport.exe を実行する
    • (2)Azure Portalから、Azure Import / Exportサービスを使用してVMのインポートジョブを作成する
    • (3)OnVM-A のホストサーバーから外付けディスクを切り離し、Azure データセンターに接続する
    • (4)Azure Portalから、Azure Import / Exportサービスを使用してVMのインポートジョブを更新する

■2.3.Azure Files と Azure Blob Storage を構成する

■2.3.1.Azure Storage でファイル共有を作成して構成する

■2.3.1.Azure Storage でファイル共有を作成して構成する

  • Azure ファイル共有がホストされている Azure リージョンの外の Azure ファイル共有 (オンプレミスの共有、他の Azure リージョン内の共有など) をパブリック エンドポイント経由で使用するために、OS は SMB 3.x をサポートしている必要がある
  • SMBプロトコルはTCPポート445が開いている必要があるため、ポート445がブロックされている場合、接続は失敗する
■2.3.2.Blob Storage でコンテナーを作成して構成する

■2.3.2.Blob Storage でコンテナーを作成して構成する

https://learn.microsoft.com/ja-jp/azure/storage/blobs/blob-containers-portal

■2.3.3.ストレージ層を構成する

■2.3.3.ストレージ層を構成する

  • ホット、クール、アーカイブなどのストレージデータ階層はBlob Storage および汎用 v2 (GPv2) アカウントのみでサポートされている
■2.3.4.BLOB とコンテナーの論理的な削除を構成する

■2.3.4.BLOB とコンテナーの論理的な削除を構成する

https://learn.microsoft.com/ja-jp/azure/storage/blobs/soft-delete-blob-overview

https://learn.microsoft.com/ja-jp/azure/storage/blobs/soft-delete-container-overview

■2.3.5.Azure Files のスナップショットと論理的な削除を構成する

■2.3.5.Azure Files のスナップショットと論理的な削除を構成する

https://learn.microsoft.com/ja-jp/azure/storage/files/storage-snapshots-files?tabs=portal

https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-prevent-file-share-deletion?tabs=azure-portal

  • Azure File Sync

    • Azure File Sync を使用することで、Windows ファイル サーバーの柔軟性、パフォーマンス、互換性を維持しながら、Azure Files で組織のファイル共有を一元化できる
    • Azure File Sync にはさらに、Windows Server を Azure ファイル共有のクイック キャッシュに変換する機能がある
    • SMB、NFS、FTPS など、Windows Server 上で利用できるあらゆるプロトコルを使用して、データにローカルにアクセスできる

  • Azure File Sync の利点

    • クラウドを使った階層化
      • クラウド階層化を有効にすると、最も頻繁にアクセスされるファイルがローカル サーバーにキャッシュされ、アクセス頻度が最も低いファイルはクラウドに階層化される
    • マルチサイト アクセスと同期
      • 各オフィスについて、Azure File Sync のデプロイの一部としてローカルの Windows Server をプロビジョニングできる
      • あるオフィスでサーバーに加えられた変更は、他のすべてのオフィスのサーバーに自動的に同期される
    • ビジネス継続性とディザスター リカバリー
      • Azure File Sync は、高可用性ストレージに対していくつかの冗長性オプションを提供する Azure Files によってサポートされている
    • クラウド側のバックアップ
      • Azure Backup を使用してクラウドで一元的なバックアップを作成することで、オンプレミスのバックアップ支出を削減する
    • 移行
      • Azure File Sync を使用すると、オンプレミスのファイル データを Azure Files にシームレスに移行できる

  • Azure File Sync を使用して Windows ファイル サーバーを拡張する

    • ストレージ同期サービスのデプロイ
    • Azure File Sync で使用する Windows Server の準備
    • Azure File Sync エージェントをインストールする
    • Windows Server をストレージ同期サービスに登録する
    • 同期グループとクラウド エンドポイントを作成する
    • サーバー エンドポイントを作成する
■2.3.6.BLOB ライフサイクル管理を構成する

■2.3.6.BLOB ライフサイクル管理を構成する

https://learn.microsoft.com/ja-jp/azure/storage/blobs/lifecycle-management-overview?tabs=azure-portal

  • ライフサイクル管理ポリシーを使用すると、BLOB を使用パターンに基づいてコスト効率の高いアクセス層に移行したり、ライフサイクルの終了時に完全に削除したりできる

  • 汎用 v2、Premium ブロック BLOB、Blob Storage のアカウントでは、ブロック BLOB と追加 BLOB でライフサイクル管理ポリシーがサポートされている

  • 現在、ライフサイクル管理を実施できるストレージアカウントはBLOBストレージのみとなる

  • 汎用 v2はブロック BLOB と追加 BLOB を適用しているときのみライフサイクル管理を適用することができる

  • アーカイブアクセス層を利用できるストレージアカウントはブロックBLOBストレージのみとなる

  • また、BLOB Storage のアーカイブレベルはLRS、GRS、または RA-GRS 用に構成されたストレージ アカウントのみでサポートされる

■2.3.7.BLOB のバージョン管理を構成する

■2.3.7.BLOB のバージョン管理を構成する

https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview

https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-enable?tabs=portal

■3.Azure のコンピューティング リソースをデプロイおよび管理する (20 - 25%)

■3.1.Azure Resource Manager (ARM) テンプレートまたは Bicep ファイルを使用してリソースのデプロイを自動化する

■3.1.1.Azure Resource Manager テンプレートまたは Bicep ファイルを解釈する

■3.1.1.Azure Resource Manager テンプレートまたは Bicep ファイルを解釈する

  • New-AzResourceGroupDeploymentコマンドレット
    • サブスクリプション内の特定のリソースグループを指定して特定のリソースをデプロイするコマンドである
    • ResourceGroupDeployment コマンドレットはリソース グループに Azure デプロイを追加する
  • New-AzTenantDeploymentコマンドレット
    • テナントスコープでデプロイを作成する際に利用するコマンドである
  • New-AzResource コマンドレット
    • Web サイト、Azure SQL Database サーバー、Azure SQL Database などの Azure リソースをリソース グループに作成する
  • New-AzDeploymentコマンドレット
    • 現在のサブスクリプション スコープでデプロイを作成する
    • これは新規にリソースグループをサブスクリプション内に作成する場合に利用するコマンドとなる

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/overview?tabs=bicep

■3.1.2.既存の Azure Resource Manager テンプレートを変更する

■3.1.2.既存の Azure Resource Manager テンプレートを変更する

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/templates/export-template-portal

■3.1.3.既存の Bicep ファイルを変更する

■3.1.3.既存の Bicep ファイルを変更する

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/decompile

■3.1.4.Azure Resource Manager テンプレートまたは Bicep ファイルを使用してリソースをデプロイする

■3.1.4.Azure Resource Manager テンプレートまたは Bicep ファイルを使用してリソースをデプロイする

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/templates/deployment-tutorial-local-template?tabs=azure-powershell

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/quickstart-create-deployment-stacks-template-specs?tabs=azure-cli

  • Azure Blueprintsは、さまざまなリソース テンプレートやその他のアーティファクトのデプロイを宣言によって調整する機能である
  • これを利用して以下のような設定を定義して、定型化することができる
    • ロールの割り当て
    • ポリシーの割り当て
    • Azure Resource Manager テンプレート (ARM テンプレート)
    • リソースグループ

■3.1.5.デプロイを Azure Resource Manager テンプレートとしてエクスポートするか、Azure Resource Manager テンプレートを Bicep ファイルに変換する

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/templates/export-template-portal

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/decompile

■3.2.仮想マシンを作成して構成する

■3.2.1.仮想マシンの作成

■3.2.1.仮想マシンの作成

https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/tutorial-manage-vm

https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/tutorial-manage-vm

  • 一度起動した仮想マシンに配置された仮想ネットワークは、後から変更することができない
  • 新しい仮想ネットワークに接続された仮想マシンが必要となる場合は、既存の仮想マシンをバックアップした上で一度削除して、バックアップに基づいて新しい仮想ネットワークに同じ構成の新しい仮想マシンを改めて起動する必要がある

https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/tutorial-automate-vm-deployment

https://learn.microsoft.com/ja-jp/azure/automation/automation-dsc-getting-started

  • cloud-Init は、Linux VM を初回起動時にカスタマイズするために広く使用されているアプローチである
  • cloud-init を使って、パッケージをインストールしてファイルを書き込んだり、ユーザーとセキュリティを構成したりすることができる
  • 初回起動処理中に cloud-init が実行されるので、構成を適用するために追加の手順や必要なエージェントはない
  • VM を作成する前に、az group create を使用してリソース グループを作成する
  • 次にaz vm create を使用して VM を作成する
  • --custom-data パラメーターを使用して、cloud-init 構成ファイルを渡す

Azure Automation State ConfigurationはAzureまたはオンプレミス環境の仮想マシンのノード上にPowerShell Desired State Configuration (DSC) 構成を記述、管理、およびコンパイルするための構成管理サービスである。
これを利用して、Azure仮想マシン構成の整合性を管理することができる。
Azure Automation State Configurationを利用する際は、以下の手順に従った設定が必要である。

  • １. DSC構成を作成する
  • ２. DSC構成をAzure Automation State Configurationにアップロードする。
  • ３. DSC 構成をノード構成 (MOF ドキュメント) にコンパイルする
  • ４. VMにノード構成を適用して、State Configurationを使用した仮想マシンの管理を有効にする
  • ５. ノードのコンプライアンス対応状態を確認する
■3.2.2.Azure Disk Encryption を構成する

■3.2.2.Azure Disk Encryption を構成する

https://learn.microsoft.com/ja-jp/azure/virtual-machines/disk-encryption-overview

https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/disk-encryption-overview

■3.2.3.仮想マシンを別のリソース グループ、サブスクリプション、またはリージョンに移動する

■3.2.3.仮想マシンを別のリソース グループ、サブスクリプション、またはリージョンに移動する

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/move-resource-group-and-subscription?tabs=azure-cli

異なるサブスクリプション間の移動の場合、両方のサブスクリプションが同じ Microsoft Entra ID テナントの一部である必要がある。

移動操作中は、ソースとターゲットの両方のリソース グループがロックされる。
移動の進行中は、これらのリソース グループ内のリソースを作成、削除、または更新することはできない。
ただし、既存のリソースは引き続き完全に動作する。

たとえば、仮想マシンを別のリソース グループに移動する場合、移動の間に、それを削除することはできず、そのプロパティ (サイズなど) を変更することはできない。
このような制限にもかかわらず、仮想マシンは正常に動作し続け、それに依存するサービスでダウンタイムが発生することはない。
このロックは最大 4 時間継続するが、ほとんどの移動はこれよりも早く完了し、ロックはそれに応じて削除される。

移動元または移動先のリソース グループまたはサブスクリプションに読み取り専用ロックが存在する場合は、Azure リソースを移動できない。

リソースを移動すると、そのリソース ID は変更される。

  • サブスクリプション間での移動のシナリオ
    • 手順 1:依存リソースが別々のリソース グループに分散されている場合は、まずそれらを 1 つのリソース グループに移動する
    • 手順 2:リソースと依存リソースを、ソース サブスクリプションからターゲット サブスクリプションにまとめて移動する
    • 手順 3:必要に応じて、依存リソースをターゲット サブスクリプション内の別々のリソース グループに再配布する
■3.2.4.仮想マシンのサイズを管理する

■3.2.4.仮想マシンのサイズを管理する

https://learn.microsoft.com/ja-jp/azure/virtual-machines/sizes/resize-vm?tabs=portal

  • 理解しておくべき重要なこととして、割り当て解除の必要がない場合でも、仮想マシンが現在実行中の場合は、そのサイズを変更すると再起動される
  • このため、VM のサイズの変更は中断が発生する手順と考える必要がある
■3.2.5.仮想マシン ディスクを管理する

■3.2.5.仮想マシン ディスクを管理する

https://learn.microsoft.com/ja-jp/azure/virtual-machines/managed-disks-overview

■3.2.6.可用性ゾーンと可用性セットに仮想マシンをデプロイする

■3.2.6.可用性ゾーンと可用性セットに仮想マシンをデプロイする

https://learn.microsoft.com/ja-jp/azure/virtual-machines/availability-set-overview

https://learn.microsoft.com/ja-jp/azure/reliability/availability-zones-overview?toc=%2Fazure%2Fvirtual-machines%2Ftoc.json&tabs=azure-cli

近接配置グループ

https://learn.microsoft.com/ja-jp/azure/virtual-machines/co-location

近接配置グループは、Azure コンピューティング リソースが互いに物理的に近くに配置されるようにするために使用される論理的なグループ化である。
近接配置グループは、短い待ち時間が要件であるワークロードに役立つ。

各 VM をできるだけ近くに配置して、可能性のある最も短い待ち時間を実現するには、それらを近接配置グループ内にデプロイする。
したがって、近接配置グループを適用するリソースは同じデータセンターに配置されている必要があるため、同じリージョンを利用している必要がある。

■3.2.7.Azure Virtual Machine Scale Sets をデプロイして構成する

■3.2.7.Azure Virtual Machine Scale Sets をデプロイして構成する

https://learn.microsoft.com/ja-jp/azure/virtual-machine-scale-sets/overview

  • スケールセットは5 つの障害ドメインと5 つの更新ドメインを使用する暗黙的な可用性セットとして機能する
  • 複数個のVM をもつスケールセットを作成すると、 5 つの更新ドメインに対してVMが均等に自動的に割り当てられる

■3.3.Azure portal でコンテナーをプロビジョニングおよび管理する

■3.3.1.Azure コンテナー レジストリを作成して管理する

■3.3.1.Azure コンテナー レジストリを作成して管理する

https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-intro

  • Azure Container RegistryはDockerイメージを格納する為のプライベートレジストリである
  • Azure CLIを利用して、”az acr buildコマンド”を実行してイメージをビルドして、ACRにPushすることでコンテナイメージを作成できる
オンプレミス環境のHyper-Vサーバーを Azure 環境にレプリケートするために必要な設定手順
  • 1.展開の計画：Recovery Services コンテナーを準備する
  • 2.ソースの設定：Hyper-V サイトを作成する
  • 3.Azure Site Recovery プロバイダーと Azure Recovery Services エージェントをダウンロードして各ホストにインストールし、コンテナーに Hyper-V サイトを登録する
  • 4.レプリケーション ポリシーを設定する
■3.3.2.Azure Container Instances を使用してコンテナーをプロビジョニングする

■3.3.2.Azure Container Instances を使用してコンテナーをプロビジョニングする

https://learn.microsoft.com/ja-jp/azure/container-instances/container-instances-overview

■3.3.3.Azure Container Apps を使用してコンテナーをプロビジョニングする

■3.3.3.Azure Container Apps を使用してコンテナーをプロビジョニングする

https://learn.microsoft.com/ja-jp/azure/spring-apps/migration/migrate-to-azure-container-apps-provision

■3.3.4.Azure Container Instances や Azure Container Apps など、コンテナーのサイズ設定とスケーリングを管理する

■3.3.4.Azure Container Instances や Azure Container Apps など、コンテナーのサイズ設定とスケーリングを管理する

  • 各サービスごとのコンテナーイメージのサポートOSは次のとおりである
    • Azure App Service：Windows Server、Linux
    • Azure Container Instances：Windows Server、Linux
    • Azure Container Apps：Linux

https://learn.microsoft.com/ja-jp/azure/aks/concepts-network

Kubernetes でのネットワークの基本
  • Kubernetes の特定の機能について
    • ロード バランサー: ロード バランサーを使うと、さまざまなリソース間にネットワーク トラフィックを均等に分散できる
    • イングレス コントローラー: これにより、アプリケーション トラフィックの転送に不可欠なレイヤー 7 ルーティングが容易になる
    • エグレス トラフィック制御: Kubernetes を使うと、クラスター ノードからのアウトバウンド トラフィックを管理および制御できる
    • ネットワーク ポリシー: これらのポリシーを使って、ポッド内のネットワーク トラフィックのセキュリティ対策とフィルター処理を実現できる

■3.4.Azure App Serviceの作成・構成

■3.4.1.App Service プランをプロビジョニングする

■3.4.1.App Service プランをプロビジョニングする

https://learn.microsoft.com/ja-jp/azure/app-service/overview-hosting-plans

App Service プランはアプリを動かすための土台（コンピューティングリソース）を提供する役割があり、作成する App Service と同じリージョンに存在している必要がある。

App ServiceプランはOSに応じて個別に作成することが必要となる。

■3.4.2.App Service プランのスケーリングを構成する

■3.4.2.App Service プランのスケーリングを構成する

https://learn.microsoft.com/ja-jp/azure/app-service/manage-scale-up

https://learn.microsoft.com/ja-jp/azure/app-service/manage-automatic-scaling?tabs=azure-portal

https://learn.microsoft.com/ja-jp/azure/azure-monitor/autoscale/autoscale-get-started?toc=/azure/app-service/toc.json

■3.4.3.App Service を作成する

■3.4.3.App Service を作成する

https://learn.microsoft.com/ja-jp/azure/app-service/overview

Azure App Service でアプリの診断ログを有効にする

Azure には、Azure App Service アプリのデバッグに役立つ組み込みの診断機能が用意されている。
App Service では以下の2つのログ記録を取得できる。

  • アプリケーションのログ記録

アプリケーションのコード実行にかかるメッセージのログが記録される。Web フレームワークや言語の標準ログパターンに基づいて、ログ取得されるメッセージは アプリケーションコードから生成される。
ログメッセージにエラーの重要性に基づいて、ステータス（重大、エラー、警告、情報、デバッグ、トレース）が割り当てられる。
アプリケーションのログ記録を有効にするときに、重大度レベルを設定することにより、ログ記録の詳細度を指定できる。

  • Web サーバーのログ記録

W3C 拡張ログ ファイル形式の生 HTTP 要求データが取得される。
ログ メッセージには、HTTP メソッド、リソース URI、クライアント IP、クライアント ポート、ユーザー エージェント、応答コードなどのデータが含まれる。
対応プラットフォームはWindowsのみ。

■3.4.4.App Service の証明書とトランスポート層セキュリティ (TLS) を構成する

■3.4.4.App Service の証明書とトランスポート層セキュリティ (TLS) を構成する

https://learn.microsoft.com/ja-jp/azure/app-service/configure-ssl-certificate?tabs=apex%2Crbac%2Cazure-cli

■3.4.5.既存のカスタム DNS 名を App Service にマップする

■3.4.5.既存のカスタム DNS 名を App Service にマップする

https://learn.microsoft.com/ja-jp/azure/app-service/app-service-web-tutorial-custom-domain?tabs=root%2Cazurecli#4-create-the-dns-records

  • 前提条件
    • Web アプリの App Service プランは、Free (F1) レベルではなく、有料レベルであることが必要である
  • 手順概要
    • カスタム ドメインを構成する
    • DNS レコードを作成する
      • CNAME レコードまたは A レコードのいずれかを使用して、カスタム DNS 名を App Service にマップする
    • ドメインの所有権を検証し、マッピングを完了する
    • DNS 解決をテストする
■3.4.6.App Service のバックアップを構成する

■3.4.6.App Service のバックアップを構成する

https://learn.microsoft.com/ja-jp/azure/app-service/manage-backup?tabs=portal

■3.4.7.App Service のネットワーク設定を構成する

■3.4.7.App Service のネットワーク設定を構成する

https://learn.microsoft.com/ja-jp/azure/app-service/networking-features

■3.4.8.App Service のデプロイ スロットを構成する

■3.4.8.App Service のデプロイ スロットを構成する

https://learn.microsoft.com/ja-jp/azure/app-service/deploy-staging-slots?tabs=portal

  • App Serviceではステージング・デプロイメントスロットを利用してアプリケーションの変更を検証してから、本番スロットと交換することでバージョン変更を実施する
  • 最初にアプリケーションをスロットにデプロイし、それを本番環境にスワップすることで、本番環境にスワップされる前に、スロットのすべてのインスタンスがウォームアップされていることを確認することができる
  • これにより、アプリケーションをデプロイする際のダウンタイムをなくすことが可能となる

■4.仮想ネットワークを実装および管理する (15 から 20%)

■4.1.Azure で仮想ネットワークを構成して管理する

■4.1.1.仮想ネットワークとサブネットを作成して構成する

■4.1.1.仮想ネットワークとサブネットを作成して構成する

https://learn.microsoft.com/ja-jp/azure/virtual-network/network-overview

  • 同じ仮想ネットワーク内に異なるサブネットに属したリソース間はデフォルト設定で通信することが可能である(Azureでは同じ仮想ネットワークにあるサブネット間の接続ルートはデフォルトで作成される)
  • 同じ仮想ネットワーク内のサブネット間通信は、本来はデフォルトの設定によって接続が可能だが、カスタムのルーティングが指定されている場合は、デフォルトのルートは利用されないため、接続ができなくなる
  • 一度起動した仮想マシンに配置された仮想ネットワークは、後から変更することはできない
  • 変更が必要な場合は仮想マシンをバックアップした上で一度削除し、変更後の仮想ネットワークにバックアップに基づいて新しい仮想マシンを配置、起動する必要がある
■4.1.2.仮想ネットワーク ピアリングを作成して構成する

■4.1.2.仮想ネットワーク ピアリングを作成して構成する

https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-peering-overview

Azure では、次の種類のピアリングがサポートされている。

  • 仮想ネットワーク ピアリング:
    • 同じ Azure リージョン内の仮想ネットワークを接続する
  • グローバル仮想ネットワーク ピアリング:
    • Azure リージョン間で仮想ネットワークを接続する

ローカルまたはグローバルの仮想ネットワーク ピアリングを使うことには、次のような利点がある。

  • 異なる仮想ネットワーク内のリソース間で、待機時間の短い広帯域幅の接続が可能である

  • ある仮想ネットワーク内のリソースは別の仮想ネットワーク内のリソースとの通信できる

  • Azure サブスクリプション、Microsoft Entra テナント、デプロイ モデル、Azure リージョン間で仮想ネットワーク間でデータを転送する機能

  • Azure Resource Manager を介して作成された仮想ネットワークをピアリングする機能

  • Resource Manager を使用して作成された仮想ネットワークを、クラシック デプロイ モデルで作成されたものにピアリングする機能

  • ピアリングの作成時またはピアリングの作成後に、いずれの仮想ネットワークのリソースにもダウンタイムは発生しない

  • ピアリングされた仮想ネットワーク間のネットワーク トラフィックはプライベートである

  • 仮想ネットワーク間のトラフィックは、Microsoft のバックボーン ネットワーク上で保持される

  • 仮想ネットワーク間の通信に、パブリック インターネット、ゲートウェイ、暗号化は要求されない

  • 最近、仮想ネットワーク ピアリングに加えて、"サブネット ピアリング" という柔軟性が追加された

    • 仮想ネットワーク ピアリングに基づいて構築された柔軟性が向上し、ユーザーは仮想ネットワーク間でピアリングする必要がある特定のサブネットを選択できる
ピアリングされている Azure 仮想ネットワークのアドレス空間のサイズを変更する

現在ピアリングされているアドレス空間で、ダウンタイムを発生させずに、ピアリングされている Azure 仮想ネットワークのアドレス空間のサイズを変更することが可能である。
この機能は、ワークロードのスケーリング後に仮想ネットワークのアドレス空間をサイズ変更する必要がある場合に便利である。
アドレス空間のサイズ変更後に、ピアリングを新しいアドレス空間の変更と同期する必要がある。
サイズ変更は、IPv4 アドレス空間と IPv6 アドレス空間の両方で機能する。

アドレスのサイズは、次の方法で変更できる。

  • 既存のアドレス範囲のアドレス範囲プレフィックスを変更 (たとえば、10.1.0.0/16 を 10.1.0.0/18 に変更)する
  • 仮想ネットワークにアドレス範囲を追加する
  • 仮想ネットワークからアドレス範囲を削除する

仮想ネットワーク ピアは、Azure portal または Azure PowerShell を使用して同期できる。

https://learn.microsoft.com/ja-jp/azure/virtual-wan/virtual-wan-about

Azure Virtual WAN は、ネットワーク、セキュリティ、ルーティングのさまざまな機能をまとめて、1 つの運用インターフェイスを提供するネットワーク サービスである

主な機能の一部
  • ブランチ接続 (SD-WAN、VPN CPE などの Azure Virtual WAN パートナー デバイスからの接続性自動化による)
  • サイト間 VPN 接続性
  • リモート ユーザーの VPN 接続性 (ポイント対サイト)
  • プライベート接続性 (ExpressRoute)
  • クラウド内接続性 (仮想ネットワークの推移的な接続性)
  • VPN ExpressRoute の相互接続性
  • プライベート接続性のルーティング、Azure Firewall、暗号化

Azureにおいてサイト間接続を作成するためには以下の手順を実行する必要があります。

  1. 仮想ネットワークの作成
    サイト間接続先としてAzure側に仮想ネットワークを作成します。

  2. ゲートウェイサブネットの作成
    サイト間接続にはVPNゲートウェイと呼ばれる仮想ネットワーク ゲートウェイが必要です。仮想ネットワーク ゲートウェイはゲートウェイサブネットと呼ばれる特定のサブネットを使用します。 ゲートウェイ サブネットは仮想ネットワークの構成時に指定した仮想ネットワーク IP アドレス範囲に含まれます。 そこには、仮想ネットワーク ゲートウェイのリソースやサービスによって使用される IP アドレスが含まれます。

  3. VPNゲートウェイの作成
    VPNゲートウェイは仮想ネットワークゲートウェイです。 パブリックネットワーク経由でAzureの仮想ネットワーク間、もしくは仮想ネットワークとオンプレミスのトラフィックを暗号化するために利用されます。VNet の仮想ネットワーク ゲートウェイ (VPN ゲートウェイ) を作成します。

  4. ローカルネットワークゲートウェイの作成
    ローカルネットワークゲートウェイはオンプレミスの場所 (サイト) を指定するルーティング先のオブジェクトです。 サイトに Azure が参照できる名前を付け、接続を作成するオンプレミスVPN デバイスの IPアドレスを指定します。

  5. VPNデバイスの構成
    オンプレミス ネットワークとのサイト間接続には VPN デバイスが必要となるため、VPNデバイスを構成します。

  6. VPN接続の作成
    VPNゲートウェイとオンプレミス VPN デバイスとの間にサイト間 VPN 接続を作成します。

  • ユーザーはポイント対サイト (P2S)VPN接続用の Windows デバイスから、ネイティブ VPN クライアントを使用してAzureの仮想ネットワークに接続することができる

  • そのためには、これらのデバイスに対して、 Azure接続に必要なVPN クライアント構成 zip ファイルをダウンロードして、ユーザーがデバイスにインストーラー パッケージをインストールする必要がある

  • ポイント対サイト (P2S) VPN ゲートウェイ接続では、個々のクライアント コンピューターから仮想ネットワークにセキュリティで保護された接続を構成することができる

  • P2S 接続はクライアント コンピューターから接続を開始することによって確立される

ルートベースのサイト間VPN接続をデプロイするためにはIKEv2プロトコルを使用する必要がある。
Internet Key Exchange Version2（KEv2）はIPsec プロトコル スイートでセキュリティ アソシエーション（SA）を設定するためのプロトコル。
Ciscoとマイクロソフトによって開発されたプロトコルであり、Windows, Mac, Android, iOS, LinuxとほとんどのOSに対応している。
この接続を有効にするには、オンプレミス ポリシー ベース VPN デバイスが IKEv2 をサポートし、Azure ルートベース VPN ゲートウェイに接続する必要がある。

Azure Virtual WAN を使用して複数のオンプレミスサイトとAzure間との接続を構成することができる。

  • １．仮想 WAN を作成する
  • ２．仮想ハブの基本設定を構成する
  • ３．サイト間 VPN ゲートウェイの設定を構成する
  • ４．サイトを作成する
  • ５．サイトをハブに接続する
■4.1.3.パブリック IP アドレスを構成する

■4.1.3.パブリック IP アドレスを構成する

https://learn.microsoft.com/ja-jp/azure/virtual-network/ip-services/virtual-network-public-ip-address

■4.1.4.ユーザー定義のネットワーク ルートを構成する

■4.1.4.ユーザー定義のネットワーク ルートを構成する

https://learn.microsoft.com/ja-jp/azure/virtual-network-manager/concept-user-defined-route

https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-udr-overview

  • Azureでは同じ仮想ネットワークにあるサブネット間の接続ルートはデフォルトで作成される
  • ただし、カスタムのルーティングが指定されている場合は、デフォルトのルートは利用されない
■4.1.5.ネットワーク接続のトラブルシューティング

■4.1.5.ネットワーク接続のトラブルシューティング

https://learn.microsoft.com/ja-jp/azure/network-watcher/connection-troubleshoot-overview

■4.2.仮想ネットワークへの安全なアクセスを構成する

■4.2.1.ネットワーク セキュリティ グループ (NSG) とアプリケーション セキュリティ グループを作成して構成する

■4.2.1.ネットワーク セキュリティ グループ (NSG) とアプリケーション セキュリティ グループを作成して構成する

ネットワーク セキュリティ グループ

https://learn.microsoft.com/ja-jp/azure/virtual-network/manage-network-security-group?tabs=network-security-group-portal

  • Azure 仮想ネットワーク内の Azure リソース間のネットワーク トラフィックは、Azure ネットワーク セキュリティ グループを使ってフィルター処理できる
  • ネットワーク セキュリティ グループには、何種類かの Azure リソースとの送受信ネットワーク トラフィックを許可または拒否するセキュリティ規則が含まれている
  • 各規則で、送信元と送信先、ポート、およびプロトコルを指定することができる
アプリケーション セキュリティ グループ
  • アプリケーション セキュリティ グループを使用すると、ネットワーク セキュリティをアプリケーションの構造の自然な拡張として構成でき、仮想マシンをグループ化して、それらのグループに基づくネットワーク セキュリティ ポリシーを定義できる
  • 明示的な IP アドレスを手動でメンテナンスせずに、大きなセキュリティ ポリシーを再利用することができる
  • アプリケーションセキュリティグループを仮想マシンに関連付けるためには 、アプリケーションセキュリティグループを対象の仮想マシンのネットワークインターフェース（NIC）に関連付ける必要がある
  • NIC経由で仮想マシンをアプリケーションセキュリティグループに参加させることで、そのアプリケーションセキュリティ グループをNSGルールのソースまたは宛先として使用することができる

主な利点

  • Azure Storage への仮想ネットワーク トラフィックのセキュリティ強化
  • Azure サービス トラフィックをフィルター処理するスケーラブルな高可用性ポリシー

サービス タグを使用すると、次の方法で Azure のネットワーク セキュリティ構成が簡略化される。

  • Azure サービスの IP アドレスを手動で追跡および更新する必要がなくなる
  • Azure サービスの IP 範囲が変更されたときに自動更新を提供する
  • セキュリティ規則管理の複雑さを軽減する
  • Azure サービスとの間のネットワーク トラフィックをきめ細かく制御できるようにする

サービス タグを使用して、ネットワーク セキュリティ グループ、Azure Firewall、ユーザー定義ルートでのネットワーク アクセスの制御を定義できる。
セキュリティ規則とルートを作成するときに、特定の IP アドレスの代わりにサービス タグを使用する。

サービス タグは、指定された Azure サービスからの IP アドレス プレフィックスのグループを表す。
サービス タグに含まれるアドレス プレフィックスの管理は Microsoft が行い、アドレスが変化するとサービス タグは自動的に更新される。
これにより、ネットワーク セキュリティ規則に対する頻繁な更新の複雑さを最小限に抑えられる。

利用可能なサービスタグ

■4.2.2.NSG で有効なセキュリティ規則を評価する

■4.2.2.NSG で有効なセキュリティ規則を評価する

https://learn.microsoft.com/ja-jp/azure/network-watcher/diagnose-network-security-rules?tabs=portal

■4.2.3.Azure Bastion を実装する

■4.2.3.Azure Bastion を実装する

Azure Bastion とは
  • Azure Bastion は、プライベート IP アドレスを介して仮想マシンに安全に接続するためにプロビジョニングするフル マネージド PaaS サービスである
  • Azure portal から TLS 経由で直接、またはローカル コンピューターに既にインストールされているネイティブ SSH または RDP クライアントを介して、仮想マシンへの安全でシームレスな RDP/SSH 接続を提供する
  • Azure Bastion 経由で接続する場合、仮想マシンにパブリック IP アドレス、エージェント、クライアント ソフトウェアはいずれも不要である
  • Bastion は、プロビジョニングされる仮想ネットワーク内のすべての VM に対して安全な RDP および SSH 接続を提供する
  • Azure Bastion を使用すると、RDP または SSH を使用した安全なアクセスを提供しながら、お使いの仮想マシンが RDP または SSH ポートを外部に公開しないように保護される
  • Azure Bastion サブネット
    • Azure Bastion を利用する際はサブネット名 AzureBastionSubnetを設定する
    • Azure Bastion Subnetに設定するサブネットには10.1.1.0/26などのサブネットマスク/26以上のアドレス空間が必要となる
主な利点
  • Azure portal を介した RDP と SSH
  • RDP/SSH の TLS およびファイアウォール トラバーサルを介したリモート セッション
  • Azure VM ではパブリック IP アドレスは必要ない
  • ネットワーク セキュリティ グループ (NSG) を管理する労力が不要
  • VM 上の別の bastion ホストを管理する必要はない
  • ポート スキャンからの保護
  • 一元的な強化
  • ゼロデイ攻撃からの保護
SKU
  • Developer SKU
  • Basic SKU
  • Standard SKU
  • Premium SKU
■4.2.4.Azure のサービスとしてのプラットフォーム (PaaS) のサービス エンドポイントを構成する

■4.2.4.Azure のサービスとしてのプラットフォーム (PaaS) のサービス エンドポイントを構成する

Azure Storage の仮想ネットワーク サービス エンドポイント ポリシー

https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-service-endpoint-policies-overview

仮想ネットワーク サービス エンドポイントのポリシーを使用すると、サービス エンドポイントを経由する Azure Storage アカウントへの仮想ネットワーク エグレス トラフィックをフィルター処理し、特定の Azure Storage アカウントへのデータ流出のみを許可できる。
エンドポイン トポリシーでは、サービス エンドポイント経由で接続する際に、Azure Storage への仮想ネットワーク トラフィックに対する詳細なアクセスが制御される。
この機能は、 すべてのグローバル Azure リージョン の Azure Storage で一般公開されている。

■4.2.5.Azure PaaS のプライベート エンドポイントを構成する

■4.2.5.Azure PaaS のプライベート エンドポイントを構成する

https://learn.microsoft.com/ja-jp/azure/private-link/private-endpoint-overview

■4.3.名前解決と負荷分散を構成する

■4.3.1.Azure DNS を構成する

■4.3.1.Azure DNS を構成する

ドメイン ネーム システム (DNS) は、サービスの名前を IP アドレスに変換する (解決する) 役割を担う。
Azure DNS は、Microsoft Azure インフラストラクチャを使用して、アプリケーションの DNS ホスティング、解決、負荷分散を提供する。
Azure DNS は、インターネットに接続する DNS ドメインとプライベート DNS ゾーンの両方をサポートし、次のサービスを提供する。

  • Azure パブリック DNS

    • DNS ドメイン用のホスティング サービス
    • Azure でドメインをホストすることで、その他の Azure サービスと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できる

  • Azure プライベート DNS

    • 仮想ネットワークのための DNS サービスである
    • カスタムの DNS ソリューションを構成しなくても、Azure プライベート DNS によって、仮想ネットワークにおけるドメイン名の管理と解決が行われる
    • プライベート DNS ゾーンには、複数の登録仮想ネットワークを含めることができる
      • 自動登録設定を有効にした場合、仮想ネットワークはプライベート DNS ゾーンの登録仮想ネットワークになる
      • １つの登録仮想ネットワークに関連付けることができる登録ゾーンは 1 つだけである
      • 自動登録設定を有効にしていない場合は、仮想ネットワークは解決仮想ネットワークとなり、仮想ネットワークには複数の解決ゾーンを関連付けることができる
      • 1 つのプライベート DNS ゾーンは複数の解決仮想ネットワークを持つことができ、解決仮想ネットワークには複数の解決ゾーンを関連付けることができる

  • Azure DNS Private Resolver

    • VM ベースの DNS サーバーをデプロイすることなく、オンプレミス環境から Azure DNS プライベート ゾーンに対して (またはその逆方向に) クエリを実行できるサービスである

  • Azure Traffic Manager

    • DNS ベースのトラフィック ロード バランサーである
    • このサービスを使用すると、パブリックに公開されているアプリケーションへのトラフィックを世界各国の Azure リージョン全体に分散することができる
    • Traffic Manager によって、パブリック エンドポイントには高可用性と高い応答速度が確保される
    • Traffic Manager では、DNS を使用して、トラフィック ルーティング方法に基づいて適切なサービス エンドポイントにクライアント要求が誘導される
    • さらに、Traffic Manager では、各エンドポイントの稼働状況も監視される
    • Azure の内部または外部でホストされている、インターネットに公開された任意のサービスをエンドポイントとすることができる
    • Traffic Manager には、さまざまなアプリケーション ニーズと自動フェールオーバー モデルに対応する、さまざまなトラフィック ルーティング方法とエンドポイント監視オプションが用意されている
    • Traffic Manager は Azure リージョン全体の障害などの障害に対応する

  • pingはIPネットワークにおいて、ネットワーク上で特定のIPアドレスを持つ機器から応答があるかを調べるためのプログラムである

  • AレコードはDNS/ドメイン名を IP TXT レコードにマッピングするために使用されるレコードである

  • これは主に、ドメインの所有権を証明するために使用される

  • したがって、pingはAレコードのマッピング情報を利用してIPアドレスを確認している

カスタム ドメイン名をテナントに追加する

Microsoft Entra テナントには、 domainname.onmicrosoft.com のような初期ドメイン名が付けられている。
初期ドメイン名は変更したり削除したりできないが、初期ドメインに追加することはできる。
カスタム ドメイン名を追加すると、サードパーティのレジストラに登録されているexample.comのドメイン名などを追加できる。
そのための設定手順は以下の通り。

  • １．ドメイン名を取得後、 サブスクリプションの所有者ロールを持つアカウントを使用して、お使いのディレクトリの Azure portal にサインインして、組織の新しいテナントを作成することに関するページの手順に従って、新しいディレクトリを作成する。そして、利用したいカスタムドメイン名をディレクトリに追加する。
  • ２．カスタム ドメイン名を追加したら、ドメイン レジストラーに DNS 情報を追加する。
  • ３．カスタム ドメイン名を登録したら、Microsoft Entra で有効であることを確認する。伝達時間は、即座に行われることも数日かかることもあり、ドメイン レジストラーによって異なる。

仮想マシンは逆引き DNS クエリ (PTR クエリ) を発行して、仮想マシンの IP アドレスを仮想マシンの FQDN にマッピングできる。
仮想マシンの IP アドレスに対するすべての PTR クエリは、[vmname].internal.cloudapp.net 形式の FQDN を返す。
[vmname].internal.cloudapp.net という形式の Azure が管理する逆引き DNS (PTR) レコードは、VM を起動すると自動的に追加され、VM を停止 (割り当て解除) すると削除される。

■4.3.2.内部またはパブリックのロード バランサーを構成する

■4.3.2.内部またはパブリックのロード バランサーを構成する

Azure Load Balancer

https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview

  • 受信ネットワーク トラフィックをバックエンド仮想マシン (VM) または仮想マシン スケール セット (VMSS) に分散するクラウド サービスである
  • 開放型システム間相互接続 (OSI) モデルの第 4 レイヤーで動作します。 クライアントにとっての単一接続点となる
  • このサービスは、ロード バランサーのフロントエンドに到着した受信フローを、バックエンド プールのインスタンスに分配する
  • これらのフローは、構成された負荷分散規則と正常性プローブに従って分配される
  • バックエンド プールのインスタンスは、Azure 仮想マシン (VM) か、仮想マシン スケール セットにすることができる
  • パブリック ロード バランサーは、仮想ネットワーク内の VM に受信と送信の両方の接続を提供する
  • 受信トラフィックのシナリオでは、Azure Load Balancer はインターネット トラフィックを VM に負荷分散できる
  • 送信トラフィックのシナリオでは、このサービスは VM から発信されるすべての送信接続のプライベート IP アドレスに VM のパブリック IP アドレスを変換できる
  • または、 内部 (またはプライベート) ロード バランサー を使用して、仮想ネットワーク内のトラフィックを負荷分散する
  • 内部ロード バランサーを使用すると、ハイブリッド シナリオでオンプレミス ネットワークからロード バランサー フロントエンドにアクセスするなど、プライベート ネットワーク接続シナリオで VM への受信接続を提供できる
  • Azure Load Balancer には、Basic、Standard、Gateway の 3 つのストックキー保持ユニット (SKU) がある
  • 各 SKU は特定のシナリオに対応しており、スケール、機能、価格の違いがある
  • Standard Load Balancer
    • ハイ パフォーマンスと非常に短い待機時間を必要とする場合に、ネットワーク層のトラフィックを負荷分散する機能を備えている
    • リージョン内およびリージョン間でトラフィックをルーティングし、高い回復性を実現するために可用性ゾーンにルーティングする
    • バックエンドプールは「単一の仮想ネットワーク内の任意の仮想マシンまたは仮想マシンスケールセット」に設定されている必要がある
  • Basic Load Balancer
    • 高可用性や冗長性を必要としない小規模なアプリケーション向けに搭載されている
    • 可用性ゾーンと互換性がない
    • バックエンドプールに設定する仮想マシンには以下のいづれかの条件が必要となる
      • 単一の可用性セットの仮想マシンである
      • 単一の仮想マシンスケールセット内の仮想マシンである
    • Basic Load Balancer は 2025 年 9 月 30 日に廃止される
  • 仮想ネットワーク内のネットワーク仮想アプライアンス (NVA) の高可用性と拡張性を高めるためには、HA ポート負荷分散規則を設定する
  • そして、HAポートはStandard Load Balancerでのみ利用可能である
  • 高可用性 (HA) ポートは負荷分散規則の一種であり、内部 Standard Load Balancer の すべての ポートに到着するすべての トラフィックの負荷分散を行う
  • HA ポート負荷分散規則は仮想ネットワーク内のネットワーク仮想アプライアンス (NVA) の高可用性と拡張性を保持するために利用される
  • 特定のユーザーのリクエストに対して同じWebサーバーがリクエスト処理を継続するようにAzureロードバランサーを設定する際は、ロードバランサー機能に対してセッション永続化を設定する
  • セッション永続化により、スティッキーセッションが有効化されるため、同じ送信元IPアドレスからのリクエストを同じ仮想マシンが継続的に処理する
Azure Application Gateway

https://learn.microsoft.com/ja-jp/azure/application-gateway/overview

  • Web アプリケーションに対するトラフィックを管理できる Web トラフィック (OSI レイヤー 7) ロード バランサーである
  • 従来のロード バランサーはトランスポート レイヤー (OSI レイヤー 4 - TCP と UDP) で動作し、送信元 IP アドレスとポートに基づくトラフィックを送信先 IP アドレスとポートにルーティングする
  • Application Gatewayではパフォーマンスカウンターを表示するために、次の7つのメトリックが利用可能である
    • リクエストの総数
    • 失敗したリクエスト
    • 現在の接続
    • 健全なホスト数
    • 応答ステータス
    • スループット
    • 不健康なホスト数
  • Azure Application Gateway 上の Azure Web Application Firewall (WAF) は、一般的な悪用や脆弱性から Web アプリケーションを積極的に保護する
    • SQL インジェクションからの保護
    • クロスサイト スクリプティングからの保護
    • その他の一般的な Web 攻撃からの保護 (コマンド インジェクション、HTTP 要求スマグリング、HTTP レスポンス スプリッティング、リモート ファイル インクルードなど)
    • HTTP プロトコル違反に対する保護
    • HTTP プロトコル異常に対する保護 (ホスト ユーザー エージェントと承認ヘッダーが見つからない場合など)
    • クローラーおよびスキャナーに対する保護
    • 一般的なアプリケーション構成ミスの検出 (Apache や IIS など)
Azure NAT Gateway
  • フル マネージドで回復性の高いネットワーク アドレス変換 (NAT) サービス
  • Azure NAT Gateway を使用すると、プライベート サブネット内のすべてのインスタンスが、完全にプライベートなままでインターネットにアウトバウンド接続できる
  • インターネットからの未承諾のインバウンド接続は、NAT ゲートウェイ経由では許可されまない
  • NAT ゲートウェイを通過できるのは、アウトバウンド接続への応答パケットとして到着するパケットのみである
■4.3.3.負荷分散のトラブルシューティングを行う

■4.3.3.負荷分散のトラブルシューティングを行う

https://learn.microsoft.com/ja-jp/azure/load-balancer/load-balancer-troubleshoot

https://learn.microsoft.com/ja-jp/training/modules/troubleshoot-routing-traffic-control-load-balancing/

■5.Azure リソースの監視と管理 (10 - 15%)

■5.1.Azure でリソースを監視する

■5.1.1.Azure Monitor でメトリックを解釈する

■5.1.1.Azure Monitor でメトリックを解釈する

  • Azure Diagnostics 拡張機能のLinux Diagnostic Extension 4.0を利用してLinux仮想マシンのメトリックとログを監視することができる
  • Azure Diagnostics 拡張機能は仮想マシンなどのAzure コンピューティング リソースのゲストOSから監視データを収集するAzure Monitor のエージェントである
  • Linux Diagnostic Extension(Linux 診断拡張機能)、Microsoft Azure 上の Linux VM の正常性を監視するのに役立つ

https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/codeless-overview

  • 自動インストルメンテーションを使用すると、Application Insights はメトリック、要求、依存関係などのテレメトリがApplication Insights リソースで利用可能になる
  • 自動インストルメンテーションの利点
    • コードの変更は必要ない
    • ソース コードへのアクセスは必要ない
    • 構成の変更は必要ない
    • インストルメンテーションのメンテナンスは必要ない
■5.1.2.Azure Monitor でログ設定を構成する

■5.1.2.Azure Monitor でログ設定を構成する

https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/data-platform-logs

■5.1.3.Azure Monitor でログのクエリと分析を行う

■5.1.3.Azure Monitor でログのクエリと分析を行う

https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/get-started-queries?tabs=kql

■5.1.4.Azure Monitor でアラート ルール、アクション グループ、アラート処理ルールを設定する

■5.1.4.Azure Monitor でアラート ルール、アクション グループ、アラート処理ルールを設定する

  • Azure Monitor サービスの制限
    • アクション グループ
      • Email：リージョンごと、メールアドレスごと、1 時間ごとに 100 件以下のメール
      • SMS：運用環境: 5 分ごとに 1 件以下の SMS メッセージ
■5.1.5.Azure Monitor Insights を使用して仮想マシン、ストレージ アカウント、ネットワークの監視を構成して解釈する

■5.1.5.Azure Monitor Insights を使用して仮想マシン、ストレージ アカウント、ネットワークの監視を構成して解釈する

https://learn.microsoft.com/ja-jp/azure/azure-monitor/visualize/insights-overview

■5.1.6.Azure Network Watcher と接続モニターを使用する

■5.1.6.Azure Network Watcher と接続モニターを使用する

Azure Network Watcher
  • Azure IaaS (サービスとしてのインフラストラクチャ) のリソースの監視、診断、メトリックの表示、ログの有効化または無効化を行うためのツールのスイートを提供する
  • Network Watcher によって、仮想マシン (VM)、仮想ネットワーク (VNet)、アプリケーション ゲートウェイ、ロード バランサーなどの IaaS 製品のネットワーク正常性を監視および修復することが可能になる
  • Network Watcher は PaaS の監視または Web の分析用に設計または意図されたものではない
  • Network Watcher は、次の 3 つの主要なツールと機能のセットで構成されている
    • 監視
    • ネットワーク診断ツール
    • トラフィック
▼監視
  • トポロジ
    • トポロジは、ネットワーク全体を視覚化して、ネットワーク構成を把握できるようにするものである
    • トポロジでは、複数のサブスクリプション、リソース グループ、場所に存在する Azure 内のリソースとそれらのリレーションシップを、対話型のインターフェイスを通じて表示することができる
  • 接続モニター(Azure Connection Monitor)
    • 接続モニターは、Azure とハイブリッド エンドポイントに関するエンド ツー エンドの接続監視を提供する
    • ネットワーク インフラストラクチャ内のさまざまなエンドポイント間のネットワーク パフォーマンスを把握するのに役立つ
    • ユースケース
      • 2 つの VM 間のネットワーク接続を確認したい
      • Azure 仮想マシン スケール セットの 1 つまたは複数のインスタンスから Azure または Azure 以外の多層アプリケーションへの接続を確認したい
      • オンプレミスのセットアップと、クラウド アプリケーションがホストされている Azure VM またはスケール セットの間の接続を確認したい
▼ネットワーク診断ツール
  • IP フロー検証
    • IP フロー検証を使用すると、仮想マシン レベルでトラフィックのフィルター処理に関する問題を検出できる
    • ある IP アドレス (IPv4 または IPv6 アドレス) との間でやり取りされるパケットが許可されるか、または拒否されるかを調べる
    • また、トラフィックを許可または拒否したセキュリティ規則も示す
  • NSG 診断
    • NSG 診断を使用すると、仮想マシン、仮想マシン スケール セット、またはアプリケーション ゲートウェイのレベルでトラフィックのフィルター処理に関する問題を検出できる
    • ある IP アドレス、IP プレフィックス、またはサービス タグとの間でやり取りされるパケットが許可されるか、または拒否されるかを調べる
    • トラフィックがどのセキュリティ規則によって許可または拒否されたかが示される
    • また、優先順位の高い新しいセキュリティ規則を追加して、トラフィックを許可または拒否することもできる
  • ネクスト ホップ
    • ネクスト ホップを使うと、ルーティングの問題を検出できる
    • トラフィックが目的の宛先に正しくルーティングされているかどうかを調べる
    • ネクスト ホップの種類、IP アドレス、特定の宛先 IP アドレスのルート テーブル ID に関する情報が提供される
  • 有効なセキュリティ規則
    • 有効なセキュリティ規則を使うと、ネットワーク インターフェイスに適用される有効なセキュリティ規則を確認できる
    • ネットワーク インターフェイスに適用されるすべてのセキュリティ規則、ネットワーク インターフェイスが存在するサブネット、それら両方の集計が示される
  • 接続のトラブルシューティング
    • 接続のトラブルシューティングを使うと、仮想マシン、仮想マシン スケール セット、アプリケーション ゲートウェイ、または Bastion ホストと、仮想マシン、FQDN、URI、または IPv4 アドレスの間の接続をテストできる
    • テストからは、接続監視機能の使用時に返されるのと同様の情報が返される
  • パケット キャプチャ
    • パケット キャプチャを使うと、パケット キャプチャ セッションをリモートで作成して、仮想マシン (VM) または仮想マシン スケール セットの間でやり取りされるトラフィックを追跡できる
  • VPN のトラブルシューティング
    • VPN のトラブルシューティングを使うと、仮想ネットワーク ゲートウェイとその接続のトラブルシューティングを行うことができる
▼トラフィック

  • フロー ログ

    • フロー ログを使用すると、Azure IP トラフィックに関する情報をログに記録し、データを Azure Storage に格納できる
    • ネットワーク セキュリティ グループまたは Azure 仮想ネットワークを介して流れる IP トラフィックをログに記録できる
    • ネットワーク セキュリティ グループ (NSG) のフロー ログは、ネットワーク セキュリティ グループを通過する IP トラフィックに関する情報をログ管理できる Azure Network Watcher の機能である
    • NSGのフローログの保持機能は、汎用 v2 ストレージ アカウントを使用している場合にのみ利用できる
    • NSGのフローログ機能で用いるストレージアカウントはNSGと同じリージョンにある必要がある

  • トラフィック分析

    • トラフィック分析(Traffic Analytics) では、フロー ログ データの充実した視覚化が提供される

■5.2.バックアップと回復を実装する

■5.2.1.Recovery Services コンテナーの作成

■5.2.1.Recovery Services コンテナーの作成

  • Recovery Services コンテナーを使用すると、IaaS VM (Linux または Windows) や Azure VM 内の SQL Server などのさまざまな Azure サービスのバックアップ データを保持できる
  • Recovery Services コンテナーは、System Center DPM、Windows Server、Azure Backup Server などをサポートする
  • Recovery Services コンテナーでは、管理オーバーヘッドを最小限に抑えながら、バックアップ データを簡単に整理できる
  • Recovery Services コンテナーはバックアップ対象のリソースと同じリージョンに作成する必要がある
  • １つのコンテナーは複数のリソースからのバックアップに利用できる
  • マルチユーザー承認（MUA）は Recovery Services コンテナーと バックアップコンテナーに対する重要な操作に対して保護レイヤー（承認機能）を追加する
  • リソースガードを作成し、コンテナーで有効化することで使用できる
主要な機能
  • 強化されたバックアップ データの保護機能
  • ハイブリッド IT 環境の一元的な監視
    • Azure IaaS VM だけでなく、他のワークロードやオンプレミスの (System Center Data Protection Manager) 資産 も、中心的なポータルから監視できる
  • Azure ロールベースのアクセス制御 (Azure RBAC)
  • 論理的な削除
  • リージョンをまたがる復元
  • データ分離
■5.2.2.Azure Backup コンテナーを作成する

■5.2.2.Azure Backup コンテナーを作成する

  • Azure Backup でバックアップデータを保存する「保管庫」には次の 2 つがある
    • Recovery Services コンテナー
    • バックアップコンテナー
  • もともとは「Recovery Services コンテナー」のみであったが、あとで「バックアップコンテナー」が登場した経緯がある
  • 仮想マシンのマネージドディスクをバックアップするには、最初に「バックアップコンテナー」を作成する必要がある
■5.2.3.バックアップ ポリシーを作成して構成する

■5.2.3.バックアップ ポリシーを作成して構成する

  • バックアップポリシーはバックアップするリソース種別ごとに作成する必要がある。
■5.2.4.Azure Backup を使用してバックアップと復元の操作を実行する

■5.2.4.Azure Backup を使用してバックアップと復元の操作を実行する

https://learn.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas

  • "32 ビット オペレーティング システム" はサポートされていない
Azure portal で Azure VM データを復元する方法

https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms

Azure Backup は、VM を復元するためのさまざまな方法を提供する。

  • 新しい VM を作成する
    • 基本的な VM を復元ポイントからすばやく作成し、起動して実行する
    • VM の名前を指定し、その配置先のリソース グループと仮想ネットワーク (VNet) を選択できる
    • 新しい VM は、ソース VM と同じリージョンに作成する必要がある
  • ディスクを復元する
    • 新しい VM を作成するために使用できる VM ディスクを復元する
    • ディスクは、指定したリソース グループにコピーされる
    • または、ディスクを既存の VM に接続することや、PowerShell を使用して新しい VM を作成することもできる
    • このオプションは、VM をカスタマイズする場合や、バックアップの時点では存在していなかった構成設定を追加する場合や、テンプレートまたは PowerShell を使用して構成する必要がある設定を追加する場合に役立つ
  • 既存のものを置き換える
    • ディスクを復元し、それを使用して既存の VM 上のディスクを置き換えることができる
    • 新たに仮想マシンを起動するよりもダウンタイムを抑制しつつ、仮想マシンを復元することができる
    • 現在の VM が存在する必要がある
    • 削除されている場合、このオプションは使用できない
    • 暗号化されていない管理 VM (カスタム イメージを使用して作成された VM など) でサポートされるが、クラシック VM、アンマネージド VM、および一般化された VM ではサポートされない
  • クロスリージョン (第2リージョン)
    • リージョン間復元を使用すると、Azure VM をセカンダリ リージョン (Azure のペアになっているリージョン) に復元できる
    • この機能は、次のオプションで使用できる
      • VM の作成
      • ディスクの復元
    • 現時点では、[既存のディスクの置き換え] オプションはサポートされていない
  • クロス サブスクリプションの復元
    • Azure Virtual Machines またはディスクは復元ポイントから (Azure RBAC 機能に従って) ソース サブスクリプションと同じテナント内の別のサブスクリプションに復元できる
    • Recovery Services コンテナーに対して [サブスクリプション間の復元] プロパティが有効な場合にのみ使用できる
  • クロス ゾーン復元

復元操作が失敗したときにアラートや通知を受け取るには、Azure Backup 用の Azure Monitor アラートを使用する。
これは、このような障害を監視し、問題の修復に必要なアクションを実行するのに役立つ。

https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-restore-files-from-vm

■5.2.5.Azure リソース用に Azure Site Recovery を構成する

■5.2.5.Azure リソース用に Azure Site Recovery を構成する

https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-overview

■5.2.6.Site Recovery を使用してセカンダリ リージョンへのフェールオーバーを実行する

■5.2.6.Site Recovery を使用してセカンダリ リージョンへのフェールオーバーを実行する

https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-quickstart

Azure Site Recoveryを適用して、AWSにあるEC2インスタンス（VM-A）をAzure環境のVNET-Aに移行するためには、Azure Migrateを利用した以下のような手順による仮想マシンの移行を実施する
  • 手順1：移行のために Azure リソースを準備する
    • Azure Migrate を利用した移行を実施するためには、Azure Migrate プロジェクトを作成して、Azure アカウントのアクセス許可を設定する必要がある
  • 手順2：EC2インスタンスにレプリケーションアプライアンスを設する
    • 移行の最初の手順は、レプリケーション アプライアンスを設定することである
    • AWS VM 移行用のアプライアンスを設定するには、アプライアンスのインストーラー ファイルをダウンロードし、それを、EC2インスタンスで実行する必要がある
  • 手順3：Mobility ServiceエージェントをEC2インスタンスにインストールする
    • レプリケーションを開始する前に、移行するソース AWS VM にMobility Service エージェントを事前にインストールしておく必要がある
    • ポータルからは、一度に最大 10 台の VM をレプリケーションに追加できる
    • 複数の VM を同時にレプリケートするため、10 台のバッチ単位で追加できる
  • 手順4：EC2インスタンスのレプリケーションを有効にする
    • 移行対象となるEC2インスタンスごとにレプリケーションを有効にする
    • レプリケーションが有効になっている場合、Azure Site Recoveryはモビリティサービスを自動的にインストールして、レプリケーションを実行する
  • 手順5：レプリケーションの状態を追跡して監視する
    • [レプリケート] をクリックすると、レプリケーションの開始ジョブが開始される
    • レプリケーションの状態を監視するには、[移行およびモダン化] 内で [サーバーをレプリケートしています] をクリックする
■5.2.7.バックアップのレポートとアラートを構成して解釈する

■5.2.7.バックアップのレポートとアラートを構成して解釈する

  • Azure Backupを利用して仮想マシンに対するバックアップを構成する際は、最初にRecovery Services コンテナーを作成する必要がある

  • Recovery Services コンテナー（Recovery Services vaults）はバックアップデータを格納するためのストレージ領域である

  • このコンテナーに保存される データはデータのコピーの他にも、仮想マシン (VM)、ワークロード、サーバー、ワークステーションなどの構成情報も含まれている

  • その際は、Recovery Services コンテナーを作成して、バックアップポリシーを作成し、VMに適用することが必要である

  • 具体的な手順は以下の通りになる

    • １．最初にバックアップを保存するためのRecovery Services コンテナーを作成する
    • ２．Recovery Services コンテナー内でリソースの種類に仮想マシンを指定してバックアップ ポリシーを適用する
    • ３．バックアップする 対象となるVM を選択する
    • ４．VM側でバックアップを有効にするには、[バックアップ] 項目の [バックアップの有効化] を選択する
      • これにより、ポリシーがコンテナーと VM にデプロイされ、Azure VM で実行されている VM エージェントにバックアップ拡張機能がインストールされる

  • Log Analytics ワークスペースはバックアップ レポートデータを保存する際に 1 つ以上の Log Analytics ワークスペースを設定することができる

  • その際にRecovery Services コンテナーが存在するリージョンまたはサブスクリプションとは異なるリージョンとサブスクリプションに配置されたLog Analytics ワークスペースを利用することができる

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?