This article is based on reporting originally published by cloudcomputing-news.net and has been expanded with additional technical context for a DevOps engineering audience.
Why AWS Data Protection Matters
A high-profile data breach involving a misconfigured Amazon S3 bucket—in which the personal details of a large portion of the US adult population were left publicly accessible for two weeks—is a stark reminder of how easily cloud storage can be exposed. In that incident, media analytics company Deep Root Analytics failed to apply access controls to an S3 bucket, leaving it readable by anyone who could locate or guess the bucket’s subdomain name. No sophisticated exploit was required: a simple configuration oversight was enough.
That case is far from unique. Misconfigured S3 buckets, over-privileged IAM roles, and unused accounts with standing credentials represent a consistently large share of real-world AWS security incidents. The lesson is straightforward: AWS provides a powerful, flexible platform, but the security of what you put inside that platform is your responsibility.
Understanding the AWS Shared Responsibility Model
AWS operates under a shared responsibility model. AWS itself is responsible for securing the underlying infrastructure—physical data centers, hardware, hypervisors, and the managed services built on top of them. AWS handles intrusion detection at the infrastructure layer and ensures the durability and availability of its storage, compute, and networking primitives.
However, customers are responsible for everything they deploy and configure within AWS. This includes:
- Identity and Access Management (IAM) policies and roles
- Network access controls, security groups, and firewall rules
- Data encryption at rest and in transit
- S3 bucket policies and public-access settings
- Operating system patching on EC2 instances
- Application-level security for custom workloads
- Audit logging and monitoring configuration
Organisations also need to account for insider risk. A significant share of security incidents involve employees—whether acting maliciously, negligently, or falling victim to phishing. Third-party vendors and business partners with access to your AWS environment add further exposure. These risks cannot be delegated to AWS; they must be managed through good configuration hygiene and tight access controls.
10 Concrete Steps to Protect Your AWS Environment
The following practices are not exhaustive, but they address the most common and highest-impact gaps in AWS security posture. Implementing all ten will give your organisation a solid baseline.
1. Enable AWS CloudTrail in Every Region
CloudTrail records API calls and management events across your AWS account, creating an immutable audit trail. Enable it on every AWS service you use, including global and non-geographic services such as CloudFront and IAM. Critically, turn on multi-region logging: if an attacker spins up resources in a region you do not normally use, multi-region CloudTrail will capture that activity. Without it, those events go unrecorded.
2. Enable MFA on the Root Account—and Use a Dedicated Device
The root account has unrestricted access to every AWS resource in your account. Enabling multi-factor authentication (MFA) on this account is non-negotiable. Use a dedicated hardware MFA token or a dedicated virtual device rather than routing codes to a personal mobile phone. A lost or reassigned personal device could otherwise become an entry point during staff turnover.
3. Enforce a Strong Password Policy
Configure IAM’s account password policy to require:
- A minimum of 14 characters
- At least one uppercase letter, one lowercase letter, one number, and one symbol
- Password expiry after no more than 90 days
- Prevention of password reuse
Weak or reused passwords remain one of the most common vectors for account compromise.
4. Restrict Access to CloudTrail Logs
Keep the list of IAM principals who can read or modify CloudTrail configuration as small as possible. If an attacker (or a phished insider) can alter logging settings, they can erase evidence of their own activity. Limit access to CloudTrail buckets and configuration to a dedicated security or operations role, not a broad admin group.
5. Require MFA to Delete CloudTrail S3 Buckets
Apply an S3 bucket policy with an aws:MultiFactorAuthPresent condition to the bucket that stores CloudTrail logs. This means that even a compromised credential cannot silently delete your audit trail—a common attacker technique to cover tracks after gaining access. Without the MFA token, the delete operation will be denied by the bucket policy.
6. Never Create Access Keys on the Root Account
Root account access keys grant programmatic access with full administrative privileges and no resource-level restrictions. If such a key is leaked—in source code, a CI/CD configuration file, or a public repository—an attacker gains complete control of your account. Delete any existing root access keys and use IAM users or roles with least-privilege policies instead.
7. Restrict Ingress on Commonly Abused Ports
Review your EC2 and VPC security groups and close any ports that do not need to be publicly reachable. Ports frequently targeted in opportunistic scans include:
- CIFS (445) — targeted by ransomware and lateral movement
- DNS (53) — if not intentionally public-facing
- FTP (20/21) — prefer SFTP or S3 for file transfers
- MongoDB (27017) — frequently found exposed with no authentication
- MSSQL (1433) — should never be publicly accessible
- SMTP (25) — unless you operate a mail server
Adopt a default-deny posture: open only what is explicitly required.
8. Automatically Expire Inactive IAM Accounts
Dormant IAM users—accounts belonging to former employees, contractors, or service integrations that are no longer active—represent standing risk with no operational benefit. Establish a process (or an automated Config rule) to identify accounts that have not been used for 90 days and disable or delete them. AWS IAM Access Analyzer and AWS Config’s iam-user-unused-credentials-check managed rule can help automate this detection.
9. Enable Access Logging for S3 Buckets
S3 server access logging records detailed information about every request made to a bucket, including the requester, the object accessed, and the operation performed. Pair this with CloudTrail data events for S3 to get full visibility into both management-plane and data-plane activity. In the event of a breach or a suspected data exfiltration, these logs are essential for investigation and regulatory reporting.
10. Use IAM Roles—Not Static Credentials—in EC2 Security Groups
Assign IAM instance profiles and roles to EC2 instances rather than embedding long-lived access keys in configuration files or environment variables. Roles issue temporary, automatically rotated credentials via the instance metadata service. This eliminates the risk of static keys being leaked in logs, AMI snapshots, or source repositories. Combine this with tightly scoped security group rules to block unsophisticated but damaging attacks such as brute-force attempts and denial-of-service from known malicious IP ranges.
Beyond the Checklist: Ongoing Security Hygiene
The ten controls above establish a strong baseline, but AWS security is not a one-time exercise. Consider the following additional practices as your environment matures:
- Enable AWS Security Hub to aggregate findings from GuardDuty, Inspector, Macie, and Config into a single dashboard.
- Use AWS Config rules to continuously evaluate your resource configurations against your security policy and alert on drift.
- Block public access at the account level for S3 using the S3 Block Public Access feature, which overrides any bucket-level or object-level ACL that would make data public.
- Encrypt sensitive data at rest using AWS KMS-managed keys and enforce encryption in transit via TLS for all API calls and application connections.
- Conduct regular access reviews using IAM Access Advisor to identify and remove permissions that have not been exercised.
Summary
AWS provides a secure, well-engineered cloud platform, but the shared responsibility model means that a significant portion of your security posture depends entirely on how your team configures and manages resources. Simple errors—an S3 bucket left public, a root access key never rotated, an unused account never deactivated—are the most common root causes of cloud data breaches. The ten controls described here are achievable, well-documented, and form the foundation of a defensible AWS security programme.