契約形態
- Azureダイレクト
- Azure EA
- Azureインオープン
- CSP
複数サブスクリプションのメリット
- 請求書の分割
- アクセス権の分離
- クォータ管理の分離
リソースマネージャとリソースプロバイダ
リソースマネージャがAPIを受け付けて、リソースプロバイダがリソースを作成する。
リソースプロバイダには、Microsoft.Compute、Microsoft.Storage、Microsoft.Webなどがある。
新しいサブスクリプションを取得した直後はリソースプロバイダが登録されていない。リソースを作成すると自動でリソースプロバイダが登録される。但し、一部のリソースは手動で登録が必要。
リソースの移動
ほぼ代表的なリソースはすべて別のリソースグループやサブスクリプショングループに移動できる。
管理ツール
- Azureポータル
- Azure CLI
- Azure PowerShell
- Azure Cloud Shell
- Azure Mobile App
ARMテンプレート
テンプレートの構造
- $schema
- contentVersion
- parameters：デプロイするときに入力可能なパラメータ
- variables：テンプレート内で使用する変数
- resources
- outputs
Azure AD
エディション
- Azure AD Free
- Azure AD Office 365 アプリ
- Azure AD Premium P1
- Azure AD Premium P2
テナント
テナントという単位で組織を管理する。テナントには1つのサブスクリプションが紐づけられる。
主な機能
- オブジェクトの管理
- MFA
- 条件付きアクセス
- セルフパスワードリセット
デバイス登録
- Azure ADデバイス登録
- Azure AD参加
- ハイブリッドAzure AD参加
環境管理
- タグ
- ロック
- クォータ
- Azure Advisor：使ってないリソースの削除を勧めてくれたりする
- Azure Policy
- RBAC
- 管理グループ：複数のサブスクリプションをグループ化
コスト管理
主なコスト
- 仮想マシン
- ストレージ
- ネットワーク：アウトバンド通信にコストがかかる
ツール
- 料金計算ツール：料金のシミュレーション
- コスト分析：集計にタグを活用できる
- 予算：過大なコストの発生を防ぐ
コスト削減
- 予約の利用
- Azureハイブリッド得点
- Visual Studioサブスクライバー向けのAzureクレジットの活用
Azure Policy
適用範囲（リソース以外すべてに適用できる） * テナント * 管理グループ * サブスクリプション * リソースグループ
※ 上位に割り当てられたポリシーを継承する
ポリシー定義
- 使用できるリソースの種類
- 許可されてないリソースの種類
- 許可されている場所
- 許可されている仮想マシンサイズSKU
- ストレージアカウントを許可されているSKUで制限する必要がある
- タグとその値をリソースに追加する
イニシアティブ定義
- 複数のポリシーをグループ化
その他
- ポリシー定義は既存のリソースに対しても評価される
RBAC
特徴
代表的な組込みロール
ロールの構造（一部）
- actions
- notActions
- assignableScopees
ロールの評価
- 複数のロールが割り当てられた場合、割り当てられたロールの和集合が実際のアクセス許可となる。但し、各ロールのnotActionsは加算されない。
仮想マシン
仮想マシンの実体とは
構成要素
- CPU
- メモリ
- ディスク
- ネットワークインターフェース
ディスク
イメージ
可用性セット
可用性ゾーン
- 複数の仮想マシンをデータセンターをわけて配置する
代表的な拡張機能
- カスタムスクリプト
- PowerShell DSC拡張機能
監視
- 診断エージェント：Diagnosticsエージェント。ゲストOSやアプリケーションが生成するログやパフォーマンスデータをストレージアカウントに収集してくれる
接続方法
- RDP
- SSH
- Bastion
Bastion接続
- RDPやSSHポートを外部公開せずにポート443を使ってAzureポータル上で仮想マシンに接続できる。
- 仮想マシンが配置されているのと同じ仮想ネットワークに、Bastionだけを配置する専用のサブネットを作成する。サブネット名は「AzureBastionSubnet」でなければならない。サブネットアドレスのプレフィックス値は26以下でなければならない。
- その後Bastionを作成してパブリックIPアドレスを割り当てる。仮想マシンにパブリックIPアドレスを割り当てる必要はない。
スケールセット
スケールセットの設定項目
- 初期インスタンス数
- スケーリングポリシー
- スケールインポリシー
- アップグレードモード：手動、自動、ローリングの3種類
- オーバープロビジョニング：有効だと、実際に要求された数より多くの仮想マシンを起動する。正常にプロビジョニングが確認できたときに余分なマシンを削除。これにより、展開時間が短縮される。
スケーリング設定
- スケールアウトの規則は、いずれかが満たされていれば実行される
- スケールインの規則は、すべてが満たされている場合に限って実行される。
ストレージアカウント
ストレージサービスの種類
- Blobコンテナ
- Azure Files
- Azure Queue Storage
- Azure Table Storage
ストレージアカウントの種類
※ アカウントの種類によって、サポートできるストレージサービスが異なる。
- Standard汎用v2
- PremiumブロックBLOB
- Premiumファイル共有
- PremiumページBLOB
レプリケーションオプション
- LRS
- データセンター内で3つのディスクにコピー
- データセンターが火災や洪水になると利用できない
- ZRS
- 3つのゾーンにデータをコピー
- GRS
- データセンター内で3つのディスクにコピー
- さらに別のリージョンのデータセンター内で3つのディスクにコピー
- 合計6つのディスクにコピーされてる
- 平常時はプライマリリージョンのみアクセス可能
- RA-GRS
- 平常時でもセカンダリリージョンは読み取りアクセス可能
- 負荷分散できる
- GZRS
- 3つのゾーンにデータをコピー
- さらに別のリージョンのデータセンター内で3つのディスク
- 合計6つのディスクにコピーされてる
- 平常時はプライマリリージョンのみアクセス可能
- GRSとはプライマリリージョンでのレプリケーションに差異あり
- RA-GZRS
- 平常時でもセカンダリリージョンは読み取りアクセス可能
- 負荷分散できる
ストレージセキュリティ
Azure Blob Storage（Blobコンテナ）
ストレージの形式
BLOB Storageのリソース
- ストレージアカウント > コンテナ― > バイナリラージオブジェクト という階層構造になっている
コンテナーのパブリックアクセスレベル
※1 下記はコンテナーでの設定
※2 インターネット経由でのアクセスを行うには、ストレージアカウントの設定で「BLOBパブリックアクセスを許可する」を有効にしておく
- プライベート
- インターネット経由でのアクセス禁止
- Azure内部からのアクセスのみ可能
- BLOB
- インターネット経由でのアクセス可能
- 但し、ファイルの一覧は取得不可
- コンテナ―
- インターネット経由でのアクセス可能
- ファイルの一覧は取得可能
BLOBの種類
コンテナーにファイルをアップロードする際に、「BLOBの種類」というパラメータを選択する必要がある
- ブロックBLOB
- 一般的なファイルをアップロードする場合に適している
- 追加BLOB
- BLOBの末尾へのブロック追加ができる。既存ブロックの更新、削除はできない
- ログの保管などに適している
- ページBLOB
アクセス層
- ホット
- クール
- アーカイブ
- 読み取りも変更も不可
- 読み取りたい場合はホットやクールに切り替えが必要（リハイドレート）数時間以上かかる場合がある。
ライフサイクル管理
- ライフサイクル管理ポリシーを設定し、アクセス層を自動で変更したり、ファイルを削除できる。
Azure Files
特徴
ストレージ層
- Premium
- トランザクション最適化
- ホット
- クール
接続
- ポート番号 445が許可されている必要がある
Azure File Sync
- ストレージ同期サービス
- Azure File Syncで使用するサーバーを登録するための最上位オブジェクト
- 同期グループを管理する
- 登録済みサーバー
- ストレージ同期サービスに対象のWindowsサーバーを登録したもの
- Azure File Syncエージェント
- Windowsサーバーにインストールするエージェントプログラム
- クラウドエンドポイント
- Azureファイル共有へのポインター
- サーバーエンドポイント
- 同期グループ
- クラウドエンドポイントとサーバーエンドポイント間の同期リレーションシップ
実装手順
- ストレージ同期サービスのデプロイ
- 同期対象のWindowsサーバーの準備
- WindowsサーバーへのFile Syncエージェントのインストール
- ストレージ同期サービスへのWindowsサーバー登録
- 同期グループおよびクラウドエンドポイントの作成
- サーバーエンドポイントの追加
サービスエンドポイント
- インターネット経由でのアクセスをブロック
- 指定した仮想ネットワークからのみアクセス許可
- 同じリージョン内の仮想ネットワークとサービスインスタンスの間で機能する
暗号化キー
種類
ネットワークサービス
種類
仮想ネットワーク
- 仮想ネットワークをまたぐ通信はできない
- またぐ場合、ピアリング設定やVPNゲートウェイを使用する
- 既定では同じ仮想ネットワーク内のサブネットはすべて通信可能
- 後からアドレス空間の拡張が可能
- ピアリング構成済みの場合は、一旦ピアリングを削除して、アドレス空間を変更後に再度ピアリングを設定する
プライベートIP
- Azure内部DHCPサービスにより自動で割り当て
- 静的な割り当ても可能。アドレスを指定できる
パブリックIP
- 静的な割り当ても可能。アドレスは指定不可
- DNS名を設定できる
- <DNSラベル名>.<リージョン名>.cloudapp.azure.com
- SKU
- Basic
- Standard
- Basicに加えて可用性ゾーンがサポートされる
ネットワークセキュリティグループ
- ネットワークインターフェース（NIC）またはサブネットに関連透けることができる
- NICとサブネット両方にNSGを関連付けた場合は、両方の規則で許可されている必要がある
- 1つのNIC（またはサブネット）に関連付けられるNSGは1つだけ
- NSGのリージョンと関連付け先のNIC（またはサブネット）のリージョンは同じである必要がある
- 受信/送信セキュリティ規則に分かれている
- 規則は優先度順にチェックされ、優先度の高い規則に一致した場合、それより引く優先度の規則は適用されない
アプリケーションセキュリティグループ
Azure Firewall
実装手順
- Azure Firewallを配置する仮想ネットワークとサブネットを作成する。既存の仮想ネットワーク上に作成してもよい。サブネット名は「AzureFirewallSubnet」で、プレフィックスは/26以下でなければならない
- Azure Firewallをデプロイする
- ルートテーブルを作成し、サブネットに関連付ける。ルートテーブルではアウトバウンドのトラヒックがAzure Firewallを経由するように設定する。
- ファイアウォールポリシーと規則の作成
規則
- ネットワーク規則
- アプリケーション規則
- アウトバウンドに適用される
- 仮想ネットワークからアクセス可能な宛先をFQDNで指定
- 一致するネットワーク規則が存在しなかった場合のみ適用される
- DNAT規則
Azure DNS
目的
- 例えば、ドメイン名がxxxx.workだった場合、ドメインに対するDNSクエリがAzure DNSに到達するには、親ドメイン workからAzure DNSに委任される必要がある
- 具体的には親ドメインのゾーンでAzure DNSを参照するNSレコードを作成する必要がある（ドメインの販売元であるドメインレジストラーがNSレコードを登録する）
プライベートDNSゾーン
- 解決仮想ネットワーク
- 動的にレコード登録されない
- 登録仮想ネットワーク
ピアリング
異なる仮想ネットワーク間では通信できないので、ピアリングが必要になる。
- 仮想ネットワークピアリング
- 同じリージョン内でのピアリング
- グローバル仮想ネットワークピアリング
- 異なるリージョン間のピアリング
特徴、注意点
- 異なるサブスクリプション、異なるテナント間でもピアリング可能
- 仮想ネットワークのアドレス空間が重複していると、ピアリングできない
- ピアリングは双方向の設定が必要
- ピアリングは推移しない。3つの仮想ネットワークが連なってピアリングされているとき、間にある仮想ネットワークをまたいでの接続はできない。必ず1対1でのピアリング接続が必要
- ピアリング済みの仮想ネットワークでアドレス空間を変更する場合は、いったんピアリングを削除する必要がある
ピアリングの選択肢
VPNゲートウェイ
特徴
- サイト間接続
- オンプレとVnetを接続
- ポイント対サイト接続
- PCとVnetを接続
- Vnet間接続
- インターネットではなく、Azureバックボーンネットワークを経由
サイト間VPN接続手順
- VPN
- ExpressRoute
VPNの種類
※ 一度作成したら変更不可。削除 ＆ 再作成が必要となる。
- ポリシーベース
- IPsecポリシーに基づいて、パケット送信
- サイト間接続でのみ使用可能、SKUはテスト・評価用のBasic SKUに限定
- ルートベース
- 世代毎にSKUタイプがある。Basic SKUはテスト評価用
- Basic SKU以外はBGPをサポート
可用性モード
※ VPNゲートウェイを作成されると、内部的には2つのインスタンスがデプロイされる。この2つのインスタンスは既定でアクティブ / スタンバイになっている
- アクティブ / スタンバイ
- メンテナンスだと切り替えに15秒程度かかる
- 障害だと切り替えに3分程度かかる
- アクティブ / アクティブ
Express Route
選択肢
接続方法
- ポイントツーポイントのイーサネット接続
- Cloud Exchangeでの同一場所配置
- 任意の環境間ネットワーク
2種類のExpress Routeピアリング
- Azureプライベートピアリング
- Vnetとの接続に使用
- VnetのプライベートIPアドレスで接続できる
- Microsoftピアリング
- Azure PaaSサービスとの接続に使用
- パブリックIPのみ
- オンプレ側でNATを使用して、プライベートIPをパブリックIPに変換する必要あり
実装手順
- Express Route回線の作成
- Express Routeピアリングの構成
- Express Routeゲートウェイの作成
- 接続の作成
Virtual WAN
スキップ
ルートテーブル
システムルート
- 既定で、サブネットに対してシステムルートが割り当てられている
- システムルートには既定でいくつかのルート情報が含まれている
- ピアリングやサービスエンドポイントの機能を有効にすると、システムルートにルート情報が追加される
ユーザー定義ルート
- ユーザーが独自に定義するルート情報
- システムルートよりも優先度が高い
- 重複したルートはユーザー定義ルートによりオーバーライドされる
ユーザー定義ルートの作成
- ルートテーブルの作成
- ルートの追加
- サブネットへの関連付け
サービスエンドポイント
- Azure内部からインターネット経由を経由せずにPaaSサービスにアクセスできる
- Vnet側の設定
- サービス側の設定
プライベートエンドポイント（Private Link）
- サービスエンドポイントもプライベートエンドポイントもどちらもインターネット経由せずにPaaSにアクセスできる
- 違いは、サービスエンドポイントがパブリックIPでアクセスするのに対し、プライベートエンドポイントではプライベートIPでアクセスする
実装
- Private Linkからプライベートエンドポイントの作成
- プライベートエンドポイントの名前を選択
- 接続対象のリソースを選択
- プライベートエンドポイントを設置するVnetとサブネットを選択
Azure Load Balancer
スキップ
Azure Application Gateway
スキップ
App Service
特徴
- 手軽にWebアプリケーションとREST APIの実行環境を構築できる
- PaaS。負荷分散や自動スケーリングができる。バージョンアップが用意。
利用可能な言語
App Serviceプラン
- App ServiceはWebアプリを動かすためのコンピューティング環境
- App Serviceプランを作成し、そのうえで動くApp Serviceを作成する
- App Serviceプランの上で、複数のApp Serviceが動く
App Serviceプランの価格レベル
- サイズとSKUによって決定される
- Free、Shared、Basic
- 開発、テスト用。自動スケールなし
- Standard、Premium
- 本番環境向け
- Isolated
- 高速なネットワーク環境で実行するミッションクリティカルなワークロード
デプロイスロット
- Standard以上の価格レベルで利用可能
- 動作している運用スロットとは別に、ステージングスロットを追加し、スワップにより切り替えできる
スケーリング
- スケールアップ/ダウン、スケールアウト/インが可能
- Standard以上であれば、カスタム自動スケーリングが可能
バックアップ
- Standard価格レベル以上で使用可能
- バックアップはストレージアカウントのBlobコンテナに保管される
- 事前にストレージアカウントの作成が必要
コンテナサービス
- コンテナーとは、アプリと実行環境を1つにまとめたもの
Azureのコンテナーサービス
- Azure Container Instances（ACI）
- WinsowsまたはLinuxのコンテナーを簡単に作成
- Azure Kubernetes Service（AKS）
- Kubernetesによるコンテナーオーケストレーションができる
Azure Container Instances（ACI）
特徴
- 高速な起動（数秒）
- インターネット公開もAzure内部のみ、どちらにも対応
- CPU、メモリの柔軟な指定
- Azure Filesでデータ保持
- WinsowsコンテナーとLinuxのコンテナーをサポート
コンテナーインスタンスの作成
- コンテナーイメージのソースを選択（コンテナレジストリから選択）
- CPUのコア数とメモリを指定
- ネットワークの種類を選択（パブリック、またはプライベート）
Azure Kubernetes Service（AKS）
Kubernetesクラスターの作成
※ クラスター作成時に以下のパラメータを設定する
- プリセット構成（Standard等）
- Kubernetesバージョン
- ノードプール
- 仮想マシンスケールセットを有効にする
- ネットワーク構成
ポッドの追加
> az aks install-cli > az aks get-credentials --resource-group <RG名> --name <クラスター名> > kubectl get nodes > kubectl apply -f <YAMLファイル名> > kubectl get pod > kubectl get svc
Azure Backup
- Azure VMのディスクはVHDファイル
- このVHDファイルはストレージアカウントに格納されている
- Azure Backupは増分バックアップを行う
- バックアップデータはRecoevery Servicesコンテナーに保存される
- Recoevery ServicesコンテナーはGRSで構成される。そのため、6重のバックアップデータコピーになる。
3つのシナリオ
- ファイルおよびフォルダーシステム状態の保護
- 仮想マシンの保護
- ワークロードの保護
Recovery Servicesコンテナー
- Azure Backupのバックアップデータ格納先
- Recovery Servicesコンテナーはバックアップするリソースと同じリージョンでなければならない
バックアップの動作
- VMのスナップショットが作成され、バックアップデータとしてRecovery Servicesコンテナーに転送される
- 実行中のWindows VMをバックアップした場合、VSSと連携してアプリ整合性スナップショットを取得する
- Linuxではアプリの整合性は確保されないので、サービス停止してバックアップを取るか、MSが用意したスクリプトを使用する必要がある
実装手順
- Recovery Servicesコンテナーを作成する
- 仮想マシンのバックアップを選択する
- バックアップポリシーを構成する（バックアップ実行時刻や保持期間）
- 最大で9,999日保持することができる
- バックアップを行うマシンを選択する
※ バックアップ有効化後にRecovery Servicesコンテナーを削除するには、バックアップの停止とバックアップデータの完全な削除が必要
「仮想マシンの保護」以外のシナリオ
- ファイルおよびフォルダーシステム状態の保護
- ワークロードの実行場所で「オンプレミス」を選択し、バックアップする内容で「ファイルとフォルダー」を選択する
- MARSエージェントやコンテナー資格情報ファイルのダウンロードなどとともに手順が表示される
- ワークロードの保護
- ワークロードの実行場所で「オンプレミス」を選択し、バックアップする内容で「Microsoft SQL Server」や「Microsoft Exchange」を選択する
仮想マシンの復元オプション
Azure Site Recovery
スキップ
Azure Monitor
Azure Monitorが収集する監視データ
- アプリケーション監視データ
- ゲストOS監視データ
- Azure Monitorエージェント、またはWindows Azure DiagnosticsやLinux Azure Diagnosticsといった拡張機能をVMにインストールする必要がある
- Azureリソース監視データ
- Azureサブスクリプション監視データ
- Azureテナント監視データ
データの種類
- メトリック
- 「モニター」の「メトリック」で参照できる
- ログ
アラート
- メトリックやログに関する条件を指定し、一致する状況でアクションを実行できる
- スコープ（アラートを出す対象）、条件、アクションの3つを指定する
- アクションはアクショングループという単位で指定する
- アクショングループにはAutomation Runbookを実行したり、通知を送信したりする
- 通知にはレート制限がある
- 電子メール：1時間で100件以下
- SMS：5分間で1件以下
- 音声：5分間で1件以下
Log Analytics
特徴
- Azure Monitorの一部として統合された。新しい名称は「Azure Monitorログ」
- ログデータに対してクエリを実行し、絞り込みや分析を行う
- オンプレも監視できる
- 保存したデータ量に基づいて課金。但し、一定量を超えるデータが収集されるまで料金は発生しない
Log Analyticsワークスペース
- Log Analyticsを使用するために、まずLog Analyticsワークスペースを作成する
- ワークスペースが作成できたら、アクティビティログなどをワークスペースに送信する
- Log Analyticsエージェントを使用することで、OSによって生成されるデータをワークスペースに送信できる
Log Analyticsエージェント * Windows用とLinux用がある * Windows用は「Microsoft Monitoringエージェント」（MMA）と呼ばれる * Linux用は「OMSエージェント」と呼ばれる * Azure MonitorエージェントはLog Analyticsエージェントの後継だが、完全に同等ではない * https://learn.microsoft.com/ja-jp/azure/azure-monitor/agents/azure-monitor-agent-migration
アクティビティログとの接続方法
- アクティビティログ > 診断設定 > 診断設定を追加する
- 収集するアクティビティログのカテゴリを選択し、宛先にLog Analyticsワークスペースを選択する
Azureリソースとの接続方法
- Azure StorageやAzure Load Balancerなどと接続するケース
- 対象リソースの「診断設定」 > 診断設定を追加する > 宛先にLog Analyticsワークスペースを選択する
Azure 仮想マシンとの接続方法
- 対象の仮想マシンにLog Analyticsエージェントをインストールする
- Log Analyticsワークスペースの画面で 仮想マシン > 接続 で対象のマシンを選択するとLog Analyticsエージェントがインストールできる
- そのほかにもARMテンプレートやPowerShellを使用する方法がある
Log Analyticsエージェントの構成
- エージェントを使用して監視データを収集するには、インストールとは別に、エージェントを使用して収集する監視データを選択しなければならない
- Log Analyticsワークスペース > エージェント構成 > 収集するデータを指定
監視データの検索
- 監視データの種類毎にテーブルを分けて管理される
- テーブルには以下の種類がある
- Event
- Syslog
- Perf
- AzureActivity
- AzureMetrics
- データ保持期間は最大730日間
- Kusto Query Languageで検索できる
kql Event | search "error" Event | where EventLog == "System"
Network Watcher
Q&A
Azure ADでAKSクラスターへの認証を提供する方法は？
- OaAuth2.0 authorization endpointを作成する
テナントルートマネジメントグループへのアクセスはだれができる？
- 既定では誰もアクセスできない。Azure AD Global Asministratorsであれば自分自身にテナントルートマネジメントグループへのアクセス権限割り当てることができる
- https://learn.microsoft.com/en-us/azure/governance/management-groups/overview#important-facts-about-the-root-management-group
Azure ADでの条件付きアクセスポリシーの設定例は？
- Azureポータルでアクセスしたときに、すべてのユーザがMFAを求められるという要件の場合、設定は以下のようになる
- Select Users & Groups : Where you have to choose all users.
- Select Cloud apps or actions: to specify the Azure portal
- Grant: to grant the MFA.
- Azureポータルでアクセスしたときに、すべてのユーザがMFAを求められるという要件の場合、設定は以下のようになる
外部のパートナー社員がマイクロソフトアカウントでAzureにアクセスしたい場合はどのように設定すればいい？
Azure Import/Exportサービスが使えるストレージアカウントは？
- ストレージアカウントの種類
- Standard General Purpose v2 storage accounts (recommended for most scenarios)
- Blob Storage accounts
- General Purpose v1 storage accounts (both Classic or Azure Resource Manager deployments)
- ストレージサービスの種類
- Import supports Azure Blob storage and Azure File storage
- Export supports Azure Blob storage
- ストレージアカウントの種類
ストレージサービスのTableをサポートしているのはどのストレージアカウント？
- General Purpose v1 storage
- General Purpose v2 storage
Recovery Servicesコンテナーが削除できない場合は何を確認すべき？
- バックアップが停止されていることを確認すべき
Recovery Servicesコンテナーと保護対象のVMは別のリージョンでもいける？
- 保護対象のVMはRecovery Servicesコンテナーと同じリージョンでなければならない
Azure Backupでバックアップできるストレージサービスは？
AzCopyでコピーできるストレージサービスは？
- Azure Blob storage
- Azure File storage
Azure Monitorエージェントで取得したログでアラートを出力する方法は＿
VMを別のVnetに移動するには？
DNSのゾーンファイルのインポート・エクスポートはできるのか？
- Azure CLIであればできる。AzureポータルやAzure Powershellでは不可
- DNSゾーンファイルについて
注意点
VM作成のためにARMテンプレートを作成する場合、リソースグループだけはテンプレートに入れられない。なので、デプロイする際に入力する必要がある。
Desired State Configuration（DSC）でVMのソフトウェア管理を行う場合に、VMは稼働している必要がある
標準の SKU パブリック IP 構成を持つか、パブリック IP 構成を持たないバックエンド プール内の仮想マシンのみをLoad Balancerに接続できます。 VM のパブリック IP は動的であるため、IP は Basic SKU IP である必要があります。このような VM (Basic SKU IP を使用) を Standard SKU ロード バランサーに追加することはできません。パブリック IP を削除するか、Standard SKU IP に変換しない限り、VM は選択のためにバックエンド プール ポータルに表示されません。
- Standard SKU パブリック IP：静的IP
- Basic SKU パブリック IP：動的または静的IP
No more than 20% of the Scale Set upgrading at any time, then 2 machines out of 10 will have maintenance, the 8 remaining VMs will be up.
- Virtual machine scale sets are created with five fault domains by default in Azure regions with no zones. For the regions that support zonal deployment of virtual machine scale sets and this option is selected, the default value of the fault domain count is 1 for each of the zones. FD=1 in this case implies that the VM instances belonging to the scale set will be spread across many racks on a best effort basis.
Each availability set can be configured with up to 3 fault domains and 20 update domains.
Zone-redundant gateways and zonal gateways both rely on the Azure public IP resource Standard SKU. The configuration of the Azure public IP resource determines whether the gateway that you deploy is zone-redundant, or zonal. If you create a public IP resource with a Basic SKU, the gateway will not have any zone redundancy, and the gateway resources will be regional.
