cloud-administration

Cloud administration

Corporate cloud is bought, not architected. Someone needed a tool, expensed it, and it entered the

estate without a review, an owner, or an offboarding path. The characteristic failure is not a bad

design — it is discovering the estate years later, one invoice at a time.

This is the cloud the business runs on. For the cloud a product is built on — environments,

infrastructure as code, scaling, region failure — see technology:cloud-infrastructure. The two

follow different rules and the boundary is worth keeping sharp.

Structure the tenant before you need to

Subscription and account structure encodes what you can later separate: billing, access, policy,

and blast radius. Retrofitting it means moving live workloads, so the cheap moment is the first

one.

A workable default is to separate by what you would want to bill, govern, or lose independently —

production corporate services, non-production, and anything with a distinct compliance obligation.

Resist a subscription per team; teams reorganize, and the structure outlives them.

Tag at creation with owner, cost center, and environment, and enforce it with policy rather than

documentation. Untagged resources become unattributable spend within a quarter, and nobody

volunteers to claim them.

The SaaS estate is the part nobody is managing

Most companies underestimate their application count by a wide margin, because the ones they know

about were bought by IT and the rest were bought by everyone else. The discovery methods that

actually work are financial, not technical: expense reports, corporate card statements, and the

identity provider's sign-in logs. Network monitoring finds less than the accounting system does.

Every application needs a named business owner, a renewal date, and a data classification. Without

the owner there is nobody to ask at renewal. Without the renewal date the negotiation happens after

auto-renewal. Without the classification, nobody knows which breach notification obligations apply

when the vendor is compromised.

An application that stores customer or employee data belongs in the review that

legal-risk:privacy-and-data-protection describes, and a departing employee's access to it is

it-operations:identity-lifecycle-administration's problem — which it cannot solve for an

application it does not know exists.

Identity is the perimeter, so treat it as infrastructure

Once the estate is cloud, network location protects nothing and the identity provider is the only

consistent control point. Single sign-on is therefore not a convenience feature; it is what makes

deprovisioning possible in one place instead of forty.

The practical rule is to refuse applications that cannot federate, or to accept them knowingly with

a documented manual offboarding step. Vendors that charge extra for SSO are charging for the

security baseline, and that cost belongs in the purchase decision rather than being discovered

later.

Conditional access, MFA, and privileged role activation are the controls worth the effort. See

security:access-and-identity for the design; this skill owns operating it across a real estate.

Cloud spend surprises are structural

Cloud bills grow because nothing in the system stops them. Resources are easy to create, nobody is

billed personally, and consumption is invisible until the invoice.

Three habits catch most of it: a budget alert on every subscription before workloads land, a

monthly review of the largest movers rather than the whole bill, and a scheduled look at anything

running that nobody has logged into. Reserved and committed pricing is real money for steady

workloads, but it is a bet on a run rate — commit only where the load is genuinely predictable.

Non-production environments running overnight and at weekends are the most common single line of

waste, and shutting them on a schedule is a change nobody notices.

Shared responsibility is narrower than people assume

The provider keeps the platform available. Almost everything else — configuration, access, and in

most cases the data itself — stays yours.

The one that catches organizations out is backup. A major SaaS suite protects itself against its

own failures, not against a user deleting a mailbox or a ransomware event propagating through

sync. Retention settings are not backups, and the recycle bin is not a recovery point. Decide

deliberately what needs independent protection under it-operations:backup-and-recovery rather

than assuming the vendor's durability promise covers your mistakes.

Tooling

Platforms: AWS, Microsoft Azure, Google Cloud, and similar.

Infrastructure as code: Terraform, OpenTofu, Pulumi, Bicep, CloudFormation, and similar.

Cost visibility: the native cost tools, or CloudZero, Vantage, Finout, and similar.

Guardrails: AWS Control Tower, Azure Policy, Wiz, and similar.

Console changes nobody can reproduce in code become the outage you cannot rebuild from.

Never

• Buy an application that cannot federate without recording the manual offboarding step.
• Let a resource exist without an owner tag and a cost center.
• Treat vendor retention settings as a backup.
• Structure subscriptions around the current org chart.