Healthcare AI Platform Consolidates Four Third-Party Services onto AWS, Moving Its Database to Amazon Aurora
Start Your Cloud Journey
Background
Our customer is a South American healthcare-technology company. Its AI platform automates the work of clinical call centres by booking, rebooking and confirming appointments and diagnostic exams for clinics, laboratories and diagnostic networks. Patients reach it over WhatsApp and, increasingly, real-time voice. The platform serves 5,000 to 10,000 patients a day and processes medical data under local data-protection law.
Its services had grown across four third-party providers and three AWS Regions.
The Challenge
The four outside providers cost about US$27,000 a month. That spend sat outside the company's AWS governance, cost controls and single bill.
The database was the critical risk: a live 456 GB PostgreSQL 15 database handling 200–300 queries a second, a public database endpoint that was a standing exposure on the security rating the customer's own contracts depend on, and a business that could accept only one bounded maintenance window.
The goals were consolidation on AWS, bringing AI under AWS governance, closing the public database exposure without adding attack surface, and leaving the team able to operate the result and repeat the migration.
Our Solution
MyOps by Yael Group delivered the project jointly with its AWS partner Elevata, funded by an AWS incentive, in three phases.
Assess
- Discovery of the full estate and a read-only assessment of the production database, which found it 52% larger than first estimated.
- A Region analysis placed the data plane in US East (Ohio), next to the existing compute.
- A decision tree weighed each database migration approach against the maintenance window. A plain dump-and-restore would have required 5–14 hours of downtime against a 30–90 minute target.
Mobilize
- A design document, target architecture, and cutover and rollback runbooks.
- Four reusable Terraform modules for Amazon Aurora PostgreSQL-Compatible Edition Serverless v2, Amazon RDS Proxy, AWS Database Migration Service (AWS DMS) and AWS PrivateLink. The same code promotes from a dedicated migration account through staging to production.
Migrate
- Applications. Heroku applications were rehosted to Docker Swarm on Amazon Elastic Compute Cloud (Amazon EC2). By mid-July 2026, production ran 22 Swarm stacks with 37 services on AWS.
- Database. PostgreSQL 15 moved like-for-like to Aurora PostgreSQL 15 through AWS DMS. Amazon RDS Proxy fronts the writer, reducing the write cutover to a single repoint, and Aurora is reachable only from inside the Amazon Virtual Private Cloud (Amazon VPC).
- Full rehearsal. An end-to-end rehearsal in a dedicated AWS account achieved 979,501 rows identical on both sides across all 68 tables. All 67 foreign keys validated with zero orphans.
- AI. All 46 production model routes in the customer's AI gateway were mapped to Amazon Bedrock, leaving the application unchanged behind the gateway.
The customer's engineers then carried out the staging and production moves using the delivered runbooks, with MyOps and Elevata providing support.
The Result
- On AWS in production. Most applications run on Docker Swarm on Amazon EC2, and the customer's team is moving the rest. The production database cutover to Amazon Aurora was completed in phases from the runbooks.
- Consolidated and governed. The platform is moving from four outside providers to one AWS estate and one bill, with AI model access available under AWS governance through Amazon Bedrock.
- Safer by design. The database runs privately behind Amazon RDS Proxy, closing the public endpoint without adding attack surface.
- Repeatable and signed off. The customer's team owns the Terraform modules and runbooks to repeat the migration. Its CTO signed off the project in September 2026, confirming the workstreams were delivered to scope.