c3.1 Design a secure architecture
Designing a secure architecture means making security a deliberate part of the design — applying the AWS Well-Architected security design principles and using the AWS Security Reference Architecture as your reference blueprint — so the design itself reduces attack surface and limits the blast radius of any breach.
Implementation guidance
Security is a design decision, not an afterthought
Architecture is itself a security control: a good design shrinks the attack surface and the blast radius of a compromise. "Designing a secure architecture" means two concrete things — following a set of design principles, and building on a reference architecture — rather than bolting controls on later.
Apply the Well-Architected security design principles
Base your design on the seven design principles of the AWS Well-Architected Framework Security pillar:
- Strong identity foundation — least privilege, separation of duties, centralized identity, no long-term static credentials.
- Maintain traceability — monitor, alert, and audit actions and changes in real time.
- Apply security at all layers — defense in depth across edge, VPC, load balancer, instance, OS, application, and code.
- Automate security best practices — controls defined and managed as code in version-controlled templates.
- Protect data in transit and at rest — classify data and apply encryption, tokenization, and access control.
- Keep people away from data — reduce direct/manual access to data to limit human error.
- Prepare for security events — incident management processes, simulations, and automation for detection and recovery.
In practice this shows up as: no exposed SSH/RDP (use Session/Fleet Manager), least-privilege network paths and security groups that reference each other rather than open CIDRs, and multiple Availability Zones for resilience.
Build on a reference architecture
Use the AWS Security Reference Architecture (SRA) as the prescriptive blueprint for how AWS security services fit together across a multi-account organization. Designing against a reference architecture gives you a known-good target to measure your design against, instead of reinventing it per project.
Know what you actually run
A design is only secure if it matches reality. Workload Discovery on AWS generates architecture diagrams from your live infrastructure, helping you review designs, find shadow resources, and export to formats like draw.io.
How to validate
- Are new architectures reviewed against the AWS Well-Architected Security pillar design principles before build (for example via a Well-Architected review)?
- Does your design follow the AWS Security Reference Architecture (SRA) for multi-account service placement?
- Does the design enforce least-privilege network paths, no exposed management ports, and multi-AZ resilience?
- Are security controls defined as code in version-controlled templates rather than configured by hand?
- Do you maintain an accurate, current view of what is actually deployed (including shadow resources)?
Threats addressed
- A design with broad network reachability and exposed management ports gives an adversary easy initial access and room to move laterally, turning a single foothold into a wide compromise.
- Security bolted on after the design is set tends to leave gaps that are expensive to fix later, whereas a design grounded in principles and a reference architecture prevents them up front.