Cloud Architecture
Cloud architecture is the set of decisions about where your systems run, how they connect, and which provider services they depend on. These decisions are usually framed as technical, and each one is also a financial commitment: every service a build depends on is a recurring line item, and every proprietary service it depends on is a line item that cannot be renegotiated, because leaving means rebuilding. These choices set the running cost and the cost of leaving years before either shows up on an invoice. The move to cloud is also an accounting event: owned infrastructure is capex that reaches the P&L below EBITDA as depreciation, while cloud services are opex that reduce EBITDA directly, so the same workload lowers reported EBITDA simply by changing where it runs, and where cloud costs are allocated to COGS the shift compresses gross margin as well. For a business valued on an EBITDA multiple, that reclassification is material before a single technical tradeoff is weighed.
How it actually works
Cloud billing is metered: compute, storage, data transfer, and per-request charges on managed services. The meter makes small architectural choices compound. A pipeline that moves data between regions pays transfer fees on every run. A job scheduled hourly when daily would do costs twenty-four times what it should, indefinitely. None of this appears as a decision anyone made; it accumulates from defaults, and the provider's defaults favor the provider.
Portability is the counterweight, and it is a property either designed in or lost. A portable build keeps business logic in standard tools, open formats, and services with equivalents elsewhere, so the provider can be replaced without rebuilding the system. A locked-in build wires proprietary services into the core, and the pricing relationship inverts: the vendor no longer has to win your business each year, because the cost of leaving exceeds any plausible overcharge.
Cost posture is set the same way, up front. Right-sizing, committed-use pricing, and storage tiering are all decisions the architecture either permits or forecloses. Retrofitting them into a system that grew by default costs more than designing them in, which is why cloud cost reviews often find line items whose business case expired years ago and whose owner has left the company.
In practice
Digital Realty and Equinix run the data centers a large share of the cloud physically runs in. Building revenue systems architecture for them followed the standard we apply everywhere: one pipeline from data sources to decisions, on infrastructure the client controls, with no component that ties the system's future to a single vendor's pricing. The storage side has its own manufactured narrative. Cloud providers perpetuate the "data gravity" myth, the idea that the more data you have, the more tools, data, and talent it attracts, because they make more money the more you store. Most of the data that lives inside these clouds can be archived without any impact to business operations once the actual insights of what happened and when are extracted. Against enterprise systems that cost millions to build, we have seen teams relying on raw data for decision making in dashboards while the analysis that drove decisions was done in spreadsheets and local statistical analysis, free tools ([how perverse incentives destroy profit](/insights/why-your-vendors-win#how-perverse-incentives-destroy-profit)).
Where we come in
Cloud architecture sits inside our Revenue Systems Architecture practice, built for businesses from new startups to the Fortune 15, including Digital Realty and Equinix. We demonstrate ROI before each build, everything is scoped up front, and the systems are portable: you are never locked to a single model, platform, or vendor. The architecture review names each line item's job, its cost, and what leaving it would require.
Start a Revenue Health Pre-Assessment →See it in action
Related terms
- Vendor lock-in
- A build that only works on one provider's platform. It converts a technology choice into a permanent cost, because leaving means rebuilding.
- Portability
- The property that a system can move providers without a rebuild. It is designed in through standard tools and open formats, and it preserves the ability to renegotiate.
- Total cost of ownership (TCO)
- The full cost of a system over its life: the platform bill, implementation, maintenance, and internal time to run it. The subscription line is usually the smallest part.
- Egress fees
- Charges for moving your own data out of a provider. They raise the cost of switching providers.
- Managed service
- A provider-run component you rent instead of operate. It trades operational effort for a metered bill and, when proprietary, for lock-in.
- Right-sizing
- Matching provisioned capacity to actual load. Systems that grow by default run oversized, and the bill does not separate oversizing into its own line.