Google Cloud to AWS Migration with Cross-Region Disaster Recovery for a Direct-to-Consumer E-commerce and AI/ML Group

Aivar delivered the migration in an assessment-led, factory-based model over eight weeks. No workload moved until its move-group had been assessed, right-sized and approved. The solution combined the following:
‍

1. Detailed assessment and sign-off: utilization-based discovery with AWS Application Discovery Service and Migration Evaluator, application dependency mapping, and right-sizing from observed utilization (for example, general-purpose VMs to M7i, memory-heavy to R7i, compute-heavy to C7i, light services to T3, and GPU workloads to g6), followed by steering-group sign-off before the first migration wave.
   ‍
2. Landing zone: AWS Control Tower with eight accounts and AWS Organizations, IAM Identity Center federated to the customer identity provider with MFA enforced, a hub-and-spoke network on AWS Transit Gateway with Site-to-Site VPN for hybrid connectivity during migration, and organization CloudTrail, AWS Config and VPC Flow Logs centralized in a log archive with S3 Object Lock.
   ‍
3. Rehosting of compute: about 55 virtual machines moved with AWS Application Migration Service, sized to observed utilization and launched from templates, with test launches in an isolated subnet before cutover. The web tier runs behind Varnish and load balancers with Auto Scaling.
   ‍
4. Managed database replatforming: PostgreSQL moved to Amazon RDS Multi-AZ using AWS DMS with change data capture, Redis moved to Amazon ElastiCache, and BigQuery moved to Amazon Redshift through Parquet export and staged transfer to Amazon S3. 
   ‍
5. Self-managed services retained where needed: MongoDB, Kafka, ClickHouse, Neo4j and Qdrant were rehosted on right-sized EC2 instances.
   ‍
6. Phased waves: non-production and the AI/ML development environment first, then the AI/ML production platform, and finally the e-commerce production workload.
   ‍
7. Cutover and rollback: each cutover followed a freeze, a final delta sync and a Route 53 switch within an approved change window, with DNS TTL lowered 24 hours in advance. Rollback remained available until formal wave acceptance, and GCP sources were retained for 14 days after cutover.
   ‍
8. Cross-region disaster recovery: AWS Backup managed centrally across accounts, with a primary vault in ap-south-1 and a copy vault in ap-south-2, each encrypted with a customer-managed KMS key, and AWS Backup Vault Lock in compliance mode. Tiers: Gold (RDS, Redshift and e-commerce data) with a 6-hour recovery point plus RDS point-in-time recovery and up to a 4-hour recovery time; Silver (application EC2, EFS/FSx, Kafka and ClickHouse volumes) with a daily recovery point and up to an 8-hour recovery time; Bronze weekly, best-effort. Restore-testing plans run monthly, and a Region-failover game day confirms Gold objectives.
   ‍
9. Security baseline: AWS WAF with the 212 Cloud Armor rules translated and run in count mode before enforcement; AWS Shield on internet-facing endpoints; AWS Network Firewall for centralized egress inspection; Systems Manager Session Manager in place of bastion hosts; GuardDuty, Security Hub (CIS and AWS Foundational Security Best Practices), AWS Config, Inspector, Macie, Secrets Manager and customer-managed KMS keys.
   ‍
10. Cost optimization: right-sized compute, gp3 storage, S3 lifecycle policies, Savings Plans for steady workloads, and scheduled shutdown of non-production environments.
    ‍
11. Migration factory and testing: each move-group was built from infrastructure as code, replicated with AWS MGN, DMS and Data Sync, validated with smoke, functional, performance, data-integrity reconciliation and security tests, and accepted through business UAT before cutover.
    ‍
12. Data and storage migration: 42+ Cloud Storage buckets moved to Amazon S3 through DataSync with structure, encryption, versioning and lifecycle policies preserved; Filestore moved to Amazon EFS and FSx; about 16 TB of block data replicated with MGN.
    ‍
13. Network and DNS: preserved CIDRs and subnets, Transit Gateway routing, NAT Gateways for egress, no publicly reachable database subnets, Route 53 for the storefront domain, and Amazon CloudFront in place of Cloud CDN.
    ‍
14. Serverless, containers and automation: Cloud Functions replatformed to AWS Lambda, containerized services moved to Amazon ECS Fargate or App Runner, and the n8n automation host rehosted on EC2.
    ‍
15. Analytics and messaging: DataStream change capture replaced with AWS DMS into Redshift and S3, Pub/Sub moved to SNS and SQS or Amazon MSK, and Cloud Scheduler replaced with Event Bridge Scheduler.
    ‍
16. Secrets and keys: Secret Manager replaced with AWS Secrets Manager, with rotation; Cloud KMS replaced with customer-managed AWS KMS keys per account and data domain; S3 Block Public Access enforced across the organization.
    ‍
17. Observability and retirement: logging and monitoring consolidated into Amazon CloudWatch, with AWS Config and CloudTrail; 22 terminated VMs, stale snapshots, orphaned disks and redundant host projects retired before migration.
    ‍
18. Retained services: managed Neo4j Aura and third-party SaaS APIs were retained and consumed cross-cloud, as they carry low migration value or contractual constraints.
    ‍
19. Operations and FinOps: Systems Manager Patch Manager for patch compliance, infrastructure as code with peer review, and AWS Budgets, Cost Anomaly Detection and Compute Optimizer for cost governance.
    ‍
20. Generative AI: Amazon Bedrock replaced the previous platform's generative AI service. 
    ‍
21. GPU workloads: GPU training and inference (vLLM) moved to Amazon EC2 g6 instances 
    ‍

Several alternatives were weighed. Amazon RDS and ElastiCache were preferred over self-managed databases because they reduce operational effort and improve availability, while MongoDB and Kafka stayed self-managed because no equivalent managed service was in scope. Large, cold datasets were staged through Amazon S3 in Parquet, while hot data moved online through DataSync and DMS. Amazon Bedrock was chosen to replace the previous platform's generative AI service.

The production environment runs in the Mumbai (ap-south-1) region. Traffic to the storefront passes through Amazon CloudFront and AWS WAF, then reaches an Application Load Balancer spread across three Availability Zones. The application tier runs in private app subnets, with separate groups for the web tier, admin, API and cron services, the n8n automation service and a Varnish cache. The data tier sits in private database subnets in each Availability Zone, holding PostgreSQL on Amazon RDS, Kafka and MongoDB on EC2, Redis on ElastiCache and Amazon Redshift. Shared services include IAM, CloudTrail, KMS, GuardDuty, Security Hub, AWS Config, CloudWatch, ECR and Secrets Manager. AWS Backup copies recovery points across to Hyderabad (ap-south-2).

‍

‍

1. Disaster recovery: The recovery point and recovery time achieved in a restore test or game day, with the date and test type. Give the Gold and Silver tiers separately.
   ‍
2. Production cutover: The downtime in minutes on the cutover date, and whether a rollback was needed.
   ‍
3. Cost: The actual monthly AWS bill for a stated month, compared with the GCP bill for the same workloads. The SOW’s USD 33,790.92 is an estimate and can’t be used here.
   ‍
4. Storefront performance: Page load time or availability before and after cutover, for a stated period. This is the business metric the review asked for.
   ‍
5. Patching hours removed: Hours per month saved on self-managed database servers, from the ops log.
   ‍
6. Consolidation: Confirm that the 13 projects are now in eight accounts. The SOW says so as a plan.
   ‍
7. Bedrock residency: The models in use and whether cross-region inference profiles are switched off.

• Gate the migration on a detailed assessment. Initial discovery was high-level, and nine projects had no detailed inventory. Wave 1 was held until the assessment had been signed off. 
  ‍
• Plan large data moves separately. Roughly 481 TiB of BigQuery data could not transfer inside the window. Exporting to Parquet and staging it in S3 kept the analytics move on schedule. 
  ‍
• Validate firewall rule translation. Moving 212 web application firewall rules carried a risk of gaps. Run the new rules in count mode before enforcement, so gaps surface without blocking traffic.
  ‍
• Clear drift before migrating. Removing terminated machines, stale snapshots and redundant host projects before migration avoided carrying waste into the new estate.
  ‍
• Set recovery objectives per tier with business owners. Record their sign-off alongside the restore-test results, so each tier is committed on evidence.