SaaS on IaaS: How Software as a Service Uses Cloud Infrastructure

Running SaaS on Infrastructure as a Service (IaaS) does not eliminate infrastructure engineering; it changes the boundary. The SaaS operator still owns tenant isolation, deployment safety, capacity, observability, data recovery, and application security while the cloud provider owns defined layers beneath them. A reliable architecture makes that boundary explicit and tests failure on both sides.

Separate tenant identity from deployment shape

Multi-tenancy is a spectrum. Tenants may share application processes and tables with a tenant key, share a database with separate schemas, use separate databases, or receive dedicated deployments. Greater isolation can simplify noisy-neighbour and regulatory boundaries but increases provisioning, upgrade, and cost complexity. Choose per workload and customer requirement rather than enforcing one pattern everywhere.

Carry a validated tenant identity from authentication through every query, cache key, object-store path, queue message, job, log, and support operation. Database row filters are insufficient if a shared cache or export job omits the tenant. Kubernetes' official multi-tenancy guidance distinguishes namespace-based soft isolation from stronger virtual-control-plane or cluster boundaries; namespace separation alone is not a universal security boundary.

Separate control plane from data plane

The control plane provisions tenants, configuration, entitlements, keys, migrations, and deployment state. The data plane serves customer requests and background workloads. Give each operation an idempotency key and durable state transition so a retry cannot create a second tenant or apply an entitlement twice. A partially failed provisioning workflow must be resumable and visible to operators.

Keep infrastructure state declarative where practical, but do not confuse a successful infrastructure apply with a ready application. Readiness requires migrations, secrets, routes, policy, data dependencies, and a functional tenant probe. The AWS SaaS Lens is a useful provider-authored catalogue of questions around tenant context, onboarding, operations, and cost, even when the application runs on another IaaS platform.

Deploy changes with bounded blast radius

Use immutable artefacts, progressive rollout, health gates, and an explicit rollback or roll-forward path. Database changes should use expand-and-contract sequencing: add backward-compatible structures, deploy code that can use both forms, migrate data with checkpoints, switch reads, and remove the old form in a later release. Never require every tenant's large migration to finish inside one deployment timeout.

Segment rollout by a small internal population, region, or tenant cohort, then compare errors, latency, and business invariants against a control. Keep emergency access narrow, time-bound, and audited. A feature flag is operational state and needs ownership, expiry, and safe behaviour when the flag service is unavailable.

Operate from service objectives and capacity limits

Define service-level indicators from the customer's path: successful authenticated requests, accepted jobs completed before deadline, data freshness, and restore success. Infrastructure CPU is a diagnostic, not the service objective. Instrument tenant and workload dimensions without placing sensitive identifiers into high-cardinality labels. The OpenTelemetry signal model provides a portable basis for traces, metrics, and logs.

Establish per-tenant and global admission limits, bounded queues, fair scheduling, and a degradation policy. Test at sustained peak plus recovery, not only with short bursts. Map unit cost per meaningful operation—such as an indexed document or completed workflow—so one tenant, query shape, or background job cannot silently erase service margin.

Rehearse cloud and application failure

Backups matter only when restoration is timed and verified. Exercise loss of a zone, database failover, expired credentials, unavailable identity provider, queue backlog, corrupt deployment, erroneous tenant configuration, and region-level dependency loss. The Google SRE dependency-failure and recovery guidance emphasises scenario-specific recovery rather than a single undifferentiated availability claim.

Record which IaaS services are essential and what portable data or recovery tooling exists outside each one. Active-active deployment is not automatically safer: it can duplicate writes and spread corruption. Choose redundancy from measured recovery objectives and consistency requirements, then prove the design through drills.