Aivar designed and delivered an AWS Control Tower Landing Zone, executed a structured six-week three-wave migration of the full in-scope Azure estate, and established organisation-wide security and observability controls across every account and region.
Governance and Account Structure
AWS Control Tower governs a multi-account Landing Zone with a defined OU structure separating Security, Infrastructure, Workloads, Sandbox, and Suspended accounts. Service Control Policies enforce baseline guardrails across every account — preventing disabling of security services, restricting resource creation to allowed regions, and enforcing MFA. AWS Budgets and billing alarms are configured per account.
Identity and Access
AWS IAM Identity Center is federated with the client's existing Microsoft Entra ID tenant through SAML 2.0 and SCIM-based lifecycle provisioning, replacing local IAM users across the entire Landing Zone. Six permission sets — Read-Only, Power User, Network Admin, Security Admin, Billing Admin, and Break-Glass — cover every required access pattern. IAM Roles for Service Accounts provide pod-level least-privilege for all EKS workloads; EC2 Instance Profiles serve the same purpose for rehosted virtual machines. No long-lived IAM user access keys exist anywhere in the Landing Zone.
Network Architecture
Two production VPCs — one in ap-south-1 and one in us-east-2 — each spanning three Availability Zones and connected through regional Transit Gateways in a hub-and-spoke topology. Public, private, and isolated database subnet tiers separate internet-facing, application, and database resources. Interface and Gateway VPC Endpoints keep traffic to ECR, Secrets Manager, KMS, STS, SSM, CloudWatch Logs, S3, and DynamoDB off the public internet. AWS WAF is deployed on every public Application Load Balancer.
Migration Execution
The in-scope Azure estate — four AKS clusters, fourteen virtual machines, seventeen App Services, twelve managed databases, three Databricks workspaces, and associated storage and networking resources — was migrated across three waves using the 6R framework. AKS clusters were replatformed to Amazon EKS to preserve the containerised operating model and gain IRSA. Virtual machines without a managed-service equivalent were rehosted via AWS Application Migration Service. Azure Function Apps were refactored to AWS Lambda. Databases were replatformed to Amazon RDS using AWS DMS with full-load and CDC replication.
Security and Observability
AWS KMS customer-managed keys, AWS Secrets Manager, GuardDuty, Security Hub, Inspector, Detective, Config, and organisation-wide CloudTrail converge findings and audit data in the Audit and Log Archive accounts. S3 Object Lock protects the central log bucket from modification. IAM Access Analyzer surfaces unintended external access across every account.
As part of discovery, Aivar performed a Total Cost of Ownership (TCO) analysis comparing the client's Azure footprint against the proposed AWS architecture, validating the migration business case ahead of programme kickoff.
1. Kubernetes Manifest Conversion Complexity: Converting Azure-specific Kubernetes manifests — storage classes, ingress annotations, container registry references, and Azure Workload Identity bindings — to their Amazon EKS equivalents took longer than initially scoped. Identity-binding conversion to IRSA required per-application validation rather than a single reusable pattern. A dedicated manifest-conversion and smoke-test checkpoint has been introduced earlier in the wave-planning process for future container migrations.
2. Orphaned Resource Discovery: Discovery surfaced several orphaned resources — duplicate proof-of-concept applications and unused App Service Plans — being paid for without providing value. An explicit retire-candidate review step has been incorporated into Aivar's discovery checklist ahead of cost modelling for all future engagements.
3. Wave Sequencing Value: Migrating non-production workloads in Wave 1 before pre-production and production proved critical for surfacing unexpected dependencies and validating runbooks before any production cutover. This phased sequencing is now a mandatory element of Aivar's migration methodology.
.svg)
.svg)
.svg)
.svg)
