AWS Security Misconfigurations: Small Drift, Severe Blast Radius

Security incidents in AWS rarely stem from zero-day exploits against the hypervisor. In practice, they trace back to routine configuration drift: an IAM policy wildcard added at 2 AM to fix a broken deployment, a database spun up in a public subnet for staging, or a security group rule left open to 0.0.0.0/0.

AWS operates on a shared responsibility model. AWS secures the physical infrastructure, virtualization layer, and managed services. You own identity management, network boundaries, data protection, and operational hygiene.

That distinction is important. AWS can provide highly secure building blocks, but an incorrectly configured building block can still create a significant security gap.

The good news is that most of these issues are preventable.

1. 1. Excessive IAM Privileges & Wildcard Policies
      IAM is often the first place where convenience wins over security.
      The path of least resistance during development is attaching managed policies such as AdministratorAccess or writing policies containing:
      
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}

      This effectively breaks the Principle of Least Privilege (PoLP).The problem becomes much more serious when an application has excessive permissions. For example, an SSRF vulnerability could potentially allow an attacker to access temporary credentials from an instance metadata service. If those credentials have broad permissions, a relatively small application vulnerability can become a much larger AWS compromise.
      Antipattern: Excessive blast radius
      
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
Hardened approach
      
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::app-production-assets-2026/*"
}

      The second policy gives the workload only the permissions it actually needs.Practical controls
      • • Use targeted resource ARNs.
          Instead of allowing access to every S3 bucket, restrict permissions to the specific bucket, prefix, queue, table, or secret required by the application.
        • Use condition keys.
          Conditions such as aws:PrincipalOrgID, aws:RequestedRegion, source VPC endpoints, or encryption requirements can add another layer of control.
        • Use Permission Boundaries.
          Permission boundaries establish the maximum permissions an IAM principal can receive, even if someone attempts to attach a broader policy.
        • Use SCPs for organization-level guardrails.
          Service Control Policies can prevent member accounts from performing certain actions, regardless of permissions granted within the account.
        • Prefer IAM roles over long-lived access keys.
          For EC2, ECS, Lambda, and other AWS workloads, use IAM roles and temporary credentials wherever possible.

      The objective isn’t to eliminate administrative access completely. It is to control where administrative access exists and reduce the blast radius when credentials or workloads are compromised.

   2. Unrestricted Management Ports in Security Groups
      Security Groups are another common source of accidental exposure.Opening SSH or RDP directly to the internet makes infrastructure continuously reachable by external scanners and attackers.
      Antipattern
      
Type: SSH
Protocol: TCP
Port: 22
Source: 0.0.0.0/0

      Similarly:
      
Type: RDP
Protocol: TCP
Port: 3389
Source: 0.0.0.0/0

      This doesn’t automatically mean the server is compromised. However, it unnecessarily increases the attack surface and exposes authentication endpoints to brute-force attempts and credential attacks.Better approach: eliminate direct management ingress
      For supported workloads, use AWS Systems Manager Session Manager instead of exposing SSH or RDP.
      Conceptually:
      
Administrator
|
↓
SSM Session Manager
|
↓
Encrypted HTTPS / TCP 443
|
↓
EC2 Instance

      The instance doesn’t need an inbound SSH rule for Session Manager access.
      For instances in private or isolated subnets, VPC Interface Endpoints can provide private connectivity to the Systems Manager control plane, including endpoints such as:
      
ssm
ssmmessages
ec2messages

      If SSH/RDP is genuinely required
      Don’t automatically open it to the world. Restrict the source to a trusted network, VPN, bastion host, or specific administrative IP range:
      SSH / TCP / 22
      Source: 10.0.36.246/32
      A useful rule is:

      If an administrative port doesn’t need to be publicly reachable, don’t make it publicly reachable.

   3. Publicly Exposed Data Stores
      Data stores deserve particular attention because they often contain the information an attacker is ultimately trying to access.The most common mistake is treating “publicly accessible” as equivalent to “compromised.”It isn’t.A public database may still have strong authentication and restrictive security groups. However, making it publicly reachable increases the attack surface and creates additional opportunities for misconfiguration.Amazon S3
      S3 exposure can occur through:
      • Bucket policies
      • IAM policies
      • Access Control Lists
      • Account-level settings
      • Bucket-level settings
      • Cross-account permissions

      For buckets that should remain private, enable and regularly validate S3 Block Public Access at the appropriate account and bucket levels.

      But don’t stop at the S3 console’s public-access indicator.

      Think about the complete access path:
      
User / Workload
|
↓
IAM Policy
|
↓
Bucket Policy
|
↓
S3 Object

      A secure bucket requires the entire authorization chain to be intentional.

      Also consider whether sensitive data is encrypted using an appropriate mechanism such as SSE-KMS, and whether access logging and monitoring are configured according to the workload’s requirements.

      Amazon RDS
      Making an RDS database publicly accessible does not automatically mean the database has been compromised.

      It does, however, increase exposure.

      A typical production architecture should look more like:
      
Internet
|
↓
Load Balancer
|
↓
Application
|
↓
Private RDS

      The database Security Group should allow database traffic only from the application layer that requires it.
      For example:
      
Application SG
|
↓
TCP 5432
|
↓
RDS PostgreSQL

      rather than:
      
0.0.0.0/0
|
↓
TCP 5432
|
↓
RDS

      Network placement, Security Groups, authentication, encryption, and database configuration should all work together.

      Amazon OpenSearch
      OpenSearch domains also require careful network and access design.

      An unnecessarily internet-accessible domain increases the potential attack surface, particularly when combined with weak access policies or authentication controls.

      Where appropriate, place OpenSearch within a VPC and restrict access through Security Groups and identity-based controls.
      The general principle is simple:

      If a data store does not need to be publicly reachable, don’t expose it.

   4. Configuration Drift: The Silent Security Problem
      One of the biggest challenges in cloud security is that an environment can start secure and become insecure later.Consider this sequence:
      
Day 1
Secure configuration
↓
Day 30
Temporary firewall rule
↓
Day 60
New IAM permission
↓
Day 90
Unused access remains
↓
Day 180
Security exposure

      This is configuration drift.The dangerous part is that nothing necessarily “breaks.” Applications may continue working normally while security boundaries slowly deteriorate.How to control driftUse automated controls rather than relying exclusively on manual reviews.Useful AWS capabilities include:
      • AWS Config for tracking configuration changes and compliance
      • AWS Security Hub for centralized security findings
      • Amazon GuardDuty for threat detection
      • AWS CloudTrail for API activity and audit trails
      • AWS IAM Access Analyzer for identifying unintended access
      • Automated remediation through EventBridge/Lambda where appropriate

      For example, AWS Config can detect when a Security Group changes from:
      
TCP 22 → 10.0.0.0/8

      to:
      
TCP 22 → 0.0.0.0/0

      CloudTrail can then help answer the next question:

      Who or what made the change?

      That distinction is important. Configuration monitoring tells you what changed; audit logs can help determine who made the change and when.

   5. Don’t Confuse “Working” With “Secure”
      A common operational mistake is prioritizing availability over security without revisiting the temporary decision.For example:”The deployment was failing, so we temporarily gave the role s3:*.”
      Or:”The developer needed database access, so we temporarily made RDS public.”
      Or:”We opened port 22 for troubleshooting and will close it later.”
      The problem isn’t necessarily the emergency action.The problem is when the temporary exception becomes permanent infrastructure.

      Every temporary security exception should have:

      1. An owner
      2. A documented reason
      3. A defined expiration/review date
      4. Monitoring
      5. A plan to remove it

      This turns emergency access from an uncontrolled risk into a managed exception.

   Conclusion
   AWS security is not only about protecting against sophisticated attacks; it is equally about preventing everyday configuration mistakes from becoming security incidents. Excessive IAM permissions, unrestricted management ports, publicly accessible data stores, and configuration drift can significantly increase an organization’s attack surface and impact the potential blast radius of a compromise.

   A secure AWS environment requires a defense-in-depth approach: apply least-privilege access, restrict network exposure, keep sensitive workloads private, encrypt and protect data, and continuously monitor the environment for unexpected changes.

   Ultimately, security should be treated as an ongoing operational practice rather than a one-time configuration task. Regular reviews, automated monitoring, and timely remediation help ensure that AWS environments remain aligned with their intended security posture as infrastructure and applications evolve.