実際にAzure Administrator（AZ-104）の資格対策をやってみると、あまりまとまった情報が無いため対策ついでにまとめました。良く出題されるポイントや、公式サイトを見ても理解しづらいところを分かりやすくメモしました。追記：合格しました
管理
管理単位
テナントルートグループ→管理グループ→サブスクリプション→リソースグループ→リソースの階層構造
- テナントルートグループ
最上位に1つ存在するもの（例：会社のイメージ）。 - 管理グループ
サブスクリプションを統合的に管理したい場合に作成する（例：部署のイメージ） - サブスクリプション
リソースグループを統合的に管理したい（主に課金管理）場合に作成する（例：システムのイメージ） - リソースグループ
リソースを統合的に管理したい場合に作成する（例：システムの機能ごとイメージ） - リソース
各種リソース（例：VMやAppServiceなど）
AzureのIDの種類
ユーザ、マネージドID、サービスプリンシパルがある
- ユーザ
EntraIDで追加する普通のID（人が操作する） - マネージドID
Azureリソースの詳細画面から追加するリソース用のID（VMやAppServiceなどのリソースが操作する） - サービスプリンシパル
Entra IDでアプリ登録するID（オンプレなどAzureでないサービスが操作する）
RBAC（ロールベースアクセス制御）
アールバックと呼ぶらしい
前提として、ロールとはAzure上のリソースへのアクセス権を付与するもの
セキュリティプリンシパル（誰に）・ロール（何を）・スコープ（どの範囲で）を決める必要あり
セキュリティプリンシパル（誰に）
プリンシパルは、普通に訳すと「主要な」だが、IT界隈では認証されたユーザとかサーバを意味するらしい。
セキュリティプリンシパルは、ユーザー、グループ、サービスプリンシパル※、マネージド ID※の4種類。
※IDの1種、このページのAzureのIDの種類参照
ロール（何を）
どんな権限を与えるか。問題集で良く出てたのは以下の4種類。
※例えば、Contributorとか言われても良く分からないので覚えておかないと問題の意味が分からないときあり。
- グローバル管理者
テナントルートグループからテナントを追加など最高権限。 - 所有者
すべてのリソースへのフルアクセスが可能。 - Contributor（共同作成者）
すべての種類の Azure リソースを作成および管理できます。ロールの割り当てやブループリントの管理はできない。さらに、ネットワークリソース（LBなど）に限定したらネットワーク共同作成者、仮想マシンに限定したら仮想マシン共同作成者などある。 - Reader（閲覧者）
Azure リソースの表示のみ。変更はできない。 - User Access Administrator（ユーザーアクセス管理者）
リソースに対するユーザーアクセスを管理。 - グループ管理者
グループ作成などができる。※グループの管理者権限ではない - 特権ロール管理者
個々のユーザーまたはグループにロールを割り当てることができる権限を付与することができる。Azureでは特権ロール管理者またはグローバル管理者が、他のユーザーに対してロールを付与する権限を与えられている。
スコープ（どの範囲で）
どの範囲に権限を与えるか。
Azureの管理単位の管理グループ以下に与えることができる。
その他
Entra IDライセンス種類
| Free | Premium P1 | Premium P2 | |
| 認証、SSO、APアクセス | △ | 〇 | 〇 |
| 管理とハイブリッドID | △ | 〇 | 〇 |
| エンドユーザーセルフサービス | △ | △ | 〇 |
| 多要素認証と条件付きアクセス | △ | 〇 | 〇 |
| ID保護 | ✕ | ✕ | 〇 |
| イベントログとレポート | △ | 〇 | 〇 |
| IDガバナンス | △ | △ | △ |
PIM
Microsoft Entra Privileged Identity Management (PIM) を使用すると、Microsoft Entraの組織においてロールの割り当て時やアクティブ化された場合などの重要なイベントが発生した際に通知を受けることができます。 この機能を使用するには、Microsoft Entra Premium P2 ライセンスが必要となります。
ロックとタグ
ロックもタグ付与もサブスクリプション以下に適用可能。テナントルートグループと管理グループには適用不可。
監視
Azure MonitorとNetwork Watcherの2つの機能が似ててややこしいので整理
Azure Monitor
リソースのメトリクスやログを収集しモニタリングできる
2種類のデータの収集と分析を行う
- メトリック
マシンやネットワークトラフィックの状況など - ログ
システム内で発生したイベントログ。Azure内だけでなく、オンプレログも収集可能。
5つの機能がある
- Insight（洞察）
Azure Monitorの中のApplication InsightsやVM Insightsなどの機能を利用して、リソースやパフォーマンスの状況を監視する機能。 - Visualize（可視化）
メトリックとログの情報を視覚的にわかりやすく表示する。 - Analyze（分析）
条件で抽出したりする。ログについてはLog Analyticsを利用できる。
Log Analyticsの利用方法は、ワークスペースを作成して、データ収集ルール (DCR) によって収集するデータを定義して、ワークスペースを送信先として設定する（Azure Monitor エージェントは自動でインストールされる。Log Analyticsエージェントを手動でインストールする方法もあるが廃止予定）。 - Respond（対応）
閾値超えや特定のイベントを検出した場合にアラートを出す。
アラートルール作成方法は、スコープ（対象とするリソース）、条件（アラートを出す条件）、アクショングループ（誰にどのような手段でアラートするか）を設定する。
Azure Automation Runbookを利用して、アラートに基づくタスクを自動化可能。
通知にはレート制限がある。
電子メール：1時間で100件以下
SMS：5分間で1件以下
音声：5分間で1件以下
アラートルールについて、メトリックはまとめて1つ作成でOK、ログはイベントごとに作成が必要。
アクショングループについて、連絡先パターンごとに作成が必要。 - Integrate（統合）
外部のツールとの連携が可能。
Network Watcher
ネットワーク監視・検証ができる。以下の機能が良く出題されていた。
- 接続モニター
接続の到達性や待ち時間を確認できる。
Log Analyticsと連携する。Log Analyticsはオンプレも対応しているので、Azure内だけではない。
接続モニターはリージョンごとに必要（接続モニター作成時はリージョンを選択する）。 - ネクストホップ
仮想マシンから特定のIPアドレスへ接続するときのネクストホップを検証する機能。仮想マシンが保持しているルーティングテーブルからネクストホップを判断する。 - パケットキャプチャ
仮想マシン間のパケットを見れる。どういう通信の中身なのかなど調査できる。 - IPフローの確認
VM、ポート、プロトコル、トラフィックの方向 (受信または送信) を指定し接続テストを行う。 - トラブルシューティング
あるVMと別のVMまたはApplicationGatewayの、FQDN、URI、または IPv4 アドレスとの間の接続をテストできる。IPフローに対して、from/toの指定が可能、結果がより詳細に出る。IPフローで分からなかったらトラブルシューティングという流れか・・・？ - NSGフローログ
送信元/先IPアドレス、ポート、プロトコル、NSGによって許可/拒否されたログを記録できる。それを分析するのはLog Analytics。ログの保持ができるのは汎用v2かつNSGと同じリージョンのストレージアカウントのみ。
アクショングループ
アクション グループはAzure サブスクリプションの所有者によって定義された通知設定のコレクションです。 アクショングループはAzure Monitor、Service Health、Azure Advisor のアラートにおいて通知するメールアドレスを指定するために使用されます。※Azure Securityは非対応
ストレージアカウント
ストレージの種類
ストレージアカウントはスタンダードとプレミアムがある
- スタンダード
V1とV2があるがV1はそろそろ廃止なので試験にでないはず - プレミアム
スタンダードより特殊な機能を備えている
ストレージは以下4種類がある
- BLOB
画像などバイナリデータを保管する、ホット・クール・アーカイブ（V2とブロックBLOBのみ）がある - ファイル
ファイル共有ストレージ - キュー
アプリケーションのメッセージ（キュー）を保管 - テーブル
NoSQLの非構造化データをKey-Valueで格納
| アカウント | ストレージ | サービス | 説明 |
|---|---|---|---|
| Standard V1 | – | – | もう使われない（おそらく試験に出ない） |
| Standard V2 | BLOB | Blob Storage | ホット・クール・アーカイブ対応 |
| ファイル | Azure Files | – | |
| キュー | Queue Storage | – | |
| テーブル | Table Storage | NoSQLの非構造化データをKey-Valueで格納 | |
| Premium | BLOB | ブロックBLOB | BLOBデータをブロック分割管理して効率転送 ホット・クール・アーカイブ対応 |
| BLOB | ページBLOB | VMディスク、VHDファィルの格納先として最適 ホットのみ | |
| ファイル | Azure Files （NFS対応） | SMBファイル共有のほかにNFSにも対応 | |
| キュー | – | – | |
| テーブル | – | – |
ストレージ冗長性の種類
以下種類の冗長性（Redundancy）あり
- LRS（ローカル冗長ストレージ）
同一ゾーン（データセンター）に3台、データ同期あり、障害時に自動切換 - ZRS（ゾーン冗長ストレージ）
同一リージョン同一ゾーン（データセンター）に3台、データ同期あり、障害時に自動切換 - GRS（Geo冗長ストレージ）
プライマリリージョンとセカンダリリージョンにそれぞれLRS、リージョン間はデータ同期なし、リージョン障害時は手動切替 - RA-GRS（読み取りアクセスGeo冗長ストレージ）
プライマリリージョンとセカンダリリージョンにそれぞれLRS、リージョン間はデータ同期なし、リージョン障害時は手動切替、ただし読み取り専用アクセスは平時も障害時も可能 - GZRS（Geoゾーン冗長ストレージ）
プライマリリージョンにZRSとセカンダリリージョンにLRS、リージョン間はデータ同期なし、リージョン障害時は手動切替 - RA-GZRS（読み取りアクセスGeoゾーン冗長ストレージ）
プライマリリージョンにZRSとセカンダリリージョンにLRS、リージョン間はデータ同期なし、リージョン障害時は手動切替、ただし読み取り専用アクセスは平時も障害時も可能
| 冗長性 | ゾーン冗長 | Geo冗長 | プライマリ リージョン | セカンダリ リージョン | セカンダリ 読み込み |
|---|---|---|---|---|---|
| LRS | 3台 | ||||
| ZRS | 〇 | 3台 | |||
| GRS | 〇 | 3台 | 3台 | ||
| RA-GRS | 〇 | 3台 | 3台 | 〇 | |
| GZRS | 〇 | 〇 | 3台 | 3台 | |
| RA-GZRS | 〇 | 〇 | 3台 | 3台 | 〇 |
ストレージ種類ごとの冗長性マップ
ストレージ種類ごとに冗長性の選択可否は以下のとおり
| アカウント | ストレージ | サービス | LRS | ZRS | GRS | RA-GRS | GZRS | RA-GZRS |
|---|---|---|---|---|---|---|---|---|
| Standard V2 | BLOB | Blob Storage | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 |
| ファイル | Azure Files | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | |
| キュー | Queue Storage | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | |
| テーブル | Table Storage | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 | |
| Premium | BLOB | ブロックBLOB | 〇 | 〇 | ||||
| BLOB | ページBLOB | 〇 | ||||||
| ファイル | Azure Files | 〇 | 〇 |
共有アクセス署名 (SAS)
Azure Storage リソースへの制限付きアクセス権を付与する URI
その他
ストレージ アカウントでACL（Access Control List）を利用することで、ディレクトリおよびファイル レベルでファイル共有に対するアクセス許可が可能となります。Access Control List（ACL）はアクセス権のセット（集合体）であり、システムのセキュリティを確保するためのアクセス制御の仕組。ACLを利用することにより、ディレクトリやファイルレベルで共有設定が可能となる。
ストレージ アカウントには世界中のどこからでも HTTP または HTTPS 経由でアクセスできる Azure Storage データ用の一意の名前空間を利用しており、世界中からアクセスすることが可能。そのため、グローバルに一意の名前にする必要がある。
Shared Access Signature (SAS) を使用すると、ストレージ アカウント内のリソースへのセキュリティで保護された委任アクセスが可能になります。Azure Storage では、次の 3 種類の Shared Access Signature がサポートされています。
・ユーザー委任 SAS
・サービス SAS
・アカウント SAS
ユーザー委任 SAS は、Microsoft Entra資格情報と、SAS に指定されたアクセス許可によって保護されます。 また、ユーザー委任 SAS はBLOB ストレージにのみ適用されます。
AzCopy はストレージ アカウント間の BLOB またはファイル コピーに利用できるコマンドで、Windows10とMacOSとLinuxに対応。
Azure Filies共有は同じリージョンのみ。
テンプレート
ARM（Azure Resource Manager）とDSC（Desired State Configration）がある
ARMはInsrastructure as Code（インフラ構成）、DSCはConfigration as Code（さらに詳細設定）
ARM
ARMテンプレート内で暗号化は “encription”セクションで記述される。
アクセス許可はVirtualNetworkRules と IpRulesで設定する、設定が無い場合はデフォルトのネットワーク設定が適用される。ネットワークのデフォルト設定は [Allow] 。ストレージ アカウントでは、Shared Access Signature (SAS) を使用したアクセスが許可されており、IP ルールは構成されていない。有効な Shared Access Signature (SAS) が提供されている場合、各ホストはインターネット経由でストレージアカウントにアクセスできる。
ARMテンプレートからVMをデプロイする際は、リソースグループを選択する
DSC
PowerShell Desired State Configuration (DSC)を用いてAzure Automation State Configuration を構成すると、各リソースの状態をダッシュボードで確認することができます。それにより、すべての仮想マシンでNGINXが使用可能であることを確認することが可能となります。
オンプレとの接続
オンプレとの接続種類
オンプレとのつなぎ方は大きく3種類（P2S、S2S、ExpressRoute）ある。
P2S（Point to Site）
Azureとオンプレの端末をつなぐ。
Azure上にVPNゲートウェイが必要。
VPN クライアント構成 zip ファイルをダウンロードして、ユーザーがデバイスにインストーラー パッケージをインストールする必要あり（クライアント証明書などをインストール？）。
128台までという制限あり。
Windows クライアントがクライアント デバイスから Azure に VPN 接続を開始するには、クライアントデバイスの管理権限が必要。
ルートベースの仮想ネットワークゲートウェイにしか対応していないため、ポリシーベースの仮想ネットワークゲートウェイを利用できない
S2S（Site-to-Site）
Azureとオンプレのゲートウェイをつなぐ。
Azure上にVPNゲートウェイとローカルネットワークゲートウェイが必要。
Azure→VPNゲートウェイ→ローカルネットワークゲートウェイ→オンプレの順。
ExpressRoute（閉域網）
AzureのExpressRouteサービスを利用して、閉域網でつなぐ
ExpressRouteゲートウェイが必要。
その他
仮想WANと仮想ハブ
仮想WANと仮想ハブを組み合わせてハブ アンド スポーク アーキテクチャを構成することにより、データセンター間のネットワーク待ち時間を最小限に抑えることができます。仮想ハブはデータセンターごとに作成することが必要となるため、今回の構成に必要な仮想ハブは3つとなります。複数の仮想ハブに対して仮想WANは１つだけ設定することでハブ アンド スポーク アーキテクチャを構成することができます。
Azure Import/Export
データ移行用ディスクドライブを利用して大量データをAzure環境に移行するサービス。データ移行用ディスクドライブをオンプレ機器につないでデータ抽出後に、Azure データセンターにディスクドライブを郵送して、Azure Blob Storage と Azure Files に大量のデータをインポートする。 さらに、Azure Import/Export ではAzure Blob Storage から（※Azure Filiesはエクスポート非対応）ディスクドライブにデータを転送し、オンプレミスのサイトに送付できます。
作成手順
１．仮想 WAN を作成する
[WAN の作成] ページの [基本] タブで、フィールド入力を行い ユーザーの利用環境に適用します。
２．仮想ハブの基本設定を構成する
仮想ハブは、サイト間、Azure ExpressRoute、またはポイント対サイト機能のためのゲートウェイを含めることができる仮想ネットワークです。[ハブ] ページで、 [+ 新しいハブ] を選択して、 [仮想ハブを作成する] ページにおいて仮想ハブを作成します。
３．サイト間 VPN ゲートウェイの設定を構成する
[仮想ハブの作成] ページで [サイト間] をクリックして [サイト間] タブを開きます。サイト間接続性設定を構成してから、ハブとサイト間 VPN ゲートウェイを作成します。
４．サイトを作成する
必要な数のサイトを作成します。 今回は大阪オフィスと東京オフィスの２つのサイトを作成します。
５．サイトをハブに接続する 。
作成したハブのページで、左側のペイン [接続] の下にある [VPN (サイト間)] をクリックして、[VPN (サイト間)] ページを開きます。[サイトの接続] ページで、設定を構成します。
オンプレファイルサーバを移行する
移行手順
手順1：Azure FileSyncエージェントを設定します。
オンプレミスファイルサーバーにAzure FileSyncエージェントをインストールします。Azure File Syncエージェントは、Windows ServerをAzureファイル共有と同期できるようにするダウンロード可能なパッケージです。
手順2：オンプレミスファイルサーバーを登録します。
これはWindowsServerをStorageSyncServiceに登録することを意味しています。WindowsServerをStorageSync Serviceに登録すると、サーバー（またはクラスター）とStorage SyncServiceの間に信頼関係が確立されます。
手順3：同期グループとクラウドエンドポイントを作成します。
同期グループは一連のファイルの同期トポロジを定義します。同期グループ内のエンドポイントは相互に同期されます。同期グループには、Azureファイル共有と1つ以上のサーバーエンドポイントを表す1つのクラウドエンドポイントが含まれている必要があります。サーバーエンドポイントは登録済みサーバー上のパスを表します。
手順4：サーバーエンドポイントを追加します。
サーバー エンドポイントを追加して、サーバー エンドポイントで Azure ファイル共有の変更内容を事前に呼び戻すように設定します。
オンプレのHyper-Vサーバを移行する
レプリケーションポリシー設定
実施期間、復旧ポイントの保持履歴、アプリ整合性スナップショットの頻度などを定義したプリケーションポリシーを設定する
Hyper-Vサイトの作成
レプリケートするVMを含むHyper-Vホストをサイトに追加します。 その後、Azure Site Recovery プロバイダーと Azure Recovery Services エージェントをダウンロードして各ホストにインストールし、コンテナーに Hyper-V サイトを登録します。
Recovery Services コンテナーの作成
オンプレミスの Hyper-V VMに対して、 Azure へのディザスター リカバリーを構成する前にRecovery Services コンテナーを準備する必要があります。Recovery Services コンテナーはバックっプデータを格納する Azure のストレージ エンティティです。 Recovery Services コンテナーを使用して、IaaS VM (Linux または Windows) や Azure SQL データベースなどのさまざまな Azure サービスのバックアップ データを保持できます。
Azure Files
ファイルサーバのPaaS
Azure File Sync
手順
- ストレージ同期サービスのデプロイ
- Azure File Sync で使用する Windows Server の準備
- Azure File Sync エージェントをインストールする
- Windows Server をストレージ同期サービスに登録する
- 同期グループとクラウド エンドポイント（Azure Filesのファイル共有）を作成する
- サーバー エンドポイント（エージェント入りのサーバー）を作成する
構成
サーバーエンドポイントとクラウドエンドポイントは1対1と限らず、サーバーエンドポイントを複数、クラウドエンドポイントを1つの構成が可能です。サーバエンドポイントは複数サーバ可能だが、ディレクトリ名が重複すると不可。
ネットワーク
NAT Gateway
Azure NAT Gateway はフル マネージドで回復性の高いネットワーク アドレス変換 (NAT) サービスです。 Azure NAT Gateway を使用すると、プライベートネットワーク内にあるVMからアウトバウンドインターネット接続が可能となります。これによって、プライベートネットワーク内のVMに対するソフトウェアのダウンロードなどの更新ができるようになります。
パブリックサブネットにNATゲートウェイを構成することで、すべてのアウトバウンド接続に NAT ゲートウェイの静的パブリック IP アドレスが使用されます。この 静的パブリック IP アドレスを利用して、NATゲートウェイはプライベートネットワーク内のVMにパブリックIPアドレスを割り当てて、インターネットへのアウトバウンドアクセスが可能なようにアドレス交換を実施します。
ロードバランサー
Basic Load Balancerは単一の可用性セットまたは仮想マシンスケールセット内の仮想マシンに対するロードバランシングをサポートしています。
Standard Load Balancerのバックエンドプールは単一の仮想ネットワーク内の任意の仮想マシンまたは仮想マシンスケールセットをサポートしています。
自動フェールオーバーを利用しアクティブ/アクティブ構成で実行されるためにはHAポートを有効にする必要があります。そして、HAポートはStandartd Load Balancerでのみ利用可能です。高可用性 (HA) ポートは負荷分散規則の一種であり、内部 Standard Load Balancer の すべての ポートに到着するすべての トラフィックの負荷分散を行います。HA ポート負荷分散規則は仮想ネットワーク内のネットワーク仮想アプライアンス (NVA) の高可用性と拡張性を保持するために利用されます。
１つのサブネットに配置された１つのバックエンドプールには異なるIPアドレスの複数の仮想マシンやIPアドレス範囲を有するスケールセットを設定することができます。ロードラバランサーのバックエンド プールは指定された負荷分散規則のトラフィックを処理するリソースのグループを定義します。後から仮想マシンと仮想マシンスケール セットを作成する予定の IP アドレス範囲を使用してバックエンド プールを事前に割り当てる場合は、IP アドレスと VNET ID の組み合わせによってバックエンド プールを構成します。
仮想アプライアンスを使用する際にはFloating IPを使用する必要があります。しかしながら、Subnet-Aには、Subnet-BとSubnet-C間でネットワークトラフィック検査を実行する2つのネットワーク仮想アプライアンス(NVA)が含まれています。既に仮想アプライアンスが設定されているため、追加でFloating IPを設定する必要はありません。
Floating IPとは、ロードバランサーのフロントに設定するIPのように、複数の機器で共有されるIPアドレスのこと。
| 機能 | Standard | Basic |
|---|---|---|
| バックエンドプール | 最大 1,000 インスタンス | 最大 300 インスタンス |
| 単一の仮想ネットワーク内の任意の仮想マシン、または仮想マシン スケール セット | 単一の可用性セットまたは仮想マシン スケール セット内の仮想マシン | |
| 正常性プローブ | TCP、HTTP、HTTPS | TCP、HTTP |
| 可用性ゾーン | 受信トラフィックと送信トラフィック用のゾーン冗長およびゾーン フロントエンド | 使用不可 |
| 診断 | Azure Monitor 多次元メトリック | Azure Monitor ログ |
| HA ポート | 内部ロード バランサーで使用可能 | 使用不可 |
| 送信規則 | 宣言型の送信 NAT 構成 | 使用不可 |
| 管理操作 | ほとんどの操作は 30 秒未満 | 一般に 60 ～ 90 秒以上 |
| SLA | 99.99% | 使用不可 |
通信制御
デフォルトは同じVNet上のリソース間は基本的に通信可能（サブネットが異なっていても通信可能）。
Azure DNS
プライベートDNSはVNetにリンクする必要あり。
DNSのリンクを自動登録有効にした場合は1つのみ、無効にした場合は複数リンクが可能。
自動登録設定は仮想ネットワークリンク作成後に変更することができる。
自動登録が有効化されたプライベートゾーンにリンクされている仮想ネットワークにおいて仮想マシンが起動すると、その仮想マシンはその仮想ネットワークがリンクされたプライベートDNSゾーンに自動的に登録されます。その際は、仮想マシンはプライベート IP アドレスを指す A レコードとしてプライベートゾーンに登録されます。
パブリック Azure DNS ゾーンには自動登録機能はないため、どのVMであっても自動で登録されることはありません。管理者がVMを指定してexample.comに登録する必要があります。
DNSとVMのリンクはリージョンをまたいで可能
ポート番号
有名どころは覚えておく必要があるぽい
RDP (TCP 3389 ※UDPではない)、SMB（445）
ピアリング
仮想ネットワークはお互いのCIDRが重複していない限りは、リージョンが異なっていてもピアリング接続を構成することが可能。
仮想ネットワークを別の仮想ネットワークにピアリング接続した後に、仮想ネットワークのアドレス空間に対してアドレス範囲を追加したり、削除したりすることはできません。 アドレス範囲を追加または削除したい場合は、一旦設定済みのピアリングを削除する必要があります。その後、アドレス範囲を追加または削除してから、仮想ネットワーク間のピアリングを再作成します。
App Service
App Serviceを作成するにはApp Service プランが必要。
App Service プランは以下定義が必要で複数アプリを作成可能。つまり同OS・同リージョンである必要あり。
・オペレーティング システム (Windows、Linux)
・リージョン
・VM インスタンスの数
・VM インスタンスのサイズ (小、中、大)
・価格レベル
個々にロードバランサーと仮想マシンを構成する場合と比較して、コストを抑えることができる。
異なるオリジンにある選択されたリソースへのアクセス権を与えるにはCORSを設定する必要がある。
App Service では独自の診断機能によって、ホストされたアプリケーションのデバッグを容易に行うことができます。App Service 内のアプリケーションへの接続エラーの詳細を確認するためには、Web サーバーのログ記録を取得することが必要です。App Service では以下の2つのログ記録を取得できます。
- アプリケーションのログ記録
アプリケーションのコード実行にかかるメッセージのログが記録されます。Web フレームワークや言語の標準ログパターンに基づいて、ログ取得されるメッセージは アプリケーションコードから生成されます。 ログメッセージにエラーの重要性に基づいて、ステータス（重大、エラー、警告、情報、デバッグ、トレース）が割り当てられます。アプリケーションのログ記録を有効にするときに、重大度レベルを設定することにより、ログ記録の詳細度を指定できます。 - Web サーバーのログ記録
W3C 拡張ログ ファイル形式の生 HTTP 要求データが取得されます。 ログ メッセージには、HTTP メソッド、リソース URI、クライアント IP、クライアント ポート、ユーザー エージェント、応答コードなどのデータが含まれます。
スワップされる設定とされない設定がある
【スワップされる設定】
一般設定 (フレームワーク バージョン、32/64 ビット、Web ソケットなど)
※Webソケットとは、ブラウザとウェブサーバーとの間で双方向通信を行うための通信規格
アプリ設定 (スロット固有として構成可能)
接続文字列 (スロット固有として構成可能)
ハンドラー マッピング
パブリック証明書
Web ジョブ コンテンツ
ハイブリッド接続 *
サービス エンドポイント *
Azure Content Delivery Network *
パスのマッピング
アスタリスク (*) 記号付きの機能は、スワップされない予定です。
【スワップされない設定】
発行エンドポイント
カスタム ドメイン名
パブリックでない証明書と TLS/SSL 設定
スケールの設定
Web ジョブ スケジューラ
IP 制限
常時接続
診断設定
クロスオリジン リソース共有 (CORS)
仮想ネットワークの統合
マネージド ID と関連する設定
サフィックス _EXTENSION_VERSION で終わる設定
| プラン | 用途 | 特徴 | ディスク領域 | カスタムドメイン | 最大インスタンス数 |
|---|---|---|---|---|---|
| Free | 試験、実験、学習 | – 1日あたりのCPU時間制限あり（60分）。 – プロダクションワークロードには非対応。 | 1 GB | 1 | |
| Basic | 低トラフィックアプリ | – トラフィック処理が低いアプリ向け。 – トラフィック管理機能不要。 | 10 GB | 〇 | 3 |
| Standard | プロダクションアプリ | – アプリの本番運用向け。 – トラフィック管理機能あり。 | 50 GB | 〇 | 10 |
バックアップ
Azure Backup
Recovery Services コンテナー（Recovery Services Vaultとも言う）をリージョンごとに作成する必要あり
古いOSでなければバックアップ可能（WindowsかLinuxかでプロセスは異なる）
自動シャットダウン中のVMに対するバックアップもサポートされているため、自動シャットダウンの設定が有効化されていてもバックアップを取得することが可能
Recovery Services コンテナー間でバックアップデータを移動する操作はAzure Backup ではサポートされていません。 新しいリージョンにバックアップデータを移動させたい場合は、そのリージョン内にリソースを移動させてから、新しいリージョン内のRecovery Services コンテナーを利用してバックアップする必要があります。
バックアップ手順
手順0：バックアップ共同作成者またはバックアップ オペレーターのロールを準備
手順1：Recovery Services コンテナーを作成する
Recovery Services コンテナーは時間の経過と共に作成される復旧ポイントやバックアップデータなどを格納する Azure のストレージ エンティティです。そこにはバックアップ関連の操作を実行するためのインターフェイスが用意されています。 たとえば、オンデマンドのバックアップの作成、復元の実行、バックアップ ポリシーの作成などの操作です。
手順2：バックアップ ポリシーを適用する
既定のポリシーでは1 日に 1 回VM がバックアップされます。 毎日のバックアップは 30 日間保持されます。インスタント回復スナップショットは 2 日間保持されます。
手順3：バックアップする VM を選択する
[仮想マシンの選択] ペインが開きます。 ポリシーを使用してバックアップを作成する VM を選択します。 [OK] をクリックします。
手順4：VM のバックアップを有効化する
保護されたリソースのバックアップ ジョブを実行すると、Recovery Services コンテナー内に復元ポイントが作成されます。 復元ポイントのいずれかを使用して、データを特定の時点に復元できます。VM バックアップを有効にするには、[バックアップ] で [バックアップの有効化] を選択します。 これにより、ポリシーがコンテナーと VM にデプロイされ、Azure VM で実行されている VM エージェントにバックアップ拡張機能がインストールされます。
手順5：バックアップ ジョブを開始する
初回バックアップはスケジュールに従って実行されます。バックアップ センターに移動し、[バックアップ インスタンス] メニュー項目を選択して、主導で実行することも可能です。
Azure Site Recovery
BCPまたはDR用のサービス
レプリケーションとフェールオーバー機能がある
レプリケーションできる条件は、Bitlocker非対応、第2世代のLinux VMはNG、データ量は第1世代VMは2TBまで、第2世代VMは4TBまで
Azure Site Recoveryを使用して、AWSにあるEC2インスタンス（VM-A）をAzure環境のVNET-Aに移行するためには、以下のような手順が必要となります。
レプリケーション手順
手順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インスタンスごとにレプリケーションを有効にします。レプリケーションが有効になっている場合、SiteRecoveryはモビリティサービスを自動的にインストールして、レプリケーションを実行します。
手順5：レプリケーションの状態を追跡して監視する
[レプリケート] をクリックすると、レプリケーションの開始ジョブが開始されます。レプリケーションの状態を監視するには、[移行およびモダン化] 内で [サーバーをレプリケートしています] をクリックします。
可用性セット
更新ドメイン（計画メンテなどで一緒に止まる単位）と障害ドメイン（同じラックなど障害時に一緒に泊まる単位）がある。
例えば、更新ドメイン5つ、障害ドメイン3つのの可用性セットにVMを10台置くことにする。
更新ドメイン1つにつき2台ずつ配置されるため、計画メンテで最大2台停止する可能性がある。
障害ドメイン1つにつき3～4台ずつ配置されるため、障害時に最大4台停止する可能性がある。
可用性セットの一部VMのサイズを変更したい場合は、可用性セット内のすべてのVMを停止する必要あり。
リソースグループ
リソースプロバイダーは特定の Azure サービスの機能を有効化するためのセクションです。 たとえば、KeyVault サービスはMicrosoft.KeyVault という名前のリソース プロバイダーで構成されています。
リソースグループに配置されたリソースが作成された日時を特定するためにはアクティビティログを用います。 アクティビティログでは以下のような内容が確認できます。
- サブスクリプション内のリソースに対していつどのような操作が行われたか (作成・変更・削除など)
- 誰が操作を開始したか
- 操作のステータス
- 操作の調査に役立つ可能性のある他のプロパティの値
リソースグループはリージョンに関係なく、リソースグループ内のリソースは様々なリージョンに作成可能
その他 雑メモ
Azure Service Bus
メッセージングサービスのこと
・Azure Service Busサブスクリプション
コンシューマ側の設定
・Azure Service Busトピック
送信者はメッセージをトピックに格納し、トピックが受信者にメッセージを送信する。
トピックはpublisher or subscriber モデルのように、publisher がメッセージを投稿または公開すると、subscriber はそれを読むことができるというメッセージに機能する
・Azure Service Busキュー
送信者はメッセージをキューに格納し、受信者はキューからメッセージを読み出す。
受信者がメッセージを読むまで、メッセージを保持する。
キューはPoint to Point モデルのように、メッセージの行き先が分かっており、特定のタイミングを要求されないメッセージに機能する。
Azure Advisor
Azure Advisorを利用してディスクの状況を確認することも可能です。Azure Advisorはコスト最適化のために、30 日を超えてVM に接続されていないディスクがある場合は、そのディスクの必要性を評価するレコメンデーションが提示されます。
Azure Portalにおいてディスクのプロパティを表示することで、接続されていないディスクを容易に確認することができます。そこではディスクを指定して削除することもできます。それによって、不要なコストを削減することができます。
Azure Key Vault
Azure Key Vaultにパスワードを保存して、適切なアクセスポリシーを設定することでパスワードをプレーンテキストに保存せずに安全に利用できます。この設定により、Azure Resource ManagerテンプレートからKey Vaultに保存されているパスワードを取得することが可能です。Key Vaultではパスワードがプレーンテキスト形式で保存されることはありません。
Docker
Azure Files ボリューム プラグインを使用することで、Azure Filesストレージをファイルシステムのディレクトリとしてマウントして、コンテナとして構成できます。また、ファイル共有を複数のコンテナー間で共有することもできます。これによって、ワークロードで共同作業したり、複数のホストで実行されているアプリケーションの構成やシークレットを共有したりできます。
Azure Files ボリューム プラグインは、Docker コンテナーに Azure Files ベースのボリュームを提供する Docker ボリューム プラグインです。Docker ボリューム プラグインは、Service Fabric クラスターにデプロイ可能な Service Fabric アプリケーションとしてパッケージ化されています。その目的は、クラスターにデプロイされている他の Service Fabric コンテナー アプリケーション用に Azure Files ベースのボリュームを提供することです。
Azure Kubernetes Services（AKS）クラスター内で実行されているPodのIPアドレスを使用してApp-Aに接続する際は、Azure Container Networking Interface (CNI) ネットワークを使用します。Azure Container Networking Interface (CNI) ネットワークを使用すると、すべてのポッドがサブネットからIPアドレスを取得して、直接接続することができます。これらのIPアドレスはネットワーク空間全体で一意である必要があります。
Azure CNI コンテナー ランタイムがネットワークプロバイダーに要求を行えるようにする、ベンダー中立のプロトコルです。 これはポッドとノードに IP アドレスを割り当て、既存の Azure 仮想ネットワークに接続する際に IP アドレス管理 (IPAM) 機能を提供します。
SQLサーバのDockerイメージはBLOBストレージを利用する必要あり。
Azure Policy
ポリシー定義
一つ一つのルールのこと
イニシアチブ定義
複数のポリシー定義をひとまとめにしたもの
ライセンスの割り当て
グループにMicrosoft Entra Premium P2ライセンスを割り当てた際に、グループ内のユーザには継承されるが、グループ内のグループには継承されない。
VMホストの変更
サブスクリプションを変更しても変わらない
Azure ポータルのVMメニューの更新管理ブレードで、更新を有効にしても変わらない
再デプロイすると変わる
