AWS Builder Center

Builder Center

AWS Security: Key Options to Consider When Building a Cloud Architecture

When building an application on AWS, security should not be something we add at the end of the project. It should be considered from the beginning of the architecture.

1. Identity and Access Management — IAM

The first security layer is controlling who can access AWS resources and what they are allowed to do.
AWS IAM allows us to manage:
  • Users
  • Groups
  • Roles
  • Policies
  • Permissions
A basic principle is:
Give users and applications only the permissions they actually need.
This is called the principle of least privilege.
For example, if an application only needs to read objects from an S3 bucket, it should not receive full administrator permissions.
For applications running on EC2, Lambda, or ECS, IAM roles are generally preferred over storing long-term access keys inside the application.

2. Network Security — VPC

The next important area is network security.
Most AWS applications run inside an Amazon VPC (Virtual Private Cloud).
A secure architecture should carefully consider which resources need to be public and which should remain private.
A common design is:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
Load Balancer
|
v
Application
|
v
Database
The database should normally not be directly accessible from the public internet.

3. Security Groups

Security Groups act as virtual firewalls for AWS resources such as EC2 instances.
For example, an application server might allow:
1
HTTPS → 443
while database access is allowed only from the application servers.
1
2
3
4
5
Application Server
|
| TCP 3306
v
RDS
Instead of:
1
2
3
4
5
Internet
|
| TCP 3306
v
Database
The second architecture creates unnecessary exposure.

4. Network ACLs

Network ACLs, or NACLs, provide another layer of network control at the subnet level.
A simple way to remember the difference is:
1
2
3
Security Group → Resource level

NACL → Subnet level
Security Groups are usually the primary control for application traffic, while NACLs can provide an additional layer of network protection.

5. Encryption with AWS KMS

Sensitive information should be protected using encryption.
AWS Key Management Service (KMS) allows us to create and control cryptographic keys.
KMS can be used with services such as:
  • S3
  • EBS
  • RDS
  • Secrets Manager
  • Lambda
  • CloudTrail
We should consider both:
Encryption at rest — protecting stored data.
Encryption in transit — protecting data while it moves between systems.
For web applications, HTTPS/TLS should normally be used.

6. Secrets Manager

Applications often need credentials such as:
1
2
3
4
Database username
Database password
API keys
Application secrets
A common mistake is putting them directly inside source code.
Instead, AWS Secrets Manager can securely store application secrets.
1
2
3
4
5
6
7
8
Application
|
| IAM Role
v
Secrets Manager
|
v
Database Credentials
The application retrieves the secret when required instead of storing the password directly in the source code.

7. AWS WAF

If we have a web application, we should consider AWS WAF (Web Application Firewall).
A common architecture is:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
AWS WAF
|
v
Application Load Balancer
|
v
Application
WAF allows us to create rules that control unwanted HTTP/HTTPS traffic.

8. AWS Shield

For applications exposed to the internet, another service to consider is AWS Shield.
AWS Shield provides protection against Distributed Denial-of-Service (DDoS) attacks.
A simplified architecture is:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
AWS Shield
|
v
AWS WAF
|
v
Load Balancer

9. CloudTrail — Monitor AWS API Activity

Security is not only about preventing attacks.
We also need to know:
Who did what, and when?
AWS CloudTrail records AWS API activity.
For example, if someone changes an IAM policy, creates an EC2 instance, or modifies an S3 bucket, CloudTrail can provide an audit trail of the API activity.

10. Amazon GuardDuty

GuardDuty is a threat-detection service.
It analyzes AWS activity and other supported data sources to identify potentially suspicious behavior.
A simplified view is:
1
2
3
4
5
6
7
8
9
10
AWS Environment
|
v
GuardDuty
|
v
Potential Threat
|
v
Security Investigation

11. Amazon Inspector

Amazon Inspector helps identify security vulnerabilities in supported workloads.
It can help identify vulnerabilities in:
  • EC2 instances
  • Container images
  • Lambda functions
This can be useful as part of a DevSecOps process.

12. AWS Security Hub

Security findings can come from multiple AWS security services.
AWS Security Hub helps provide a centralized view of security findings.
1
2
3
4
5
6
7
8
9
GuardDuty ──────┐
Inspector ──────┤
AWS Config ─────┤
Other Services ─┤
v
Security Hub
|
v
Security Findings

13. AWS Config

AWS Config helps us understand and monitor the configuration of AWS resources.
For example, we may want to detect whether:
  • An S3 bucket becomes publicly accessible
  • Security groups allow unnecessary access
  • Resources are configured according to organizational rules
1
2
3
4
5
6
7
AWS Resources
|
v
AWS Config
|
v
Configuration Compliance

14. Practical AWS Architecture Example

Let's put these security concepts together using a simple three-tier web application.
Imagine we are building an online application with:
  • A public web application
  • Backend application servers
  • A database
  • Private file storage
  • Centralized logging and security monitoring
A secure architecture could look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
INTERNET
|
v
AWS Shield
|
v
AWS WAF
|
v
Application Load Balancer
|
+--------------+--------------+
| |
v v
Public Subnet Public Subnet
| |
v v
NAT Gateway NAT Gateway
| |
+--------------+--------------+
|
v
Private Subnets
|
+-----------+-----------+
| |
v v
EC2 / ECS EC2 / ECS
Application Tier Application Tier
| |
+-----------+-----------+
|
v
Private Database
Amazon RDS
The important security idea is that the application servers and database are not directly exposed to the internet.

Adding S3 for Application Data

Suppose our application allows users to upload documents or images.
Instead of storing those files directly on the application servers, we can use Amazon S3.
1
2
3
4
5
6
7
8
9
10
User
|
v
Application
|
v
Private S3 Bucket
|
v
Encrypted Objects
The S3 bucket should remain private.
The application can access it through an IAM role with only the required permissions.
For example:
1
2
3
4
5
Application IAM Role
|
| PutObject / GetObject
v
S3 Bucket
We don't need to give the application full S3 administration permissions.

Adding Secrets Manager

The application also needs database credentials.
Instead of putting them in the application configuration:
1
DB_PASSWORD=mypassword
we can use:
1
2
3
4
5
6
7
8
9
10
11
Application
|
| IAM Role
v
AWS Secrets Manager
|
v
Database Credentials
|
v
RDS
This reduces the risk of accidentally exposing credentials through source code or configuration files.

Adding KMS Encryption

Now let's add encryption.
1
2
3
4
5
6
AWS KMS
|
+-----------+-----------+
| | |
v v v
S3 RDS EBS
We can use AWS KMS keys to help protect sensitive data stored by supported AWS services.
The exact key-management design should depend on the application's security and compliance requirements.

15. Monitoring the Architecture

Security doesn't stop after deployment.
We also need visibility into what is happening.
Our architecture can include:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
AWS Environment
|
+-----------------+-----------------+
| | |
v v v
CloudTrail GuardDuty Config
| | |
+-----------------+-----------------+
|
v
Security Hub
|
v
Security Findings
This gives us multiple security capabilities:
CloudTrail
Tracks AWS API activity.
GuardDuty
Detects potentially suspicious activity.
AWS Config
Monitors resource configuration and compliance.
Security Hub
Provides a centralized view of security findings.

16. Example Security Flow

Let's imagine a user visits our application.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
1. User
|
v
2. AWS Shield
|
v
3. AWS WAF
|
v
4. Application Load Balancer
|
v
5. EC2 / ECS Application
|
+------> Secrets Manager
|
+------> S3
|
v
6. Amazon RDS
Behind the scenes, we also have:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
IAM
|
+--> Controls access

KMS
|
+--> Protects encryption keys

CloudTrail
|
+--> Records API activity

GuardDuty
|
+--> Detects threats

Inspector
|
+--> Finds vulnerabilities

AWS Config
|
+--> Checks configuration

Security Hub
|
+--> Centralizes findings
This is an example of defense in depth.
If one security control fails, additional controls can still provide protection.

17. How I Would Approach a New AWS Architecture

When starting a new AWS project, I would ask these questions before deploying resources:

Identity

  • Who needs access?
  • What permissions do they need?
  • Can IAM roles be used instead of long-term credentials?
  • Is MFA enabled where appropriate?

Network

  • Which components actually need internet access?
  • Can application servers remain private?
  • Can the database remain private?
  • Which ports need to be open?

Data

  • What data is sensitive?
  • Does it need encryption?
  • Where should encryption keys be managed?
  • Where should application secrets be stored?

Application

  • Does the application need WAF?
  • Does it need DDoS protection?
  • Are dependencies and container images scanned?
  • Is HTTPS enabled?

Monitoring

  • Is CloudTrail enabled?
  • Are security logs being retained appropriately?
  • Is GuardDuty enabled?
  • Are configuration changes monitored?
  • Where will security findings be reviewed?

18. A Simple Secure Architecture Mindset

We don't need to enable every AWS security service for every application.
Instead, we should match security controls to the risk, data sensitivity, business requirements, and architecture.
A useful way to think about an AWS architecture is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
IDENTITY
|
v
NETWORK
|
v
APPLICATION
|
v
DATA
|
v
MONITORING
|
v
DETECTION & RESPONSE
Each layer addresses a different security concern.

Final Thoughts

AWS provides a large number of security services, but building a secure architecture starts with understanding the fundamentals.
For a typical web application, some of the key security considerations are:
1
2
3
4
5
6
7
8
9
10
11
12
IAM
VPC
Security Groups
KMS
Secrets Manager
WAF
Shield
CloudTrail
GuardDuty
Inspector
AWS Config
Security Hub
We don't necessarily need all of them in every project.
The important lesson is:
Security should be designed into the architecture from the beginning, not added after the application is deployed.
A good AWS architecture doesn't rely on a single security control. It uses multiple layers—identity, network controls, encryption, secure secrets management, threat detection, logging, and continuous monitoring.
This approach is often called defense in depth, and it is one of the most important concepts to understand when designing secure cloud architectures.
#AWS #AWSBuilder #AWSArchitecture #AWSCloud #CloudSecurity #DevOps #CyberSecurity #IAM #AWSWAF #GuardDuty #AWSKMS #CloudComputing
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article