Azure経験者がAWS案件に入る前に知っておきたい3つの違い

Azureでの開発経験を持つエンジニアがAWS案件に参画する際に知っておくべき、管理単位、権限設計（IAMとRBACの違い）、ネットワーク制御（セキュリティグループとネットワークACL）など、設計思想の違いを解説します。

はじめに

Azureを中心に経験してきたエンジニアがAWS案件に入ると、単なるサービスの置き換えでは対応できず、Azureとの違いに戸惑うケースがあります。
実務でつまずきやすいのはサービスの違いというよりも、設計思想が異なる点にあります。

今回は、Azure経験者が最初に押さえておきたいポイントとして、管理単位、権限設計、ネットワークに関する違いを紹介していきたいと思います。

1. AWSアカウント分離によるマルチアカウント運用

Azureでは、サブスクリプションやリソースグループを管理単位として意識することが多いかと思います。
一方でAWSでは、AWSアカウント自体がセキュリティ、アクセス制御などの管理単位として扱われます。

AWSのベストプラクティスとしてはアカウント単位で分離することを推奨しています。
※案件規模や既存の運用方針によってはVPCなどを分離単位として扱うケースもあります。

AWS案件参画時は、まず以下を確認すると構成を把握しやすくなります。

環境やシステムをアカウント単位で分けているか
AWS OrganizationsやOUを使っているか
SCPなどのガードレールが設定されているか

2. Azure RBACとAWS IAMの違い

Azure RBACがロールを選んで割り当てる仕組みであるのに対し、AWS IAMはポリシーを組み立ててアタッチする仕組みとなっています。

Azure RBACは「誰に」「どのロールを」「どのスコープで」付与するかを考えます。

一方で、AWS IAMは複数のポリシーを組み合わせて最終的なアクセス可否を決めます。
そのため、IAMロール側に権限が付いているかだけではなく、関係するポリシー全体（SCP、リソースベースポリシー、アクセス許可の境界、信頼ポリシーなど）で許可されているかを見る必要があります。

権限関連で押さえておきたいポイントは以下のとおりです。

IAMユーザー、IAMロール、IAMポリシーの違い
アイデンティティベースポリシーとリソースベースポリシーの違い
信頼ポリシーの役割
SCPによる制御の有無
明示的なDenyの影響

※信頼ポリシー： IAMロールを別のエンティティ（他のAWSサービスやアカウント）が引き受けるための許可を定義するもの

3. ネットワークはセキュリティグループとネットワークACLを使って制御する

Azureではネットワークセキュリティグループ（以下NSG）を、AWSではセキュリティグループとネットワークACLを使って通信を制御します。
NSGはサブネット、NICの両方に適用することができますが、AWSではセキュリティグループとネットワークACLを使い分ける点が大きな違いです。
AWSにおける通信制御は、セキュリティグループはEC2インスタンスなどのリソース単位で、ネットワークACLはサブネット単位でといったように役割が分かれています。

Azureとの対比で整理すると以下のとおりです。

	NSG（Azure）	セキュリティグループ（AWS）	ネットワークACL（AWS）
適用単位	サブネット / NIC	リソース	サブネット
ステート	ステートフル	ステートフル	ステートレス
設定ルール	許可 / 拒否	許可のみ	許可 / 拒否