Insights · Azure + AWS · Cloud Strategy
When one cloud isn't the answer: running Azure and AWS side by side
Federal programs rarely get to pick a single cloud — inheritance, enterprise agreements, and mission systems decide for them. The real question is how to run two clouds without doubling your risk.
The single-cloud debate is largely a commercial fiction. In practice a federal program arrives with an Azure enterprise footprint here, an AWS-hosted mission system there, and a mandate to modernize both without breaking either. On data-modernization work supporting the CDC mission, JRSS engineers have delivered exactly this shape: Azure carrying the analytics platform — AKS for containerized services, Synapse for warehousing, Data Factory for orchestration, Logic Apps for integration — alongside AWS services including Lambda, S3, and RDS where existing systems and program needs put them.
Split by workload, never by half-measures
Hybrid fails when every application is asked to straddle both clouds. It works when each workload lives fully in one cloud — chosen for data gravity, existing accreditations, and service fit — with deliberate, well-defined integration points between them. An event lands in S3 and a Lambda function notifies the Azure pipeline; the seam is explicit, documented, and testable. Two clean estates beat one smeared one.
AWS: LAMBDA · S3 · RDS
ONE TERRAFORM CODEBASE · BOTH CLOUDS AUDITABLE FROM SOURCE CONTROL
One language for two clouds
The technique that makes dual-cloud governable is infrastructure-as-code in a single toolchain. Terraform describes both estates in one language, in one repository, through one review process. Every subnet, role, and policy on either cloud traces to a commit with an author and an approval. For a security office, that changes the conversation entirely: instead of auditing two consoles' worth of hand-made settings, they audit source code — and drift between what was approved and what is running becomes detectable by machine.
Security posture must be written once
Encryption standards, logging requirements, identity boundaries, and least-privilege rules are defined once, as policy, then implemented natively on each side — Azure Policy and RBAC on one, IAM and service control policies on the other. The anti-pattern is letting each cloud's team interpret security independently; the result is two postures, and an assessor will find the gap between them.
The honest trade-offs
Hybrid costs something: two sets of service limits to know, two billing models to watch, and engineers who must be more than single-cloud specialists. It pays for itself when it respects reality — systems stay where their data, users, and authorizations already are, and modernization proceeds without a forced migration that would consume years and budget for no mission gain. The goal is not cloud purity. It is a program that can pass an audit, absorb change, and keep delivering.