Cloud Security Architecture and Trust Boundaries

Why architecture boundaries matter

Cloud environments combine tenants, accounts, subscriptions, or projects with regions, availability zones, virtual networks, managed services, workload identities, and external connections. Names differ by provider, but the review question is stable: which team controls a component, which identity can change it, which network can reach it, and what fails when a dependency is unavailable? A separate account or subscription can improve isolation, but only when permissions, shared networks, logging, and administrative paths are controlled with it.

Architecture inventory

Area	Record during review
Organization and tenant	Account, subscription, or project owner; production classification; inherited policy; billing or emergency contacts.
Workload and data plane	Public and private services, data stores, queues, workload identities, data classification, and dependencies.
Management and control plane	Administrative roles, automation, infrastructure-as-code, break-glass access, configuration history, and audit destination.
Connectivity	Virtual networks, routing hubs, private endpoints, DNS, hybrid links, third parties, and expected traffic paths.

Trust-boundary checklist

Mark each point where an identity, network, service, or external provider is trusted to make or relay a decision.
Separate production from non-production by ownership, credentials, network reachability, and data handling rather than by label alone.
Identify shared services such as identity, DNS, logging, image registries, key management, and transit routing; each can become a common failure domain.
Map public endpoints, private service paths, partner integrations, hybrid connectivity, and administrative access paths.
Record where evidence is produced and whether it remains available during an outage or account compromise.

Architecture-review workflow

Start with a current inventory and data-flow diagram. Include people, automation, services, data stores, and external dependencies.
Assign owners for account policy, identity, networking, logging, recovery, and each workload. Escalation paths should be usable outside normal business hours where required.
Test the design against failure domains: an unavailable region, expired certificate, disabled log route, identity-provider outage, routing error, or unavailable shared service.
Check whether a broad administrator, shared network, or cross-account trust defeats the intended isolation boundary.
Retain approved diagrams, policy references, representative audit events, recovery assumptions, and open questions with the change record.

Fictional hybrid example

A company hosts a customer API in a production account, sends audit logs to a central security account, and connects private workloads to an on-premises network through a routing hub. A review finds that a shared automation role can alter both production routing and the log destination. The team separates the role, adds alerting for route and log changes, documents the hub dependency, and verifies recovery contacts. The accounts remain useful isolation boundaries, but the decision rests on the combined identity, network, and monitoring controls.

Common mistakes

Common mistakes include treating a private address as an access-control decision, sharing administrator roles across environments, omitting SaaS and third-party paths from diagrams, or assuming centralized logging survives every failure. Another is treating regional separation as a complete availability plan without reviewing identity, DNS, data replication, deployment, and recovery dependencies.

Evidence to retain

Keep a dated architecture diagram, account and environment inventory, ownership matrix, data-flow notes, relevant organization policies, and approved exceptions. For important changes, retain a small set of representative configuration and audit references rather than a claim that the entire environment was reviewed. Note assumptions about provider services, third parties, hybrid links, and recovery dependencies. This gives later reviewers a starting point when architecture, ownership, or business context changes.