In this piece, I’ll be looking at cloud-agnostic architecture.
- What it is
- Why it’s relevant to Singapore-based teams
- And some principles, trade-offs and common myths
This should help educate teams exploring this option on whether it’s the right approach for them.
What is cloud-agnostic architecture?
Cloud-agnostic architecture is an approach to building, deploying, and operating software so that the same workload runs on more than one public-cloud provider with only minor, scripted changes.
Portability is achieved through adopting open standards, vendor-neutral tooling, and strict abstraction layers. This cloud-agnostic approach prioritises parity over deep integration and preserves optionality.
Just as a universal power adapter works in any country’s electrical outlets, cloud-agnostic applications can “plug into” any cloud provider (AWS, Azure, GCP) without significant modification.
Why Singapore teams should take note
Singapore’s rules make portability and resilience real constraints. The next three points show how regulations are positioning cloud-agnostic design as a key component of compliance in 2025 and beyond.
Financial sector (MAS)
Regulated financial institutions are expected by MAS to develop a workable cloud exit strategy for critical workloads. MAS’s Cloud Advisory says exit strategies should consider data portability and possible migration options. MAS supervisors may require remediation where deficiencies are found, per MAS’s Outsourcing Guidelines.
Personal data (PDPC)
Since 1 Oct 2022, PDPC can fine large organisations up to 10% of annual turnover in Singapore (where local turnover exceeds S$10m) for PDPA breaches. A portable data layer gives the option to move or rehydrate personal data in a compliant region/provider if circumstances change.
IMDA guidance
IMDA’s 2025 Advisory Guidelines are advisory best practices aimed mainly at CSPs/DC operators. They emphasise resilience measures (e.g., BCP/DR planning and testing, including failover tests) that align with building for portability. IMDA encourages adoption; it does not mandate multi-cloud.
Guiding principles of cloud-agnostic architecture design
Cloud-agnostic architecture is built around core principles. Each contributes to the overall goal of ensuring an application remains portable, flexible, and operationally consistent.
If you’re interested in learning how we might build a cloud environment that fits your needs, see our architecture design service.
Abstraction first
Applications rely on neutral interfaces rather than proprietary cloud APIs. For example, code calls RESTful or gRPC APIs and interacts with ingress controllers like Kubernetes, instead of directly referencing AWS or Azure SDKs. Abstraction keeps changes minimal when switching providers.
Portable state
Data and state are stored in ways that facilitate easy migration or replication across clouds. Common examples include widely supported open-source databases such as PostgreSQL and MySQL, or S3-compatible storage that can run consistently on different cloud platforms. If you’re using NoSQL databases, consider whether storing JSON on PostgreSQL meets your needs, before using vendor-specific NoSQL databases. This ensures that stateful workloads remain mobile.
Declarative automation
Infrastructure configurations are stored and managed through infrastructure-as-code (IaC) tools such as Terraform or Pulumi. This approach allows identical environments to be consistently deployed, managed, and audited across different cloud regions or providers, dramatically simplifying cloud migration.
Shared observability
Applications employ vendor-neutral observability tools. Metrics, logs, and traces pass through technologies like Prometheus, Grafana, and OpenTelemetry, providing a single view across clouds. Uniform monitoring simplifies operational troubleshooting, especially during failovers or migrations.
Loose coupling
Applications are designed in loosely coupled, modular components, often as microservices. Individual components can be independently scaled, modified, or migrated between clouds without impacting the entire application, further reducing vendor lock-in.
Business drivers and trade-offs
Although a cloud-agnostic strategy can be highly beneficial, it’s worth mentioning a few of the practical trade-offs.
Global resilience vs. engineering overhead
Why it matters
Businesses need applications to stay available across regions and recover quickly from outages; a cloud-agnostic stance helps by keeping failover paths open beyond a single provider
Trade-off
Avoiding cloud-specific global databases (e.g., DynamoDB Global Tables, Aurora Global Database) means re-implementing replication, failover, and backups on open platforms (e.g., Postgres, Kafka), increasing engineering and operational burden.
Compliance reach vs. multi-cloud complexity & cost
Why it matters
Regulated industries must place workloads in certain jurisdictions and sometimes diversify providers; cloud-agnostic design eases deploying the same system across different vendors and regions.
Trade-off
Multi-cloud adds architectural and operational complexity, can introduce cross-cloud latency, and raises costs through data egress and duplicated tooling.
Negotiation leverage vs. loss of proprietary features
Why it matters
Companies want credible exit options to strengthen their position in pricing talks; cloud-agnostic architectures preserve portability that translates into negotiation leverage.
Trade-off
Favoring portable, lowest-common-denominator services often means forgoing richer, tightly integrated proprietary features that could speed delivery or improve performance.
Key building blocks
In terms of which technologies come into play in agnostic environments, the below are the key building blocks.
Runtime
Applications are containerised and orchestrated with Kubernetes. Helm charts or Kustomize packages define deployments in a way that works consistently across AWS EKS, Azure AKS, and GKE. This ensures the same workload can be deployed in multiple environments with minimal change.
Networking
A service mesh or API gateway handles transport security, authentication, and traffic shaping at the platform layer. These features apply uniformly across clusters, keeping service-to-service communication consistent and secure—no matter the underlying cloud.
Infrastructure automation
Infrastructure is provisioned through tools like Terraform, with cloud-specific details—such as region names or resource IDs—isolated in variables. While the Terraform providers would need to change, maintaining a clear structure helps in systematically finding the equivalent Kubernetes, load balancer, storage and managed database services across cloud providers.
CI/CD pipelines
Workloads are built and released through a shared pipeline (often Argo CD) with cloud-specific deployment settings passed in as parameters. This allows a single process to support deployments to multiple cloud environments.
Observability
Monitoring is handled by a common stack: Prometheus collects metrics, Loki or OpenSearch stores logs, OpenTelemetry exports traces, and Grafana presents everything in one dashboard. Operators get a consistent view of the system, regardless of where it’s running.
Together these layers form the scaffolding for cloud-agnostic applications that can shift provider in minutes. They echo the guidance from VMware, Synopsys, and Teradata while keeping the focus on the architecture rather than the cloud-native vs. cloud-agnostic debate.
A practical roadmap
Start with a clear driver (compliance, DR, or bargaining power) and map the path to cloud-agnostic infrastructure. Audit every proprietary service. Replace the lowest-hanging fruit first: managed SQL can become Postgres on Kubernetes; a proprietary queue can become Kafka.
Create Terraform modules for two clouds and wire them into a single pipeline. Build shared observability next; without cross-cloud dashboards, nobody trusts the failover drill.
Run a small drill: shift five percent of live traffic to the standby cloud, capture RTO, RPO, and cost. Iterate. Scale the drill to 25 percent, then 100 percent. When drills pass and costs stabilise, update runbooks and on-call rotations. At that point the workload is truly cloud-agnostic, not just multi-cloud in slideware.
Cost curve: what to expect
Costs rise first: duplicate runtime, egress fees, licences, and talent premiums. The curve is steeper if you begin with heavyweight applications that assume deep service integration. Mitigation is also interim:
- Autoscale and scale-to-zero trim idle services
- Tagged cost dashboards expose waste early
- Hard retirement dates kill duplicate runtime fast
When overlap ends, each service scales to real demand. In many Singapore projects the final bill lands below the original monolith baseline, because over-provisioned servers disappear.
Common myths debunked
If you’re being put off from a cloud-agnostic design strategy for any of the below reasons, think again. There are many myths that don’t apply with proper diligence.
Agnostic means you must run every workload on two clouds at once
In practice, most teams keep one primary provider and maintain a validated standby. Dual-running 24/7 is optional, not compulsory.
Performance collapses without native services
Smart caching, edge routing, and right-sized instances hold latency close to single-cloud baselines even when proprietary accelerators are avoided.
Only large enterprises can afford portability
Among our customers, local fintechs and SMEs have demonstrated that lean teams can operate a portable stack with standard Kubernetes and infrastructure as code.
Regulators insist on permanent multi-cloud traffic
IMDA and MAS focus on a tested exit path. Periodic drills, diligent security practices and an updated IaC on a single cloud satisfy most audits; constant live traffic on multiple clouds is rarely required.
Kubernetes is the only way to stay portable
Kubernetes simplifies the job, but containerised applications running on managed vendor-specific container orchestration services such as AWS ECS or GCP Cloud Run plus Terraform can still shift workloads between providers, albeit with more manual effort.
Cloud agnostic and cloud native are in the same ballpark of newer approaches to solution design
They describe different dimensions. Cloud-native applications focus on advantage of elasticity and automation (containers, microservices, serverless). Cloud agnostic is about ensuring those applications can run across multiple cloud providers without lock-in. An architecture can be both at once.
Key takeaways
- Regulations make cloud-agnostic design a vital design space in Singapore (and globally)
- As with any approach, there are benefits and trade-offs. In this case complexity and engineering overhead are rewarded with resilience, higher compliance and, in some cases, increased bargaining power.
- Cloud-agnostic architecture can be approached like many other approaches to solution architecture: incremental, goal-focussed iterations are the best path to adoption.
At Just After Midnight, we’ve helped teams in Singapore and around the world deliver solutions that work for them.
If you’re looking for help with cloud-agnostic design, or any other element of your cloud solution, drop us a line and we’ll be right with you.
