If you’ve ever worked inside a hospital network, you know there’s a layer of legacy technology quietly keeping everything alive and assisting in patient care: ultrasounds, PACS routers, vitals monitors, and biomedical interfaces. These devices rarely make headlines. They don’t run Kubernetes. They are not made with AI or AI agents. They don’t speak DNS. Some don’t even know what DNS is.
They speak one language:
A single static IP address hard-coded into firmware or OS of the devices.
And that’s fine… until the moment you move to the cloud, a different data center, or afterwards, when you have to move between regions in the cloud because of a regional issue, be it failure or server maintenance, or you need to migrate to a newer version. In modern cloud architecture, we expect redundancy across multiple AWS Regions. However, when a failover occurs, the IP address changes, and suddenly, every static IP clinical device loses its ability to communicate.
It’s not just a technical issue. It’s a clinical one. Images stop flowing. Monitors stop reporting. Workstations time out. And you can’t just “fix it.”
Someone would need to physically walk around and reconfigure every device, sometimes hundreds, across multiple facilities. Healthcare cannot afford to have patients at risk during that level of outage. So we set out to solve a problem the cloud still hasn’t fully solved:
A Breakthrough from AWS That Changed Everything
In October 2023, AWS published a small networking enhancement that barely drew attention outside of deep cloud engineering circles:
EC2 instances could now attach ENIs from multiple VPCs
It wasn’t marketed as a healthcare feature. It didn’t appear in any clinical workload guidance. And nowhere in the announcement did AWS describe the magnitude of what this change would enable. For most industries, it was simply another incremental networking improvement. But for healthcare, this update quietly unlocked something extraordinary, even if no one noticed at the time. This was the missing piece. The moment this update dropped, we knew: We could finally build a true multi-region floating IP for healthcare devices.
This was the missing piece. The moment this update dropped, we knew: We could finally build a true multi-region floating IP for healthcare devices.
Designing a Floating IP That Could Survive a Region Dying
The core idea was simple:
- Keep the devices pointed at one IP address forever.
- Make the IP move – not the devices.
To do this, we created a dual-VPC, dual-ENI model.
Historically, EC2 instances could attach multiple ENIs, but all ENIs had to reside within the same VPC. Once that VPC was connected to a Transit Gateway, every ENI on the instance became routable through that attachment. Because the primary ENI always needed to stay online for application and Epic ODB mirror traffic, it was not possible to remove or move the VPC without breaking connectivity, making a true Floating IP architecture impossible prior to the 2023 update.
So we split responsibilities:
Used for:
- Epic replication
- Normal ODB communication
- Application traffic
- Monitoring
This ENI never moves. It’s the stable backbone for Epic.
2. Floating ENI
Used for:
- The clinical-facing static IP (for example, 172.30.26.45)
- Routing traffic from DICOM, PACS, vitals, etc.
- Region-to-region mobility
The ENI itself remains attached to the ODB instance, but the reachability of its IP moves between regions via Transit Gateway routing. To the devices, the IP appears to “live” in whichever region is currently active, even though they never change their configuration.
We placed the Floating IP/ENI in a Floating VPC: a small, isolated VPC that exists purely to hold the reusable static IP block.
It’s paired across both regions using identical CIDRs. That makes the IP portable – and portable means survivable.
Failover Isn’t Instant … and That’s Okay
One thing we discovered quickly: Failover timing isn’t dictated by your code. It’s dictated by AWS Transit Gateway lifecycle states.
Here’s the real breakdown from production testing:
Time
- Demotion (remove routes) ~60 seconds
- ENI detach (TGW) ~4 minutes
- Promotion (attach to master region) ~75 seconds
- TGW route propagation3–4 seconds
Total failover ~4 .6 minutes
This is predictable. It’s consistent. And most importantly, it’s fully acceptable for clinical RTO/RPO based on customer input.
We are not failing over a transactional system. We’re shifting routing for diagnostic and monitoring devices.
A four-minute improvement is lifesaving compared to manual IP reconfiguration across multiple hospitals.
Building Automation That Prevents Split-Brain Chaos
Failover isn’t the hard part. Failover without split-brain is the hard part.
- AWS Step Functions
- AWS Lambda
- DynamoDB Global Tables
- Transit Gateway route updates
- ENI state validation loops
- Never allows two regions to become master
- Stops promotion if the ENI is still attached elsewhere
- Corrects invalid states autonomously
- Rewrites all four TGW route tables deterministically
- Updates DynamoDB to record the authoritative master region
It doesn’t just fail over. It fails over “safer than a human could”.
This Is Not Just for Epic ODB, It’s for Every Static-IP Device
Epic ODB is only one example. This architecture now supports or can support any device or system that relies on static IP routing:
- Ultrasound machines
- CT/MRI scanners
- PACS/VNA routers
- Lab instruments
- Vital sign monitors
- Biomedical devices
- HL7 interfaces
- IoT/OT medical systems
If it doesn’t speak DNS, if it can’t be centrally updated, if reconfiguring it is a clinical or operational risk…It can benefit from this architecture.
Avoiding “DEATH BY PENNIES” 85% Cost Reduction
Let’s talk cost. Cloud micro-billing is real. Years ago, I started calling it: “DEATH BY PENNIES” – when millions of sub-cent transactions silently drain your cloud budget.
- A real-time file watcher for instant change detection
- A 10-minute Step Function safety check
- A 3-minute stabilization wait after failover
- Debounced ENI state checks to avoid thrashing
The cost dropped from:
- $226/month → $33/month
- ≈85% savings
- With zero impact on RTO/RPO
Optimization didn’t require compromising resiliency. It just required respecting the difference between control-plane checks and data-plane impact—and avoiding DEATH BY PENNIES along the way.
What This Means for Healthcare Cloud Architecture
This solution:
- Enables real multi-region resiliency for static-IP systems
- Reduces clinical downtime risk
- Hardens Epic’s disaster recovery posture
- Eliminates manual device reconfiguration during regional events
- Provides a reusable pattern for any healthcare ecosystem
- Ties together multiple AWS enhancements into a cohesive system
- Delivers fully automated, self-healing failover
- Avoids “Death by Pennies” micro-billing traps
- Works without additional managed routing appliances, NAT, or EIPs
This is the kind of architecture that quietly improves healthcare not by adding shiny new features, but by making the critical, boring, invisible parts reliable.
As an AWS Premier Tier consulting partner, Optimum Healthcare IT works with your organization to align your business needs and future growth strategy.
Subscribe to The Optimum Pulse
Make sure to subscribe to our LinkedIn newsletter for the latest news and updates in healthcare IT.
