How exposed is your AWS infrastructure?

Your AWS infrastructure can be running perfectly… and be completely exposed.

AWS gives you extraordinarily powerful infrastructure. But the ultimate security of what runs there doesn't depend only on AWS: it depends on your configuration, your permissions, your identities, your applications, your networks, your secrets, your storage, your monitoring, your code and your operating processes. That's the ground where AWS security is won or lost.

AWS isn't necessarily "hacked". Very often the problem is that someone configured a door that should never have been left open.

An infrastructure can work correctly and be insecure

IT WORKS  ≠  IT'S SECURE

The server responds. The application works. Users log in. The database is available. Files get saved. Everything is green. And yet, in that same account, there may be:

• An open port nobody remembers why it exists
• A forgotten Access Key from a developer who's no longer around
• An S3 bucket with more access than it should have
• A user with administrator permissions who only needed to read a report
• A database that accepts connections from the Internet
• Secrets written directly in the code
• Zero logs and zero alerts: nobody would know if something already happened

A system's availability doesn't prove its security.

Where can they get in?

A modern AWS architecture isn't a server: it's a set of connected services — IAM, EC2, ECS, Lambda, API Gateway, ALB, CloudFront, S3, RDS, Aurora, DynamoDB, VPC, Secrets Manager, KMS… Every service is also a surface to review. The attacker's final destination is almost always the same: your data.

1. IAM: the first place you should review

One of the biggest risks in an AWS account isn't on a server: it's in who has permission to do what. Users, roles, policies, groups, old accounts, Access Keys, MFA, cross-account access. IAM security in AWS is the master lock for everything else.

An identity with excessive permissions can become a master key.

2. Access Keys: a credential can become a way in

Access Keys live longer than they should: in repositories, in .env files, in scripts, on servers, in CI/CD pipelines, on laptops, in logs, in backups. A long-lived credential that leaves your control is a direct way into the AWS API — with whatever permissions that identity has.

Code
  ↓
Exposed credential
  ↓
AWS API
  ↓
IAM
  ↓
AWS resources

The right direction: temporary credentials, IAM Roles instead of static keys, Secrets Manager, rotation, removal of credentials no longer in use, and monitoring of their activity.

3. S3: who can read your data?

S3 holds documents, backups, customer files, reports, logs and database exports — the company's information core. The risk comes from a public bucket, an overly generous bucket policy, excessive permissions, uncontrolled cross-account access or compromised credentials.

The problem isn't only where your data is. It's who can access it.

4. EC2 and exposed servers

Not everything should be reachable from the Internet. A 0.0.0.0/0 on SSH, on a database, on Redis, on an admin panel or on a management port means: anyone in the world can knock on that door. The right architecture puts layers between the Internet and your application — and keeps internal components on private networks.

5. RDS and Aurora: your database shouldn't be exposed

Publicly Accessible, open Security Groups, public subnets: the recipe for an enterprise database to receive direct connections from the Internet. Not every public exposure is automatically a vulnerability — but there must be an architectural justification and matching controls: private network, encryption, credentials in Secrets Manager, rotation and logging.

If an enterprise database can receive connections directly from the Internet, you have to ask why.

6. Security Groups: one rule can open too much

SSH         0.0.0.0/0
PostgreSQL  0.0.0.0/0
MySQL       0.0.0.0/0

Every rule should be able to explain why it exists: source, destination, port, service and real need. When the answer is "that's how it worked", the rule was designed by accident.

"It's working" doesn't mean "it's correctly exposed".

7. Secrets inside the code

API_KEY
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
DATABASE_PASSWORD
JWT_SECRET

Git repos, .env files, Docker images, logs, scripts, pipelines: all of them are places where secrets end up living — and multiplying. The right destination is AWS Secrets Manager or Parameter Store, IAM Roles where a credential isn't even needed, secure variables in CI/CD, and rotation.

8. CloudTrail: if you don't know who did what, you're practically blind

Security isn't only about blocking attacks. It's also about being able to reconstruct what happened.

Who modified this resource? When, from where, with which API? Was a user created? Was a policy changed? Was something deleted? If your organization can't answer those questions, it doesn't have visibility — it has faith. AWS CloudTrail, CloudWatch, AWS Config and Detective exist exactly for this.

9. GuardDuty and threat detection

Prevention + Detection + Response

Configuring Security Groups is prevention. But a mature security architecture also detects: GuardDuty analyzes account signals — API activity, network patterns, identity behavior — and raises its hand when something doesn't add up, without you having to build that detection yourself. Security Hub brings the findings together in one place you can prioritize.

10. Your application is also part of the attack surface

AWS can be correctly configured and your application can still be vulnerable.

Laravel, FastAPI, Node.js, your APIs, your dependencies, your containers, your CI/CD, your authentication and authorization, your admin endpoints: AWS protects none of that for you. Real security is the sum — AWS security, infrastructure security and application security. Assessing one without the others leaves gaps exactly where attackers look.

11. Containers and Kubernetes add another surface

Docker, ECR, ECS, EKS, Fargate: a modern cloud architecture also runs packaged software, with its images, its permissions, its secrets and its workloads. An old image with vulnerable dependencies or a task role with too many permissions is as much attack surface as an open port — just less visible.

What happens if someone gets access?

Depending on the existing permissions and controls, the impact can range from data theft to modification or deletion of data, service disruption, creation of unauthorized infrastructure, cryptomining and resource abuse — or the compromise of other connected accounts.

Cryptojacking: when someone uses your AWS for their own benefit

With access to an account, an attacker can spin up compute for workloads that aren't yours — mining included. The symptoms: unexpected CPU, new instances nobody asked for, rising consumption and an AWS bill that doesn't match your operation.

Ransomware and data destruction

Ransomware in the cloud isn't just encrypting servers: it's deleting, modifying, encrypting and — the real blow — destroying the backups with the same compromised credentials. The controls that change the outcome: backups with versioning and Object Lock, account separation, least privilege, MFA, logging and monitoring.

A backup that can be deleted with the same credentials that protect production isn't a sufficiently isolated recovery strategy.

AI is changing the speed of attacks

No sensationalism: automation and AI accelerate the analysis of large volumes of information, the identification of weak configurations and the generation of campaigns. What used to take weeks of manual work is automated today. The practical conclusion isn't fear — it's symmetry: defense needs automation too.

Telemetry → Context → Analysis → Detection → Prioritization → Response

How do you know how exposed your AWS is?

Identity

• MFA enabled on all human accounts
• Old users removed
• Unnecessary Access Keys removed
• IAM Roles used properly, with least privilege
• No unnecessary administrative permissions
• Controlled cross-account access

Network

• No administrative ports unnecessarily public
• Security Groups reviewed rule by rule
• Databases on private networks where appropriate
• VPC with proper segmentation

Data

• S3 reviewed and Block Public Access enabled
• Encryption at rest
• Versioning where appropriate
• Backups in place and protected

Applications

• Dependencies up to date
• Secrets out of the code
• Protected APIs, robust authentication and authorization
• Containers and images reviewed

Monitoring

• CloudTrail active with log retention
• GuardDuty and Security Hub enabled
• AWS Config and CloudWatch with alerts that someone actually receives

An AWS security audit should answer these questions

1. 1Who has access to our AWS account, and which users have administrative privileges?
2. 2Are there old credentials that are still active?
3. 3Which resources are exposed to the Internet — and which ones shouldn't be?
4. 4Do we have public databases or S3 buckets with excessive permissions?
5. 5Where are our secrets stored?
6. 6Can we tell who modified a resource, when and from where?
7. 7Do we have working threat detection — or only prevention?
8. 8Would our backups survive the credentials that protect production?
9. 9What would happen if a credential were compromised today?
10. 10Does our application have vulnerabilities the infrastructure can't cover?

It's not only about finding vulnerabilities

Discover → Analyze → Prioritize → Fix → Validate → Monitor

A list of 200 alerts without context protects nothing. The value lies in classifying each finding — critical, high, medium, low — by real impact, likelihood, exposure, ease of exploitation and business impact, and in tackling first what actually reduces risk.

What do we review in an AWS security assessment?

A secure architecture isn't the same for every company

There's no universal checklist. The right architecture depends on the type of company, its data, its regulation, the criticality of the operation, the users, the traffic, the budget and the tolerance for risk. That's why the assessment matters more than the recipe.

Security doesn't mean closing everything. It means allowing exactly what's needed and controlling the rest.

A conceptual case

A company — fictional, but the pattern repeats — had AWS working, the application working, the database working and backups running. During an assessment the following turned up: excessive IAM permissions, unnecessarily open Security Groups, old credentials still active, secrets stored where they shouldn't be, incomplete monitoring and resources without controls.

No incident had happened. That was precisely the best moment to fix it.

AWS can't protect what you configured incorrectly

The AWS shared responsibility model is simple to state and easy to forget: AWS secures the infrastructure of the cloud; you secure what you put in it. The exact boundaries depend on the service (Lambda isn't the same as EC2), but identities, permissions, data, configuration and applications are always on your side.

Is your AWS really protected?

You don't need to wait for an intrusion to discover your infrastructure had an open door. A security assessment lets you know what's exposed, which permissions are excessive, which controls are missing and what should be fixed first — with priorities, not an endless list.

Security isn't about waiting to detect an attack. It's about reducing the opportunities for one to happen.

WITS — Software · AI · Automation · Cybersecurity · AWS