Azure Administrator Associate (AZ-104) 対策まとめ

#はじめに

5月ぐらいから業務でAzureを触り始めたので、せっかくならと思い資格を取ることにしました。
前回に「AZ-900」 を受験して合格したので今回は「**AZ-104: Azure Administrator Associate**」を受験しました。
難易度は、中級程度？やや高め？ぐらいだと思います。Azureの主要なサービスの基本概念、デプロイ、管理、監視について幅広く求められます。

ただの備忘録ですが、Az-104を受ける人の情報源になればと思います。


- 2021/09/11 に無事一発合格しました
- オススメはUdemyで過去問をやることに限ります！(英語の問題ですが、、Azureって日本語の教材少なすぎる、、)
- 実技があるみたいなうわさがありますが、私が受けたときはなかったです

#出題範囲

| 分野 | 割合 |
|:-:|:-:|
| Azure アイデンティティおよびガバナンスの管理   | 15-20%  |
|  ストレージの作成と管理  | 15-20%  |
| Azure 計算資源の展開と管理   | 20-25%  |
| 仮想ネットワークの構成と管理   | 25-30%  |
| Azure 資源の監視とバックアップ   | 10-15%  |


個人的に、「Azure Backup」、「Azure Import/Export」、「Azure File Sync」、「Network Watcher」、「App Service プラン」あたりが良く出題されているように感じました(問題集より)


##【ユーザーに権限付与する方法】
(1) **RBAC (Role-based Access Control)** : ロールを通してユーザーのアクセス許可を制御
(2) **PIM (Privileged Identity Management)**

-  セキュリティプリンシパルへのロールの割り当てを永続ではなく**期限付きにできる**
- PIMを使用するなら**AzureAD側で設定**し、永続ロール割り当ては**リソース側**で行う

- PIMは、**P2ライセンスで使用可能**、サイバー攻撃対策の1つ
- ユーザーがロールをアクティブ化する際に上司の承認を要求したり、MFAを要求したりできる




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

| ロール名 | Read | Create/Delete/Update | アクセス管理 |
|:-:|:-:|:-:|:-:|
|  所有者(Owner) |  o |  o |  o |
|  共同作成者(Contributor) |  o |  o | x  |
| 閲覧者(Reader)  | o  |  x |  x |



- `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ファイルはこれ)

エンドポイント
**https://<ストレージアカウント名>.blob.core.windows.net/** 
**https://<ストレージアカウント名>.file.core.windows.net/** 
**https://<ストレージアカウント名>.queue.core.windows.net/** 
**https://<ストレージアカウント名>.table.core.windows.net/** 

**アカウント(基本的にストレージアカウントは汎用V2でok)** 

**(1) Blobストレージアカウント**

- **ブロックBLOBと追加BLOBに特化したストレージアカウント**(その他は使えない)
- クール、ホット、アーカイブのアクセス層を選択できる
- **現在、汎用v2で同様のアクセス階層の制御が可能のため、Blobストレージアカウントを使用する場は無くなってきた**


**(2) 汎用v2ストレージ (汎用v1 ＋Blobみたいな感じ)**

- Blob, Files, Queue, table, Disk用のアカウント(**基本的このストレージアカウントを推奨**)
- 料金体系もBlobストレージと同等
- `ZRS対応しているのは汎用V2のみ`



##【レプリケーション】

**(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 File Sync】


**まず、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` をインストール**

- Agentをインストールすると認証が求められるので、先ほどAzure ファイル共有を作成したアカウントでサインイン
- (Azure Subscription, RG, Storage sync Serviceを選択)
- 登録済みサーバーにあればOK

**(4) 「リソースの作成」 → 「Azure File Sync」を選択し、「＋同期グループ」を選択**

- ここでクラウドエンドポイントは選択する
- 「Azureファイル共有」では`作成したAzure ファイル共有を選択`→これが**クラウドエンドポイント**
- 同期グループでは１つのクラウドエンドポイントと複数のサーバーエンドポイントを設定

**(5) 「同期グループ」→「サーバーエンドポイントの追加」**

-  サーバの同期させるフォルダ「登録済みサーバー」から選択
-  登録された`サーバーをプルダウンから選択`し、サーバの同期させる`フォルダへのパスを入力`

メモ

- **Azure File Syncでは同期サーバーからの変更は即時エージェントにより同期されますが、Azure Filesからの変更は24時間に1回しか同期されない**

- ストレージアカウントはAzure File Syncと同じリージョン


----

- **同期グループ(Sync Group)** : 同期するクラウドエンドポイントとサーバーエンドポイントの紐づけ
- **クラウドエンドポイント** : 同期をとる際のクラウド側の同期先パス
- **サービスエンドポイント**: 同期をとる際のサーバ側の同期先パス





##【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を提供できるサブネットが必要
- AKSまわり

##【Azure Kubernetes Service (AKS)】

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


```
#[CLI]クラスタの作成
$ az aks create -n クラスタ名 -g RG -l リージョン --kuberbetes-version 1.7.7 --generate-ssh-keys

#[PowerShell]Create or update a k8s cluster
$ Set-AzAks XXX

#クラスタの証明書取得
$ az aks get-credentials -n クラスタ名 -g RG

#コンテナをAKSにデプロイ
$ az acr build --image XXX --registry XXX --file Dockerfile

#autoscale パターン①
$ kubectl autoscale deployment azure-vote-front --cpu-percent=50 --min=3 --max=10

#autoscale パターン② (マニフェスト利用)
$ kubectl apply -f XXX.yaml

```



##【ロードバランサ】


- 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**へ

```sample.json

{
   "$schema":
   "contentVersion":
   "parameters":{},
   "variables":[],
   "outputs":[],
}
```

①ARMテンプレートでイメージからVMをデプロイ
②Blobストレージにおいてあるzipファイルをダウンロード (XXX.ps1とDSCモジュールをzip化しておく)
③デプロイされたVMで先程のファイル(ex:setup.ps1)が実行され、OSの設定が行われる


**ARM template デプロイ**

```
$ az deployment group create -g NameGroup --template-file template.json
```
or Portalから「テンプレート」で検索、[＋追加] → [展開]

**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  |



```
$ azcopy copy LOCAL-FILE-PATH https://az104data.blob.core.windows.net/public --recursive #ソースデータをコピー先の場所にコピーする
$ azcopy make 'https://mystorageaccount.blob.core.windows.net/XXXX' #コンテナー or ファイル共有を作成
$ azcopy sync #元の場所を同期先の場所にレプリケートする
```



###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を利用したトラフィック分析が可能
- トラフィックを可視化し、悪意のある攻撃の規模や傾向を推測するのに役立つ


##【VNet間を繋ぐ】

###(i) サイト間(IPsec)
(1) gatewayサブネット作成
(2) local gateway作成
(3) VPN gateway作成
(4) VPN 接続



###(ii) Vnet間

(1)VNet作成
(2)VNetGWの作成 (接続先となるVNetでも同様にGW作成)
(3)接続

`Local Network Gatewayのアドレス空間は自動的に作成され、設定される`

**GWの種類** : (1) VPN(IPSec) (2) Expressroute(専用線)
###(iii) VNetピアリング

- Azureの仮想ネットワーク同士を、Azureのバックボーンを使用して接続する機能
- 複数の仮想ネットワーク同士をGWなしで簡単に接続できる
- Azure Portalで [仮想ネットワーク]を選択し、[ピアリング]→ [+追加]で設定可能

- `[GW転送を許可する]`→ 自身のVNet内のVPNゲートウェイの転送を許可
- `[リモートゲートウェイの使用]` → デフォルトルートとしてピアリング先のVPNゲートウェイを利用

- 両方のVnetでピアリングの状態が「接続済み」になればOK
- `VNetが他のVNetとピアリングしている場合、VNetのアドレス空間にアドレス範囲を追加した利、アドレス範囲を削除したりすることはできない`


##【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にデプロイし専用環境でアプリケーション実行を可能にする

**賢い使い方**

- 高いSLAが必要な場合は、アプリは単独・少数のアプリを入れたApp Service Planに分離する
- Health Checkを有効にする
- リージョンごとに同じアプリをデプロイして、Traffic ManagerやAzure Front Door等でリスク分散する


**スロット**

- 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) バックアップ停止
(2) 登録済みのストレージアカウントがすべて削除されていることを確認
(3) 削除


###(1) Azure Backup

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



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

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

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

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


###バックアップ手順

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

###リカバリ手順

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



###(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`」→ 「`監査ログ`」→「`データ設定のエクスポート`」で選択可能

**Azure Subscriptionのlog**

- Service Health: アプリとリソースが依存するサブスクリプション内のAzureサービスの正常性の情報を提供
- Activity Log : サービスの正常性レコードとAzureリソースに対して行われた構成の変更に関するレコード

**Azureが出力するログとメトリック**

**(1)Activity Logs**

- リソースに対して`外部から実行された書き込み操作`で、いつ誰が行ったかを記録するもの
- Azureの基盤側のログ

**(2)Diagnostic Logs(診断ログ)**

- 各リソースが出力するログ

**(3)Metrics**

- 各リソースが出力する数値的に計測された値, CPU使用率とか


**アラートルール** : 監視対象リソース、監視条件、通知方法(アクショングループをattach)

**アクショングループ** : どの宛先の電子メールに送信するか、どのfunctionを呼び出すかなどの通知方法を定義
- 詳細(e-mail,SMS, 音声,Azure Function, Logic Apps, webhook, Automation Runbook)

##【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 MFAの２要素目の登録をユーザーに強制させる


**④カスタム条件付きアクセスポリシー**

- これらのポリシーを有効にすると、怪しいサインインに対して強制的に多要素認証を要求したり、多要素認証が登録されていない脆弱なアカウントに対して強制的に多要素認証を登録させたり、怪しいユーザーアクションに対してアクセスをブロックさせたり、パスワードを強制変更させたりして、Azure ADのIDを動的に、リアルタイムに保護


**条件つきアクセス**

- Azure ADへの認証に対して、制限対象に該当するユーザーを許可・拒否することができる機能
- MFAの設定 [Azure AD]-[条件付きアクセス]-[アクセス制御]-[許可]-[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上でダウンロードしたファイルを実行







##【SSPR】

**SSPR**

- Azure AD Freeでは使えない
- オンプレミスのADと同期している場合、SSPRを行うには`P1, P2`ライセンス
- user admin role X, global OK
-  Mobile app notification, mobile app code, email, mobile phone, office phone, security questions

 


##そのほか (わからなかったことのメモです)

- VMをVMSSに追加するとRGはどこでもよく、`リージョンだけ同じ`にする必要あり
- デバイスが追加できない時は、[`Device Setting blade`]のデバイスの設定の最大を確認する
- **Azure Data Lake Storage G2** 
   - 大量のログなどを容量を気にすることなく、とりあえず生のまま安価に高機能なストレージに突っ込むことができる
   - 複数の分析基盤と接続もできるので便利

- 直接peeringされたVNetにアクセスできるがVNetのPeeringやネットワークの`トポロジに変更があった時`、`VPNクライアントを再度インストールする`
- `Blue-Green Deployment` : LBの接続先を直接切り替えるなどして新しい本番環境をリリースする運用方法
- webAppとAppServicePlanは**同じリージョン**にある必要あり
- peering statusが **"Disconnected"**の時は、両方のVNetからPeeringを削除してから`再作成する必要あり`


- VMの名前解決
→同じVNet内のVMは、Azureで提供される名前解決により、相互にホスト名で名前解決できる
→異なるVNetは名前解決できない
→独自にDNSサーバーを設定する、Azure DNSプライベートゾーンを使用


- **Azure Performance Diagnostics Extension** → windowsやLinuxのVMに影響を与える可能性のあるパフォーマンス問題のトラブルシューティングを支援




**Bastion**

-  VMでPublic IPから直接、シームレスにRDPとSSHで接続
-  VMはパブリックIP, agentなどはいらない
-  TLSを介してAzure Portalから直接VMへSSHする


**スナップショット** : VMのすべてのディスクの特定の時点のバックアップ


**UPN(User Principal Name)** 

- インターネット上のサービスで使われるログイン名
- UPNはActive DirectoryではユーザーのIDを指す
- Active Directoryにおけるユーザー名の表記法の１つで、登録ユーザーのアカウント名のあとに所属ドメイン名を「@」を挟んで連結したもの

**idfixツール** 

- Active Directoryの問題解決
- オンプレミスでIDオブジェクトとその属性の検出と修復を実行するために使用

---

- NSGはRegion間を移動できない。同じリージョンでしか使えない
- SMBプロトコル : `port 445`
- Azureがドメイン名を確認、どのタイプのDNSレコードを作成するか？→ **TXT, MX**


- `VMを単にVNET間で移動はできない`
→ diskを残したまま、VM1を削除し、別のVNetで新たにVMを作成してディスクをアタッチする

- リソースはサブスクリプション間で移動できる


- RGを削除する前にやること
(1)ロックを削除
(2)Recovery Service Vault からのVMのBU停止


- Recovery Services Vaultを削除前に最初にやること→ **各バックアップ項目のバックアップを停止**


**マネージドID**

- Azure ADの認証をサポートするサービスに対してAzureリソース自身で認証を行うことができるAzure ADで管理されるID
- マネージドIDを利用すると、Azureリソース自身が認証されるため、コード等から認証情報を排除できる

**Azure Backup report**

(1) Log Analytics ワークスペース作成 (デフォが30日間保存)
(2) コンテナの診断結果を構成 (send to Log Analytics　を有効化)
(3) Recovery Services valutの「overview」→ 「Backup Reports」で開く
*storage accountとLog Analytics ワークスペースは同じリージョンでないとだめ




**puppet**

- サーバー構成管理ツールの１つ
- 各サーバーにエージェントをインストール
- 現状だと各サーバーにエージェント入れるのは比較的容易、SI案件だとハードル高い(Ansibleとはエージェント不要)

**カスタムスクリプト拡張**

- 自動的にAzureストレージからスクリプトとファイルをダウンロードし、仮想マシンでPowerShellスクリプトを実行できる

**カスタムオペレーター**

VMの起動、停止、再起動の許可


Microsoft.Compute/VirtualMachines/start/action
Microsoft.Compute/VirtualMachines/deallocate/action
Microsoft.Compute/VirtualMachines/restart/action
Microsoft.Compute/VirtualMachines/*/read


- 「Azrue AD」 → 「ユーザー」→「ユーザー設定」→「外部コラボレーション設定」

- ゲストのアクセス許可を制限する
- 管理者とゲスト招待元ロールのユーザーは招待ができる
- メンバーは招待できる
- ゲストは招待できる
- ゲストの電子メールワンタイムパスワードを有効にする


**コラボレーションの制限**

- 招待を任意のドメインに送信することを許可
- 指定したドメインの招待を拒否
- 指定したドメインに対してのみ招待を許可




**kubectl** : 主に水平方向にスケールするために使用


**プロビジョニング** : 必要に応じてネットワークやコンピュータの設備などのリソースを提供できるよう予測し準備しておくこと



**プライマリドメイン**

- プライマリドメイン名 : "XXX.onmicrosoft,com" (組織を作成すると)
- プラマリドメインは、新しいユーザーを作成した時にそのユーザーの既定のドメインになる
- `プライマリドメインを変更するには、カスタムドメインの追加をする`
- サブドメインを追加する場合は、最初にルートドメインを追加して確認
- Azure ADで指定したドメインを使えるようにするにはDNSレコードを作成し、ドメインを所有しているという確認を完了させる


**プライベートDNS設定**

- インターネットではなく、独自のネットワーク内で名前解決を行うためのDNS
- VNet内で名前解決する

**cloud-init**

- Linux VMを初期起動時にカスタマイズするために広く使用されている手法
- パッケージをインストールしてファイルを書き込んだり、ユーザーとセキュリティを構成したりできる
- VM or VMSSを構成するために使用


**Azure Storage Explorer** : あらゆる場所からクラウドストレージを管理するツール

- Log Analytics ワークスペースは、location & サブスクリプションは Recovery Service Vaultが存在するところから独立

- **UsageLocation** : 全ユーザーに対して更新できる

- **traffic analytics** → readerでもOK
- Azure DNS → CLIを使用したtゾーンファイルのimport/export をサポート

**wookbook**

- [Azure Active Directory]→ [wookbook]
- Azure ADサインログの情報を収集して視覚化

**Effective Route** : 

- ネットワークのルーティングを確認するための方法
- ルートテーブルから見れる

- ストレージアカウントは、レプリケーションタイプの変更できる

**Azure Data Box** : ハードディスクに大量のデータを保存し、オンプレミスからクラウドへ物理配送

**Azure Advisor** : 取得されたメトリック、ログデータをもとにベストプラクティスに従うような推奨事項を自動生成

**AssignableScopes** : 割り当てにロールを使用できるスコープを指定。定義できる管理グループは1つのみ

**ロック**

- Delete : add/modifyはできる
- Read : 何もできない(readはできる)

**グループ**

| 種類 | 説明 |
|:-:|:-:|
|  ①Security Group | 一般的、一度に全てのメンバーに一連の権限を与える。Azure ADの管理者が必要。Azureのリソースへのアクセス権など管理  |
| ②Microsoft 365 Group |  メンバーが共有の受信トレイ、カレンダー、ファイルにアクセスすることでコラボレーション機会を提供。ユーザーと管理者の両方で利用できる。Office365などのSaaSアプリケーションのアクセスを管理する |


- Log Analytics ワークスペースは、Recovery Service Vaultからは、location & サブスクリプションは独立

- Azure Filesにアクセス (REST, SMB ) : SAS Tokenは対応していない

- **Performance Diagnostics エージェント** : VMの高度な監視機能、windows/Linuxで利用可能
- VMのCPUパフォーマンス問題 → VMのsize変更 (スケールアップ)



- NVA(Network Virtual Appliance) : ネットワークの機能やサービスが含まれたVM (Marketplaceから)


#参考文献

- [Azureの監視手法の種類と使い分け](https://qiita.com/_Y_N/items/9b8a4ee4826e05c06a4f)
- [Azure VM (Virtual Machine) 運用監視エージェントまとめ](https://qiita.com/hisnakad/items/cfa9c87c0c0fb010f62a)
- [一から丁寧にAzureで仮想マシンを立ててみる。](https://qiita.com/_akira19/items/b95dac39b51d44d8931a)
- [ストレージアカウントでSASトークンを使ってみる](https://qiita.com/papeMK2/items/0f18d61d5e0eb7cc8451)
- [Azure Backup手法まとめ](https://qiita.com/shingo_kawahara/items/1928de314339e59b9d71)
- [Azure Storageについての基本的なこと](https://qiita.com/t-noguchi/items/2e172a2667e6e890a694)
- [【Azure】Network Watcherでネットワーク調査をする](https://qiita.com/hikaru_motomiya/items/fe398a84e7b98c4b3ce4)
- [試験 AZ-104: Microsoft Azure Administrator](https://qiita.com/JQinglong/items/f626e9cd98fa80dfac3c)
- [くらう道](https://www.cloudou.net/)

参考書

- 速習Azure Administrator
- ひと目でわかる、Azure Active Directory