AWS Security: Your Responsibility Starts at the Account Level
The AWS shared responsibility model is clear: AWS secures the infrastructure. You secure your configuration, your data, and your access controls. Most AWS security incidents are not caused by AWS vulnerabilities — they are caused by misconfigured IAM policies, publicly accessible S3 buckets, unencrypted data stores, and monitoring that was never set up.
Here are the 10 security controls we implement on every AWS workload, in priority order.
1. Enable MFA on Every IAM User — Especially Root
The AWS root account has unrestricted access to everything. It should have a hardware MFA device attached, its access keys should be deleted (not just disabled), and it should be used only for the specific actions that require it — which are very few.
Every IAM user with console access should have MFA enforced via an IAM policy that denies all actions unless MFA is present.
2. Migrate to IAM Identity Center (SSO)
Long-lived IAM user credentials are a security liability. IAM Identity Center provides temporary, role-based access to AWS accounts through your existing identity provider (Okta, Azure AD, Google Workspace). Engineers get time-limited credentials. No more shared access keys. No more "who has access to what" ambiguity.
3. Apply Least Privilege to Every IAM Role
The wildcard IAM policy (*) is the single most common misconfiguration we find in AWS accounts. Every IAM role should have the minimum permissions needed to perform its specific function — nothing more.
Use IAM Access Analyzer to identify overly permissive policies. Use Service Control Policies (SCPs) in AWS Organizations to enforce guardrails at the account level — for example, blocking the creation of public S3 buckets or the disabling of GuardDuty.
4. Never Store Credentials in Code or Environment Variables
Use AWS Secrets Manager for application secrets and API keys. Use IAM roles for service-to-service authentication — Lambda to DynamoDB, ECS to RDS, EC2 to S3. Instance metadata service v2 (IMDSv2) should be enforced on all EC2 instances to prevent SSRF-based credential theft.
5. Encrypt Everything
S3 server-side encryption (SSE-KMS), EBS encryption, RDS encryption, Secrets Manager encryption — all using AWS KMS with customer-managed keys (CMKs) for workloads with compliance requirements. Enforce encryption via SCPs and AWS Config rules. There is no performance penalty for encryption in 2024.
6. Network Segmentation with VPC and Security Groups
Private subnets for application and data tiers. Public subnets only for load balancers and NAT Gateways. Security groups following least-privilege: allow only the specific ports and sources needed. No 0.0.0.0/0 ingress rules except for the load balancer on ports 80 and 443.
VPC Flow Logs enabled and shipped to CloudWatch or S3 for network-level visibility.
7. Enable GuardDuty in Every Account and Region
Amazon GuardDuty is threat detection as a service. It analyses CloudTrail, VPC Flow Logs, and DNS logs for indicators of compromise — credential compromise, cryptomining, command-and-control traffic, unusual API calls. It costs approximately $1-3/month per account at low data volumes. There is no excuse not to have it enabled.
Configure GuardDuty findings to route through Security Hub for centralised review and to trigger SNS notifications for HIGH and CRITICAL severity findings.
8. Enable AWS Security Hub
Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and Firewall Manager into a single dashboard. Enable the CIS AWS Foundations Benchmark standard — it provides 43 automated checks that cover the most common misconfigurations. Assign a target score and track it over time.
9. CloudTrail in Every Account and Region — Permanently
CloudTrail logs every API call made to your AWS account. It is your audit trail for security incidents, compliance requirements, and operational troubleshooting. Enable CloudTrail with log file integrity validation, encrypted S3 storage, and retention of at least 1 year. Enable multi-region trails in the management account to capture global service events.
10. Define and Test an Incident Response Runbook
Detection is only valuable if it triggers a response. Define a runbook for the most likely incident types: compromised IAM credential, GuardDuty HIGH finding, public S3 bucket exposure, unusual spend spike. The runbook should specify: who gets notified, what the isolation procedure is, who has authority to take production actions, and how the incident is documented.
Test it. Run a tabletop exercise. Identify the gaps before an incident does.
Start Here
If you are not confident that all 10 of these controls are in place across your AWS accounts, a security baseline review is the highest-ROI investment you can make. The cost of a misconfiguration incident — data breach, regulatory fine, customer notification — dwarfs the cost of prevention by orders of magnitude.
Contact GenClouds for a structured AWS security assessment aligned to the CIS AWS Foundations Benchmark.