Every AWS deployment we've built for clients in banking, insurance, and healthcare starts with the same conversation: "We need to move fast, but we can't compromise on security or compliance." These aren't competing goals—they're design constraints that shape how we approach AWS architecture from day one.
After deploying production workloads for dozens of regulated enterprises, we've developed patterns that balance agility with governance. This article shares the foundation patterns we use to help clients build AWS environments that their security teams, compliance officers, and auditors can trust.
The Multi-Account Foundation
The single most impactful architectural decision in AWS is account structure. Organizations that start with a single account inevitably face painful migrations later. Those that over-engineer with dozens of accounts from day one create management overhead that slows everything down.
We've settled on a pattern that works well for mid-market regulated enterprises: enough separation to satisfy compliance requirements, but not so much that it becomes unwieldy.
Recommended AWS Account Structure
Why This Structure Works
The four-OU structure (Security, Infrastructure, Workloads, plus the Management account) provides clear separation of concerns without excessive complexity:
- Security OU houses centralized logging and security tooling—accessible to security teams, isolated from developers who might accidentally modify audit trails
- Infrastructure OU contains shared networking and common services—managed by platform teams, consumed by application teams
- Workloads OU is where applications live—each significant workload in its own account, with sub-OUs for production versus non-production
The One-Workload-Per-Account Rule
We recommend one significant application or workload per AWS account. This seems excessive until you've experienced a security incident where blast radius containment saved the day, or an audit where clean account boundaries made evidence gathering straightforward.
Landing Zone Essentials
AWS Control Tower provides a managed landing zone, but regulated industries often need customizations that go beyond the defaults. Here's what we typically add:
Service Control Policies (SCPs)
SCPs are the guardrails that prevent well-meaning developers from creating compliance problems. Our baseline SCPs for regulated clients typically include:
Region Restriction
Limit deployments to approved regions only. For US-based financial services, this often means us-east-1 and us-west-2, with explicit denial of all others.
Encryption Requirements
Deny creation of unencrypted resources—S3 buckets, EBS volumes, RDS instances. Make encryption the default, not an option.
Public Access Prevention
Block public S3 buckets, public RDS instances, and unrestricted security groups at the organization level.
Root User Restrictions
Prevent root user actions except for the handful of tasks that genuinely require root credentials.
Centralized Logging Architecture
Every regulated environment needs comprehensive logging that can't be tampered with by the teams being logged. Our standard pattern:
Centralized Logging Flow
The key insight: logs flow to a dedicated account where workload teams have no write access. S3 Object Lock ensures even administrators can't delete logs during the retention period—a requirement for most financial services compliance frameworks.
Network Architecture for Regulated Workloads
Network design in AWS has evolved significantly. The hub-and-spoke model using Transit Gateway has become the standard for enterprises with multiple accounts and hybrid connectivity requirements.
The Network Hub Pattern
We centralize network management in a dedicated Network Hub account within the Infrastructure OU. This account owns:
- Transit Gateway: The central router connecting all VPCs and on-premises networks
- Shared VPC for inspection: Where network traffic flows through security appliances
- Direct Connect or VPN termination: Hybrid connectivity to data centers
- DNS resolution: Route 53 Resolver endpoints for hybrid DNS
Workload accounts connect to the Transit Gateway via attachments, but network routing decisions happen centrally. This allows security teams to enforce inspection requirements without relying on individual application teams to configure their VPCs correctly.
AWS Network Firewall Consideration
For clients requiring deep packet inspection or IDS/IPS capabilities, AWS Network Firewall in the inspection VPC provides cloud-native traffic filtering. For those with existing Palo Alto or Fortinet investments, we deploy those appliances instead—the architecture supports either approach.
Identity Foundation
IAM is where most AWS security problems originate. Our foundation pattern emphasizes:
AWS IAM Identity Center (SSO)
Every human accessing AWS should authenticate through Identity Center, federated with the organization's identity provider. No IAM users with passwords. No long-lived access keys for humans. This single change eliminates entire categories of credential compromise.
Permission Sets, Not IAM Policies
We define standardized permission sets in Identity Center that map to job functions:
- ViewOnly: Read access across services for auditors and observers
- Developer: Permissions needed for day-to-day development in non-production
- Operator: Production access for incident response and operations
- Administrator: Full access, used sparingly and with enhanced logging
Permission boundaries prevent privilege escalation—even administrators can't create more powerful roles than they themselves possess.
Service Accounts and Machine Identity
For automated processes, we use IAM roles exclusively. Applications running on EC2 use instance profiles. Lambda functions have execution roles. ECS tasks have task roles. The principle: credentials should never be stored in code, configuration files, or environment variables.
Secrets Management Pattern
AWS Secrets Manager with automatic rotation for any credential that must exist (database passwords, API keys). Applications retrieve secrets at runtime using IAM roles—they never have static credentials baked in.
Compliance as Code
Regulated industries require evidence of compliance—and that evidence needs to be current, not point-in-time snapshots from annual audits. We implement continuous compliance monitoring using:
AWS Config Rules
Config rules evaluate resource configurations against compliance requirements continuously. When a resource drifts out of compliance, we know within minutes—not during the next audit cycle.
Our baseline Config rule set for financial services typically includes 50+ rules covering encryption, access logging, network security, and IAM hygiene. These map to specific PCI DSS, SOC 2, and internal policy requirements.
Security Hub Integration
Security Hub aggregates findings from Config, GuardDuty, Inspector, and third-party tools into a single compliance dashboard. We configure it with the compliance standards relevant to each client—CIS AWS Foundations Benchmark, PCI DSS, or custom frameworks.
The result: compliance posture is visible in real-time, with automated alerting when scores drop below thresholds.
Building on the Foundation
The patterns described here represent the foundation layer—what needs to be in place before any application workloads are deployed. Getting this right takes time upfront but pays dividends throughout the AWS journey:
- New applications inherit security controls automatically
- Compliance evidence is generated continuously
- Blast radius is contained by account boundaries
- Security teams have visibility without blocking development
In subsequent articles, we'll explore how to build on this foundation—serverless architectures, AI/ML infrastructure, and advanced security patterns that leverage these baseline capabilities.
