What is the Azure equivalent of AWS ECS? ECS, Fargate, ECR → Azure mapping

For a deeper comparison with architecture diagrams and deployment strategy analysis, see our full blog post: AWS vs Azure container deployment strategies compared.

The mapping

Key differences that break the 1:1 mapping

Orchestration model

AWS separates orchestration (ECS) from compute (EC2/Fargate). You choose a “launch type” per service. Azure combines both into Container Apps, where you choose a plan type (consumption vs dedicated) at the environment level, not per service.

Networking

ECS tasks get ENIs attached to a VPC subnet. Azure Container Apps run inside a Container Apps Environment, which can be injected into a VNet but uses a different networking model (Envoy-based ingress, internal vs external visibility flags).

Scaling

ECS uses Application Auto Scaling with target tracking or step policies. Container Apps use KEDA-based scaling rules with built-in support for HTTP concurrent requests, CPU, memory, and custom metrics from any KEDA scaler.

Cost model

Azure Container Apps can scale to zero and has a meaningful free tier. Fargate always runs (minimum 1 task if service is active).

Migration decision tree

Your AWS workload is...

├── Long-running web service on ECS/Fargate
│   └── Azure Container Apps (consumption or dedicated plan)
│
├── Batch job / scheduled task on Fargate
│   └── Azure Container Instances (ACI) with Logic Apps trigger
│       OR Container Apps Job
│
├── Simple web app on App Runner
│   └── Azure Web App for Containers
│
├── Kubernetes workload on EKS
│   └── AKS (most portable, same manifests with minor changes)
│
└── Event-driven / queue processor on ECS
    └── Container Apps with KEDA scale rule
        (scales to zero on empty queue)

Common pitfalls

• IAM to RBAC translation. ECS task roles map to Azure Managed Identities, not RBAC roles. The permission model is fundamentally different.
• Load balancer differences. ALB features (path-based routing, weighted targets, slow start) are handled by Container Apps ingress natively. You don’t provision a separate load balancer.
• Secrets management. ECS pulls secrets from Secrets Manager/SSM at task start. Container Apps references secrets from Azure Key Vault or environment-level secrets. The injection mechanism differs.
• Logging. ECS uses CloudWatch Logs with awslogs driver. Container Apps sends logs to Azure Monitor / Log Analytics by default. Plan for log pipeline migration.
• Service mesh complexity. If you use App Mesh, don’t assume you need Istio on Azure. Container Apps provides most mesh features (mTLS, traffic splitting, observability) without a separate mesh layer.

Validation

If you’re evaluating a migration, validate the mapping against your specific workloads:

# 1. List your ECS services and their launch types
aws ecs list-services --cluster your-cluster \
  --query 'serviceArns[*]' --output table

# 2. Check resource allocation per service
aws ecs describe-services --cluster your-cluster \
  --services your-service \
  --query 'services[*].{name:serviceName,cpu:cpu,memory:memory,launchType:launchType}'

# 3. Map each to the Azure equivalent using the table above
# Long-running + Fargate → Container Apps (consumption)
# Long-running + EC2    → Container Apps (dedicated) or AKS
# Batch + Fargate       → ACI or Container Apps Job

For EKS workloads, the migration is more straightforward because Kubernetes manifests are largely portable. The main changes are ingress controllers, persistent volume claims (EBS to Azure Disk), and IAM-to-Managed-Identity mapping.

Multi-cloud container strategies often start with “which service maps to which”. But the real complexity is in networking, IAM, and operational tooling. Get the service mapping right first, then plan the operational migration separately.

Planning a multi-cloud container strategy?

Book a free 30-minute call. We help teams migrate container workloads between AWS and Azure with minimal downtime.

Book a call