Untangling Multi-Cloud Billing for a Self-Service MongoDB Atlas Portal

The Problem.

The client operates an internal self-service portal that lets teams across the organization provision their own infrastructure on demand. The portal is built on a custom workflow engine, with a separate flow for each provisionable product. One of those flows handles MongoDB Atlas, and that flow had a structural billing problem.

When the MongoDB Atlas integration was first built, it was set up against a single MongoDB-paying organization — the one originally created when the client deployed Atlas on Azure. That setup was fine when Azure was the only PaaS in scope. But over time, teams across the organization began provisioning Atlas clusters on AWS and GCP through the same portal, and every one of those clusters still rolled up to the original Azure-anchored paying org.

The clusters and projects were properly segregated at the technical level — the architecture was clean. But because billing flowed through a single paying organization, finance couldn't separate MongoDB Atlas spend by underlying cloud provider. Every dollar of Atlas usage looked, on the invoice, like it came from one place. Cost attribution back to AWS, GCP, and Azure as distinct PaaS lines was effectively impossible without manual reconciliation, and the manual approach didn't scale to the portal's provisioning volume.

Underneath the billing problem sat an engineering problem. The provisioning workflow had grown an if-else ladder that hardcoded which paying org and which environment to target for each PaaS. Every change — a new environment, a new cloud provider, a new sandbox tier — meant editing code paths and shipping a new portal release. The architecture didn't have a clean place for the team to express "this PaaS uses this paying org for this environment" without touching code.