Design Secure Architectures for SAA-C03

This guide covers Domain 1: Design Secure Architectures of the AWS Certified Solutions Architect – Associate (SAA-C03) exam. Security is not a feature you bolt onto a finished design—it is a foundational principle that shapes every component of a well‑architected AWS solution. As a solutions architect, you are expected to integrate security into identity management, data protection, network boundaries, and operational monitoring from the very beginning, and to apply the shared responsibility model accurately.

By the end of this guide, you will understand how to select and combine AWS security services, apply least‑privilege principles, protect data in transit and at rest, design secure network topologies, and build auditing and monitoring into your architectures. The focus is on architectural decision‑making and real‑world trade‑offs, preparing you not only for the certification but for the security challenges you will face in production.

Learning Objectives

After completing this domain, you should be able to:

• Design secure workloads by applying the AWS shared responsibility model.
• Implement identity and access management using IAM policies, roles, and federation.
• Protect data at rest and in transit using encryption and key management services.
• Secure network architectures with VPC controls, firewalls, and private connectivity.
• Apply least‑privilege principles and enforce separation of duties.
• Select appropriate security services for threat detection, compliance, and incident response.
• Evaluate architectural trade‑offs between security, complexity, cost, and performance.

These objectives are about practical design competence, not memorisation of service limits.

Core Security Design Principles

Every secure architecture on AWS rests on a set of foundational principles. Understanding these principles helps you make consistent design decisions even when the requirements change.

• Least privilege – Grant only the permissions necessary to perform a task, and review them regularly. Start with no access and add specific permissions as needed.
• Defense in depth – Apply multiple overlapping layers of security. If one control fails, others still protect the workload. This includes identity controls, network filtering, encryption, and monitoring.
• Zero trust – Assume that no network is inherently safe. Authenticate and authorise every request, regardless of its origin. In AWS this translates to fine‑grained IAM policies, service control policies, and network micro‑segmentation.
• Shared responsibility model – AWS secures the cloud infrastructure; you secure what you put in the cloud. Understanding which controls are yours to implement is critical for designing compliant architectures.
• Secure‑by‑default design – Configure resources with the most restrictive settings possible and then open access only as required. Examples include block public access on S3 buckets and default‑deny security group rules.
• Separation of duties – Prevent any single entity from having excessive control. Use multiple AWS accounts, IAM roles with distinct scopes, and approval workflows to reduce risk.

Each of these principles translates into specific AWS service configurations, which we will explore in the following sections.

Identity and Access Management

Identity and access management is the cornerstone of AWS security. The following services and patterns help you control who can do what in your environment.

AWS IAM

IAM allows you to create users, groups, and roles and attach policies that define their permissions. Key design decisions include:

• Using IAM roles instead of long‑term access keys for applications and services. Roles provide temporary credentials and avoid the risk of leaked keys.
• Defining customer‑managed policies that follow least privilege, rather than relying on overly broad AWS managed policies. Start with ReadOnlyAccess or PowerUserAccess only when appropriate, and then refine.
• Applying permission boundaries to limit the maximum permissions a role or user can ever have, even if additional policies are attached later. This is essential in delegated administration scenarios.
• Configuring cross‑account access using roles with trust policies that allow users or services in one account to access resources in another, without sharing credentials.

AWS Organizations and Service Control Policies

For multi‑account environments, AWS Organizations enables central governance. Service control policies (SCPs) act as guardrails that restrict what actions can be taken across accounts. Use SCPs to enforce security invariants—for example, preventing users from disabling CloudTrail or leaving encryption disabled.

Federation and Temporary Credentials

Instead of creating IAM users for every human, federate identities from an existing identity provider (such as Microsoft Active Directory or a SAML/OIDC provider) using AWS IAM Identity Center. Temporary credentials reduce the attack surface and centralise access management.

Common Architecture Decisions

• EC2 instance access to S3: Use an IAM role attached to the instance, not hard‑coded credentials.
• Cross‑service authorization: A Lambda function writing to DynamoDB uses an execution role with a tightly scoped policy.
• Multi‑account data sharing: Use cross‑account IAM roles with trust policies that allow only specific principals from the trusted account.

The table below summarises the primary IAM‑related services and their architectural roles.

AWS Service	Primary Purpose	Common Architecture Use Case
IAM	Manage users, groups, roles, and policies	Core authorization for all AWS services; defines who can access what
AWS Organizations	Centralised management of multiple accounts	Enforce SCPs, consolidate billing, isolate workloads per environment
IAM Identity Center	Workforce identity federation	Replace IAM users with federated SSO access
AWS Directory Service	Managed Microsoft AD or LDAP‑compatible directory	Hybrid identity and legacy application authentication

Data Protection

Protecting data is a critical architectural responsibility. It involves encryption, key management, and the secure handling of secrets.

Encryption at Rest and in Transit

• Encryption at rest: Use AWS KMS to create and manage encryption keys. Most AWS services support server‑side encryption (SSE) with KMS keys, including S3, EBS, RDS, DynamoDB, and SQS. Decide between AWS managed keys, customer managed keys, and your own key material based on compliance needs.
• Encryption in transit: Enforce TLS for all communications. Use AWS Certificate Manager (ACM) to provision and renew certificates for Application Load Balancers, CloudFront distributions, and API Gateway endpoints.

Key Management

AWS KMS is the central service for managing cryptographic keys. Important architectural considerations:

• Use customer managed keys when you need fine‑grained key policies, rotation control, or compliance auditing.
• Apply key policies that follow least privilege: allow only specific IAM principals to encrypt or decrypt.
• Use KMS grants to provide temporary permissions to specific AWS services without modifying key policies.

Secrets Management

AWS Secrets Manager and Systems Manager Parameter Store allow you to store database credentials, API keys, and other secrets securely. Secrets Manager offers automatic rotation for RDS and other services, which simplifies operational security. The architecture principle is simple: never store secrets in code or environment variables.

Network Security

A secure network design limits the blast radius of an attack and ensures that only intended traffic reaches your resources.

VPC Security Controls

• Security Groups act as stateful virtual firewalls at the instance level. Design them to allow only specific port and source combinations. Use security group referencing to allow traffic from other security groups, not CIDR ranges, for better maintainability.
• Network ACLs provide stateless subnet‑level filtering. Use them as a coarse‑grained secondary control, not as a replacement for security groups.
• Subnet design: Place public‑facing resources in public subnets and backend systems (databases, application servers) in private subnets. Use a NAT Gateway for outbound internet access from private subnets.

Private Connectivity

• VPC Endpoints (Interface and Gateway) allow private connectivity to AWS services without traversing the public internet. Use Gateway endpoints for S3 and DynamoDB, and Interface endpoints for everything else.
• AWS PrivateLink lets you expose services securely across VPCs and accounts without using public IPs or VPC peering.

Edge Security

• AWS WAF protects web applications from common exploits like SQL injection and cross‑site scripting. Attach it to CloudFront distributions, Application Load Balancers, or API Gateway.
• AWS Shield provides DDoS protection. Shield Standard is included automatically; Shield Advanced offers enhanced protection and cost‑protection for larger attacks.
• CloudFront provides TLS termination at the edge and can restrict access to your origin using Origin Access Control.

Secure Storage Design

Each AWS storage service has its own set of security controls. Designing securely requires you to configure them appropriately.

• Amazon S3: Enable block public access at the account level unless you have a specific use case for public buckets. Use bucket policies to grant access to specific principals and conditions. Enable default encryption and consider S3 Object Lock for write‑once‑read‑many compliance requirements.
• Amazon EBS: Encrypt volumes using KMS keys. Share encrypted snapshots by modifying the key policy to allow the target account.
• Amazon EFS: Enforce encryption in transit using the EFS mount helper. Control access with POSIX permissions and IAM policies for file system access.

Monitoring, Auditing and Compliance

Security is not a set‑and‑forget activity. Continuous monitoring and auditing are essential for detecting misconfigurations, investigating incidents, and proving compliance.

• AWS CloudTrail records API calls across your accounts. Enable it on all accounts, create a trail that writes to a centralised S3 bucket, and enable log file integrity validation. Use CloudTrail Insights to detect unusual API activity.
• Amazon CloudWatch collects metrics and logs. Set alarms for security‑relevant events, such as root account usage or S3 bucket policy changes.
• AWS Config evaluates resource configurations against rules you define. Use it to detect non‑compliant resources, such as unencrypted EBS volumes or open security groups. Config integrates with AWS Systems Manager for automated remediation.
• Amazon GuardDuty provides threat detection using machine learning and threat intelligence. It analyses VPC flow logs, CloudTrail logs, and DNS queries to find suspicious activity. Enable it in all accounts and consolidate findings with GuardDuty administrator.
• AWS Security Hub aggregates and prioritises security findings from multiple services into a single dashboard. It also runs automated compliance checks against standards like the AWS Foundational Security Best Practices and CIS Benchmarks.

Common Architecture Scenarios

Scenario 1: Multi‑Account Enterprise with Sensitive Data

A financial services company operates multiple AWS accounts and needs to ensure that customer data is encrypted and access is tightly controlled, with centralised auditing.

Architecture decisions:

• Use AWS Organizations with SCPs that deny disabling CloudTrail and KMS key deletion.
• Create a centralised security account for GuardDuty administrator, Security Hub, and CloudTrail aggregation.
• Implement IAM roles for cross‑account access from a shared services account.
• Enforce encryption at rest on all S3 buckets and EBS volumes using customer managed KMS keys with restricted key policies.
• Deploy VPC endpoints for all AWS service access and use PrivateLink for inter‑account communication.

Scenario 2: Public‑Facing Web Application

An e‑commerce company runs a web application that must be accessible from the internet but protected against common web exploits and DDoS attacks.

Architecture decisions:

• Use CloudFront with a custom domain and ACM certificate for TLS termination.
• Attach AWS WAF to CloudFront with managed rule groups for SQL injection and cross‑site scripting.
• Enable AWS Shield Advanced for DDoS protection and cost‑safeguard.
• Place the Application Load Balancer in a public subnet and the application servers in a private subnet. Security groups on the ALB allow HTTPS from CloudFront only; application security groups allow traffic only from the ALB security group.
• Store all static assets in an S3 bucket with block public access enabled, using CloudFront Origin Access Control for secure access.

Scenario 3: Cross‑Account Resource Sharing

A development team in Account A needs to read objects from an S3 bucket in Account B without sharing long‑term credentials.

Architecture decisions:

• In Account B, create an IAM role with a policy that grants read access to the specific S3 bucket.
• Define a trust policy on the role that allows the development team’s IAM principal in Account A to assume the role.
• In Account A, grant the development team permission to call sts:AssumeRole.
• The bucket policy in Account B also authorises the role for S3 access, following the principle that both IAM and resource‑based policies must permit the action.

Common Design Mistakes

Avoid these frequent missteps when designing secure architectures:

• Overly permissive IAM policies – Using * in actions or resources without careful review. Always scope policies to specific services and actions, and use condition keys to restrict access further (e.g., by source IP or VPC).
• Public S3 buckets – Leaving Block Public Access disabled or applying bucket policies that allow Principal: * for read or write. Instead, use CloudFront or pre‑signed URLs for controlled sharing.
• Unnecessary internet exposure – Placing database servers or internal services in public subnets with public IPs. Always keep backend systems in private subnets and access them via bastion hosts, Session Manager, or VPN.
• Missing encryption – Storing sensitive data in unencrypted EBS volumes or S3 buckets. Enable default encryption and block the creation of unencrypted resources using AWS Config or SCPs.
• Weak monitoring – Failing to enable CloudTrail or ignoring GuardDuty findings. Without logs, you cannot detect or recover from security incidents.
• Hard‑coded credentials – Embedding AWS access keys in code or configuration files. Always use IAM roles for EC2 instances, Lambda functions, and containers.

Related AWS Services

The table below summarises the primary AWS security services, their purpose, and typical architectural usage patterns.

AWS Service	Primary Purpose	Common Architecture Use Case
IAM	Identity and access control	Core authorization for all AWS resources
AWS Organizations	Multi‑account governance	Enforce SCPs and centralised billing
AWS KMS	Key management	Encryption for S3, EBS, RDS, and custom applications
AWS Secrets Manager	Secrets storage and rotation	Database credentials, API keys
AWS WAF	Web application firewall	Protect CloudFront, ALB, API Gateway from web exploits
AWS Shield	DDoS protection	Mitigate volumetric attacks (Standard/Advanced)
Amazon CloudFront	Content delivery and edge security	TLS termination, geo‑restriction, OAC for S3
AWS CloudTrail	API auditing	Governance, compliance, and security investigation
AWS Config	Resource compliance	Detect unencrypted volumes, open SGs, drift
Amazon GuardDuty	Threat detection	Identify compromised instances, malicious IPs
AWS Security Hub	Centralised security posture	Aggregate findings, compliance checks

Relationship with Other SAA‑C03 Domains

Security architecture does not exist in isolation. It directly influences and interacts with the other three exam domains:

• Design Resilient Architectures – Resilient designs often require secure failover mechanisms. For example, cross‑region replication of encrypted data must handle key management in both regions. IAM policies must permit the replication service to use the destination KMS key.
• Design High‑Performing Architectures – Security controls can introduce latency. Placing a WAF in front of your application and using VPC endpoints instead of NAT gateways for service access both have performance implications that must be weighed against security benefits.
• Design Cost‑Optimized Architectures – Security services come with costs. KMS keys incur a monthly charge, WAF has per‑rule costs, and Shield Advanced represents a significant investment. An architect must balance the cost of security controls with the risk they mitigate.

When you practice architecture scenarios, you will need to satisfy requirements from multiple domains simultaneously—for instance, designing a secure, highly available, and cost‑effective web platform. Treating domains as interconnected forces rather than isolated lists will improve both your exam performance and your real‑world design skills.

Related CloudCertPro Learning Resources

• AWS Services for SAA-C03 – Deepen your knowledge of the individual services used in secure designs.
• AWS Hands‑on Labs for SAA‑C03 – Practice building secure architectures, including IAM policies, VPC endpoints, and encryption configurations.
• AWS Architecture Scenarios for SAA‑C03 – Apply secure design principles in realistic, multi‑domain business problems.
• SAA‑C03 Study Resources – Access official AWS documentation, study checklists, and reference links.
• Remaining SAA‑C03 Domains – Continue to Design Resilient, High‑Performing, and Cost‑Optimized Architectures.

What to Explore Next

Security is the foundation of every AWS architecture. Once you are comfortable with the principles and services covered here, proceed to the Design Resilient Architectures domain. Resilient designs build on secure foundations: the fault‑tolerant, multi‑region patterns you will learn next depend on the identity and network controls you have just studied.

To solidify your understanding, complete at least one hands‑on lab that involves writing a scoped IAM policy, setting up a VPC with private subnets and endpoints, and enabling CloudTrail with an alarm for root account activity. Then attempt a security‑focused architecture scenario from the CloudCertPro library to test your ability to make architectural trade‑offs under realistic constraints.