Secure Cloud Architecture

A payments team is ready to create its first production environment. It needs compute, a database, object storage for settlement files, access to a payment processor, and a deployment identity. If the platform offers only an empty cloud account and documentation, the team must invent the security model while trying to ship. Public routes, broad roles, local access keys, and incomplete logs become the path of least resistance.

A landing zone changes the starting point. The team receives a production boundary with private networks, central identity, protected audit logs, approved deployment paths, and policies that reject the most dangerous configurations. Exceptions remain possible, but they are visible decisions with owners and evidence. Secure cloud architecture is this inherited control surface: it limits blast radius, grants temporary authority, keeps workloads private by default, and preserves an account of changes even when a workload account is compromised.

Give the organization a security shape

Accounts, projects, subscriptions, or their equivalent are useful security boundaries because they can carry separate administrators, policies, quotas, networks, and logs. Begin with an organization hierarchy that applies non-negotiable controls above application teams. Beneath it, separate production from staging and development. Put security operations and central logging outside workload accounts. Give shared networking, artifact repositories, identity brokers, and hardened images a shared-services boundary with named owners.

The boundaries should follow consequences, not an organizational chart. A development compromise must not yield a production deployment credential. Compromise of the payments workload must not permit deletion of the audit copy needed to investigate it. A shared networking account may connect many environments, but its routes and operators then carry exceptional blast radius. Sensitive data may warrant its own account and keys when that creates a meaningful identity, network, or recovery boundary.

Separation has an operating cost. Every boundary adds provisioning, policy, quota, billing, incident, and recovery work. Split where the boundary can be enforced and operated; do not create decorative accounts that all share the same administrator role and unrestricted network. Conversely, combining production and development to avoid that work usually creates shared roles, shared secrets, accidental peering, and ambiguity during an incident.

For each boundary, record its purpose, owner, data classes, parent policy, allowed connections, privileged access path, log destination, recovery owner, and decommissioning condition. That record is the first version of the cloud architecture, not an appendix produced for audit.

Make authority temporary and attributable

Nearly every cloud control ultimately depends on identity: who may alter a route, assume a role, read an object, export a key, disable a log, or deploy a workload. Treat identity policy as production code.

Humans should enter through a central identity provider using named accounts and strong multifactor authentication. Ordinary access is separate from privileged elevation. An engineer who needs to inspect the payments account assumes a narrow, expiring role; an emergency administrator uses a distinct break-glass path whose activation alerts responders and creates session evidence. Shared administrator credentials erase both accountability and a clean revocation path.

Workloads need their own identities. Bind the settlement worker to a runtime role that can read its input location, write its result, and call the necessary key operation. The deployment pipeline receives different authority to update the worker. Neither role needs the other’s power, and neither should inherit a human operator’s permissions. Prefer short-lived workload credentials issued from a verified workload context over access keys copied into environment variables or CI settings.

Policy review must follow the path to power rather than search only for a role named admin. Wildcard actions, permission to create or attach policies, ability to pass a stronger role to compute, external federation, resource policies, and key grants can all produce equivalent authority. Review the subject, permitted actions, resources, conditions, trust policy, session duration, and every route by which the role can be assumed.

Organization-level denial policies or equivalent guardrails should reserve actions that no ordinary workload account needs: leaving the organization, disabling required audit collection, making protected storage public, or using unapproved regions, for example. A denial is strongest when it is narrow enough to remain enabled. A sweeping policy that teams routinely bypass does less work than a small set of durable invariants.

Long-lived keys are exceptions. When one cannot yet be replaced, give it an owner, purpose, storage location, last-used signal, rotation deadline, and tested revocation procedure. A quarterly spreadsheet review is not a control if nobody can tell which process will fail when the key is revoked.

Route deliberately

The payments API needs public ingress; its database, settlement worker, and administrative interfaces do not. Build the network from that statement. Public traffic terminates at an approved edge that applies transport, request-size, and abuse controls before forwarding to private workloads. Administrative access uses an authenticated privileged path rather than an exposed management host. Data stores and cloud control services use private endpoints where this materially removes public paths.

Egress deserves the same design attention as ingress. The settlement worker may need the payment processor, central logging, identity, time, name resolution, and update services; it does not therefore need arbitrary Internet access. Route sensitive workloads through restricted or inspected paths, and make allowed destinations an owned contract. Plan how certificate rotation, provider address changes, and emergency updates occur so that responders do not dismantle egress policy during the first outage.

Peering, transit networks, shared virtual networks, and private links can join trust boundaries without an obvious public endpoint. Each connection needs an owner, source and destination, allowed routes and ports, data classification, flow evidence, and removal condition. Check return paths and transitive reach: a narrow-looking link can become a route from development through shared services into production.

Network controls reduce reachable paths; they do not authorize an application operation. The service must still authenticate the caller and enforce the tenant and object boundary established in the previous chapter.

Protect each form of stored state

Object stores, snapshots, disks, managed databases, data warehouses, and backups expose different controls, but the baseline can impose the same questions: who may read, who may write, which network path is allowed, which key protects the data, what is logged, how long the data remains, and who can restore or destroy it?

Block public storage at the organization or account level, then allow it only for an intentionally public asset path. Encrypt stored data by default. Use separate customer-managed or tenant keys when the threat model, deletion model, or contractual boundary requires them—not merely to add a key-shaped resource. Key policy, grants, rotation, recovery, and audit access determine whether the separation is real.

Enable object- or query-level evidence for sensitive stores where it is needed to answer who accessed what. Classify lifecycle and retention rules alongside the data rather than applying one retention period to everything. Scan for sensitive data in unexpected buckets, shares, snapshots, exports, and analytics copies; the primary database is rarely the only copy that matters.

Backups must survive the administrator or failure that damages production. Use immutability or a logically isolated backup boundary for critical data, and separate restore authority from routine application write authority. Test a restore with the intended key, identity, network, and integrity checks. A successful backup job proves that bytes were copied, not that the service can recover safely.

Inherit a compute baseline

The platform should make a secure workload easier to declare than to assemble. Virtual machines begin with owned, hardened images and a patch deadline based on exposure and criticality. Instance metadata protections are enabled where the platform offers them. Runtime roles are narrow, secrets come from an approved identity-backed path, and security-relevant process, identity, network, and control-plane events reach central monitoring.

Apply the same contract to functions, containers, batch jobs, notebooks, and managed services, adapting the mechanism to the service. A managed database removes operating-system patch work from the application team; it does not remove choices about identities, public access, keys, audit events, backups, or incident ownership.

Container platforms consume rather than replace the cloud baseline. Clusters need approved registries and image provenance, workload identity, external secret paths, central logs, and network boundaries. Admission policy should reject privileged settings, host access, mutable production image references, and missing ownership metadata. Cluster and namespace boundaries must agree with environment, tenant, and risk boundaries in the surrounding accounts. The next chapter develops that workload contract in detail.

Preserve evidence outside the failure

Central collection must exist before the incident. Send organization and account control-plane audit events, identity activity, sensitive data-plane access, network flow evidence, build and deployment events, and security-policy decisions to a protected logging boundary. Restrict deletion and configuration changes there more tightly than ordinary log search. Monitor gaps as events: silence after someone disables a source is not healthy inactivity.

A useful baseline names events rather than saying “logging enabled”:

control plane: identity, policy, network, storage, compute, key, and log changes
identity: login, federation, token issuance, role assumption, elevation, denial
data plane: reads, writes, exports, and key use for classified stores
network: accepted and rejected flows at consequential boundaries
delivery: source revision, artifact identity, pipeline actor, deployment target
guardrails: finding, policy decision, exception, remediation, suppression

for every source:
  owner; destination; retention; expected volume; search test; gap alert

The payments team should be able to start with a deployment identifier and trace the pipeline identity, role assumption, policy decision, changed resources, workload identity, network flows, and sensitive storage access. Test that path before an incident. Logs that exist but cannot be joined, searched, or accessed by the responder on call are only latent evidence.

Turn dangerous defaults into policy

Guardrails operate at different moments. Preventive policy blocks a public settlement bucket, a broad administrator grant, disabled audit collection, or an unencrypted sensitive store. Detective policy alerts when a new external trust, public route, key export, unapproved region, or exceptional role appears. Corrective automation may remove a public policy, quarantine a workload, add required ownership tags, or open an incident with the resource owner.

Automation needs a safety boundary. It must preserve evidence, avoid deleting the affected resource, recognize dependencies, and have an owner who can stop or reverse it. For a newly public bucket, removing the public policy is often a safe first action; deleting the bucket to make the alert disappear is not. Test policy on representative infrastructure definitions and in a disposable account before applying it across the organization.

Exceptions are part of the architecture. The public API edge is an intended exception to private ingress; a legacy integration key may be a temporary exception to workload identity. Record the requested capability, affected resources and data, threat created, compensating controls, approver, owner, expiry, and proof of removal. An exception without an expiry quietly becomes the new baseline.

Respond to cloud misconfiguration

Suppose monitoring reports that the settlement bucket became public after a policy change. The response should be executable without first deciding who owns the cloud:

1. Confirm the resource, account, policy path, time, data classification, and whether public access is effective rather than merely requested.
2. Preserve the control-plane event, policy versions, access events, object inventory, deployment record, and relevant identity sessions in the protected evidence boundary.
3. Remove or narrow the public path if that can be done safely. Quarantine access rather than deleting the resource or logs.
4. Determine which actor or workload changed the policy, how it obtained authority, which objects were reachable, and whether access evidence shows reads or listing.
5. Search for the same policy, role, pipeline, template, and public path in other accounts. One finding may reveal a fleet-wide control failure.
6. Correct the enabling condition: the role, organization guardrail, infrastructure template, exception process, or detection gap. Add a regression check at that layer.
7. Restore intended service, continue monitoring, and pass evidence to the approved incident process for customer, contractual, legal, or regulatory decisions.

Pre-authorize who may quarantine resources, suspend identities, alter organization policy, approve emergency changes, and access central evidence. An incident is a poor time to discover that the responder can see the alert but cannot contain its source.

Review the inherited control surface

Before an application team accepts a landing zone, platform and security owners should be able to answer these questions with resources, policies, test results, and logs—not intentions:

• Which boundaries separate production, non-production, security, logging, shared services, and sensitive data? Which connections cross them?
• How do humans elevate privilege, how do workloads receive identity, and which paths can create equivalent administrator power?
• Which workloads are publicly reachable, where does traffic terminate, and what constrains outbound and administrative paths?
• Which controls prevent public storage, protect keys and backups, record sensitive access, and prove a restore?
• Which image, patch, metadata, secret, runtime-role, and telemetry defaults every compute service inherits?
• Can responders trace identity, control-plane, data, network, and deployment activity from the central evidence boundary if a workload account is lost?
• Which policies prevent common failures, which detect drift, which remediate it, and how are unsafe automatic actions constrained?
• For every exception, who owns the residual risk, what evidence compensates for it, and when does it expire?
• Can the team run the misconfiguration playbook with its current authority, contacts, and search tools?

The landing zone is ready when the payments team can deploy without inventing these controls, a dangerous configuration fails before release, and responders can reconstruct and contain a change without trusting the account that may have been compromised. That is the promise application teams inherit; every workload platform built on top of it must preserve the same boundaries.