AWSエンジニアのためのAzure Administrator対策

#はじめに
お疲れ様です。yuki_inkです。
この度、Microsoft Azure Administrator試験(AZ-104)に合格しました。
以前Azure Fundamentals試験(AZ-900)に合格した際は下記の記事を投稿しましたが、本稿はその続編です。

https://qiita.com/yuki_ink/items/417a52b8f42fca258171

#主に活用した教材
###[合格対策Microsoft認定試験AZ-104:Microsoft Azure Administratorテキスト&演習問題](https://www.amazon.co.jp/%E5%90%88%E6%A0%BC%E5%AF%BE%E7%AD%96Microsoft%E8%AA%8D%E5%AE%9A%E8%A9%A6%E9%A8%93AZ-104-Microsoft-Azure-Administrator%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-%E6%BC%94%E7%BF%92%E5%95%8F%E9%A1%8C/dp/4865943080/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=1UWSWF8WR01VR&keywords=AZ104&qid=1644047625&sprefix=az104%2Caps%2C193&sr=8-1)
2022年2月時点で日本語のAzure Administrator対策本がこれしかなく、選択の余地なしに購入しました。
全体的にバランス良くまとまっており、また演習問題・模擬試験も掲載されているため、試験対策としては本書で十分という印象です。

ただ、サービスによっては、[Fundamentals対策で使った黒本](https://www.amazon.co.jp/%E6%A8%A1%E6%93%AC%E5%95%8F%E9%A1%8C%E4%BB%98%E3%81%8D-Microsoft-Azure-Fundamentals%E6%95%99%E7%A7%91%E6%9B%B8-AZ-900/dp/429501141X/ref=pd_lpo_1?pd_rd_i=429501141X&psc=1)には書かれてるけどこっちには書かれてない、というようなものもありました（それだけFundamentalsの試験範囲が広く浅くだった??）。
そのため、本書をメインの教材して活用しつつ、時々Fundamentalsの黒本を流し読んでその内容を思い出してみたり、実際にAzure Portalを触って具体的な設定方法のイメージを掴んだりするという形で対策を進めました。

https://www.amazon.co.jp/%E5%90%88%E6%A0%BC%E5%AF%BE%E7%AD%96Microsoft%E8%AA%8D%E5%AE%9A%E8%A9%A6%E9%A8%93AZ-104-Microsoft-Azure-Administrator%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-%E6%BC%94%E7%BF%92%E5%95%8F%E9%A1%8C/dp/4865943080/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=1UWSWF8WR01VR&keywords=AZ104&qid=1644047625&sprefix=az104%2Caps%2C193&sr=8-1

※本番の試験では、実際の設定画面のスクショから情報を読み取ったり、「このリソース作るためにAzure Portalからどのような操作をしますか？」みたいな問題が多かったです。
　そのため、一度はAzure Portalを触っておくことをおすすめします。


#AWSエンジニアのためのAzure Administrator対策
本題です。
筆者が理解に苦しんだ部分を中心にまとめます。

特にストレージアカウントについては、そもそもそんな概念はAWSにないため、非常に理解に苦しみました。
[Fundamentals対策]((https://qiita.com/yuki_ink/items/417a52b8f42fca258171#%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88))でも多少触れてはいるものの、当時は「Azureのストレージサービス使うためには事前にストレージアカウントを作っておかないといけない」というくらいの理解だったため、細かい言及は避けた（できなかった）んですが、、
今回は勇気を出して、がっつり触れておきたいと思います。

##(1) アイデンティティとガバナンスの管理
アイデンティティとガナバンスを管理するための機能群について、まとめて触れる。
独断と偏見で、かつ強引に、AzureとAWSのそれぞれの機能を対応付けてみた。

|Azure  |概要　　|AWS  |
|---|---|---|
|Azure AD テナント  |ユーザーと権限を管理するためのプール　|-（強いて言えば踏み台アカウント）　 |
|Azure AD ユーザー  |Azure環境でのログインユーザー　|IAM ユーザー　 |
|Azure AD グループ  |AD ユーザーを束ね、権限管理を簡素化　|IAM グループ  |
|Azure AD ロール  |AD テナント自身に対するアクセス権限　|IAM ポリシー |
|RBAC ロール  |リソースに対するアクセス権限　|IAM ポリシー / リソースベースのポリシー(※1)  |
|サブスクリプション  |請求、管理、アクセス制御の単位　|AWSアカウント  |
|管理グループ  |サブスクリプションをまとめるグループ　|AWS Organizations  |
|マネージド ID |リソースにRBAC ロールを割り当てる仕組み　|IAM ロール  |
|Azure ポリシー  |AD ユーザーのリソースに対する権限を制限　|IAM ポリシー / AWS OrganizationsのSCP / AWS Config(※2)  |

**AzureではID管理の機能=Azure ADが、サブスクリプションとは切り離された場所にある**ということを、まず念頭に置いていただきたい。
AWSで言えば、IAMとその他のリソースを別々に管理しなければならないようなイメージ。

そもそもAzure ADは、パブリッククラウドとしてのAzureだけでなく、Microsoft 365をはじめ数多くのSaaSアプリケーションと統合されていいる。
つまり、Azure ADユーザーはAzure Portalにログインするためだけのユーザーではない。
だからこそ、サブスクリプションの外に、大規模な認証機構として存在しているのだと思う。

###RBACロールについて（上表中※1）
上記のような違いがあるからこそ、リソースに対するアクセス管理では、Azure・AWSでは発想に違いがある。
Azureでは、リソースの側からADユーザー（あるいはADグループ）に対してRBAC権限を割り当てるイメージ。
実際、RBACロールを設定するときの画面操作もそんな感じで、リソースの画面から権限設定を行う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/eef761b4-c7d1-6d58-0169-536259551da1.png)
※RBACロールの設定は、サブスクリプション、リソースグループ、個別のリソースごとに設定が可能。
※上位の階層のRBACロール設定は、下位の階層に継承される。

一方で、AWSでのリソースに対するアクセス管理では、まずIAMユーザー（あるいはIAMグループ）に対してIAMポリシーの付与を行う。
操作はすべてIAMの画面内で完結し、その設定にリソースの存在は関係しない。
AWSの場合、リソース側からアクセス制御を実施したい場合、S3バケットポリシーなどの「リソースベースのポリシー」を利用する。
そのため、AzureでのRBACロールの設定は、AWSでのIAMポリシー設定とリソースベースのポリシー設定の両側面を持っていると言えるのではないか。

###Azureポリシーについて（上表中※2）
利用できるリソースの種類やリージョンに制限をかけたいとき、[Azureポリシー](https://docs.microsoft.com/ja-jp/azure/governance/policy/overview#:~:text=Azure%20Policy%20%E3%81%AF%E3%80%81%E7%B5%84%E7%B9%94%E3%81%AE,%E6%A9%9F%E8%83%BD%E3%81%8C%E5%82%99%E3%82%8F%E3%81%A3%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82)を使う。
Azureポリシーは管理グループ、サブスクリプション、リソースグループに割り当てることが可能。

ポリシーに反するリソースの展開の防止（**拒否**）の他、そのポリシーに準拠しているかどうかの評価（**監査**）も可能である点が興味深い。
ポリシーとして「監査」が設定されている場合、定期的に状態が検査され、ポリシー違反の有無が表示される。
ポリシーに準拠していないリソースの自動修復も可能。
![mosaic_20220211160317.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/22b6ec3b-853e-2d76-8b70-e46d206eb87d.png)
AWSの場合を考えると、例えば利用可能なリージョンを制限しようとしたとき、方法は2つある。
　①IAMポリシーの「Condition」セクション
　②AWS OrganizationsのSCP(Service Control Policy)機能
また、リソースのコンプライアンス準拠状態を評価したい場合、AWS Configを利用することになる。
そのため、AzureポリシーはAWSのIAM ポリシー、AWS OrganizationsのSCP、AWS Configに該当すると考えた。



##(2) ストレージアカウント
各ストレージサービスの利用の前提となる。
実際にリソースを作成する前に、まずストレージアカウントで各ストレージの設定だけしておく、というイメージ。

[Fundamentals対策](https://qiita.com/yuki_ink/items/417a52b8f42fca258171#%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88)で掲載したAWSサービスとの対応付けを再掲しておく。

|ストレージサービス  |AWS  |
|---|---|
|BLOB（Binary Large Object）ストレージ  |S3  |
|Fileストレージ  |EFS / FSx  |
|Tableストレージ  |Dynamo DB ※　 |
|Queueストレージ  |SQS  |

AWSの場合、S3バケットを例に挙げると、パブリックアクセス設定やバージョニング設定は、バケットを作成するその時に行う。
しかし、Azureの場合、BLOBストレージ、Fileストレージなど各種ストレージサービスの設定を最初にまとめてしておき、実際にBLOBストレージを作成する際は名前を指定するだけ、という形になる。
※ストレージアカウントの種類を「Standard 汎用 v2」としたときのイメージ

###ストレージアカウントの種類
ストレージアカウントを作成する際、まずはその種類を決める必要がある。
ストレージアカウントの種類によって、下記が決定される。
**　　●どのストレージサービスが利用できるか**
**　　●どの冗長オプションが利用できるか**
**　　●ストレージのパフォーマンス**

ストレージアカウントの種類は近年頻繁に変わっているため、ここでは明記せず、公式ページを参照していただきたい。
（テキストで紹介されている「Standard 汎用 v1」は既に消えている。。）

https://docs.microsoft.com/ja-jp/azure/storage/common/storage-account-overview#types-of-storage-accounts


###冗長オプション（データのレプリケーション）
ストレージアカウントの作成時、冗長オプションも設定する必要がある。
上記のストレージアカウントの種類によって、選択できる冗長オプションが変わる点に注意。

AWSのストレージサービスでは耐久性と可用性はAWSの既定に従うケースがほとんどのため、ユーザー側でそれらを明示的にコントロールできる（しないといけない）のは新鮮。
また、読み取り専用エンドポイントも併せて利用できる冗長オプション(RA)があるのも面白いと思った。

こちらの記事が分かりやすかったです。

https://qiita.com/hikaru_motomiya/items/18055deb63b5515b6a9b


###BLOBストレージのアクセス層
BLOBストレージには、アクセス頻度と保持期間に基づいてデータをコスト効率よく保管できるよう、「アクセス層」という機能が用意されている。
ということで、**「BLOBストレージのアクセス層」＝「S3 のストレージクラス」**。

BLOBストレージのアクセス層は下記の3種類。
 - ホット
 - クール
 - アーカイブ

せっかくなので、S3のストレージクラスと対応付けてみる。

|BLOBストレージのアクセス層  |S3 のストレージクラス  |
|---|---|
|ホット  |Standard　 |
|-  |Intelligent-Tiering 　 |
|クール（ZRS：ゾーン冗長ストレージ※）  |Standard-IA (Infrequent Access)  |
|クール（LRS：ローカル冗長ストレージ※）  |One Zone-IA |
|-  |Glacier Instant Retrieval  |
|-  |Glacier Flexible Retrieval（旧Glacier）  |
|アーカイブ 　|Glacier Deep Archive  |

※冗長オプションで別途設定

いや、S3のストレージクラス充実しすぎ。。

BLOB データのアクセス層は、「ホット」と「クール」をまとめて「オンラインアクセス層」と言ったりするらしい。
また、「アーカイブ」は最小保存期間が180日、データの取り出しに最大15時間かかることから、「Glacier Deep Archive」相当の機能と判断した。
※「Glacier Deep Archive」は最小保存期間が180日。データの標準取り出し時間は 12 時間以内。

S3同様、BLOBでもライフサイクル設定によるアクセス層の移行が可能（ただし、汎用v2 StorageおよびBlob Storageのアカウントのみ）。

https://docs.microsoft.com/ja-jp/azure/storage/blobs/access-tiers-overview


###ストレージアカウントへのアクセス
主に3つのパターンがあり、特徴もAWSと通ずるものがあったため、両者を対応付ける。

|Azure  |AWS  |
|---|---|
|マネージドID（IAM）  |IAMロール　 |
|共有アクセス署名（SAS）  |署名付きURL 　|
|アクセスキー  |アクセスキーID・シークレットアクセスキー  |

・基本的にはマネージドID
・有効期限やIP制限をかけるなら共有アクセス署名
・アクセスキーはセキュリティリスクが高く非推奨
というように、AWSエンジニアにはお馴染みの思想がそのまま使える。

ただし、上記の対応付けが完全に正しいわけではなく、差異もある。

Azureの共有アクセス署名は「ストレージアカウント」の機能として提供され、BLOB、File，Table，Queueのいずれのストレージでも利用できる。
しかし、AWSの署名付きURLは、それぞれのストレージに対応するサービスの全てで利用できるわけではない。

また、Azureのアクセスキーはストレージアカウント作成時に自動で生成されるものであり、ユーザーの権限とは何の関係もない。
（アクセスキーを使えばストレージアカウント全体にフルコントロールでアクセスできる。震える。）
一方でAWSのアクセスキーID・シークレットアクセスキーはIAMユーザーに紐付くものであり、それらを使って引き受けられる権限はIAMユーザーに付与されている権限に依存する。

AzureとAWSの対応付けはあくまでイメージとして考えていただきたい。。（この項目に限らず）


##(3) Azure App Service
ホスティングしたアプリケーションの負荷分散、スケーリングなどを自動でやってくれる、AzureのPaaSサービス。
ということで、**「Azure App Service」＝「AWS Elastic Beanstalk」**。

それぞれのサービスで出てくる概念についても対応付けてみる。

|Azure App Service  |AWS Elastic Beanstalk  |
|---|---|
|App Service プラン  |アプリケーション　 |
|デプロイスロット  |環境 　 |

「App Service プラン」の作成時は、OSの種類やSKU、冗長構成を指定する。
Elastic Beanstalkの「アプリケーション」作成時は「より多くのオプションの設定」としてインスタンスタイプなどを指定できるが、それはあくまでオプションであり、特に要件がなければ気にする必要はない。
「App Service プラン」ではそれらを（ある程度）明示的に指定する必要がある、というイメージ。

「デプロイスロット」はElastic Beanstalkの「環境」と同様、URLスワップに対応しており、Blue-Greenデプロイの手段として利用可能（ただし、SKUがStandard以上のApp Serviceプランのみ）。


##(4) SKU - Stock Keeping Unit
Azureには「SKU」という、価格オプションのような概念がある。
この選択内容で利用できる機能が決まる。
[こちらの記事](https://wisdom-gate.jp/blog/2018/12/11/sku%E3%81%A3%E3%81%A6%EF%BC%9F/)では、SKUを「作成するリソースでの選択可能な機能種類」と定義していた。

SKUを指定しなければならないサービスは、先述のAzure App Serviceをはじめ、Azure Load Balancerや仮想ネットワークゲートウェイなどがある。

|SKU指定が必要なサービス（例）  |SKUのオプション  |
|---|---|
|Azure App Service  |Free、Shared、Basic、Standard、Premium、Isolated　 |
|Azure Load Balancer  |Basic、Standard、Gateway　　|
|仮想ネットワーク ゲートウェイ  |[Basic、VpnGw1、VpnGw2など...](https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways#gwsku) 　 |

お気づきの通り、SKUのオプションはサービスによって異なる。
そのため、例えば同じ「SKU=Basic」でも、サービスによって意味が変わってくる点に注意。



##参考
・[AWSとAzureのID管理の違い【AWS技術者のためのAzure入門 第１回】](https://jinzai.edifist.co.jp/aws-no1-id-config-compare)
・[Azure 勉強メモ (Azure AD と RBAC)](https://qiita.com/RyomaTaniyama/items/6bd3fd0506345a5f8de4)
・[Azure Storage 再入門](https://www.softbanktech.co.jp/special/blog/cloud_blog/2019/0019/)
・[SKUって？](https://wisdom-gate.jp/blog/2018/12/11/sku%E3%81%A3%E3%81%A6%EF%BC%9F/)



#終わりに
前回の記事より書くのに苦労しました(^o^;
AzureについてFundamentalsのときより深く勉強したことで、AzureとAWSの共通点より差異の方に着目するようになってしまい、この記事のテーマである共通点の方に沿ってまとめるのが難しかったです笑。

アイデンティティとガバナンスの管理については、AWSとAzureではかなり毛色が違うように思います。
個人的にはAWSのやり方のほうがシンプルで好きです。

また、ストレージサービス、PaaSサービスでは、冗長構成や性能について、AWSでは設定しなくてよい部分をAzureでは設定しなければならないというケースが多いように思いました。
逆に、AWSではブラックボックスで一律設定になっている部分が、Azureではユーザの思い通りに設定しやすいと言うこともできます。
そのあたりがAzureかAWSかを選ぶときのポイントになるかもしれないなぁと思いました。