AWSとAzureの違いをまとめてみた

一部だけですが、AWSとAzureの違いについてまとめてみました。
サービス名の比較はAzureの公式ドキュメントにまとまっています。
AWS サービスと Azure サービスの比較

共通

ブラウザの管理画面

どちらともWebブラウザでクラウドのリソースを作成・閲覧・削除するためのGUIツールが提供されており、次のような名称で呼びます。

• Azure：Azureポータル
• AWS：AWSマネージメントコンソール

Azureの場合は単にポータル、AWSの場合はコンソールと呼んだりもします。マネージメントコンソールは「マネコン」と略されることもありますが私はこの呼称は使いません。

使い勝手に関しては完全に慣れの問題なのでどちらも一長一短あるとは思いますが、個人的にはどちらかというとAzureポータルのほうがメニューがわかりやすく洗練されている気がして好みです。

AWSマネージメントコンソールは、昔のUIのようにお気に入りをTop画面にピン留めできるように戻したもらえたほうが嬉しいと思ってるのですが私だけでしょうか。。

あとは、リージョンの選択操作で違いがあります。
Azureの場合、ネットワークやサーバなどのリソース作成時に毎回リージョンを選択しますが、AWSの場合は最初にコンソール画面右上でリージョンを選択しておいて、それから各リソースを作成する流れです。

リージョン

Azureは日本にリージョンを開設した当初から東日本、西日本の東西2つのリージョンでサービスを提供しており、国内でも災害対策などでリージョンを跨いで冗長化できる点がAzureの強みでもありました。

AWSも東西2つのリージョンはありましたが、大阪リージョンは「ローカルリージョン」という扱いで、審査を承認された一部のユーザーしか利用できない特殊なリージョンでした。2021年3月にようやく正式にスタンダードなリージョンとして開設されたため、Azureとの優位性の違いは小さくなっていくと思われます。

アベイラビリティゾーン

呼び方は少しだけ異なります。

• Azure：可用性ゾーン
• AWS：Availability Zone

AWSの場合は東西リージョンとも3つのAZがありますが、Azureは2021年9月現在では東日本リージョンのみ3つのAZが提供されており、西日本リージョンは未対応です。

リソースグループ

Azureではすべてのリソースが「リソースグループ」に属します。
Explorer や Finder でフォルダの中にファイルをぽいぽいと放り込んでいくイメージ。そのフォルダ単位でアクセス制御したり、フォルダごとまとめて削除できるように、リソースグループ単位で権限付与、削除、課金明細のグルーピングなどができて便利です。

一般的には、ライフサイクルの異なるリソースごとに分類したり、プロジェクトや環境ごとに分けたりします。（プロジェクトや環境はアカウントで分離したほうが良いですが）

AWSにも「リソースグループ」という概念はあり似たようなことはできるようなのですが、一括削除の用途としては使えないようです。CloudFormation や Terraform でコード管理し始めるとあまり気にならないのだとは思いますが、個人的には似たような機能がAWSにも欲しいなぁと思います。

リソースの名前

AWSを学び始めた頃に最も衝撃的だったのはコレですかね。。

Azureの場合、基本的に作成するリソースには名前を付けます。たとえば、仮想マシンを「websv」で作成すると一覧にはその名前が表示され、かつ、それがOSのホスト名になります。

AWSの場合、同じくEC2を例にあげると、作成時に名前を指定するパラメータはなくて、Nameタグをつけておかないと一覧から探しづらいですし、ホスト名は「ip-xx-xx-xx-xx.ap-northeast-1.compute.internal」のような形式でプライベートIPを元にした名前がつけられます。

ホスト名はともかく、リソースの命名は一律ありでいいんじゃないかと思ったりします。

ネットワーキング

インターネットへの外部接続

AWSの場合、EC2がインターネットに出ていくためには以下の設定が必要です。

• VPCにインターネットゲートウェイをアタッチ
• インターネットゲートウェイ宛のルートを追加したルートテーブルをサブネットに割り当て
• EC2にパブリックIPアドレスを割り当て

Azureの場合、上のどれも必要ありません。
仮想マシンをサブネット上に作成すれば、それだけでインターネットへ出ていくことができます。Azureでは良くも悪くも暗黙的に存在しているものがあり、裏でよしなにやってくれています。

まず、Azureでは「システムルート」と呼ばれる既定のルートテーブルがサブネットに作成されます。もし、こいつをカスタマイズしたい場合は、別途カスタムルートを作成することで上書きできます。

出典：仮想ネットワーク トラフィックのルーティング

さらに、AzureにはデフォルトでSource NAT (SNAT)する機能があり、パブリックIPアドレスを持たないVMであっても、リージョン内にプールされている任意のIPにNAT(変換)される仕組みになっています。注意点含め、以下のブログ記事がわかりやすいです。

アクセス制御

AWSの場合、ACLとセキュリティグループで通信を制御します。

• ACL：サブネット単位の通信を制御。ステートレス
• セキュリティグループ：NIC単位の通信を制御。ステートフル

Azureの場合、ネットワークセキュリティグループ(NSG)で通信を制御しますが、ACLとセキュリティグループを合わせたような性質になっています。

• サブネット、NICどちらにも割り当て可能
• 優先度が低いルールから順に評価
• 許可/拒否の指定が可能
• ステートフル

コンピューティング

仮想サーバ

呼び方は以下のような違いがあります。

• Azure：仮想マシン
• AWS：EC2

最も違いを感じたのはOSの管理者アカウントの指定でしょうか。
Azureの場合、Linuxであればユーザー名を自由に指定し、鍵認証かパスワード認証かを選択できます。Windowsの場合はユーザー名、パスワードを指定できます。

AWSの場合、LinuxであればOSごとにユーザー名は決まっています（作成時に入力しません）AmazonLinuxであれば ec2-user、Ubuntuであればubuntu、Centosであればcentos みたいな感じです。パスワード認証は選択できず、キーペアを作成してSSH接続します。あとでOSの設定をイジってパスワード認証を有効化することは可能です。Windowsの場合もユーザー名はAdministrator固定で、かつ、初期パスワードは自動生成されるのでキーペアで復号して確認します。

可用性セット

これはAzure固有の概念です。AWSにはありません。
可用性セットには「障害ドメイン」と「更新ドメイン」という概念があります。

障害ドメインは、電源やネットワーク機器などを共有する範囲、つまりサーバラックのイメージです。
同一AZに複数の仮想マシンを作成する場合、同じサーバラックに配置されてしまう可能性があり、物理的なハードウェア障害や電源断などの影響を同時に受けてしまう恐れがありますが、可用性セットでグルーピングしておくと共有する範囲が分散され、同時に影響を受けることがなくなります。

更新ドメインは、メンテナンスの影響を受ける範囲です。
WindowsUpdateや計画メンテナンス等、再起動を伴うアップデートが適用される場合に同時に適用されて一斉に再起動されるのを防ぐことができます。

アクセス制御

これが一番ややこしい気がしてます。

• Azure：RBAC
• AWS：IAM

総じてあまり自信がないので間違っている可能性がある点ご了承ください。
AWSの場合、IAMの整理として以下のような感じでしょうか。

• "だれ" にあたるものとしてユーザー(人が利用するアカウント)がある
• そのユーザーの権限をIAMポリシーで定義する
• IAMポリシーには操作できる権限だけでなく"何を"操作できるか "Resource" で対象のリソースも記述できる
• IAMポリシーにはAWSによって用意されている「AWS管理ポリシー」と利用者が自由に作成する「カスタマー管理ポリシー」がある
• ユーザーをグループに所属させ、グループにIAMポリシーを適用することでまとめて権限を付与できる
• 人だけでなくEC2などのAWSリソースや特定のアカウントに権限を付与するための仕組みとしてIAMロールがある

Azureの場合も似ていますが、ロールの意味が違う点がややこしい。

• ユーザー、グループの概念は同じ
• IAMポリシーのことをAzureでは「ロール(役割)」と呼ぶ
• ロールにはAzureによって用意されている「組み込みロール」と利用者が自由に作成する「カスタムロール」がある
• "何を"の指定は「スコープ」で定義する
• IAMロールのことをAzureでは「マネージドID」と呼ぶ

さらにややこしいのが、Azureサブスクリプションと AzureAD の関係。ユーザーに関する要素はAzureADに切り離されているイメージ。ほんで、どちらにも管理者アカウントがあると。。以下のMSブログ記事が参考になります。

IaC

最後にインフラのコード化について。

• ARMテンプレート
• CloudFormation

AWSのCloudFormationでは JSON / YAML で記述できますが、ARMテンプレートは JSON のみです。

JSONのみはツライと思うのでYAMLのサポートを期待していたのですが、いつの間にかドメイン固有言語 (DSL)で記述する Bicep というツールが用意されていました。Terraformっぽい。

まとめ

今回はAWSとAzureのサービスや用語の違いについてご紹介しました。
個人的な感想としては、Azureのほうが初心者に優しくわかりやすい気がしますが、AWSのほうが情報量が多いので圧倒的に学びやすいと思います。