学習した際の備忘録ですが、Az-104を学習する方々の力になればと思います。
殴り書き感があるので時間があるときに編集して見やすくしようと思います

ユーザーに権限付与する方法

(1) RBAC (Role-based Access Control) : ロールを通してユーザーのアクセス許可を制御
(2) PIM (Privileged Identity Management)

セキュリティプリンシパルへのロールの割り当てを永続ではなく期限付きにできる
PIMを使用するならAzureAD側で設定し、永続ロール割り当てはリソース側で行う
PIMは、P2ライセンスで使用可能、サイバー攻撃対策の1つ
ユーザーがロールをアクティブ化する際に上司の承認を要求したり、MFAを要求したりできる

ロールの割り当て

①セキュリティプリンシパル→誰に対して (ユーザー/グループ/サービスプリンシパル/マネージドID)
②ロール定義→ どのようなアクセス権を
③スコープ→どのリソースを対象に (管理グループ/サブスクリプション/リソースグループ/リソース)

Contributorロールでは、Azure RBACでロールを割り当てることはできない→Ownerロールを割り当てる
VM Contributor ロール : VMを管理できるが、VMへのアクセスや接続されているVNetやストレージアカウントへのアクセスはできない
traffic analytics : Owner, contributor, reader, network contributor
2つのテナント間で同期はできない (ただし、ゲストユーザーとしては招待できる)
Azure AD テナントを単体で取得することはできない(Azureサブスクリプションやoffice365にサインアップした際に取得)
User administrator + Global administrator →ユーザーの追加・削除できる
新しいテナントを作成したユーザーのみそのテナントに追加され、グローバル管理者となる(ほかの人は新しいテナントにアクセスできない)

タグ

リソース/RGは、MAX50個のタグをもてる
RGに通用されたタグはリソースには継承されない
ただし、PolicyをRGに適用すればタグはリソースにも適用される
Policyを適用してタグを割り当てても、すでに存在してるものには意味なし
Policyは更新や作成されたタイミングで適用(移動されてきたリソースも意味なし？)

ストレージアカウント

Azureストレージサービスの管理単位
各ストレージサービスに対し、一意の名前空間を割り当て
コストを下げたければ、アクセス層も考慮(hot→cool)
4つのストレージがある
(1) BLOBストレージ : オブジェクトストレージ
(2) Azure Files : SMB3.0でのファイル共有
(3) Tableストレージ : NoSQL
(4) Queueストレージ : メッセージング機能
BLOBストレージには３種類ある
①ブロックBLOB : ドキュメント、メディア、BUに適した
②追加BLOB : ログ
③ページBLOB(Disk) : ランダムアクセスをサポート(VHDファイルはこれ)

レプリケーション

(1) LRS(Local Redundant Storage):ローカル冗長ストレージ

１つのDC(データセンター)にデータのコピーが３つ作成 (1リージョン3レプリカ)
DC全体が利用できなくなったら、データ利用不可
SLA : 11ナイン

(2)ZRS:ゾーン冗長化ストレージ

リージョン内のDCに非同期でレプリケート
3データセンターに１つずつ複製させる(１つのリージョン内)

(3)GRS(Geographically Redundant Storage):地理冗長ストレージ

ローカルコピーの３つ(同じデータセンター内)に加え、別のリージョンにさらにコピーが３つ(同じデータセンター内)保持される
プライマリゾーンで障害が発生すると、セカンダリリージョンにフェールオーバーして業務が継続可能
２リージョン、６レプリカ

(4)RA-GRS: 読み取りアクセス地理冗長ストレージ

GRSに加えて、セカンダリリージョンにあるデータへの読み取りアクセスができる
プライマリが利用できない状態になったとき、セカンダリからデータを読み取る

(5) GZRS : Geoゾーン冗長ストレージ

３つのデータセンターにそれぞれ複製され、セカンダリリージョンのある１つのデータセンターに3つ分レプリケーション

(6) RA-GZRS : 読み取りアクセスgeoゾーン冗長ストレージ

ZRS+GRSの機能を提供

Azure Files

フルマネージドのファイル共有サービス
コンテナを永続的に置くところとして使われる
使い方① : サーバーレスのAzureファイル共有をマウント
使い方② : Azure File Syncを使用してAzureファイル共有をwindowsサーバに同期

Azure File Sync

オンプレミスのファイルサーバーで管理しているファイルをAzure Filesに同期するサービス
SMB, NFS, FTPSなどのプロトコルを使用しオンプレミスのサーバーへアクセス
Azure Fileサービスでは、容量に対する課金に加えてアクセス量による課金がある

手順
(1) ストレージアカウントの作成
(2) ストレージアカウントの「ファイル共有」にファルダ作成
(3)サーバにAzure File Sync Agent をインストール
(4) 「リソースの作成」 → 「Azure File Sync」を選択し、「＋同期グループ」を選択
(5) 「同期グループ」→「サーバーエンドポイントの追加」

Azure Import/Export

物理ディスクから、Azure blob StorageとAzure Filesに大量のデータをインポートできる
汎用v2のストレージアカウント推奨
ジョブごとの利用可能な最大ディスクドライブは10台
Import/ExportにSLAはなく、ベストエフォート対応
windowsシステムでBitLockerを有効にする必要がある
Import...Blob, File
Export...Blob
WAImportExportツール : ドライブの準備および修復用のツール
dataset.csv : コピーするディレクトリの一覧またはファイルの一覧を含むcsvファイ
driveset.csv : マップされるディスクの一覧を含むcsvファイル

Azure Import手順 (Blob or Files)
(1) サーバー(windows)に外付けハードディスクをとりつけ、waimportexport.exeでデータをディスクドライブにコピー(データはBitLockerで暗号化される)
(2) Azure Portalで、インポートジョブを作成(ドライブのジャーナルファイルをupload)
(3) 外付けディスクをAzureのデータセンターに発送
(4) Azure Portalからインポートジョブを更新
(5) ディスクドライブが返送される

②Azure Export (Blobからのみ)

Desired State Configuration (DSC)

構成管理ツール
ps1ファイルに「こうあってほしい状態」を記述しておき、それを実行することで書かれている通りの状態に構成
Azure Automation State Configuration サービスへのVMのブートストラップ
使用例としては、ARMテンプレートとDSCを組み合わせて、テンプレートのデプロイ時にAzureVMにDSC extentionをインストールしDSC用のスクリプトを実行してos設定を自動するなど
構成を特定の状態に保持続けるための仕組み

あるべき状態を定義

定義に基づいて設定を変更
定期的に設定をチェックし正しい状態を維持
Azure Automation State Configuration使用

(1) 構成ファイル(XXX.ps1)をAzure Automation State Configuration にupload
(2) 構成をノードの構成としてコンパイルする (Set-AzAUtomationDSCCompilationJob)
(3) 管理されるVMを登録する
(4) コンパイル済みのノード構成を管理対象ノードに割り当て
(5) 管理対象ノードの準拠状態を確認する

Azure Container Networking Interface (CNI)

Azure VNetからnodeとPodにIPを割り当てる
すべてのPodがサブネットからIPアドレスを取得し直接アクセスできる
すべてのAzure VNet に存在するために他のAzureやオンプレミスのリソースにルーティングできる
すべてのIPアドレスがVNetから割り当てられるので、十分な数のIPを提供できるサブネットが必要

Azure Kubernetes Service (AKS)

AKS自体の利用やk8sクラスターには料金がかからないということ
k8sのノードの利用に対してだけ課金を行う
簡略化されており、自動アップグレード、スケーリング、自己修復などを簡単に操作なしに利用することできる
マスターはAKSによって管理されるが、ノードは自分で管理する必要あり
コンテナランタイム: AKSではDockerでなくMobyを使用
[$az aks get-credentials] : ~/.kube/config の取得

ロードバランサ

Basic LBとStandard LBがある
Basic LBは、SLAなし、バックエンドプールは単一の可用性セット or VMSS
Standard LBは、SLA(99.99)で、バックエンドプールに単一のVMもOK

バックエンドプール

VM, VMSSを追加できる(Standard LBの場合)
Public IPを持っているか、Public IPなしで同じ仮想ネットワーク上にあれば
VMにPublic IPアドレスが付与されている時は、候補としてVMが表示されないため、Public IPはデタッチする必要あり
LBがバックエンドプールで管理しているのは、VMではなくNICのIP構成

スティッキーセッション(セッションアフィニティ)

ユーザーのセッションを特定のターゲットにバインドするように設定
ユーザーのセッション中のすべてのリクエストが同じターゲットに送信される
クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立つ
使用するにはクライアントがcookieをサポートする必要がある

高可用性(HA)ポート

負荷分散規則の一種
stanrdardで対応、Basicでは使用不可
内部standard Load Balancerのすべてのポートに到着するすべてのフローの負荷分散を簡単に行う方法を提供

Direct Server Return(DSR)

LBの機能のひとつ
クライアントからLB経由でアクセスすれば応答も、サーバ→LB→クライアントとLBを経由する
DSRを使うとLBを経由せずサーバ→クライアントに直接応答がいく
LBの負荷分散規則の設定のところで選択できる
LB側での処理が必要なくなりシステム全体としてスループット向上

Floating IP

クラスタリング構成の複数のサーバがあるときに、クライアント側にサーバが切り替わったことを意識させないように、クラスタ内で共有してもつ仮想IPのこと

インバウンドNATルール

接続時のポート番号が一般的なポート番号を使わなくて済むため、ポート番号を知らないとアクセスできない状態になる
接続時のポート番号をサーバーごとに分けるので、目的のサーバーに必ず到達することができる
LBでPort番号を変換 = インバウンドNAT ex) 5000→22

ARM template と DSC を用いた構成管理

ARM

リソースを作成・更新・削除する管理サービス
PF or API的な立ち回りをしてくれるのですべての異なるツールに一貫性をもたせることができる

ARM Template

デプロイしたいAzureのリソース、その設定値などをJSON形式で書いておく設計図みたいなもの
同じ環境を繰り返し作りたいときに便利
パスワードとかは、Azure Key Vaultへ
①ARMテンプレートでイメージからVMをデプロイ
②Blobストレージにおいてあるzipファイルをダウンロード (XXX.ps1とDSCモジュールをzip化しておく)
③デプロイされたVMで先程のファイル(ex:setup.ps1)が実行され、OSの設定が行われる

Automation DSC

システムの構成・制御・デプロイを行う宣言型のPFであるPowerShell DSCとAzure Automationの機能によって、リソースの幅広い範囲の一貫したデプロイ・監視・更新ができる

LCM(Local Configuration Manager)
→ノードの状態の取得・必要な状態との比較、構成の実現をする
→ApplyOnly, ApplyAndMonitor, ApplyAndAutoConnect

Azure Automation

Azure Portal上のサービスでPowershellスクリプトを定期実行するためのサービス
Powershellでできることはすべて自動化
タスクがユーザーの操作を必要としないときやタスクが繰り返し行われるとき使用すべき
VMを作成し、異なるAzure環境にコピーできる
VMをBUし、シャットダウンできる
Azure webサイトの環境設定をリモートで更新できる
VMの自動停止と自動起動 (業務で使用料抑えられる)

Automation アカウント

Azure ADに作成されるAutomationリソースのサービスプリンシパル(システム用のアカウント)
RunbookスクリプトでAzureリソースを管理するためにはAzure AD認証が必要

azcopy

AzcopyではBlobとFileをサポート
Blob...Azure AD, SAS
File...SAS

SAS(Shared Access Signature) トークン

基本的に、IP制限、トークンの有効期限、ファイルやデータ書き込み、読み取り等の制限が可能
コンテナへのアクセス許可、特定のファイルへのアクセス許可など細かくアクセス制御することができる

Firewall

動作箇所 : ネットワーク境界(インターネットor VNet とVNetの境界)
対象レイヤー: L3/L4＋L7
FQDNによるフィルター処理
SNAT,DNAT使用可能 →FWではVMにパブリックIPが割り当てられていない場合でも、SNATやDNATの機能によってFWのPublicIPを利用することでVMとインターネットとの間で通信できる
有料
サブネットは、AzureFirewallSubnetという名前に必ずする
AzureFirewallSubnetは、プレフィックス25以下
FWを経由させるにはルートテーブルを使用

Network Security Group : NSG

[既定の受信] : VNet & LBからのトラフィックのみokay
[既定の送信] : インターネット& VNetへのトラフィックのみokay
VMのインバウンドとアウトバウンドトラフィックをフィルタリングできる
NSGがないと全てのインバウンドとアウトバウンドのアクセス許可される
Network WatcherのNSGフローログ機能を使用して、NSGを通過するネットワークトラフィックをログに記録することができる

Application Security Groups: ASG

NSG : 宛先と送信先を指定する際、IPアドレスとセグメントの指定をする。同じサブネットに複数の用途をもつVMが共存している場合、IPアドレスをNSGに直接記載
ASG : NIC単位でグループ化して、グループ単位で送信/受信を定義することできる
個別にNSGを設定しなくても、細かく制御することが可能になる

Network Watcher

Azure Vnet内のリソースの監視・診断・メトリックの表示・ログの有効化/無効化を行うツール
既定で有効

(1)IP Flow Verify(ネットワーク診断)

NICとsubnetに適用したNSGの通信可否をシミュレーションできる
送信元及び宛先IPv4アドレス、ポート、プロトコル(TCP/UDP)、トラフィックの方向(受信または送信)を指定し接続テストを行う
アクセスを拒否される時は、NSGに問題がある

(2)接続モニター(監視)

サーバ間(VM間)での通信可否とRTTを継続的に測定し続ける→一回だけなら、「接続のトラブルシューティング」
VMとIPアドレス間のネットワーク接続を監視する (死活監視)
定期的な間隔で通信を監視し、VMとエンドポイントの間の到達性・レイテンシー・ネットワークトポロジー変更通知
エンドツーエンドの接続監視
ソースに指定するVMにはNetwok Monitorエージェントがインストールされている
アラートの作成もできる

(3) ネットワークパフォーマンスモニター (監視)

ネットワークパフォーマンスを監視
OMSエージェント間でネットワークの接続性やExpressRouteの性能監視をする機能を備えている

(4)NSGフローログ(ログ)

NSGを介して送受信するIPトラフィックの情報をストレージアカウントに格納する

(5) 接続のトラブルシューティング(ネットワーク診断)

接続モニターの一回バージョン
VM→VM TCP接続確認できる、到達の可否、接続時の待機時間
Azure上のVMから宛先を指定して実行すると、VMにログインをしなくてもネットワークの接続性を確認できる
到達できなかった時の接続障害
→ Memory, GuestFirewall, DNSResolution, NetworkSecurityRule, UserDefinedRoute

(6) VPNのトラブルシューティング

VPNゲートウェイと接続の正常性を診断するツール
診断結果はストレージアカウントに保存される
診断がサポートされているGWはルートベースのGWのみ

(7) 使用量＋クォータ

サブスクリプションで使用しているネットワーク関連リソースの使用状況とクォータを確認できる
大規模な構成になってくるとパブリックIPが頭打ちになんてことがあるので確認できる
クォータ引き上げの依頼もこの画面からサポートリクエストを上げられる
通信しているホストごとや、利用されているアプリケーションごとの分析も自動で行われる
これをもとにNSGルール更新すれば、good.

(8) トラフィック分析

Log Analyticsを利用したトラフィック分析が可能
トラフィックを可視化し、悪意のある攻撃の規模や傾向を推測するのに役立つ

Azureとオンプレミスの接続

(i) 【Expressroute】

回線事業者が提供する専用線を使用した通信 (安心・安全・高品質)
対応するには、ExpressRouteに対応している回線事業者との契約が必要
ExpressRoute回線に接続できるVNetの数 : 既定 10
ExpressRouteを介してAzureのサービスを利用するためには、サービスに応じたピアリングを構成す* る必要がある
ルータ間で冗長化されており、単一障害時にも通信を継続
PaaS、SaaSでも利用できる
(ii) 【サイト間接続】
Vnet側に
　　　- ①仮想ネットワーク
　　　- ②Local Network GW
　　　- ③仮想ネットワークGW**を作成
「接続」を設定

Local Network Gateway

オンプレミス拠点の情報を設定するリソース
例) Public IP, オンプレのアドレス空間など

(iii)【ポイント対サイトVPN接続 (クライアントPC ⇆ Azure)】

クライアント端末から直接Azure上のVPN gatewayに対してVPN接続を行うサービス
Point2siteをVPN接続→証明書を使用して認証
ルートベースでないとダメ (ポリシーベース✖︎)

手順
①VNet作成
②ルート証明書＆クライアント証明書の作成
③仮想ネットワークゲートウェイ作成
→ゲートウェイサブネットと呼ばれる専用のサブネット作成 (/27, /28ぐらいがおすすめ)

P2S構成で (1)アドレスプール (2)トンネルの種類 (3) 認証の種類 (4) ルート証明書を設定 (Azure側)
クライアント証明書は、ルート証明書に紐づくように作成、形式は.pfx
アドレスプール＝VNetのアドレス空間、オンプレと被らないように
この方法は、固定IPもルータなどのVPNデバイスもいらない
テレワークとかに向いてる、複数のクライアントからのネットワーク接続とかいうパターンも

VPN

種類
①Route-based: 動的 / IKEv2 (基本的にこっち)

接続するIPによって別のIPsecトンネルを利用する
ポリシーベースより柔軟性に優れているから基本的にはこちらを使用
②Policy-based : 静的 / IKEv1 (1拠点しか接続できない)
1つのIPSecトンネル上で、暗号化通信を行うIPアドレスを静的に指定
実用的ではない
Basicでのみ使用可能

VPN Protocol : SSTP, OpenVPN, IKEv2
証明方式 : 証明書、RADIUS, AzureAD認証
SKU(Route-based) : Basic,VpnGW1, VpnGW2, VpnGw3

App Service plan

複数のアプリを入れる箱みたいなもの＝ VMととらえてよい
新しくwebアプリを作成するときには必ずApp Service プランを選択 or 新たに作成する必要あり
課金はApp Serviceには一切かからず、このApp Serviceプランにかかる
いつでもハードウェアのプランを変更することができる
App ServiceプランがFree, Basicの場合はコンピューティングリソースは他のユーザーと共有になるため、クォータ制限がある
本番環境では、コンピューティングリソースがユーザー専用となるStandardプラン以上を推奨

App Service Environment

App Serviceプランには、１つだけ特殊なisolatedというプランがある
App Service Environmentで利用するためのApp Serviceプラン
App Serviceをユーザー独自のVNetにデプロイし専用環境でアプリケーション実行を可能にする

スロット

standard以上が必要
同じ名前の別アプリみたいなもの(Production, Staging, dev)
スロットスワッピング : 仮想IPスワップを実現するようなサービスで主にFQDN以外の要素を切り替えることができる (StagingとProduction環境をURLはそのまま、中身だけを変える)
デフォルトだと、運用スロット(production slot)がひとつのみ
デプロイ後にサーバー上でのビルド処理が走るようなケースでは、少なからずダウンタイムが発生→デプロイスロットを使う
複数のデプロイメントスロットを有効にするにはアプリがStandard, Premium, Isolatedのいずれかでないとダメ(errorならscale up the App Service Planをする)

kudo

App Serviceにデプロイしたり簡易診断するのに重宝する便利な機能
kudoは１つの独立したウェブアプリなので、デプロイしたりkudoセッションを使うとアプリ本体とkudoアプリの２つが計算資源を共有した状態となる

App Service

OSやミドルウェアのインストール、管理が不要であり、ビルド済みのアプリケーションをgitやsftpなどでApp Serviceにデプロイするだけでアプリを公開できる
web Apps, Mobile Apps, Logic Apps, API Appsの総称
セキュリティや負荷分散、自動スケーリングなどはサービスとして提供されているため、独自に実装することはなく、設定を変更するだけで柔軟に環境を構築できる

Azure Private Link

オンプレミスからAzure PaaSへプライベート接続できる
Azure PaaSは、基本インターネット経由でアクセス(PaaS上で機密情報をもつならダメ)
Azure PaaSのFWがあるが、結局はインターネットを経由するのでよくない
Private Linkは、ExpressrouteやVPN GW経由でPaaSに接続できる ←サービスエンドポイントとの違い
流れ
①オンプレ→ private endpoint
②private endpoint → private link
③private link → 各PaaS

サービスエンドポイント

VNet内の特定のネットワーク範囲から直接PaaSにアクセスする仕組みを持っている
Azureのバックボーンを利用した直接接続を行うことで、インターネットへのアクセス制限を行いながら安全な接続
Public IP が不必要になる

Recovery Services

以下の2つを利用するにはRecovery Service コンテナー (Recovery Service Vault)の作成が必要

バックアップデータを格納する入れ物
ストレージエンティティみたいなもの
IaaS VMやAzure SQLデータベースなどの様々なAzureサービスのBUデータが格納される
blobをバックアップできない、Fileのみ
Recovery Services Vaultを削除する前にバックアップ停止、登録済みのストレージアカウントがすべて削除されていることを確認、削除

(1) Azure Backup

基本は、Azure VMを丸ごとバックアップ。複数ディスクがあってもすべて取得
Azure Backupによって、VM上で実行されているAzure VMエージェントに、バックアップ拡張機能がインストールされる
agentを導入することで、フォルダ/ファイル単位にバックアップ可能
バックアップスケジューラーを設定することで、定期的な取得が可能
オンプレミスのデータもAzureにバックアップ可能(MARSエージェントを用いて、Linuxはサポートなし)
リストアは別VMとして復元
他のリージョンは復元できない
Recovery Service Vaultでカスタム定義されたバックアップポリシーを使用している。保存されているデータを消したいならバックアップポリシーを変更
コンテナが消せないなら、そのコンテナはバックアップデータを受信するように設定されている
Azure Backupを使用すると、バックアップされたデータはコンテナに格納される
既定では、Recovery Services コンテナーではGRSが使用される
データ転送でコストはかからない
シャットダウン or

[Agentによるバックアップと復元]

エージェント : Microsoft Azure Recovery Services(MARS) エージェント
エージェントをインストールして、フォルダ/ファイル単位にバックアップする
バックアップ先のAzure Backupは別リージョンでも可能
バックアップ取得元サーバーは、Azure VMだけでなくオンプレミスも可能
windowsのみ

[VMのバックアップ手法としてスナップショットも選択肢としてある]

MarketPlaceから"snapshot"を選択
スナップショットはディスク単位の取得になるため、複数ディスクをアタッチしたVMでは整合性に注意

バックアップ手順

Recovery Services コンテナーを作成
「概要」の「＋バックアップ」をクリック(ワークロード、何をバックアップするか選択)
バックアップポリシーを作成し、バックアップする仮想マシンを選択→「バックアップの有効化」をクリック
スケジューラーはスケジュールされた時刻にバックアップをトリガーする (ジョブの一部としてスナップショット作成)
「バックアップアイテム」→ 「Azure Virtual Machine」の順にクリックし、「今すぐバックアップ」を選択でOK

バックアップのデータの流れ、[VM]→ [snapshot]→ [バックアップデータ]

リカバリ手順

「バックアップアイテム」→ 「Azure Virtual Machine」
「VMの復元」をクリック
リカバリ対象の復元ポイントを選択して「OK」をクリック
復元の構成を入力し、「復元」をクリック

(2) Azure Site Recovery (2020/01にサポート終了)→ Azure Migrate

オンプレの物理サーバーやVMのディザスタリカバリとして、災害時はAzure上でサーバを速やかに復旧できる仕組み

(1)ASRを有効にすると、VMのバックアップが自動で開始される。ディスクへの書き込みは、すぐにソースロケーションのキャッシュストレージアカウントに転送される

(2)ASRはキャッシュ内のデータを処理し、レプリカのマネージドデジスクに送信

(3)データが処理された後、復旧ポイントとなるスナップショットが作成

(4) フェールオーバを開始すると、ターゲットロケーションにVMが作成される。フェールオーバーには、任意の復旧ポイントを使用できる

機能
①レプリケーション : 物理サーバやVMのディスクを丸ごとAzureに同期
②フェールオーバー : Azureに同期されたディスクを使ってAzure上にVMを作成する

Azure Monitor

Application Insightsで、アプリケーションと関連する問題の検出と診断
仮想マシンとAKSのインフラレベルの問題を関連付け
メトリックの監視と視覚化 (Azureダッシュボード、ワークブック)
ログのクエリと分析(Azure Monitor Logs)
アラートとアクションのセットアップ
メトリックとログは、Azure Monitorで使用する２つの基本的なデータ
ログデータは、Log Analytics workspaceに格納される。アクティビティログは90日間
ログの保存先は、「Azure Active Directory」→ 「監査ログ」→「データ設定のエクスポート」で選択可能

Log Analytics → Azure Monitor Logs

ログ収集＆分析基盤 as a Service
保存するところは、Log Analyticsワークスペース
ログデータを収集・検索・分析機能を提供するPF
対象コンピュータにagentをインストールするだけ (VMは登録時に自動でインストールされている)
監視サービスではない
ログの長期保存には向いていない

VM

VMのサイズ変更→停止の必要あり(ダウンタウンを引き起こす)

移動

VMのVNet間移動は、一度VMのみ削除し、残ったdisk,VHDファイルから新たにVMへアタッチ
同じVNet内のサブネット移動であればNICのIP設定変更によって可能なためハードルは低い

Azure Resource Mover

リージョン間でAzureリソースを移動する機能
リソースの移動でなくコピーなので、移動前のリソースはそのまま残っているため自分で削除する必要あり

データディスク追加

データディスクは1つあたり1TBまで利用でき、それ以外の容量を使いたい時は複数のデータディスクをアタッチする
作成したらOS側でディスクの追加をする
(sshでVMに入り、新しいディスクをマウントする作業をする)

管理グループ

サブスクリプションに対する権限管理を、サブスクリプションの所有者よりも上のレイヤでガバナンスを効かせたいケース
1つのディレクトリで複数のサブスクリプションの管理/運用の効率化
階層は６階層まで(ルート管理グループとサブスクリプションは含めず)
MAX10,00個まで管理グループ作成できる
ルート管理グループ= Azure ADのIDが一緒

Azure AD

Azure Subscriptionが信頼するAzure ADテナントは１つ
Azure ADテナント(既定)と Azure AD テナント(追加)の一括管理はできない。一つずつ管理

Azure ADテナント削除

組織を削除するグローバル管理者1人を除き、すべてのユーザーが削除されている
Azure ADと連携指定いるアプリケーションがないこと
組織に関連づけられているマイクロソフトのオンラインサービスのサブスクリプションがないこと

Active Directory Domain Services (ADDS)

オンプレミス上のIDと認証やコンピュータの管理、GPO、信頼などの主要な機能を提供する企業用のLDAPサーバー

Azure Active Directory Domain Services (Azure ADDS)

オンプレミス環境のAD DSのドメイン参加、GPO、LDAP、kerberos認証などのADDSにある主要機能をクラウド上にて利用すること

Azure AD Identity Protection

Microsoft データセンターに蓄積された膨大なデータをもとに、ユーザーの普段と異なる怪しいサインインや侵害されたアカウントを自動で検出しそのリスクを調査
検出したリスクを機械学習を通して、3段階で評価する(リスクレベル)
すべてのユーザーに対してP2ライセンス必要
3つの既定ポリシー
①ユーザーリスクポリシー
②サインインリスクポリシー
③MFA登録ポリシー
④カスタム条件付きアクセスポリシー

Azure Policy

評価を実行し、準拠されていないリソースをスキャン
デプロイのプロパティに注目して制限する
組織が利用するためのポリシー
ex) ストレージアカウントSKU, リソース種類、場所、VMのSKU
RBAC→ユーザー操作に焦点

Azure Policyを割り当てられるスコープ
(1) 管理グループ
(2) サブスクリプション
(3) RG

ユースケース

組織が展開するリソースの種類を指定する
組織が展開できる仮想マシンSKUのセットを指定する
必要なタグとその値を適用する
ポリシー定義が少ない場合でも、イニシアティブ定義をするのがおすすめ
イニシアティブ定義を定義したら、RGなどに割り当てる
ポリシーを設定したら「コンプライアンス」ブレードを使用して、準拠していないイニシアティブ、準拠していないポリシー、準拠していないリソースを確認する

Blueprint

Azure Policyを再利用・再配布可能な形で定義。別サブスクリプションに簡単に適応できる
Blueprintの中にRBAC, イニシアティブがあり、イニシアティブの中にPolicyがあるイメージ

VMの可用性

可用性セット(Availability Set)
同一データセンター内の別のサーバーラックに配置された仮想マシンを配置する設定のこと
物理サーバーや電源装置、ネットワークスイッチなどラック内で障害が発生しても別ラックに配置された仮想マシンに切り替えることでシステム停止を防ぐ
複数のVMを同じ可用性セットに作成→予期しないメンテナンスなどに対応できる
料金はかからない
SLA : 99.95%
システムの商用を考えているのなら必須
VMを作る時は、可用性セットを最初に作ってからそのグループ内にVMを作る
事前に作成しておいて、LBに関連づけする
必ず同一のDC内で構成される必要あり
同じ役割を持つサーバ群を可用性セットでグループ化する (ex: webサーバ２台の可用性セット)

①障害ドメイン(Fault Domain)

def:2, Max:3(1から選択可能)
電源とネットワークスイッチが独立したVMのグループ
障害ドメイン「２」は、「同じ可用性セット内の仮想マシンは少なくとも２台の物理ホストに分けることを保証する」
障害ドメインを2つにすると、同じ可用性セットに2つのVMを立てた時に2つの障害ドメインに自動的に振り分ける
同様に更新ドメインを5つにするとこの可用性セットにVMを作成するたびに、その5つのどれかに自動的に振り分けられる

②更新ドメイン(Update Domain)

def:5, Max:20(1から選択可能)
同時に起動されるVMのグループ

安定稼働が必要なVMは、可用性セットに作成
VMを可用性セットに追加できるのはVM作成時のみ
設定変更は、可用性セット内のすべてのVMを停止する必要あり

可用性ゾーン(AZ)

データセンターそのものの障害によるシステム停止を防ぐ(DC障害対策)
同じリージョンの中で３つのDC(1,2,3)に分散させるイメージ
SLA : 99.99%
LBを冗長構成するためStandard Load Balancerの費用がかかることがある

仮想マシンスケールセット(VMSS)

仮想マシンを「必要なときに」「必要なぶんだけ」「自動で」リソースの調達できる
インスタンス数の最小・最大、スケールイン・スケールアウトの条件を決めれる
同一イメージのVMをグループ化して、作成・管理・負荷分散する
LB or AGWの作成も統合され自動で実行される
スケールセットには自動スケーリングが組み込まれている

Upgrade policy & Upgrade mode

manual : 手動
automatic : 自動的にOSとかのupgradeがなる
rolling : セットアップした間隔でバッチでupgrade
オーケストレーション : 仮想マシンをスケールセットで管理する方法を選択

(1)均一

仮想マシンモデルを定義すると、そのモデルに基づいてAzureによって同一のインスタンスが生成
同一インスタンスの大規模なステートレスワークロード用に最適化されている

(2)フレキシブル

任意の構成の仮想マシンを手動で作成してスケールセットに追加
同一または複数の仮想マシンの種類を使用して、大規模に高可用性を実現

近接通信配置グループ(Proximity Placement Group)

低遅延が求められる場合に有効
VM間のネットワークパフォーマンスを最大化することが目的
VM作成時に選択できる
可用性セット、可用性ゾーン、VMSSと併用可能
起動時に物理的に近接する場所に配置される

Azure ADのデバイス管理

Azure AD 参加: 組織の所有しているwindows 10デバイスを対象にしている構成
Azure AD 登録: スマートフォンなどの個人所有のデバイスを対象にしている構成

Intune

マイクロソフトは、モバイルデバイス管理およびモバイルアプリケーション管理のSaaSアプリケーションを提供
Intuneにデバイスを登録すると、登録されたデバイスに対してIntuneがさまざまなポリシーを提供できる
P1ライセンスを持っていると、ユーザーが個別にIntuneにデバイスを登録しなくても、Azure ADテナントに参加/登録したデバイスをAzure ADテナントからIntuneに自動登録できる

Azure AD Connect

Active Directory ドメインサービス(ADDS)とAzure Active Directory間でユーザー情報を同期し、認証基盤を統合
「Azure AD Connectのダウンロード」をクリックして、ダウンロードしオンプレのAD上でダウンロードしたファイルを実行