「AWSは分かるけど、Azure案件にアサインされて、結局あのサービスはAzureで言うと何にあたるんだろう…」——AWS出身のエンジニアがAzureを触り始めるとき、あるいはその逆のケースで、真っ先に欲しくなるのが「サービスの対応表」です。AzureとAWSは名称も設計思想も異なりますが、機能面ではほぼ1対1で対応するサービスが数多く存在します。この記事では、コンピューティングからセキュリティまで、分野別にAzureとAWSのサービスを一覧で対応させて整理します。
コンピューティング
| 用途 | AWS | Azure |
|---|---|---|
| 仮想マシン | EC2 | Virtual Machines |
| オートスケーリング | Auto Scaling | Virtual Machine Scale Sets |
| サーバーレス関数 | Lambda | Azure Functions |
| マネージドコンテナ | ECS | Container Apps |
| Kubernetes | EKS | Azure Kubernetes Service(AKS) |
| コンテナレジストリ | ECR | Azure Container Registry |
| PaaS(Webアプリ) | Elastic Beanstalk | App Service |
| バッチ処理 | AWS Batch | Azure Batch |
仮想マシン(EC2 / Virtual Machines)とKubernetes(EKS / AKS)は、名称こそ違えど設計思想もほぼ共通しています。一方でPaaSのWebアプリホスティングは、AWSがElastic Beanstalk(EC2やコンテナを裏側で構成する形)であるのに対し、AzureのApp Serviceはより直接的な「Webアプリ専用PaaS」として位置づけられており、Azureの方が手軽に使われる傾向があります。
ストレージ
| 用途 | AWS | Azure |
|---|---|---|
| オブジェクトストレージ | S3 | Blob Storage |
| ブロックストレージ(VM用) | EBS | Managed Disks |
| ファイル共有 | EFS | Azure Files |
| アーカイブストレージ | S3 Glacier | Blob Storage(Archiveアクセス層) |
| CDN | CloudFront | Azure CDN / Front Door |
S3とBlob Storageはどちらもオブジェクトストレージの中核サービスで、ストレージクラス(頻繁アクセス/低頻度アクセス/アーカイブ)の考え方もよく似ています。ただしAzureはBlob Storage単体でアクセス層(Hot/Cool/Archive)を切り替える設計であるのに対し、AWSはS3・S3 Glacierといった形でサービス自体が分かれている点が異なります。
データベース
| 用途 | AWS | Azure |
|---|---|---|
| リレーショナルDB(マネージド) | RDS | Azure SQL Database |
| フルマネージドNoSQL | DynamoDB | Cosmos DB |
| データウェアハウス | Redshift | Azure Synapse Analytics |
| インメモリキャッシュ | ElastiCache(Redis/Memcached) | Azure Cache for Redis |
| MySQL/PostgreSQL互換 | RDS for MySQL/PostgreSQL | Azure Database for MySQL/PostgreSQL |
DynamoDBとCosmos DBはどちらもグローバル分散・低レイテンシを謳うフルマネージドNoSQLですが、Cosmos DBはAPIレベルでSQL・MongoDB・Cassandraなど複数のインターフェースを選べる点が特徴で、既存資産の移行先として選ばれやすい傾向があります。
ネットワーク
| 用途 | AWS | Azure |
|---|---|---|
| 仮想ネットワーク | VPC | Virtual Network(VNet) |
| ロードバランサー(L4) | Network Load Balancer | Azure Load Balancer |
| ロードバランサー(L7) | Application Load Balancer | Application Gateway |
| DNS | Route 53 | Azure DNS |
| オンプレ接続(専用線) | Direct Connect | ExpressRoute |
| VPN接続 | Site-to-Site VPN | VPN Gateway |
VPCとVNetは基本概念がほぼ同じで、サブネット・ルートテーブル・NSG(Network Security Group、AWSでいうセキュリティグループ)といった構成要素も1対1で対応します。ExpressRouteとDirect Connectも同様に、閉域網でクラウドと自社拠点を接続するという目的は共通しています。
ID・セキュリティ
| 用途 | AWS | Azure |
|---|---|---|
| ID・アクセス管理 | IAM | Microsoft Entra ID(旧Azure AD)+ RBAC |
| シークレット管理 | Secrets Manager | Key Vault |
| マルチアカウント管理 | AWS Organizations | 管理グループ(Management Groups) |
| SSO | IAM Identity Center | Entra ID SSO |
| 監査ログ | CloudTrail | Azure Monitor(アクティビティログ) |
ID管理はAzureとAWSで最も設計思想の差が大きい領域です。AWS IAMがクラウド内で完結するのに対し、Entra IDはMicrosoft 365やオンプレADとも統合される全社的なID基盤である点は、Azureとは?AWSとの違いを現役エンジニアがわかりやすく解説でも詳しく触れています。
サーバーレス・アプリケーション統合
| 用途 | AWS | Azure |
|---|---|---|
| 関数実行(FaaS) | Lambda | Azure Functions |
| APIゲートウェイ | API Gateway | API Management |
| メッセージキュー | SQS | Azure Queue Storage / Service Bus |
| Pub/Sub通知 | SNS | Azure Service Bus(トピック) / Event Grid |
| ワークフロー・オーケストレーション | Step Functions | Logic Apps |
| イベントストリーミング | Kinesis | Event Hubs |
メッセージング周りはAzureの方がサービスの粒度が細かく、単純なキューイングにはQueue Storage、エンタープライズ向けのPub/SubにはService Bus、大量イベントの集約・ルーティングにはEvent Gridと使い分ける設計になっています。AWSはSQS(キュー)とSNS(通知)のシンプルな2本立てで、まずはこちらの方が学習コストが低いと感じるエンジニアが多いでしょう。
監視・運用・DevOps
| 用途 | AWS | Azure |
|---|---|---|
| 監視・メトリクス | CloudWatch | Azure Monitor |
| ログ管理 | CloudWatch Logs | Log Analytics |
| インフラ構成管理(IaC) | CloudFormation | ARM Template / Bicep |
| CI/CD | CodePipeline / CodeBuild | Azure DevOps / GitHub Actions |
| コスト管理 | Cost Explorer | Cost Management |
IaCについては、AWSのCloudFormationに対してAzureはARM Template、さらにその上位互換であるBicepが主流になりつつあります。CI/CDはAWSがCodePipeline/CodeBuildで完結させるのに対し、AzureはMicrosoft傘下のGitHubとの連携が強く、GitHub ActionsをそのままAzureのCI/CDとして使うケースも増えています。
対応表を使うときの注意点
ここまでの対応表はあくまで「主目的が近いサービス」を並べたものであり、機能や制約が完全に一致するわけではありません。特に次の点には注意してください。
- 粒度の違い:AWSは1つの用途に対してサービスが1つのケースが多い一方、Azureは似た用途でも複数のサービスに分かれていることがあります(メッセージングなど)。逆にAzureで1つのサービスに機能が集約されているケース(Blob Storageのアクセス層など)もあります。
- 課金体系の違い:同じ「対応関係」にあるサービスでも、課金単位(リクエスト数、実行時間、プロビジョニング容量など)が異なるため、コスト試算は個別に確認が必要です。
- 成熟度の違い:AWSは先発サービスが多く機能が枯れている一方、Azureは後発の分だけ新しい設計思想を取り入れているサービスもあります。移行時は「名前が同じだから同じ」と思い込まず、必ずドキュメントで機能差分を確認しましょう。
まとめ
AzureとAWSは、コンピューティング・ストレージ・データベース・ネットワークといった基本カテゴリではほぼ1対1でサービスが対応しており、片方の知識があればもう片方への応用は決して難しくありません。一方でID管理やメッセージングのように、設計思想そのものが異なる領域も存在します。この対応表を足がかりに、実際の案件で触れているサービスがもう一方のクラウドでは何に当たるのかを調べながら理解を広げていくと、マルチクラウド環境でも迷わず対応できるようになります。