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.
Sources
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
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.
