AWS Cloud Security Explained: What’s Left Exposed?

Using AWS? You might assume security is handled for you - but that’s a dangerous misconception. While AWS secures its own infrastructure, what happens inside your cloud environment is up to you.

Think of your AWS security like a secure building: AWS provides the sturdy walls and roof, but you’re in charge of the locks, the alarm system, and making sure no one leaves valuables lying around.

In this blog, we highlight what AWS doesn’t secure with real-world examples and share key actions to help you keep your AWS environment safe.

Understanding the AWS Shared Responsibility Model

AWS operates on a Shared Responsibility Model, meaning that both AWS and its customers have distinct responsibilities.

AWS secures the underlying infrastructure that powers its cloud services - including hardware, some software, networking, and data centers - essentially providing the “walls and roof”. Meanwhile, customers are responsible for securing their data, applications, and configurations within the AWS environment - the “locks on the doors” and the “alarm system”.

In short, AWS handles the security of the cloud, while customers are responsible for security in the cloud. Understanding this distinction is key to maintaining a secure cloud environment.

Impactful AWS Vulnerabilities You Are Responsible For

Let’s look at some real-world vulnerabilities that fall under your responsibility and what you can do to mitigate them.

The following examples focus on two key areas from the AWS Shared Responsibility Model:

• Platform, Applications, and Identity and Access Management
• Operating System, Network, and Firewall Configuration

Platform, Applications, Identity and Access Management

SSRF and the AWS Metadata Service

As an AWS customer, you’re responsible for securing vulnerabilities in your applications deployed in the cloud - including application-layer issues like Server-Side Request Forgery (SSRF).

SSRF vulnerabilities allow an attacker to manipulate a server into making unintended requests, which can lead to unauthorized data access or further exploitation.

SSRF can be particularly dangerous in cloud environments because the metadata service assumes that any request it receives is legitimate. If an attacker exploits an SSRF vulnerability, they could trick the server into exposing highly sensitive data, like IAM credentials, which could provide an initial foothold into your cloud environment. 

Defending against this weakness requires a twofold approach:

1. Secure your applications - Identify and fix any SSRF vulnerabilities using a web application vulnerability scanner.
2. Enable AWS IMDSv2 - This improved metadata service mitigates SSRF attacks, adding a defense-in-depth layer even if your application is vulnerable. AWS provides this safeguard, but it’s your responsibility to configure it properly!

Access Control Weaknesses

Identity and Access Management (IAM) in AWS allows you to control which users and services can access specific resources. While you can restrict access to authorized users within your organization, AWS also enables you to grant access to external accounts or even make resources public.

Managing access is your responsibility - only your organization understands which data should be public (e.g. website media files) and which should remain private (e.g. server backups containing customer data).

Historically, S3 buckets have been a prime target for misconfiguration because it was all too easy to accidentally make them public. These days, AWS has made it harder - you might’ve noticed warnings all over the interface to try to prevent it - but it’s still possible to expose your bucket-stored data with a single misstep. Making sure this doesn’t happen sits within your part of the responsibility model.

Misconfigurations and Data Exposures

You are responsible for the data stored in AWS and the security of the applications that access it. For example, if your application connects to an AWS Relational Database Service (RDS), you’re responsible for making sure that application doesn’t expose sensitive data to attackers.

While AWS does help secure your RDS data store - such as automatic patch updates - they have no control over the way you’re using that data and can’t be responsible for its security in totality. 

Take a multi-tenant SaaS application using RDS as an example. You are responsible for securing the application and ensuring attackers can’t access other users’ data. Authentication and authorization fall under your responsibility model, and a simple IDOR (Insecure Direct Object Reference) vulnerability is all it takes for an attacker with a user account to download sensitive data belonging to all other users.

Operating System, Network and Firewall Configuration

Patch Management 

It almost goes without saying, but AWS does not patch your servers for you. If you deploy EC2 instances, both the operating system (OS) and any software the server is running will develop vulnerabilities over time. AWS handles patching the firmware and updating the hardware that your EC2 is running on, but the OS and software layers are your responsibility.

For example, if you deploy an Ubuntu 24.04 LTS EC2 instance running Redis, you are responsible for patching vulnerabilities in the OS (Ubuntu) and in the software (Redis). In this case, agent-based vulnerability scanning would help you find these issues. AWS, on the other hand, is only responsible for issues affecting the underlying hardware, such as Spectre. 

AWS provides services that reduce the need for some patch management, like Lambda, but even these require your attention occasionally to ensure they are using a supported runtime with the latest patches. Unfortunately, there’s no way to completely escape this responsibility, and it’s an important one!

Firewalls and Attack Surface

AWS gives you control over your attack surface but isn’t responsible for what you choose to expose. You can make services publicly accessible or protect them within private cloud networks - the choice, and the risk, are yours.

For example, if you deploy a GitLab server inside your AWS account, it’s your responsibility to secure it. This means layering it behind a VPN, using a firewall to block access from arbitrary hosts, or placing it inside a VPC while ensuring your team has a secure way to access it. If a new zero-day vulnerability in GitLab drops tomorrow and your server is publicly exposed, you’ll quickly regret leaving it on the internet - and AWS won’t be to blame.

AWS Security: The Key Takeaway

These examples cover just a fraction of the security risks in AWS, but they make an important point: cloud security isn’t "done for you". While AWS provides a solid foundation, securing your environment is still your responsibility. Overlooking these gaps can leave your organization exposed - fortunately, we know just the tool to help you close them...

Level Up Your AWS Security With Intruder

Intruder helps you stay ahead of all these vulnerabilities and more, by combining agentless cloud security scanning, vulnerability scanning, and attack surface management in one powerful, easy-to-use platform.

Why it’s a game changer:

• Find what others miss: Intruder combines external vulnerability scanning with information from AWS accounts to find risks that other solutions might miss.
• No false alarms: CSPM tools can overhype severity. Intruder prioritizes real risks so you can focus on what truly matters.
• Crystal clear fixes: Issues are explained in plain English with step-by-step remediation guidance.
• Continuous protection: Stay ahead with continuous monitoring and alerts when new risks emerge.‍
• Predictable pricing: Unlike other cloud security tools that can rack up unpredictable costs, there’s no surprise charges with Intruder. Cloud Security is included with Pro and Premium at NO extra cost.

Get set up in minutes and receive instant insights into your cloud security - start your 14 day free trial today.