AWS Security Hardening: IAM, S3 Bucket Security, and VPC Best Practices

Amazon Web Services (AWS) dominates enterprise cloud infrastructure, and with that dominance comes an outsized share of cloud security incidents. The majority of AWS security failures are not zero-day exploits or sophisticated attacks — they are misconfigurations that expose resources to the internet, over-permissioned identities that allow lateral movement, and monitoring gaps that allow attackers to operate undetected. This guide covers the highest-impact AWS hardening practices across the three control domains that appear most frequently in security assessments: IAM, S3, and VPC.

IAM: Least Privilege as Architecture, Not Aspiration

AWS Identity and Access Management (IAM) is the foundation of AWS security. Every access control decision in AWS routes through IAM, which makes IAM misconfiguration the single highest-impact security failure mode in cloud environments. The principle of least privilege — granting only the permissions required for a specific task — must be implemented as an architectural discipline, not a goal to eventually work toward.

Common IAM Misconfigurations

The most dangerous IAM misconfiguration is attaching the AdministratorAccess managed policy to production workload roles or to long-lived IAM users. AdministratorAccess grants *:* — literally all actions on all resources. A compromised IAM principal with AdministratorAccess can create new administrative users, export all secrets from Secrets Manager, exfiltrate all S3 data, spin up resources for cryptomining, and destroy the entire AWS account. Security assessments find AdministratorAccess in production workload configurations in roughly 35-40% of AWS environments assessed.

Other high-frequency IAM misconfigurations include:

• No MFA on root account: The AWS root account has irrevocable access to every resource in the account. Not enabling MFA on root is a critical finding. Root should also have no access keys — root access should require console login with hardware MFA.
• Long-lived access keys: IAM user access keys that are not rotated (commonly found keys with ages of 2-5+ years) represent a persistent credential exposure risk. Prefer IAM roles with temporary credential vending (STS) over long-lived access keys wherever possible. For programmatic access from compute, use instance profiles (EC2) or IRSA (EKS) — never embed access keys in application code or environment variables.
• No permission boundaries on customer-managed roles: Permission boundaries cap the maximum permissions a role can grant, preventing privilege escalation through role assumption chains. Without permission boundaries, a role with iam:CreateRole can create a role with higher privileges than itself — a common privilege escalation path.
• Wildcard resource scoping: Policies that grant actions like s3:GetObject on Resource: "*" instead of scoping to the specific bucket. Apply the most specific resource ARN possible for every policy statement.

AWS Organizations and Service Control Policies

For organizations with multiple AWS accounts, Service Control Policies (SCPs) in AWS Organizations provide guardrails that apply even to account root users. SCPs are the most powerful preventive control in AWS: a deny in an SCP cannot be overridden by any IAM policy within the account. Effective SCP patterns include: denying root user actions outside break-glass scenarios, restricting to specific approved AWS regions, denying creation of internet gateways without explicit approval, and requiring encryption on all EBS volumes and S3 buckets.

S3: Eliminating Public Exposure and Protecting Data

S3 data exposure — buckets inadvertently made public, or accessible to overly broad IAM principals — has been the source of more high-profile data breach incidents than any other AWS service. The controls required to prevent this are well-understood and available at no additional cost:

S3 Block Public Access

S3 Block Public Access settings should be enabled at the account level (not just per-bucket) unless there is a specific documented business requirement for public S3 content. Account-level Block Public Access prevents any new policy or ACL from making buckets or objects public, regardless of who creates them. This single control eliminates an enormous class of accidental exposure incidents. Assess your existing buckets using AWS Trusted Advisor or AWS Config rule s3-bucket-public-read-prohibited.

S3 ACLs and Bucket Ownership

AWS now recommends disabling S3 ACLs entirely (using the BucketOwnerEnforced object ownership setting) for new workloads. ACLs are a legacy access control mechanism that operates separately from bucket policies and IAM policies, creating confusion and potential gaps. With ACLs disabled, object ownership is always with the bucket owner and access is controlled exclusively through bucket policies and IAM — a simpler, more auditable model.

S3 Security Configurations Checklist

• Enable S3 server-side encryption by default (SSE-S3 minimum; SSE-KMS for sensitive data requiring key management visibility)
• Enable S3 Object Lock (WORM) for compliance-sensitive data and backup buckets to prevent ransomware deletion
• Enable S3 access logging and deliver logs to a centralized, immutable security logging bucket
• Use S3 VPC Endpoints to keep S3 traffic on the AWS network rather than traversing the internet
• Implement bucket policies that explicitly deny s3:DeleteObject and s3:PutBucketPolicy for non-administrative roles
• Enable S3 Event Notifications to CloudTrail for all data access events on sensitive buckets

VPC Architecture and Network Security

AWS Virtual Private Cloud (VPC) architecture decisions made during initial deployment are difficult to change later — getting the network architecture right matters. Key principles:

Subnet Segmentation

Maintain strict separation between public subnets (resources that need to be internet-accessible, such as load balancers), private application subnets (compute, containers), and private data subnets (RDS, ElastiCache, Redshift). Never place database instances in public subnets. This sounds obvious but appears in security assessments more often than it should — typically in environments that started as quick prototypes and were never properly architected.

Security Groups vs. NACLs

Security Groups (stateful, at the instance/ENI level) are your primary network control. Define security groups by function and restrict sources to specific security group IDs rather than CIDR ranges wherever possible — this creates a more maintainable security posture that scales with the environment. Network ACLs (stateless, at the subnet level) provide a backstop defense layer: use them to deny known-bad CIDR ranges and to enforce baseline restrictions that apply to all resources in a subnet regardless of security group configuration.

VPC Flow Logs

Enable VPC Flow Logs for all VPCs and deliver them to CloudWatch Logs and/or S3 for retention. Flow logs capture source/destination IP, port, protocol, bytes, and accept/reject decisions for all network traffic traversing ENIs. They are essential for incident response (reconstructing attack paths) and threat hunting (detecting port scanning, unexpected communication paths, data exfiltration volumes). The cost is justified by the investigation capability they provide.

AWS Security Services Integration

AWS provides several native security services that should be enabled in every production account:

• Amazon GuardDuty: Threat detection service analyzing CloudTrail, VPC Flow Logs, and DNS logs for known malicious patterns. Enable in every region, every account. GuardDuty findings for credential exfiltration, instance compromise, and unusual API activity are high-fidelity and actionable. Cost is typically $1-5/month for small accounts and scales with data volume.
• AWS Security Hub: Aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and third-party tools. Provides a unified security posture view and maps findings to CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices standards.
• AWS CloudTrail: Log all management API calls across all regions to an immutable S3 bucket with CloudTrail log file integrity validation enabled. CloudTrail is the forensic record of everything that happened in your AWS account — without it, incident response is severely hampered.
• Amazon Inspector: Automated vulnerability assessment for EC2 instances and Lambda functions. Continuously monitors for OS-level CVEs and network reachability issues without requiring agent deployment on modern instances.

AWS security hardening is a core component of our cloud security assessment service. Our assessments identify IAM privilege escalation paths, S3 exposure risks, VPC architecture weaknesses, and gaps in security service coverage. For organizations seeking ongoing cloud security management, our managed infrastructure service includes AWS security monitoring and hardening. Contact us to schedule a cloud security assessment.