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

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

#主に活用した教材
###合格対策Microsoft認定試験AZ-104:Microsoft Azure Administratorテキスト&演習問題
2022年2月時点で日本語のAzure Administrator対策本がこれしかなく、選択の余地なしに購入しました。
全体的にバランス良くまとまっており、また演習問題・模擬試験も掲載されているため、試験対策としては本書で十分という印象です。

ただ、サービスによっては、Fundamentals対策で使った黒本には書かれてるけどこっちには書かれてない、というようなものもありました（それだけFundamentalsの試験範囲が広く浅くだった??）。
そのため、本書をメインの教材して活用しつつ、時々Fundamentalsの黒本を流し読んでその内容を思い出してみたり、実際にAzure Portalを触って具体的な設定方法のイメージを掴んだりするという形で対策を進めました。

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

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

特にストレージアカウントについては、そもそもそんな概念はAWSにないため、非常に理解に苦しみました。
Fundamentals対策でも多少触れてはいるものの、当時は「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ロールを設定するときの画面操作もそんな感じで、リソースの画面から権限設定を行う。

※RBACロールの設定は、サブスクリプション、リソースグループ、個別のリソースごとに設定が可能。
※上位の階層のRBACロール設定は、下位の階層に継承される。

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

###Azureポリシーについて（上表中※2）
利用できるリソースの種類やリージョンに制限をかけたいとき、Azureポリシーを使う。
Azureポリシーは管理グループ、サブスクリプション、リソースグループに割り当てることが可能。

ポリシーに反するリソースの展開の防止（拒否）の他、そのポリシーに準拠しているかどうかの評価（監査）も可能である点が興味深い。
ポリシーとして「監査」が設定されている場合、定期的に状態が検査され、ポリシー違反の有無が表示される。
ポリシーに準拠していないリソースの自動修復も可能。

AWSの場合を考えると、例えば利用可能なリージョンを制限しようとしたとき、方法は2つある。
　①IAMポリシーの「Condition」セクション
　②AWS OrganizationsのSCP(Service Control Policy)機能
また、リソースのコンプライアンス準拠状態を評価したい場合、AWS Configを利用することになる。
そのため、AzureポリシーはAWSのIAM ポリシー、AWS OrganizationsのSCP、AWS Configに該当すると考えた。

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

Fundamentals対策で掲載した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」は既に消えている。。）

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

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

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

###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のアカウントのみ）。

###ストレージアカウントへのアクセス
主に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」という、価格オプションのような概念がある。
この選択内容で利用できる機能が決まる。
こちらの記事では、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など...

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

##参考
・AWSとAzureのID管理の違い【AWS技術者のためのAzure入門 第１回】
・Azure 勉強メモ (Azure AD と RBAC)
・Azure Storage 再入門
・SKUって？

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

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

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