If you’re using AWS, it’s easy to assume your cloud security is handled – but that’s a dangerous misconception. AWS secures its own infrastructure, but security within a cloud environment remains the customer’s responsibility.
Think of AWS security like protecting a building: AWS provides strong walls and a solid roof, but it’s up to the customer to handle the locks, install the alarm systems, and ensure valuables aren’t left exposed.
In this blog, we’ll clarify what AWS doesn’t secure, highlight real-world vulnerabilities, and how cloud security scanners like Intruder can help.
AWS operates on a Shared Responsibility Model. In simple terms:
Understanding this distinction is essential for maintaining a secure AWS environment.
Let’s look at some real-world vulnerabilities that fall under the customer’s responsibility and what can be done to mitigate them.
Applications hosted in AWS are still vulnerable to attacks like SSRF, where attackers trick a server into making requests on their behalf. These attacks can result in unauthorized data access and further exploitation.
To defend against SSRF:
AWS Identify and Access Management (IAM) allows customers to manage who can access what resources – but it’s only as strong as its implementation. Customers are responsible for ensuring users and systems only have access to the resources they truly need.
Common missteps include:
AWS customers are responsible for the security of the data they store in the cloud – and for how their applications access that data.
For example, if your application connects to an AWS Relational Database Service (RDS), the customer must ensure that the application doesn’t expose sensitive data to attackers. A simple vulnerability like an Insecure Direct Object Reference (IDOR) is all it would take for an attacker with a user account to access data belonging to all other users.
It almost goes without saying, but AWS does not patch servers! Customers who deploy EC2 instances are fully responsible for keeping the operating system (OS) and software up to date.
Take Redis deployed on Ubuntu 24.04 as an example – the customer is responsible for patching vulnerabilities in both the software (Redis) and the OS (Ubuntu). AWS only manages underlying hardware vulnerabilities, like firmware issues.
AWS services like Lambda reduce some patching responsibilities, but you’re still responsible for using supported runtimes and keeping things up to date.
AWS gives customers control over their attack surface, but isn’t responsible for what they choose to expose.
For instance, if a GitLab server is deployed on AWS, the customer is responsible for layering it behind a VPN, using a firewall, or placing it inside a Virtual Private Cloud (VPC) while ensuring their team has a secure way to access it. Otherwise, a zero-day vulnerability could leave your data compromised, and AWS won’t be at fault.
These examples make one thing clear: cloud security doesn’t come out of the box. While AWS secures the underlying infrastructure, everything built on top of it is the customer’s responsibility. Overlooking that fact can expose an organization to serious risk – but with the right tools, staying secure is entirely within reach.
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:
Get set up in minutes and receive instant insights into your cloud security – start your 14 day free trial today.
