AWS Security in Practice: Protecting a Cloud Application with IAM, Security Groups, CloudTrail and GuardDuty
Deploying an application on AWS is only one part of building a cloud system. Once an application is running, we also need to think about questions such as: Who can access the application? Which AWS resources can the application access? Which network ports should be exposed? How can we detect suspicious activity? How can we investigate what happened after a security event?
AWS Security in Practice: Protecting a Cloud Application with IAM, Security Groups, CloudTrail and GuardDuty
Deploying an application on AWS is only one part of building a cloud system.
Once an application is running, we also need to think about questions such as:
- Who can access the application?
- Which AWS resources can the application access?
- Which network ports should be exposed?
- How can we detect suspicious activity?
- How can we investigate what happened after a security event?
AWS provides multiple security services and controls that work together to answer these questions.
In this article, we will look at a practical security architecture for an application running on AWS and understand the roles of IAM, Security Groups, CloudTrail, and GuardDuty.
The Application
Consider a simple web application running on an Amazon EC2 instance.
A basic architecture might look like this:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
Application / Web
|
v
EC2
|
v
AWS Resources
Now let's add security controls around the application.
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
Internet
|
v
Load Balancer
|
v
Security Group
|
v
EC2
|
IAM Role
|
+---------+---------+
| |
v v
AWS APIs AWS Resources
CloudTrail
|
v
API Activity
GuardDuty
|
v
Security Findings
Each component has a different responsibility.
1. IAM: Who Can Access What?
AWS Identity and Access Management (IAM) controls access to AWS resources.
One of the most important security principles is least privilege.
The idea is simple:
Give an identity only the permissions it actually needs.
For example, suppose an EC2 application needs to read objects from an S3 bucket.
Instead of giving the application broad access to every S3 bucket in the AWS account, we can provide permissions specifically for the required bucket and actions.
Conceptually:
1
2
3
4
5
6
7
8
9
10
Application
|
v
IAM Role
|
v
Read objects
|
v
Specific S3 Bucket
This reduces the potential impact if the application is compromised.
2. IAM Roles for Applications
A common mistake is putting AWS access keys directly inside application code.
For example:
1
2
3
4
5
Access Key
Secret Key
|
v
Application Code
This creates an unnecessary security risk.
Credentials could accidentally end up in:
- Source code
- Git repositories
- Configuration files
- Docker images
- Logs
Instead, AWS workloads such as EC2 instances can use IAM roles.
The architecture becomes:
1
2
3
4
5
6
7
EC2
|
v
IAM Role
|
v
AWS Service
The application can then obtain temporary credentials through the AWS environment instead of storing long-term credentials in the application.
This is a much cleaner approach for cloud workloads.
3. Security Groups: Controlling Network Access
IAM controls permissions to AWS resources.
Security Groups control network traffic to resources such as EC2 instances.
Think of a Security Group as a virtual firewall associated with the resource.
For example:
| Protocol | Port | Source | Purpose |
|---|---|---|---|
| HTTP | 80 | Internet | Web traffic |
| HTTPS | 443 | Internet | Secure web traffic |
| SSH | 22 | Trusted IP | Administration |
The important principle is:
Only expose the ports that are actually required.
For example, if an application only needs HTTPS traffic, there is little reason to expose additional application ports directly to the internet.
4. Why Port Exposure Matters
Imagine an application running on:
1
2
3
4
5
6
7
EC2
|
+-- Port 22 SSH
+-- Port 80 HTTP
+-- Port 443 HTTPS
+-- Port 3000 Application
+-- Port 5432 Database
Opening all of these ports publicly would unnecessarily increase the attack surface.
A better architecture might be:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
HTTPS :443
|
v
Application
|
v
Internal Database
The database does not need to be directly accessible from the public internet.
Similarly, an application server can be placed behind a load balancer rather than exposing its internal application port directly.
5. CloudTrail: Knowing What Happened
Security controls are important, but security also requires visibility.
Suppose someone makes an unexpected change to an AWS resource.
We need to answer:
- Who performed the action?
- What action was performed?
- When did it happen?
- Which AWS resource was affected?
AWS CloudTrail records AWS API activity.
Conceptually:
1
2
3
4
5
6
7
8
9
10
User / Application
|
v
AWS API Call
|
v
CloudTrail
|
v
Event Record
For example, an event could contain information about an API operation, the identity that performed it, and the resource involved.
This makes CloudTrail useful for auditing and investigation.
6. CloudTrail and Security Investigations
Consider this scenario.
An administrator notices that an important AWS resource was modified unexpectedly.
Without logging, the investigation becomes much harder.
With CloudTrail:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Unexpected Change
|
v
CloudTrail
|
v
Find API Event
|
v
Identify Identity
|
v
Identify Action
|
v
Investigate
CloudTrail therefore does not necessarily prevent every security incident.
Instead, it provides an important record of activity that can help us understand what happened.
This distinction is important:
Prevention and visibility are different security objectives.
7. GuardDuty: Detecting Suspicious Activity
AWS also provides Amazon GuardDuty, a threat detection service designed to identify potentially malicious or suspicious activity.
A simplified architecture is:
1
2
3
4
5
6
7
8
9
10
AWS Environment
|
v
Relevant Activity
|
v
GuardDuty
|
v
Security Finding
GuardDuty can help identify signs of potential threats and suspicious behavior within an AWS environment.
For example, imagine an application instance begins behaving unusually.
The security workflow could look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
Unusual Activity
|
v
Detection
|
v
GuardDuty Finding
|
v
Security Investigation
|
v
Remediation
This is different from CloudTrail.
CloudTrail focuses on recording AWS API activity.
GuardDuty focuses on threat detection and identifying potentially malicious behavior.
8. CloudTrail vs GuardDuty
These services can work together, but they solve different problems.
| Service | Main Purpose |
|---|---|
| IAM | Identity and permissions |
| Security Groups | Network access control |
| CloudTrail | Record AWS API activity |
| GuardDuty | Threat detection |
A simple way to remember them is:
1
2
3
4
5
6
7
8
9
10
11
IAM
"What are you allowed to do?"
Security Group
"Which network traffic is allowed?"
CloudTrail
"What happened?"
GuardDuty
"Does this activity look suspicious?"
This is much easier to understand than memorizing service descriptions individually.
9. Putting Everything Together
Now let's combine the controls around our application.
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
36
37
Internet
|
v
Load Balancer
|
v
Security Group
|
v
EC2
|
IAM Role
|
+-----------+-----------+
| |
v v
AWS Services S3 / RDS
AWS Account Activity
|
v
CloudTrail
|
v
Event Records
|
v
Monitoring
AWS Environment
|
v
GuardDuty
|
v
Security Findings
This architecture demonstrates an important cloud security concept:
Security is not provided by one service.
It is built from multiple layers.
10. Defense in Depth
A useful way to think about cloud security is defense in depth.
Instead of relying on one security control, we use multiple layers.
For example:
1
2
3
4
5
Layer 1 → IAM
Layer 2 → Network Security
Layer 3 → Application Security
Layer 4 → Logging
Layer 5 → Threat Detection
If one control fails, other controls can still provide protection or visibility.
For example, suppose an application vulnerability allows an attacker to compromise an application server.
If the server's IAM role has excessive permissions, the attacker may potentially gain access to additional AWS resources.
If the role follows least privilege, the potential impact can be reduced.
This is why permissions are part of application security, not just an administrative concern.
11. A Practical Security Scenario
Let's consider a simple example.
An EC2-hosted application has an IAM role that allows it to read data from a specific S3 bucket.
Its security group allows:
1
2
HTTPS → Application
SSH → Trusted administrator IP
CloudTrail is recording AWS API activity.
GuardDuty is enabled for the AWS environment.
The architecture looks like:
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
Internet
|
HTTPS
|
v
+---------------+
| Load Balancer |
+---------------+
|
v
+---------------+
| EC2 |
+---------------+
|
IAM Role
|
v
S3 Bucket
AWS API Activity
|
v
CloudTrail
|
v
Audit Records
Threat Detection
|
v
GuardDuty
|
v
Security Finding
Now imagine the application is compromised.
The attacker may attempt to access AWS resources through the application's permissions.
This is where least privilege becomes important.
If the IAM role only allows the required S3 actions on the required bucket, unnecessary access is not automatically available.
At the same time, CloudTrail provides visibility into API activity, while GuardDuty can help identify suspicious behavior.
12. Security Is Also About Configuration
Cloud security isn't only about installing security products.
Configuration decisions matter enormously.
For example:
Risky
1
2
3
SSH
Port 22
Source: 0.0.0.0/0
Better
1
2
3
SSH
Port 22
Source: Trusted administrator IP
Similarly:
Risky
1
2
3
4
5
6
7
Application
|
v
IAM
|
v
Administrator-level permissions
Better
1
2
3
4
5
6
7
Application
|
v
IAM Role
|
v
Only required permissions
Small configuration decisions can have a significant effect on the security posture of a cloud environment.
13. Security Does Not End After Deployment
A common misconception is:
1
2
3
Deploy application
↓
Security finished
In reality:
1
2
3
4
5
6
7
8
9
10
11
12
13
Deploy
↓
Monitor
↓
Detect
↓
Investigate
↓
Remediate
↓
Improve
↓
Repeat
Cloud environments change constantly.
New applications are deployed, permissions change, infrastructure is modified, and new vulnerabilities are discovered.
Security therefore needs to be treated as an ongoing process.
14. A Practical Learning Path
For someone learning AWS security, it is useful to understand the concepts in a logical order.
1
2
3
4
5
6
7
8
9
10
11
12
13
AWS IAM
↓
Least Privilege
↓
VPC + Security Groups
↓
CloudTrail
↓
GuardDuty
↓
Monitoring
↓
Incident Investigation
Once these concepts are comfortable, they can be applied to more complex architectures involving:
- Load balancers
- Auto Scaling
- Containers
- Amazon EKS
- Amazon RDS
- Amazon S3
- CI/CD pipelines
- Serverless applications
The goal isn't to memorize every AWS security service.
The goal is to understand where security controls belong and what problem each control solves.
Conclusion
AWS security is best understood as a combination of identity, network controls, logging, monitoring, and threat detection.
A basic secure architecture can be summarized as:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
USERS
|
v
Network Controls
|
v
APPLICATION
|
v
IAM Permissions
|
v
AWS RESOURCES
|
+--------+--------+
| |
v v
CloudTrail GuardDuty
| |
v v
Logging Threat Detection
The four concepts covered in this article provide a strong foundation:
IAM controls what identities can do.
Security Groups control network access.
CloudTrail provides visibility into AWS API activity.
GuardDuty helps detect potentially malicious activity.
Together, these controls demonstrate an important principle of cloud security:
Secure architecture is not about finding one perfect security service. It is about combining multiple controls so that prevention, visibility, detection, and response work together.
As cloud applications move from a single EC2 instance to containers, microservices, and Amazon EKS, these security fundamentals remain relevant. The architecture becomes more complex, but the underlying principles of least privilege, restricted network access, visibility, and continuous detection remain the same.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article