Aws To Azure Cheat Sheet

Mastering Cloud Transition: AWS to Azure Reference for Engineers

Cloud migration projects, especially those involving AWS-to-Azure transitions, are loaded with nuance and edge cases that catch teams off guard. Classic scenario: the business demands rapid migration, expecting a lift-and-shift, but architectural mismatches between platforms lead to project overruns. An engineer’s reference table—not a sales gloss—keeps velocity up and surprises down. This mapping targets experienced teams, calling out critical feature differences, gotchas, and practical caveats.

AWS/Azure Service Equivalency Table

Practical Migration Workflow

Step 1: Inventory Everything

• Use aws resourcegroupstaggingapi get-resources --tag-filters Key=Migration to pull in-scope assets.
• Document dependencies at the protocol and port level; VNet peering gaps often skew expectations.

Step 2: Baseline Configuration

• Spin up Azure resources using ARM or Bicep templates for infrastructure as code parity (avoid click-ops).
• Example: VM deployment via CLI—

  az vm create --resource-group prod-rg \
    --name web-01 --image Ubuntu2204 --size Standard_D2s_v5 \
    --admin-username azureuser --generate-ssh-keys
  

• Translate Security Groups to NSG rules; test with Test-NetConnection from deployment host.

Step 3: Data and Service Migration

• Databases: Azure Database Migration Service facilitates near-zero downtime cutovers for MySQL/Postgres.
• Object Storage:

  azcopy copy 'https://mybucket.s3.amazonaws.com/*' 'https://mystorageaccount.blob.core.windows.net/container' --recursive
  

  Note: AzCopy infrequently stalls with large object counts (>1M) due to throttling—split at prefix if needed.

Step 4: Application Refactoring

• Lambda to Functions: Handler signatures may require change; environment variables may be handled differently.
• AKS/EKS: AKS disables Docker runtime by default (uses containerd). Update Helm charts as needed.

Migration: EC2 & RDS Backed WebApp Example

Scenario: Migrating a Django app on EC2 serving traffic behind ALB, talking to RDS Postgres with S3-hosted assets.

Steps:

1. Compute: Azure VM scale sets for web layer (Standard_D4s_v5). Resize for comparable CPU/RAM.
2. Load Balancing: Azure Load Balancer cannot directly terminate TLS; use Application Gateway for L7, with WAF.
3. Database: Azure Postgres MI (v14) with geo-redundant backup enabled.
4. Assets: Script S3-to-Blob migration with AzCopy; set blob lifecycle policies for hot/cool tiers.
5. Monitoring: Configure Azure Monitor to log to Log Analytics; install OMS agent on VMs to mimic CloudWatch metrics.

Known Issue: Post-migration, expect cold starts in Functions to behave differently; memory usage limits (1.5GB default) are lower than larger Lambda configs unless pre-provisioned.

Side Note: Non-Obvious Gaps

• AWS’s Route 53 Traffic Flow isn’t replicated in Azure DNS—geo-routing needs Traffic Manager, which complicates multi-cloud DNS.
• Cosmos DB’s consistency levels do not match DynamoDB strong/weak semantics—review for critical workloads.
• Azure’s spot instance pricing and eviction rates differ from EC2 spot; use az vm list-skus for region support.

Migration Isn’t “Drag and Drop”

Migrating to Azure requires both tactical service mapping and operational re-tooling. API signatures, authentication flows, and network controls won’t always match—test each step, especially for security and compliance.

Keep this table in rotation during planning and deployment. The printable engineer-friendly PDF is still in the works; until then, adapt as requirements evolve.

Trouble picking equivalents or running into code translation blockers?
Leave a note with details, error logs, and configs for targeted guidance.