Seven years on from when I first wrote about cloud security architecture on this site, the fundamentals haven’t changed — but almost everything around them has. The cloud providers have matured, the threats have evolved, and the regulatory landscape has tightened considerably. If I were starting a security architecture engagement at a financial services organisation tomorrow, here’s what I’d actually focus on.
Start with what hasn’t changed
The job is still the same: take real business requirements — regulatory, contractual, and operational — and translate them into controls that demonstrably protect customer assets. The temptation in 2026 is to start with the AWS service catalogue and work backwards, but that’s how you end up with a sprawling estate of half-configured services that nobody can attest to in an audit.
What does change is the level of integration available. In 2019, you genuinely had to plumb together your own controls. In 2026, the providers have done much of the integration work for you — the question is whether you understand it well enough to rely on it.
The non-negotiables
A modern cloud security architecture in a regulated environment needs to address these areas. Most organisations get the first three right and then stall.
Identity is still the perimeter. Centralised identity and access management — internal users, external users, machine identities — sits at the foundation of everything else. If you’re still operating with long-lived IAM users and access keys at scale in 2026, that’s the first thing to fix. AWS IAM Identity Center (formerly SSO) federated with your enterprise IdP, IAM Roles Anywhere for workloads that need to authenticate from outside AWS, and a hard line against static credentials in code or pipelines. Pair this with automated detection of any keys that do leak — leaked credential scanners are cheap and effective.
Encryption everywhere, with keys you control. All data at rest, all data in transit, no exceptions. The interesting question in 2026 isn’t whether to encrypt — it’s where the keys live and who can use them. KMS with customer-managed keys gives you key policies you can audit; CloudHSM gives you FIPS 140-3 Level 3 boundary if you genuinely need it. Most workloads don’t, and treating CloudHSM as the default adds operational cost and complexity that you’ll regret. Reserve it for the workloads that actually require single-tenant HSMs — typically PCI-DSS PIN environments or specific regulatory mandates.
Detect, respond, and aggregate at scale. GuardDuty, Security Hub, and Detective are now genuinely useful out of the box, and the aggregation story has improved dramatically. If you’re running a multi-account estate (and at any reasonable scale you should be), the delegated administrator model with cross-region aggregation is the right pattern. I’ve covered the specifics of this in a separate post, but the principle is: findings should land in one place, normalised, prioritised, and ticketed automatically. If your detection engineers are still manually triaging across consoles, you’re losing time you don’t have.
DevSecOps as actual practice, not slideware. Security tooling integrated into the pipeline — IaC scanning (Checkov, tfsec, or the equivalents baked into your CI), SAST and SCA on every PR, container scanning before promotion, and policy-as-code with OPA or AWS-native equivalents. The bar in 2026 is that nothing reaches production without these gates, and engineers see the findings inside their own tooling rather than via a separate security ticket queue.
The areas where most organisations are weakest
In my experience, these are the gaps that come up repeatedly in architecture reviews:
Third-party risk on cloud services themselves. SaaS sprawl is real. Every team has a half-dozen tools with broad OAuth scopes into Microsoft 365, Google Workspace, GitHub, or your CRM. The blast radius of a compromised SaaS integration is often larger than a compromised EC2 instance, and far harder to detect. A proper inventory of OAuth grants, conditional access policies, and a process for reviewing third-party scopes is overdue at most organisations.
Service control policies and resource control policies that actually constrain things. SCPs are powerful — and underused. Most organisations I see have permissive SCPs that block obvious bad things (root account usage, leaving the home region) but don’t meaningfully constrain workload behaviour. Layered SCPs at the OU level, combined with the newer Resource Control Policies for cross-service guardrails, give you defence in depth that doesn’t depend on every engineer doing the right thing.
Egress controls and DNS. Most cloud breaches at scale involve data leaving the environment over channels nobody was watching. VPC endpoints for AWS services, DNS Firewall blocking known-bad domains, Network Firewall for egress filtering on workloads that genuinely need it. The problem is that retrofitting egress controls to a mature estate is painful, so this needs to be in the foundational landing zone from day one.
Backup and recovery, properly tested. I include this under security architecture deliberately. Ransomware in cloud environments is a security control failure as much as an operational one, and the recovery story is what determines whether the incident is a footnote or a board-level event. Immutable backups, separate trust boundaries (often a separate AWS account with limited access paths), and tested recovery runbooks. Tested being the operative word.
The artefacts that matter
If you’re producing security architecture documentation that nobody reads, you’re not doing security architecture. The artefacts that genuinely move the needle are:
- A security blueprint or HLD that maps controls to business requirements, refreshed annually
- Reference patterns that engineering teams can self-serve from — documented, versioned, and ideally codified as Terraform modules
- Risk-accepted exceptions with owners and review dates, not buried in a spreadsheet nobody opens
- Threat models for the workloads that actually matter, kept lightweight enough to update when the system changes
Everything else is overhead.
Where to focus next
If you’re rebuilding or reviewing your cloud security architecture this year, I’d put effort into three things in this order. Get identity right end-to-end. Get detection and response aggregation working across the whole estate. Then tackle the SaaS and third-party integration risk that nobody else is looking at. The infrastructure-layer controls are increasingly commoditised; the gaps are at the edges.
More on the multi-region GuardDuty and Security Hub aggregation pattern in the next post.