はじめに
お疲れ様です。yuki_inkです。
この度、Microsoft Certified: Azure Fundamentals（AZ-900）に合格しました。
私は仕事上AWSに携わることが多くAWS認定資格も保有していますが、他のパブリッククラウドは未経験でした。
しかし世のトレンドはマルチクラウド。
シェア第２位のAzureもやっとくかぁと思い、受験に至りました。
AWSとAzureってサービスの内容に大きな違いはないやろ？ サービスの名前が違うだけやろ？
・・・と上司に言われ、自分でもそう思っていました。
ですが、いざ勉強してみると、そんなことはなかったです。
AWSでは提供されていないようなサービスもありましたし、似ているけど使い方が微妙に違うようなサービスもありました。
AWSの考え方が染み付いている私にとって、Azureの学習は異文化交流のようなものでした。
本稿では、その異文化交流の中で得た知見を残しておこうと思います。
AWSエンジニアがAzureを勉強するメリット
Azure勉強してよかったと思うポイントを2つ紹介します。
①クラウドエンジニアとしての成長
「AWSしか使えません」よりかは「AWSとAzureどっちも分かります」の方が強そう。
また、IT基盤を作って欲しいと言われた時に何も考えずにAWSを採用するのではなく、Azureと比較することで、質の高い仕事ができるようになったかなと思います。
その延長に、マルチクラウドの実装というのも見えてくるはず。
②AWSの勉強にもなる
AWSとAzureのサービスをそれぞれ比較しながら学習を進めると、あれ、AWSのこのサービスなんだっけ？どういう仕組みなんだっけ？何のサービスと統合してるんだっけ？と疑問に思うことがあります。
その都度確かめることで、AWSの知識の深化にも繋がりました。
主に活用した教材
徹底攻略 Microsoft Azure Fundamentals教科書[AZ-900]対応
図が多かったのがよかったです。
テナントやサブスクリプション、可用性セットなどのAWSにはない概念を理解するために、テキストの図は大いに役立ちました。
模擬問題1回分が付いているので、最後の追い込みにも使えました。
AWS サービスと Azure サービスの比較
MicrosoftがAWSとAzureのサービスを比較してくれたものです。
このAzureサービス、AWSで言えば何になるかなと思った時に参照しました。
ただし、網羅性はそこまで高くない印象です。
載ってればラッキー程度に思っておくのが良いかと思います。
AWSエンジニアのためのAzure Fundamentals対策
本題です。
AWSとAzureでサービスに違いがある部分と、私が理解に苦しんだ部分を中心にまとめます。
テナント・サブスクリプション
テナント
Azure ADの「テナント」＝オンプレADの「ドメイン」。
テナントは会社などの組織単位で作成することが一般的。
Azureの利用者は、Azure ADで認証が行われ、サブスクリプションの利用が承認される。
サブスクリプション
「サブスクリプション」＝AWSの「アカウント」。
サブスクリプションは請求、管理、アクセス制御の単位となる。
AWSで本番環境と開発環境を分ける際、「本番アカウント」「開発アカウント」のようにアカウントごと分けるケースがある。
それと同じノリで、本番環境、開発環境で別々のサブスクリプションを契約できる。
サブスクリプションは、必ず1つのAzure ADテナントを信頼する必要がある。
テナントとサブスクリプションの関係は「1対多」になる。
1つのサブスクリプションが複数のテナントを信頼することはできない。
AWSの場合、ID管理はIAMの設定によりアカウント内で完結する。
つまり、「テナント」のような概念はAWSには無いように思う。
文章で書いても伝わりづらいと思うので、こちらの記事をご参照ください。
大変分かりやすかったです。
可用性セット
Azureの冗長化オプションの1つ。
同一AZ（Azureでは「可用性ゾーン」と言われるが、もうAZでいいじゃないかと思う）内で複数の仮想マシンを起動する際、仮想マシンをそれぞれ独立した物理サーバに配置できる。
複数の仮想マシンを「同一の可用性セットに指定する」ことに注意。
AZ冗長を組むほど災対に熱くなれない場合にいいかもと思った。
AWSで言えば、「パーティションプレイスメントグループ」あるいは「スプレッドプレイスメントグループ」に近いか。
Azure Load Balancer
ALBと略したい衝動に駆られる。
Azure Load Balancerはレイヤ4負荷分散装置。
つまり、「Azure Load Balancer」＝AWSの「NLB」である。
これは発狂した。
ちなみに、AWSの「ALB」はAzureの「Azure Application Gateway」にあたる。
ストレージアカウント
ストレージサービスの管理の単位。
公式によれば、
Azure ストレージ アカウントには、すべての Azure Storage データ オブジェクト (BLOB、ファイル共有、キュー、テーブル、およびディスク) が含まれます。 このストレージ アカウントでは、世界中のどこからでも HTTP または HTTPS 経由でアクセスできる Azure Storage データ用の一意の名前空間が提供されます。 ストレージ アカウント内のデータは、持続性があり、高可用性で、セキュリティ保護されており、非常にスケーラブルです。
とのこと。
ストレージアカウントを作成することで、各種ストレージサービスが利用できるようになる。
以下、AWSサービスとの比較。
| Azure | AWS |
|---|---|
| BLOB（Binary Large Object）ストレージ | S3 |
| Fileストレージ | EFS / FSx |
| Tableストレージ | Dynamo DB ※ |
| Queueストレージ | SQS |
つまり、これらのリソースを作るためには、Azureでは事前にストレージアカウントを作っておかなければならない。
しかもストレージアカウントには多くの種類がある。
非常にややこしい。
※NoSQLのキーバリューストアとして、Azureは「Azure Cosmos DB」も提供している。
Tableストレージは使用できるクエリが限定されているため、クエリしたいのであればCosmos DBを推奨。
Azure Monitor
「Azure Monitor」＝AWSの「CloudWatch + CloudTrail」。
| 機能 | Azure | AWS |
|---|---|---|
| メトリクス情報の取得 | Azure Monitor メトリック | CloudWatch メトリクス |
| ログ収集 | Azure Monitor ログ ※1 | CloudWatch Logs |
| アラート | Azure Monitor アラート ※2 | CloudWatch Alarm |
| アクティビティログの取得 | Azure Monitor アクティビティログ | CloudTrail |
正直これはいいなと思った。
※1 Azure Log Analyticsから名称変更され、Azure Monitorに統合
※2 Azure Alertから名称変更され、Azure Monitorに統合
Azure Virtual Network (VNet)
Azureの「VNet」＝AWSの「VPC」。
AWSでは、リージョンの中にVPCが存在して、AZの中にサブネットが存在する。
しかしAzureでは、リージョンの中にVNetとサブネットがある（AZをまたいでサブネットを作成できる）。
こちらの記事が分かりやすかった。
ネットワークセキュリティグループ（NSG）
NSG は仮想マシン（正確に言えばネットワークインターフェース）とサブネットの両方に割り当て可能。
つまり、Azureの「NSG」＝AWSの「SG + NACL」である。
AWSでは基本的にSG（ホワイトリスト）で制御し、明確に通信を遮断したい場合にサブネット単位でNACL（ブラックリスト）を使うケースが多い。
しかし、Azureは基本的にはサブネット単位で制御。
同じサブネットの仮想マシンは全て同じ通信制御が適用されることになる。
それはそれでいいかもと思った。
Azure DDoS Protection
そのままではあるが、「Azure DDoS Protection」＝「AWS Shield」。
どちらも2つのサービスレベルが提供されている。
| レベル | Azure | AWS |
|---|---|---|
| 無償 | Basic | Standard |
| 有償 | Standard | Advanced |
えぇ・・・（困惑）
終わりに
ID管理、オンプレミスとの連携、脅威インテリジェンスベースのフィルタリングといった分野は、やっぱりMicrosoft強いな、、と思いました。
一方で、AzureはAWSに比べ、権限設定の方法や契約方式がややこしいという印象も受けました。
次はAzure Administrator（AZ-104）に挑戦する予定です。
AWSではDevOps Engineer – Professionalを受験予定。
AWS・Azureの比較で新たな発見があれば、またQiitaで共有したいと思います。