Part 058 — AWS/Azure Mapping Cheat Sheet

Goal: setelah menyelesaikan part ini, Anda mampu menerjemahkan konsep AWS ↔ Azure dengan benar, memahami caveat-nya, dan tidak terjebak pada mapping satu-ke-satu yang menyesatkan.

Part ini adalah cheat sheet, tetapi bukan sekadar tabel nama service. Fokusnya adalah mental model equivalence: apa yang mirip, apa yang berbeda, dan apa dampaknya ke Java/JAX-RS backend, EKS/AKS, private connectivity, identity, observability, security, cost, dan production operations.

Rule utama:

AWS dan Azure sering punya service yang terlihat mirip, tetapi boundary, identity model, network behavior, DNS behavior, policy scope, dan operational ownership-nya bisa berbeda.

1. Mapping Caveat

Jangan membaca tabel mapping sebagai “service A sama persis dengan service B”. Mapping hanya membantu orientasi.

Contoh:

• AWS IAM role bukan sama persis dengan Azure managed identity.
• AWS Security Group bukan sama persis dengan Azure NSG.
• AWS VPC Endpoint/PrivateLink bukan sama persis dengan Azure Private Endpoint/Private Link.
• ALB bukan sama persis dengan Azure Application Gateway.
• CloudWatch bukan sama persis dengan Azure Monitor + Log Analytics.
• EKS bukan sama persis dengan AKS.

Yang harus dimapping adalah:

Concept
Boundary
Runtime identity
Network path
DNS behavior
Policy model
Operational ownership
Failure mode
Debugging evidence
Cost driver

2. Account, Subscription, and Organization Mapping

Review notes

Untuk enterprise backend system, account/subscription boundary biasanya menentukan:

• siapa yang boleh deploy,
• siapa yang bisa membaca logs,
• siapa yang bisa mengubah network,
• siapa yang membayar cost,
• siapa yang menjadi blast radius saat salah konfigurasi.

Internal verification checklist

• Apakah dev/test/prod dipisah account/subscription?
• Apakah shared services punya account/subscription terpisah?
• Apakah network hub punya account/subscription terpisah?
• Apakah logging/security account/subscription terpisah?
• Apakah sandbox dibatasi policy?

3. Region, Availability Zone, and Fault Domain Mapping

Java/JAX-RS impact

Region/AZ memengaruhi:

• latency ke database/broker/cache,
• cross-zone data transfer,
• SDK region configuration,
• failover behavior,
• DNS routing,
• consistency saat multi-region.

PR review question

Apakah dependency ini berada di region/AZ yang sama dengan workload, dan apa dampaknya ke latency, cost, dan failure isolation?

4. Identity and Access Mapping

Critical caveat

AWS IAM role menjawab dua hal sekaligus:

Who can assume me?
What can I do after assumed?

Azure lebih sering memisahkan:

Which identity exists?
What role assignment does it have?
At which scope?
How does workload obtain token for that identity?

Java/JAX-RS impact

Dalam Java service:

• AWS SDK membaca credential dari provider chain.
• Azure SDK sering memakai DefaultAzureCredential atau credential spesifik.
• Runtime identity harus eksplisit untuk Kubernetes.
• Error auth sering muncul sebagai SDK exception, bukan HTTP auth error internal.

Review questions

• Runtime principal sebenarnya apa?
• Scope permission minimum di mana?
• Apakah token/credential temporary?
• Apakah trust relationship terlalu luas?
• Apakah audit log bisa menjelaskan access?

5. Network Mapping

Security Group vs NSG caveat

AWS Security Group:

• stateful,
• attached to ENI/resource,
• allow rules only,
• often used as workload boundary.

Azure NSG:

• stateful,
• attached to subnet and/or NIC,
• has inbound/outbound security rules,
• rule priority matters,
• often combined with UDR/Azure Firewall/private endpoint design.

Java/JAX-RS impact

Network misconfiguration muncul sebagai:

• DNS failure,
• connect timeout,
• TLS handshake failure,
• intermittent latency,
• connection reset,
• broker/database connection timeout,
• SDK timeout.

PR review question

Apakah route, firewall, DNS, and source/destination identity jelas dari pod sampai dependency?

6. DNS Mapping

Common failure mapping

PR review question

From inside the pod, what does nslookup or equivalent resolve, and is that the intended private/public endpoint?

7. Load Balancer and Ingress Mapping

ALB vs Application Gateway caveat

ALB and Application Gateway both solve L7 routing, but review must compare:

• ingress controller integration,
• WAF capability,
• TLS certificate lifecycle,
• private frontend support,
• health probe behavior,
• source IP behavior,
• cost model,
• logs/diagnostics,
• Kubernetes target registration.

PR review question

If a request returns 502/503/504, which layer owns the error and what health check/probe/log proves it?

8. API Gateway and API Management Mapping

Gateway vs ingress caveat

API gateway is not just “another ingress”. It may own:

• API productization,
• consumer authentication,
• usage plans/subscriptions,
• rate limiting,
• request/response transformation,
• developer portal,
• private API boundary,
• API version governance.

Ingress usually owns Kubernetes cluster entry routing.

PR review question

Is this concern API governance, cluster ingress, reverse proxying, or service mesh? Which layer should own it?

9. Private Connectivity Mapping

Caveat: PrivateLink names are misleadingly similar

AWS PrivateLink and Azure Private Link are conceptually similar: private access to services without traversing public internet. But implementation differs in:

• endpoint resource representation,
• DNS integration,
• provider/consumer model,
• security boundary,
• approval workflow,
• service support matrix,
• cross-region/cross-tenant behavior.

PR review question

Is private connectivity proven by DNS, routing, security policy, and service logs — or merely assumed because a private endpoint object exists?

10. Container Registry Mapping

Java/JAX-RS impact

Registry affects application indirectly:

• image pull failure prevents rollout,
• wrong tag deploys wrong version,
• mutable tag breaks rollback evidence,
• vulnerability finding blocks promotion,
• private registry DNS/auth failure causes pod stuck in ImagePullBackOff.

PR review question

Is production deploy pinned to an immutable artifact, and can the cluster pull it privately with the intended identity?

11. Object Storage Mapping

Presigned URL vs SAS caveat

Both can grant temporary access. But review must inspect:

• permissions granted,
• TTL,
• revocation model,
• signed resource scope,
• IP/network restriction if used,
• auditability,
• whether link leaks customer data.

Java/JAX-RS impact

• Upload/download should stream.
• Large file should not load fully into heap.
• Metadata must avoid sensitive data.
• URL generation must be bounded and auditable.
• Retry/idempotency matters for multipart upload.

PR review question

Does this design expose bytes through app service, direct object storage link, or both — and what are the memory/security/observability consequences?

12. Config, Secret, and Key Mapping

Secret vs config rule

Config: non-sensitive behavior input.
Secret: sensitive credential/token/key material.
Key: cryptographic primitive controlling encryption/signing.
Certificate: identity/trust material for TLS or signing.

Do not store all four in one place without a lifecycle reason.

PR review question

What is the lifecycle of this value: who creates it, who reads it, how it rotates, how app reloads it, and how access is audited?

13. Observability Mapping

Critical caveat

CloudWatch is a broad AWS observability service. Azure Monitor is an umbrella platform that often uses Log Analytics workspaces and Application Insights depending signal type. Do not expect identical dashboard/query/retention/cost behavior.

Java/JAX-RS impact

For portability, application should standardize:

• structured logs,
• correlation ID,
• OpenTelemetry traces,
• RED/USE metrics,
• dependency metrics,
• error classification,
• PII-safe logging.

Then export to cloud-native backend based on environment.

PR review question

Are app-level telemetry conventions cloud-portable even if storage/query backend differs?

14. Kubernetes Mapping: EKS vs AKS

EKS vs AKS caveat

The Kubernetes API is portable. The production platform behavior is not fully portable.

Non-portable areas:

• CNI/IP allocation,
• ingress controller annotations,
• service type load balancer behavior,
• workload identity setup,
• storage classes,
• private cluster access,
• observability integration,
• node upgrade process,
• registry auth,
• network policy implementation.

PR review question

Is this Kubernetes manifest truly portable, or does it depend on EKS/AKS-specific annotations, identity, storage, ingress, or networking behavior?

15. Managed PostgreSQL Mapping

Java/JAX-RS impact

• JDBC URL may change across failover.
• TLS certificate chain may differ.
• Connection pool must tolerate failover.
• DNS caching can affect recovery.
• Parameter limits may change query/runtime behavior.
• Private endpoint DNS impacts app connectivity.

PR review question

Does the app connection pool and DNS behavior tolerate database failover and maintenance events?

16. Messaging Mapping

Caveat

Kafka protocol compatibility does not guarantee identical behavior in:

• broker metadata,
• topic management,
• retention,
• partitioning,
• consumer group behavior,
• transactions/idempotent producer support,
• operational metrics,
• quotas/throttling,
• failure semantics.

PR review question

Are we depending on generic Kafka client behavior, or on broker-specific semantics that may not map across AWS/Azure?

17. Redis Mapping

Java/JAX-RS impact

• Redis client must handle failover.
• Connection pool must be bounded.
• Cache miss path must not overload database.
• TTL strategy must be explicit.
• Eviction policy affects correctness.
• Serialization versioning matters.

PR review question

Is Redis being used as cache, lock, session store, rate limiter, or state store — and does the selected managed service mode preserve the required semantics?

18. IaC, Governance, and Policy Mapping

PR review question

Is this policy enforced preventively, detected after drift, or merely documented as convention?

19. Quick AWS ↔ Azure Mapping Table

20. Portability Checklist

Before designing “cloud portable” application behavior, classify portability into layers.

20.1 Portable layers

Usually portable with discipline:

• Java/JAX-RS application logic.
• HTTP API contract.
• OpenAPI spec.
• Structured logging format.
• OpenTelemetry instrumentation.
• Container image format.
• Kubernetes Deployment/Service basics.
• PostgreSQL SQL subset if managed service differences are controlled.
• Kafka client usage if broker semantics are compatible.

20.2 Partially portable layers

Portable only with abstraction or environment-specific config:

• Cloud SDK integrations.
• Object storage access.
• Presigned URL/SAS generation.
• Secret/config retrieval.
• Workload identity.
• Ingress annotations.
• StorageClass.
• Autoscaling behavior.
• Observability export.
• Private endpoint DNS.

20.3 Non-portable layers

Expect provider-specific implementation:

• IAM/RBAC policy.
• VPC/VNet design.
• PrivateLink/Private Endpoint setup.
• API Gateway/APIM policies.
• WAF rules.
• Managed database HA/backup settings.
• Kubernetes CNI behavior.
• Cloud-native audit/compliance policy.
• Cost model.
• Quota model.

20.4 Rule

Do not force portability where correctness, security, or operability requires provider-specific implementation.

Better approach:

Portable application contract
+ provider-specific platform adapter
+ explicit environment verification
+ common observability vocabulary

21. Migration Checklist: AWS to Azure or Azure to AWS

21.1 Identity

• Map runtime identities.
• Replace IAM role assumptions with managed identity/service principal or vice versa.
• Rebuild trust/federation.
• Re-scope permission.
• Validate SDK credential chain.

21.2 Networking

• Rebuild CIDR/VNet/VPC plan.
• Recheck subnet sizing.
• Translate SG/NSG/firewall model.
• Recreate private endpoint/private link.
• Rebuild private DNS.
• Validate hybrid routing.

21.3 Kubernetes

• Translate ingress annotations.
• Translate StorageClass.
• Translate workload identity.
• Translate registry pull auth.
• Validate CNI/IP behavior.
• Validate autoscaling/node pool behavior.

21.4 Data services

• Validate PostgreSQL version/extensions/parameters.
• Validate backup/restore process.
• Validate broker semantics.
• Validate Redis failover/cluster mode.
• Validate object storage consistency/access policy.

21.5 Operations

• Rebuild dashboards.
• Rebuild alerts.
• Rebuild log queries.
• Rebuild audit evidence.
• Rebuild DR runbook.
• Rebuild cost model.

22. Review Checklist for Architecture Mapping

Use this when someone says “Azure equivalent of X is Y” or “AWS equivalent of X is Y”.

[ ] Are we mapping concept or service name?
[ ] Does the boundary match?
[ ] Does the identity model match?
[ ] Does the policy scope match?
[ ] Does the network path match?
[ ] Does private DNS behave the same?
[ ] Does Kubernetes integration behave the same?
[ ] Does SDK credential chain behave the same?
[ ] Does observability produce equivalent evidence?
[ ] Does cost model differ?
[ ] Does quota model differ?
[ ] Does DR behavior differ?
[ ] Does compliance evidence differ?
[ ] What is provider-specific and should not be abstracted away?

23. Common Wrong Assumptions

Wrong assumption 1 — “VPC equals VNet exactly”

Better view:

• Both are virtual network containers.
• But routing, service endpoint, private endpoint, firewall, DNS, and Kubernetes CNI behavior differ.

Wrong assumption 2 — “IAM role equals managed identity”

Better view:

• AWS IAM role combines trust and permission model.
• Azure managed identity is an identity; authorization is via role assignment or service-specific access policy.

Wrong assumption 3 — “Private endpoint means private traffic automatically works”

Better view:

• Private endpoint object is only one part.
• DNS, routing, security rules, firewall, service access policy, and source network must align.

Wrong assumption 4 — “Kubernetes makes cloud differences irrelevant”

Better view:

• Kubernetes standardizes scheduling and service abstractions.
• Cloud-specific CNI, ingress, storage, identity, load balancer, registry, and observability still matter.

Wrong assumption 5 — “Cloud SDK defaults are production-ready”

Better view:

• Defaults may work for happy path.
• Production needs explicit timeout, retry, credential source, region/endpoint, metrics, logging, and throttling behavior.

Wrong assumption 6 — “Object storage is just file storage”

Better view:

• Object storage is not a POSIX filesystem.
• It has object keys, metadata, lifecycle, signed access, eventual operational constraints, and different access semantics.

Wrong assumption 7 — “Multi-cloud improves resilience automatically”

Better view:

• Multi-cloud increases operational complexity.
• It may reduce provider dependency but introduces data replication, identity, DNS, observability, and runbook complexity.

24. Java/JAX-RS Backend Mapping Strategy

For Java/JAX-RS services, avoid scattering provider-specific code everywhere.

Recommended layering:

JAX-RS Resource Layer
  ↓
Application Service Layer
  ↓
Domain Logic
  ↓
Port / Interface
  ↓
Provider Adapter: AWS or Azure
  ↓
Cloud SDK Client

Example port

public interface ObjectDocumentStore {
    UploadResult upload(DocumentUploadCommand command);
    DownloadHandle createDownloadHandle(DocumentDownloadCommand command);
    void delete(DocumentDeleteCommand command);
}

AWS adapter

• Uses S3 client.
• Uses presigned URL if needed.
• Uses AWS credential provider chain.
• Uses region/endpoint config.
• Emits AWS-specific metrics tags carefully.

Azure adapter

• Uses Blob Storage client.
• Uses SAS if needed.
• Uses Azure credential chain.
• Uses blob endpoint config.
• Emits Azure-specific metrics tags carefully.

What should remain common

• Domain operation semantics.
• Request validation.
• File size limit.
• Metadata policy.
• Audit event.
• Timeout budget.
• Error classification.
• Retry policy intent.
• PII/logging rules.

What should remain provider-specific

• IAM/RBAC details.
• Endpoint/private DNS.
• SDK client configuration.
• Signed URL/SAS generation mechanics.
• Encryption key integration.
• Service-specific exception mapping.

25. Internal Verification Checklist

Use this checklist in CSG/team context.

Platform model

• Which cloud providers are actually used?
• Which workloads run on AWS?
• Which workloads run on Azure?
• Which workloads run on-prem?
• Are AWS/Azure used symmetrically or for different product/customer contexts?

Account/subscription

• AWS account structure.
• Azure subscription structure.
• Environment separation.
• Shared services boundary.
• Network boundary.
• Logging/security boundary.
• Cost allocation tags.

Network

• VPC/VNet diagrams.
• CIDR plan.
• Subnet plan.
• Route tables/UDR.
• SG/NSG/firewall rules.
• Private endpoint inventory.
• Public endpoint inventory.
• Hybrid connectivity.

Identity

• IAM roles.
• Azure managed identities/service principals.
• Workload identity mapping.
• CI/CD identity.
• Human operator access.
• Break-glass policy.
• Audit logs.

Kubernetes

• EKS clusters.
• AKS clusters.
• Namespace strategy.
• ServiceAccount strategy.
• Ingress controllers.
• Storage classes.
• Network policies.
• Observability add-ons.

Managed services

• PostgreSQL provider.
• Kafka/RabbitMQ provider.
• Redis provider.
• Object storage provider.
• Secret/config provider.
• Container registry provider.
• Monitoring/tracing backend.

Operations

• CI/CD pipeline.
• Terraform/IaC repo.
• GitOps repo.
• Runbooks.
• Incident notes.
• DR evidence.
• Cost dashboards.
• Security review process.

26. Final Mapping Principle

The most useful mapping is not:

AWS service X = Azure service Y

The useful mapping is:

For this production capability,
what is the runtime boundary,
identity model,
network path,
DNS behavior,
security policy,
observability evidence,
cost driver,
failure mode,
and rollback path
in AWS versus Azure?

That is the level of mapping senior backend engineers need for real production systems.

27. Reference Anchors

Use these as vendor anchors, then verify internal platform reality:

• AWS IAM: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
• AWS VPC: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
• AWS PrivateLink: https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html
• AWS Route 53: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html
• AWS Elastic Load Balancing: https://docs.aws.amazon.com/elasticloadbalancing/
• AWS API Gateway: https://docs.aws.amazon.com/apigateway/
• AWS ECR: https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html
• AWS S3: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
• AWS CloudWatch: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html
• AWS EKS: https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html
• Azure RBAC: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
• Azure Virtual Network: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
• Azure Private Link: https://learn.microsoft.com/en-us/azure/private-link/private-link-overview
• Azure DNS: https://learn.microsoft.com/en-us/azure/dns/dns-overview
• Azure Application Gateway: https://learn.microsoft.com/en-us/azure/application-gateway/overview
• Azure API Management: https://learn.microsoft.com/en-us/azure/api-management/api-management-key-concepts
• Azure Container Registry: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-intro
• Azure Blob Storage: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction
• Azure Monitor: https://learn.microsoft.com/en-us/azure/azure-monitor/overview
• Azure Kubernetes Service: https://learn.microsoft.com/en-us/azure/aks/what-is-aks

28. Key Takeaways

• AWS/Azure mapping membantu orientasi, tetapi tidak boleh menggantikan review desain.
• Mapping paling berbahaya adalah mapping nama service tanpa memahami boundary dan failure mode.
• Identity, private connectivity, DNS, load balancing, Kubernetes integration, observability, and cost are the areas where “equivalent service” most often hides real differences.
• Java/JAX-RS backend should keep domain semantics portable, but cloud adapters explicit.
• In CSG/team context, verify actual account/subscription, VPC/VNet, identity, private endpoint, DNS, EKS/AKS, observability, CI/CD, IaC, and runbook standards internally.