AWS Transactional Platform with GCP Analytics and ML Services
Designed a true multi-cloud platform where customer-facing workloads remained on AWS while analytics and machine learning capabilities were implemented on GCP using managed data and MLOps services better suited to that part of the workload.
Architecture Diagram
Purpose
The client wanted analytical scale and managed ML capabilities without relocating its transactional application platform out of AWS. The project solved that by keeping OLTP workloads in AWS while moving analytics and MLOps into GCP, creating a best-fit split between transactional ownership and data / ML execution.
Technical Implementation
- Kept the transactional application on AWS by running APIs and background services on EKS with Amazon RDS for PostgreSQL as the system of record, which allowed the client to preserve its existing application runtime, network boundaries, and IAM operating model.
- Replicated operational data from PostgreSQL into BigQuery using Datastream for BigQuery, then used partitioned BigQuery datasets for model features, reporting tables, and historical analysis so analytical workloads were separated from the OLTP path instead of competing with it.
- Built the ML path on GCP with Vertex AI Pipelines, Vertex AI Model Registry, and Vertex AI endpoints for training, versioning, and serving, while using BigQuery as the main feature and monitoring data source because it fit the client's need for managed analytics and model operations without standing up a separate Spark or self-managed ML platform.
- Validated the cross-cloud flow by reconciling source-to-target row counts between RDS and BigQuery, replaying representative CDC windows, running batch prediction tests from Vertex AI against production-like datasets, and returning scored outputs to AWS through versioned files in S3 and application-side integration checks before enabling the workflow for live business use.
Client Delivery & Handover
The work was carried out with the client platform, data, and product teams because the design affected application ownership on AWS as well as analytics and ML operations on GCP. Joint workshops were used to define which capabilities stayed in AWS and which moved to GCP, then paired implementation sessions were used to build the replication, feature, and model-serving paths with the client engineers. Handover included service-boundary documentation, data lineage diagrams, BigQuery dataset guidance, Vertex AI operating runbooks, model release procedures, and training sessions on monitoring, retraining, and cross-cloud support ownership.
Outcome
The client ended up with a practical best-fit multi-cloud model: AWS remained the home for transactional services, while GCP handled analytical scale and managed ML operations without forcing the application platform itself to move.
Project Snapshot
Category
Multi-Cloud & Data
Sector
Multi-Cloud Data & AI
Duration
18 weeks
Next Step
If this project is close to the work your team is planning, Ideamics can discuss comparable architectural decisions, delivery sequencing, and implementation tradeoffs in more detail.