AWS Secure Architecture: Services, Scenarios, and Exam Tips
Learn how to design secure AWS architectures with practical scenarios covering IAM, encryption, network security, threat protection, compliance, and identity federation.
When we talk about designing secure architectures in Amazon Web Services (AWS), we need to understand how different services work together to protect identities, applications, networks, and data.
Security is not a single service that we enable after deploying an application. It is a set of decisions that we make throughout the design process.
For example, an application can use encryption and still expose sensitive information if its storage permissions are incorrect. A server can have a secure operating system and still be vulnerable if its security group allows unrestricted access to administrative ports.
As I continue my AWS Solutions Architect Associate journey, I am studying how to select the right AWS services for different security requirements. I want to understand what each service does, when to use it, and how to identify the right solution when presented with a real-world scenario.
According to the AWS Certified Solutions Architect Associate (SAA-C03) exam guide, Domain 1: Design Secure Architectures accounts for 30% of the scored content. The domain covers secure access to AWS resources, secure workloads and applications, and appropriate data security controls.
In this article, I will break down seven important areas of AWS security using practical scenarios, service comparisons, and tips to help me remember the right solution.
1. Identity and Access Management (IAM)
Imagine you work for a company that hosts its applications on AWS. The developers need access to application logs, the database administrator needs access to database resources, and the security team needs to review audit records.
Should everyone receive administrator access?
Definitely not.
Giving every employee full access to AWS resources creates unnecessary risk. If an account is compromised or someone makes a mistake, the impact could extend across the entire environment.
AWS Identity and Access Management (IAM) helps control who can access AWS resources and which actions they can perform.
The principle of least privilege guides this process. Each identity should receive only the permissions required to perform its assigned tasks.
IAM roles
An IAM role provides a set of permissions that a trusted identity or service can assume when needed.
Unlike an IAM user, a role does not have long-term credentials attached to it. AWS Security Token Service (AWS STS) can provide temporary credentials when an authorized principal assumes a role.
Scenario: A company runs an application on an Amazon Elastic Compute Cloud (Amazon EC2) instance. The application needs to read files from an Amazon Simple Storage Service (Amazon S3) bucket.
Instead of storing access keys inside the application code, create an IAM role with permission to read objects from the required bucket. Attach the role to the EC2 instance through an instance profile.
The application can then obtain temporary credentials through the AWS SDK's default credential provider chain.
When to use it: Use IAM roles when AWS services, applications, users, or external identities need temporary access to AWS resources.
IAM policies
An IAM policy defines permissions through statements that specify allowed or denied actions, resources, and optional conditions.
For example, a policy can allow a developer to read objects from a particular S3 bucket without allowing that developer to delete those objects.
Policies can be attached to identities or resources, depending on the policy type and supported service.
Scenario: A company wants its support team to view objects in an S3 bucket containing application logs. The team must not upload, modify, or delete files.
Create a policy that allows the required read and list actions on the specific bucket and its objects. Do not grant unnecessary write or delete permissions.
When to use it: Use IAM policies to define which actions an identity or resource can perform.
IAM permissions boundaries
A permissions boundary sets the maximum permissions that an IAM user or role can receive through identity-based policies. It does not grant permissions by itself.
Think of it as a ceiling on the permissions that an identity-based policy can grant.
Scenario: A company allows a development team to create IAM roles for application workloads. However, developers must not create roles with permissions to administer IAM or access restricted production resources.
The company can apply an appropriate permissions boundary to the roles created by the team. The boundary limits the permissions that identity-based policies can grant.
When to use it: Use permissions boundaries when delegating IAM role creation or when you need to limit the maximum permissions of specific identities.
Service control policies (SCPs)
Service control policies are AWS Organizations policies that define the maximum available permissions for principals in member accounts.
An SCP does not grant permissions. IAM policies and other applicable authorization controls must still permit the requested action.
Scenario: A company manages development, testing, and production accounts through AWS Organizations. Its security policy prohibits member accounts from disabling certain security services or leaving approved AWS Regions.
The organization can use an SCP to restrict the relevant actions across the applicable accounts.
When to use it: Use SCPs to establish organization-level permission guardrails across AWS accounts.
Permissions boundary vs SCP
| Feature | Permissions boundary | SCP |
|---|---|---|
| Scope | An IAM user or role | Accounts in an AWS organization or organizational unit |
| Purpose | Limits permissions an identity-based policy can grant | Limits permissions available to principals in affected member accounts |
| Grants access? | No | No |
| Typical use | Delegated role creation | Organization-wide guardrails |
Exam tip: If the question describes a developer who can create roles but must not grant them excessive permissions, consider a permissions boundary. If it describes restrictions across multiple AWS accounts, consider an SCP.
For further reading, see the IAM policy documentation and permissions boundaries documentation.
2. AWS Security Services: KMS, CloudHSM, Secrets Manager, and ACM
Applications often need encryption keys, database passwords, API credentials, and digital certificates.
AWS provides services that help manage these security requirements without forcing every application team to build its own key-management infrastructure.
The important skill is knowing which service solves which problem.
AWS Key Management Service (AWS KMS)
AWS Key Management Service helps you create and manage cryptographic keys and control their use through policies and permissions.
Many AWS services integrate with KMS to encrypt data at rest.
Scenario: A financial application stores customer records in Amazon RDS. The organization requires encryption at rest and wants to control which AWS identities can use the encryption keys.
Configure the database to use an appropriate KMS key. Restrict access through the relevant key policy and IAM permissions.
When to use it: Use KMS when you need managed encryption keys, access controls, key usage auditing, and integration with supported AWS services.
AWS CloudHSM
AWS CloudHSM provides dedicated hardware security modules (HSMs) in which customers can manage cryptographic keys and perform cryptographic operations.
It offers a different level of control from the standard KMS experience. You manage important aspects of the HSM environment, including its users and configuration.
Scenario: A financial organization has a requirement for cryptographic operations to take place within dedicated HSM hardware. Its compliance and security requirements also demand direct control over HSM users and key operations.
CloudHSM may be appropriate if the requirements align with its capabilities and operating model.
When to use it: Consider CloudHSM when you need dedicated HSM control or cryptographic capabilities that your requirements cannot meet through the standard KMS model.
Exam tip: KMS is commonly the appropriate choice for managed encryption across AWS services. CloudHSM is relevant when the scenario specifically requires dedicated HSM control.
AWS Secrets Manager
AWS Secrets Manager helps you store, retrieve, and manage sensitive information such as database credentials, API keys, and other application secrets.
It can also support automatic rotation for supported secrets when configured with the required rotation process.
Scenario: A web application connects to an Amazon RDS database. The database password is currently stored in a configuration file inside the application's deployment package.
If someone obtains that package, the password could be exposed.
Move the credential into Secrets Manager. Configure the application to retrieve the secret through an authorized IAM role. Restrict access to the required secret and configure rotation where supported.
When to use it: Use Secrets Manager when an application needs secure storage, retrieval, or rotation of credentials and other secrets.
Avoid placing secrets in source code, container images, public repositories, or unprotected configuration files.
AWS Certificate Manager (ACM)
AWS Certificate Manager helps provision, manage, and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for supported AWS services and integrations.
TLS protects data in transit by encrypting the connection between communicating endpoints.
Scenario: An online store uses an Application Load Balancer to receive HTTPS traffic. The company needs a trusted certificate for its domain and wants to simplify certificate renewal.
Use ACM to provision an appropriate certificate and associate it with the supported load balancer listener.
When to use it: Use ACM when you need to manage certificates for HTTPS and other supported TLS use cases.
Exam tip: If the requirement involves encryption keys, think KMS. If it involves credentials, think Secrets Manager. If it involves TLS certificates, think ACM. If it specifically requires dedicated HSM control, consider CloudHSM.
3. VPC Security: Security Groups, Network ACLs, Flow Logs, and Endpoints
An Amazon Virtual Private Cloud (Amazon VPC) provides a logically isolated network for AWS resources.
However, creating a VPC does not automatically make every resource secure. You must control network paths, limit traffic, and decide which resources need public access.
Security groups
A security group acts as a virtual firewall for supported resources, such as EC2 instances and network interfaces.
Security groups are stateful. If an inbound connection is allowed, response traffic is allowed automatically, subject to the connection and service behavior.
Scenario: A company hosts a web application on EC2 instances behind an Application Load Balancer.
The web servers should accept HTTP or HTTPS traffic only from the load balancer. They should not accept direct public traffic.
Configure the web servers' security group to allow the required application port from the load balancer's security group. Configure the load balancer's security group to allow the intended client traffic.
When to use it: Use security groups to control traffic to and from supported resources.
Network access control lists (network ACLs)
Network ACLs are stateless traffic filters associated with VPC subnets.
They evaluate inbound and outbound traffic using numbered rules. Because they are stateless, you must account for both directions of traffic, including relevant return traffic and ephemeral ports.
Scenario: A company wants an additional subnet-level control to block traffic from a known range of IP addresses. Its architecture requires a subnet-level network filter in addition to security groups.
A network ACL can provide this additional control.
When to use it: Use network ACLs when subnet-level traffic filtering is required. Security groups are generally the primary choice for controlling traffic to individual workloads.
VPC Flow Logs
VPC Flow Logs capture information about IP traffic to and from network interfaces, subnets, or VPCs, depending on their configuration.
They help with network troubleshooting, traffic analysis, and security investigations. They do not capture every packet or replace packet inspection tools.
Scenario: A company notices unexpected connection attempts against its application servers. The security team needs records of accepted and rejected IP traffic to investigate the pattern.
Enable VPC Flow Logs and publish the records to an appropriate destination, such as Amazon CloudWatch Logs or Amazon S3.
When to use it: Use VPC Flow Logs to investigate network traffic and troubleshoot connectivity or security issues.
VPC endpoints
VPC endpoints allow supported AWS services to be accessed through private network paths without requiring the traffic to use an internet gateway or NAT device for that service access.
Gateway endpoints support Amazon S3 and Amazon DynamoDB. Interface endpoints use AWS PrivateLink and support many other AWS services.
Scenario: An application runs on EC2 instances in a private subnet. It needs to retrieve files from S3, but the company does not want that traffic to depend on an internet gateway or NAT gateway.
Create an S3 gateway endpoint and configure its route tables and policies appropriately.
When to use it: Use VPC endpoints when workloads need private connectivity to supported AWS services.
Remember that a VPC endpoint does not automatically make every request authorized. IAM policies, endpoint policies, and resource policies can still affect access.
Security group vs network ACL
| Feature | Security group | Network ACL |
|---|---|---|
| Scope | Resource or network interface | Subnet |
| Stateful? | Yes | No |
| Rules | Allow rules | Allow and deny rules |
| Evaluation | All applicable rules determine whether traffic is allowed | Rules are evaluated in numerical order |
| Common use | Restrict application and administrative traffic | Apply additional subnet-level filtering |
Exam tip: If a question mentions stateful filtering at the instance level, think security groups. If it requires stateless filtering or explicit subnet-level deny rules, consider network ACLs. If it asks for network traffic records, think VPC Flow Logs.
4. Securing Data at Rest and in Transit
Encryption protects data from unauthorized disclosure when implemented with appropriate access controls and key management.
Two important requirements are encryption at rest and encryption in transit.
Encryption at rest
Encryption at rest protects stored data. AWS services offer different encryption options depending on the resource and configuration.
Amazon S3
Amazon S3 supports server-side encryption for objects. Current default encryption behavior includes server-side encryption with Amazon S3 managed keys (SSE-S3).
Some workloads require server-side encryption with AWS KMS keys (SSE-KMS) for additional key-management and access-control requirements.
Scenario: A company stores financial reports in S3. Its security policy requires the company to control access to the encryption keys and audit key usage.
Configure the bucket and object access appropriately. Use SSE-KMS with a suitable KMS key when the requirement calls for customer-managed key controls.
Do not assume that encryption alone prevents public access. Configure S3 Block Public Access, bucket policies, IAM permissions, and other required controls.
Amazon EBS
Amazon Elastic Block Store (Amazon EBS) provides block storage for EC2 instances. EBS encryption protects supported volume data, snapshots, and related data transfers between the instance and the volume.
Scenario: A company runs a database on an EC2 instance. Its policy requires the database's storage volumes and snapshots to be encrypted.
Enable EBS encryption using the appropriate key configuration. Review the account's default EBS encryption settings and snapshot-copy requirements.
When to use it: Use EBS encryption when EC2 workloads require encrypted block storage.
Amazon RDS
Amazon Relational Database Service (Amazon RDS) supports encryption at rest for supported database configurations.
For encrypted RDS instances, encryption covers the underlying storage and supported automated backups, snapshots, and replicas according to the service's encryption behavior.
Scenario: An organization migrates a customer database to RDS. Its security requirements mandate encryption at rest and restricted access to database credentials.
Enable RDS encryption when creating the database, select an appropriate KMS key, and protect database credentials through Secrets Manager or another approved mechanism.
For existing unencrypted RDS instances, review the supported migration approach. You may need to create an encrypted snapshot and restore it as a new encrypted instance.
Encryption in transit
Encryption in transit protects information as it moves between clients, applications, and services.
Scenario: Customers use an online banking portal to view account balances. The organization must protect their sessions from network interception.
Configure HTTPS using TLS certificates managed through ACM where supported. Enforce secure connections and appropriate TLS configurations at the relevant endpoints.
For connections between application components, assess the required encryption separately. HTTPS at the public load balancer does not automatically prove that every internal connection is encrypted.
Exam tip: S3, EBS, and RDS are relevant when the requirement concerns stored data. ACM and TLS are relevant when the requirement concerns secure connections. Always check whether the question specifies default encryption, customer-managed keys, or additional key-control requirements.
5. AWS WAF, AWS Shield, and Amazon GuardDuty
Applications face different threats. Some attacks target web requests, some overwhelm network capacity, and others involve suspicious activity within an AWS environment.
AWS provides separate services for these problems.
AWS WAF
AWS WAF is a web application firewall that helps inspect HTTP and HTTPS requests and control which requests reach supported resources.
It supports rule-based filtering, managed rule groups, rate-based rules, and other protections against common web exploits.
Scenario: An online store receives repeated malicious requests that appear to target SQL injection vulnerabilities. The security team wants to inspect and filter web requests before they reach the application.
Deploy AWS WAF with appropriate managed rules and application-specific rules on a supported resource.
When to use it: Use AWS WAF to filter web requests and help protect supported applications against common web attacks.
AWS Shield
AWS Shield provides protection against distributed denial-of-service (DDoS) attacks.
AWS Shield Standard provides automatic protection against common network and transport layer DDoS events for supported AWS services. AWS Shield Advanced offers additional protection and features for eligible resources and configurations.
Scenario: A public-facing service experiences large volumes of malicious network traffic that threaten its availability.
Use the relevant AWS Shield protections for the architecture. Consider Shield Advanced if the business requires its additional capabilities and support.
When to use it: Use AWS Shield when the requirement focuses on DDoS protection and service availability.
Amazon GuardDuty
Amazon GuardDuty is a threat detection service that analyzes supported data sources and signals to identify potentially malicious activity.
It can identify findings related to suspicious API activity, compromised credentials, unusual network behavior, and other threats, depending on the enabled protections.
Scenario: A company suspects that an EC2 instance has been compromised. The security team wants to detect suspicious behavior without building a threat detection system from scratch.
Enable GuardDuty for the relevant AWS environment and review its findings. Integrate alerts with the organization's incident response process.
When to use it: Use GuardDuty to detect potential threats and suspicious activity in supported AWS environments.
Which service should you choose?
| Requirement | Service to consider |
|---|---|
| Filter malicious HTTP requests | AWS WAF |
| Protect against DDoS attacks | AWS Shield |
| Detect suspicious activity and potential threats | Amazon GuardDuty |
Exam tip: WAF filters requests. Shield helps protect availability against DDoS attacks. GuardDuty detects potential threats. These services can complement one another, but they are not interchangeable.
6. Compliance and Audit: CloudTrail, AWS Config, and Security Hub
Organizations need to understand what happens in their AWS environments, whether resources comply with security requirements, and which security findings need attention.
These services help answer different questions.
AWS CloudTrail
AWS CloudTrail records AWS account activity, including supported management events and, when configured, relevant data events.
CloudTrail event history provides a searchable history of recent management events. Trails and event data stores support different collection, retention, and analysis requirements.
Scenario: A company discovers that an S3 bucket policy changed unexpectedly. The security team needs to identify the API activity associated with the change.
Use CloudTrail to investigate the relevant event. Review the event's identity, timestamp, API action, and other available details.
When to use it: Use CloudTrail when you need to investigate AWS API activity and establish who performed an action, when it occurred, and what request was made.
AWS Config
AWS Config records resource configuration information and changes for supported resources. It can evaluate resource configurations against rules and conformance packs.
Scenario: A company requires its S3 buckets to meet specific configuration requirements. The security team wants to identify buckets that do not comply and track configuration changes over time.
Configure AWS Config recording and appropriate rules to evaluate the relevant resources.
When to use it: Use AWS Config to assess resource configurations, track changes, and evaluate compliance with defined configuration rules.
AWS Security Hub
AWS Security Hub helps aggregate, organize, and prioritize security findings from supported AWS services and integrations. Its capabilities can include security posture management and checks against supported standards.
Scenario: A security team receives findings from GuardDuty and other security tools. Analysts want a consolidated view of security issues across their AWS environment.
Configure Security Hub and its relevant integrations to collect and prioritize supported findings.
When to use it: Use Security Hub when you need a centralized view of security findings and security posture information.
CloudTrail vs AWS Config vs Security Hub
| Service | Main question it helps answer |
|---|---|
| CloudTrail | What AWS API activity occurred? |
| AWS Config | How was a resource configured, and did its configuration change? |
| Security Hub | Which security findings and posture issues need attention? |
Exam tip: For API activity, think CloudTrail. For resource configuration history and compliance rules, think AWS Config. For aggregated security findings, think Security Hub.
These services work best as complementary controls. A security finding may need CloudTrail investigation, while AWS Config can help establish whether the affected resource violates a configuration requirement.
7. Identity Federation: Cognito, IAM Identity Center, and Cross-Account Access
Companies often use multiple applications, teams, and AWS accounts. Managing separate credentials for every application and account can increase administrative effort and security risk.
Identity federation allows users to authenticate through a trusted identity provider and access resources according to the configured trust and authorization policies.
However, not every identity service serves the same audience.
Amazon Cognito
Amazon Cognito provides identity features for web and mobile applications. User pools support application user directories and authentication. Identity pools can provide AWS credentials to authenticated or unauthenticated identities under configured rules.
Scenario: A company builds a customer-facing mobile banking application. Customers need to register, sign in, and access protected application features.
Use a Cognito user pool to manage application users and authentication. If the application needs to grant users access to AWS resources, assess whether an identity pool and appropriately restricted IAM roles are required.
When to use it: Use Cognito for customer-facing web and mobile application identity requirements.
AWS IAM Identity Center
AWS IAM Identity Center helps organizations manage workforce access to AWS accounts and supported applications. It can integrate with an external identity provider and assign access through permission sets.
Scenario: A company has separate development, testing, and production AWS accounts. Employees need to sign in through the company's identity provider and access only the accounts and roles authorized for their jobs.
Use IAM Identity Center to manage workforce access. Assign suitable permission sets to users or groups for the relevant AWS accounts.
When to use it: Use IAM Identity Center for centralized workforce access to multiple AWS accounts and supported applications.
Cross-account access
Cross-account access allows a principal in one AWS account to access resources in another account when the required trust and permissions are configured.
IAM roles are a common way to implement this model. A role's trust policy determines which principals can assume it, while its permissions policies define what the role can do.
Scenario: A security team works in a dedicated security account. Its authorized analysts need read-only access to selected resources in production accounts.
Create an appropriately restricted role in each target account. Configure the trust policy to allow the intended security-account principals to assume the role. Grant only the required read permissions.
When to use it: Use cross-account roles when users or workloads need controlled access to resources in another AWS account.
Choosing the right identity solution
| Requirement | Service or feature |
|---|---|
| Customer registration and sign-in | Amazon Cognito |
| Workforce access across AWS accounts | AWS IAM Identity Center |
| Controlled access from one AWS account to another | IAM roles and cross-account trust |
Exam tip: Identify the identity type first. Customers signing in to your application point toward Cognito. Employees accessing company AWS accounts point toward IAM Identity Center. A workload or principal accessing resources in another account points toward cross-account IAM roles.
Putting the concepts together
Consider a company building an online store on AWS. It wants to protect customer information, restrict employee access, and detect suspicious activity.
A secure design could combine the services discussed in this article:
- Use IAM roles to grant application workloads temporary credentials.
- Apply IAM policies and permissions boundaries to restrict access.
- Use SCPs to establish organization-level permission guardrails where appropriate.
- Place application resources in a VPC with public and private subnets where required.
- Restrict workload traffic with security groups and use network ACLs when subnet-level filtering is needed.
- Use VPC endpoints for private access to supported AWS services.
- Encrypt stored data with the appropriate S3, EBS, or RDS encryption configuration.
- Use KMS to manage encryption keys and Secrets Manager to protect application credentials.
- Use ACM to manage TLS certificates for supported endpoints.
- Apply AWS WAF and Shield protections where the application requires web filtering and DDoS protection.
- Enable GuardDuty and configure CloudTrail and AWS Config for threat detection, investigation, and configuration monitoring.
- Use Security Hub to consolidate supported security findings.
- Use Cognito for customer identity and IAM Identity Center for workforce access where appropriate.
This design is only a starting point. The final architecture depends on business requirements, data sensitivity, access patterns, compliance obligations, availability needs, and cost constraints.
Security also depends on correct configuration. Enabling a service without reviewing its policies, integrations, alerts, and operational requirements does not guarantee a secure workload.
Quick revision guide
Before answering a scenario-based AWS security question, identify the requirement and match it to the relevant control.
| If the scenario asks for… | Consider… |
|---|---|
| Temporary permissions for an application on EC2 | IAM role |
| Maximum permissions for a delegated IAM role | Permissions boundary |
| Permission guardrails across AWS accounts | SCP |
| Managed encryption keys | AWS KMS |
| Dedicated HSM control | AWS CloudHSM |
| Secure storage and rotation of credentials | AWS Secrets Manager |
| TLS certificates for supported AWS services | AWS Certificate Manager |
| Stateful filtering for a workload | Security group |
| Stateless subnet-level filtering | Network ACL |
| Records of IP traffic | VPC Flow Logs |
| Private connectivity to supported AWS services | VPC endpoint |
| Encryption at rest | Appropriate S3, EBS, or RDS encryption |
| Web request filtering | AWS WAF |
| DDoS protection | AWS Shield |
| Detection of suspicious AWS activity | Amazon GuardDuty |
| AWS API activity history | AWS CloudTrail |
| Resource configuration compliance | AWS Config |
| Aggregated security findings | AWS Security Hub |
| Customer application authentication | Amazon Cognito |
| Workforce access to AWS accounts | IAM Identity Center |
| Access to resources in another AWS account | Cross-account IAM role |
These are study aids, not automatic answers. Read the full scenario before choosing a service. A question may include several requirements, and the correct design may require more than one control.
Final thoughts
Studying AWS security has helped me understand that secure architecture requires more than memorizing service names. I need to recognize the problem, understand the available controls, and select the combination that satisfies the requirements.
If you are also preparing for the AWS Solutions Architect Associate exam, I recommend using the official SAA-C03 exam guide alongside hands-on practice.
What AWS security concept would you like to see explained through a practical lab?