DEV Community

Abd Alrhman Alloush
Abd Alrhman Alloush

Posted on

What Happens When Your Team Adds Azure to AWS and GCP

#azure #aws #cloud #database

It usually starts with one reason.

A new enterprise client requires Azure. Or the company gets acquired by a Microsoft shop. Or the data team wants Azure OpenAI Service. Or legal requires a specific Azure region for data residency. Whatever the trigger — it's never "let's add Azure because we wanted three clouds."

But the result is always the same: you now have a third cloud, and the operational complexity doesn't just add — it multiplies.

I've seen this happen at multiple companies over years of hands-on database engineering. Teams that had a reasonably clean AWS + GCP setup suddenly find themselves managing three credential models, three consoles, three billing dashboards, and databases spread across providers that have no awareness of each other.

Here's what actually happens, and what you can do about it.

The Azure Credential Model Is Different

AWS uses IAM roles and access keys. GCP uses service accounts with JSON key files. Azure uses something called service principals — identities registered in Azure Active Directory (now called Microsoft Entra ID) with roles assigned at the subscription or resource group level.

If your team already has muscle memory for aws configure and GCP service account JSON files, Azure will feel unfamiliar at first.

A minimal setup for database management looks like this:

# Create a service principal with Reader role on a resource group
az ad sp create-for-rbac \
  --name "1datacloud-reader" \
  --role Reader \
  --scopes /subscriptions/<subscription-id>/resourceGroups/<rg-name>
Enter fullscreen mode Exit fullscreen mode

This gives you a clientId, clientSecret, tenantId, and subscriptionId — four values you'll need to authenticate against Azure APIs.

Compared to a GCP service account (one JSON file) or AWS IAM (access key + secret), it's more moving parts. And it's completely separate from the mental model your team already uses for the other two clouds.

The Azure Database Landscape

Before you can manage Azure databases, you need to know what Azure calls them.

Azure SQL Database — Microsoft's managed relational service. Similar to AWS RDS for SQL Server, but Azure-native. Good performance, tight Active Directory integration, T-SQL.

Azure Database for PostgreSQL — Flexible Server — Managed PostgreSQL. This is the one that matters most if your team is already on PostgreSQL on RDS or Cloud SQL. Flexible Server is the current generation (the old Single Server was deprecated in 2025).

Azure Database for MySQL — Flexible Server — Same generation shift. If you're migrating from RDS MySQL, this is the target.

Azure Cosmos DB — A globally distributed, multi-model NoSQL database. Supports multiple APIs: SQL (document), MongoDB, Cassandra, Gremlin, Table. If your team uses DynamoDB on AWS, Cosmos DB is the Azure equivalent in terms of positioning.

Azure SQL Managed Instance — A deployment option that gives you a full SQL Server engine (including SQL Server Agent, cross-database queries, linked servers) rather than the PaaS-scoped Azure SQL Database. Useful for migrations from on-prem SQL Server.

Azure Synapse Analytics — Azure's answer to BigQuery and Redshift. Distributed SQL at scale, integrated with Azure Data Lake.

That's six different service types, each with its own API surface, pricing model, and management interface — before you've written a single query.

What Breaks First

1. Nobody knows what's running

With AWS and GCP, at least your team knows which console to open. With Azure added, there are now resources in Resource Manager that the DevOps team created, resources in the old Classic deployment model that nobody touches, and resources across multiple subscriptions that were set up at different times for different reasons.

Azure has resource groups as an organizing layer, but if your team didn't enforce naming conventions and resource group discipline from day one, you'll spend a lot of time clicking around the portal to understand what exists.

2. Schema awareness disappears

When a new database gets spun up on Azure — say, a PostgreSQL Flexible Server for a new product — it often happens outside the normal provisioning process. Someone clicks through the portal. It doesn't get added to the inventory spreadsheet. The team doesn't know its schema until someone asks "where does this data live?"

This is the same problem that exists on AWS and GCP, but Azure makes it worse because it's the new unknown. Your AWS and GCP databases are at least in the mental model of the team. The Azure ones aren't yet.

3. Credential rotation gets complicated

Now you have three sets of credentials to rotate on a schedule:

  • AWS: IAM access keys (or instance profiles if you're doing this right)
  • GCP: service account JSON keys
  • Azure: service principal secrets (which have an expiry date and will stop working when they expire)

Azure service principal secrets expire — the default is 1 year. If you don't have rotation automation in place, you'll get a failed deployment or a broken integration six months from now, traced back to an expired credential nobody remembered to rotate.

4. Monitoring is fragmented

Azure Monitor is its own ecosystem, completely separate from CloudWatch and Cloud Monitoring (GCP). Each provider has its own metrics, its own alerting primitives, its own cost of learning. Teams that didn't have unified observability before will feel this most acutely.

The Multi-Cloud Inventory Problem, Revisited

If you were managing AWS and GCP and already felt like you lacked a complete picture of your databases, adding Azure makes that problem structurally harder.

Previous post in this series: Why Your Team Needs a Multi-Cloud Database Inventory covers the inventory problem in depth. The short version: every provider has native tooling that shows you that provider's resources only. No cross-cloud view exists unless you build it or use a tool designed for this.

With three providers, the options are:

  • Three console tabs always open
  • A custom aggregation script that you maintain (and that breaks when any provider updates its API)
  • A unified tool that connects to all three and maintains the view automatically

What Good Multi-Cloud Database Management Looks Like

The goal isn't to eliminate Azure's complexity — that complexity reflects real engineering tradeoffs. The goal is to not re-solve the same "where are my databases?" problem every time you add a provider.

A good multi-cloud database management setup:

  1. Connects to each provider once using that provider's native credential model (IAM for AWS, service account for GCP, service principal for Azure)
  2. Auto-discovers all instances across accounts, subscriptions, and projects — without you clicking through consoles
  3. Maintains schema metadata so you know not just that an instance exists, but what tables and columns are inside it
  4. Requires no agents or infrastructure changes — purely API-based, read-only by default

This is what 1DataCloud does. AWS, GCP, and MongoDB Atlas are fully supported today. Azure support is in active development — SQL Database, Cosmos DB, and PostgreSQL Flexible Server are coming. If you want to be notified when Azure goes live, sign up for the free tier and you'll get early access.

Practical Steps for Your Next 30 Days

If your team just added Azure (or is about to), here's a pragmatic checklist to avoid the worst outcomes:

Week 1 — Inventory what exists:

  • List all Azure subscriptions your organization has
  • List all resource groups with "sql", "db", "postgres", "mysql", "cosmos" in the name
  • For each: note engine type, region, size, who owns it

Week 2 — Tighten credential hygiene:

  • Create service principals with Reader role (not Contributor) for monitoring/inventory access
  • Set explicit expiry reminders for all Azure service principal secrets
  • Document where the credentials are stored (Key Vault, secrets manager, etc.)

Week 3 — Connect schema metadata:

  • For each database with real production data: connect and document the top-level schema (database names, table count)
  • Flag any instances that are publicly accessible (Azure portal → Networking → Public access)

Week 4 — Unify the view:

  • Either add Azure to your existing inventory tool, or start using a tool that handles all three providers together
  • Set a calendar reminder to verify the inventory is still accurate in 90 days

The Bigger Picture

Adding Azure isn't a mistake — for many teams it's the right call. Enterprise integrations, Microsoft ecosystem dependencies, data residency requirements, specific services like Azure OpenAI — these are real reasons.

But adding a cloud provider without a plan for managing what you deploy there is how you end up with databases nobody tracks, credentials that expire in production, and schema documentation that's six months out of date.

The teams that handle multi-cloud well aren't the ones that avoided complexity. They're the ones that decided early on how they were going to keep a complete picture of what they have.

Is your team running Azure alongside AWS or GCP? What's been the hardest part to manage? I'm particularly curious about organizations that migrated workloads TO Azure from another cloud — the other direction is less common.

Abd Alrhman Alloush is the Founder & CEO of 1DataCloud — a unified dashboard for managing and querying databases across AWS, GCP, and MongoDB Atlas, with Azure support in active development.

Top comments (0)