AWS provides a highly secure cloud platform, but that does not mean your environment is secure by default. As we explored in the AWS Responsibility Model article, security is a shared responsibility so you must do your part to ensure your resources are safe.
Most AWS security incidents do not involve advanced attackers or zero-day exploits. They happen because of basic mistakes, often made by people who are new to the cloud and still applying on-prem thinking to a very different environment.
This article walks through the top 10 AWS security mistakes beginners make, explains why they are risky, and shows how to avoid them.
1. Using the Root Account for Daily Work
Every AWS account has a root user with unlimited privileges. This is effectively "God Mode" and can do almost anything on your account. Beginners often use it because it’s easy.
Why It’s a Problem
- Root user has full control over the account
- If compromised, your entire account is at risk
How to Avoid It
- Ensure the root user uses a strong password
- Don't create access keys for the root user
- Enable MFA on the root user
- Create alternative access (IAM user or IAM role) for daily use
Note
It's recommended not using the root account unless absolutely necessary.
If you are experimenting with AWS, an IAM user will likely suffice for the time being. However, keep in mind that IAM users have long-term credentials such as passwords and access keys, which you should rotate regularly.
The best practice, however, is to create an use an IAM role for daily operations as roles provide temporary credentials by default.
2. Not Enabling Multi-Factor Authentication (MFA)
Passwords alone are not enough, especially in the cloud that can be accessed from anywhere in the world.
Why It’s a Problem
If credentials are leaked through phishing or reuse, attackers can log in immediately.
How to Avoid It
Adding MFA adds a second layer of defense that protects your account. Attackers would need to also get hold of the second authenticator factor to successfully log in.
Recommendations:
- Enable MFA for the root account
- Require MFA for privileged IAM users
3. Having public S3 buckets
S3 is one of the core services in AWS. It easily lets you store objects like files, images, videos, etc.
Why It’s a Problem
Public S3 buckets can expose:
- Customer data
- Backups
- Logs
- Intellectual property
- Source code
Many major data breaches started this way. If data should not be public, explicitly prevent it.
How to Avoid It
All new buckets are private by default, but a single misconfiguration can unintentionally expose their contents to the internet.
Recommendations:
- Review bucket policies carefully
- Implement alerts to notify you when a bucket goes public (AWS Config, CloudTrail, EventBridge services can help)
- Enable S3 Block Public Access at the account level or organization-level
Note
Having public S3 buckets is not inherently a security issue. There are valid use cases for public buckets. Just ensure the objects stored in them are truly intended to be public.
4. Overly permissive Security Groups
Security Groups are AWS’s primary network firewall, but beginners often configure them too loosely, or use the default ones because they "just work" at the cost of being highly permissive.
Why It’s a Problem
Overly permissive security groups are problematic because they significantly increase the attack surface of your environment.
When services like SSH, RDP, or databases are exposed to the internet, they become easy targets for automated scans, brute-force attacks, and exploitation attempts.
Even if the underlying application is secure, unnecessary exposure increases the likelihood of compromise.
For instance, a security group with a rule like:
SSH (22) from 0.0.0.0/0
allows SSH traffic from the entire internet.
How to Avoid It
- Review inbound and outbound rules regularly
- Restrict access to known IP ranges and expected ports/traffic
- Use AWS System Manager Session Manager instead of SSH where possible
- Monitor changes via AWS Config or a custom solution (i.e. EventBridge + Lambda)
5. Insufficient Password Policies
Weak or poorly enforced password policies are a common security gap in AWS environments, especially in accounts that were set up quickly or without security in mind.
By default, AWS allows basic password requirements unless you explicitly configure stronger rules, and many beginners never revisit these settings.
Why It's a Problem
Passwords are often the first, and sometimes only, line of defense protecting AWS accounts.
If password policies are too lenient, they become easy targets for brute-force attacks, credential stuffing, or simple guessing.
This risk is amplified when users reuse passwords across multiple services or fall for phishing attempts.
An attacker who successfully compromises a single IAM user with a weak password may gain access to sensitive resources, escalate privileges, or move laterally within the account.
How to Avoid It
- Enforce strong IAM password policies (length, complexity, rotation)
- Require multi-factor authentication (MFA) for all users, especially privileged ones
- Disable unused IAM users and credentials
Strong password policies are a basic control, but they remain one of the most effective ways to reduce account compromise, especially when combined with MFA.
Note
Prefer IAM roles over long-lived user passwords whenever possible.
6. Insecure Use of Access Keys
AWS access keys provide programmatic access to your account and services. While they are powerful, they are also easy to misuse.
Why It's a Problem
Access keys are long-lived credentials. If they are exposed through source code repositories, configuration files, logs, or shared scripts, an attacker can use them immediately, often without triggering obvious alarms.
Unlike passwords, access keys do not expire by default and are frequently forgotten after being created.
Once compromised, access keys can be used from anywhere in the world to interact with AWS APIs, potentially allowing attackers to read data, launch resources, or incur significant costs.
How to Avoid It
- Use IAM roles instead of access keys whenever possible
- Store secrets in AWS Secrets Manager or Parameter Store (Secure String)
- Rotate access keys regularly and delete unused ones
- Monitor access key usage with CloudTrail
Access keys should be treated like highly sensitive secrets. In most modern AWS environments, they should be the exception, not the default.
7. Overly Permissive IAM Policies
Beginners often use policies like AdministratorAccess or *:* just to make things work.
Why It’s a Problem
- Violates the principle of least privilege
- Increases blast radius if credentials are compromised
- Makes auditing difficult
How to Avoid It
- Start with minimal permissions
- Grant only what is required
- Use AWS-managed policies as learning references, not defaults
Convenience today becomes risk tomorrow.
8. Logging and Monitoring Gaps
If you don’t log activity, you won’t know when something goes wrong.
Why It’s a Problem
Without logs, you cannot:
- Detect suspicious behavior
- Investigate incidents
- Prove compliance
How to Avoid It
- Enable AWS CloudTrail
- In large organizations with multiple AWS accounts, configure an organization trail in CloudTrail
- Protect CloudTrail so that only the security team can change settings
- Send logs to a protected S3 bucket
- Monitor alerts using CloudWatch, Security Hub or a third-party solution
Visibility is a core security requirement, not an optional feature.
9. Insecure use and storage of Secrets and Access Keys
Hard-coding passwords and API keys is a common beginner shortcut. Similarly, secrets that never change are secrets that eventually get compromised.
One of the most common security oversights in AWS environments is creating credentials: passwords, access keys, or secrets, and then leaving them unchanged for months or even years.
Why It’s a Problem
- Credentials can leak via source control
- They are hard to rotate
- They are often shared unintentionally
How to Avoid It
- Use AWS Secrets Manager or Parameter Store for secrets
- Use IAM roles instead of access keys and IAM users
- Rotate credentials frequently.
10. No encryption of stored data
Failing to encrypt data at rest is a common security gap in AWS environments, particularly in early-stage or test accounts where security controls are often overlooked.
While AWS supports encryption for most storage services, it is not always enabled automatically or consistently across all resources.
Why It's a Problem
Unencrypted data is vulnerable if storage is accessed by unauthorized users, compromised credentials, or misconfigured permissions.
Without encryption, anyone who gains access to the underlying data can read it directly, including sensitive customer information, credentials, backups, or intellectual property.
Encryption adds a critical layer of protection by ensuring that even if data is accessed improperly, it cannot be read without the appropriate encryption keys.
How to Avoid It
- For S3 buckets, encryption at rest is enabled by default but consider using your own encryption key
- Enforce encryption in transit when interacting with S3 buckets
- Require encryption for EBS volumes and snapshots
- Use AWS Key Management Service (KMS) to manage encryption keys
- Enforce encryption using AWS Config rules or service control policies (SCPs)
Top comments (0)