blogs
AWS Security Fundamentals: IAM, VPC, and S3 Best Practices
A practical look at AWS IAM, VPC, and S3 fundamentals -- the cloud security controls that matter most, from my AWS Cloud Solutions Architect coursework.
AWS Security Fundamentals: IAM, VPC, and S3 Best Practices
Cloud security is not optional anymore — it's the dominant paradigm. Most organizations run significant workloads on AWS, and misconfigured cloud infrastructure is one of the most common causes of data breaches today. As part of my AWS Cloud Solutions Architect program, I spent focused time learning these fundamentals. Here's what actually matters.
IAM: The Foundation of AWS Security
Identity and Access Management (IAM) controls who can do what in your AWS environment. Getting IAM right is the single most impactful thing you can do for cloud security.
The Principle of Least Privilege — Every IAM entity should have only the permissions required for its specific function, nothing more.
// BAD — AdministratorAccess for an application
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
// GOOD — Specific permissions for a specific application
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-app-bucket/*"
}
Key IAM practices:
-
Never use root account credentials for day-to-day operations. Lock the root account with MFA and only use it for tasks that genuinely require root (like closing the account).
-
Use IAM Roles for EC2 instances instead of embedding access keys in application code. Roles provide temporary credentials automatically rotated by AWS.
-
Enable MFA for all human IAM users, especially those with privileged access.
-
Rotate access keys regularly and audit unused credentials with IAM Access Advisor.
-
Use IAM Permission Boundaries to limit the maximum permissions a role or user can be granted, even by an admin.
IAM Policy Conditions — Add conditions to make policies context-aware:
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2"]
}
}
}
This restricts EC2 operations to specific regions — useful for ensuring resources don't get created in unmonitored regions.
VPC: Network Isolation in the Cloud
A Virtual Private Cloud (VPC) is your private network segment in AWS. Properly configured, it provides strong network isolation between your resources and the public internet.
VPC Architecture Best Practices:
Separate subnets by function and exposure level:
- Public subnets: Resources that need direct internet access (load balancers, bastion hosts)
- Private subnets: Application servers, databases — no direct internet access
- Isolated subnets: Sensitive data stores with no internet route at all
Internet-facing resources should be in public subnets. Application logic in private subnets. Databases in isolated subnets. Traffic flows through the tiers; the database never talks directly to the internet.
Security Groups vs. Network ACLs:
Security Groups are stateful — if you allow inbound traffic on port 443, the return traffic is automatically allowed. Apply them to individual resources.
Network ACLs are stateless — you must explicitly allow both inbound and outbound. Apply them at the subnet level for an additional layer.
Security Group for Web Server:
Inbound: Port 443 from 0.0.0.0/0
Inbound: Port 22 from Bastion Host Security Group ID only
Security Group for Database:
Inbound: Port 3306 from Web Server Security Group ID only
No public inbound access
VPC Flow Logs — Enable Flow Logs for all VPCs. They capture metadata about network traffic (source/destination IPs, ports, accept/reject) and feed into CloudWatch or S3. This is essential for security investigation and anomaly detection.
S3: Common Misconfigurations and How to Prevent Them
S3 bucket misconfigurations have caused some of the largest data breaches in cloud history — healthcare records, financial data, government files exposed publicly because someone left ACLs set to public.
Block Public Access — the default for all buckets:
aws s3api put-public-access-block \
--bucket my-bucket \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Enable this at the account level too, so it applies to all current and future buckets:
aws s3control put-public-access-block \
--account-id YOUR_ACCOUNT_ID \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Enforce encryption at rest and in transit:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnencryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
},
{
"Sid": "DenyNonHTTPS",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
S3 Versioning and Object Lock — Enable versioning to protect against accidental deletion and ransomware attacks. Object Lock with WORM (Write Once Read Many) compliance mode prevents any deletion or modification, even by an admin.
AWS Security Services Worth Knowing
GuardDuty: Threat detection service that continuously monitors CloudTrail, VPC Flow Logs, and DNS logs for malicious activity. Uses machine learning to detect anomalies. Turn it on in every account and region.
Security Hub: Aggregates security findings from GuardDuty, Inspector, Macie, Config, and third-party tools into a single dashboard. Runs compliance checks against CIS AWS Foundations Benchmark automatically.
CloudTrail: Logs every AWS API call — who did what, from where, when. Essential for incident investigation and compliance. Enable in all regions, with log file validation (so logs can't be tampered with) and delivery to a dedicated, write-protected S3 bucket.
Macie: Automatically discovers and classifies sensitive data in S3 — PII, financial data, credentials. Invaluable for understanding your data exposure.
My Takeaway from the AWS Security Architect Program
Cloud security is fundamentally about reducing attack surface through configuration. Unlike on-premises security where you buy and install hardware controls, cloud security is largely policy-as-code. The tools are there; the defaults often aren't secure; you have to configure them intentionally.
The most important habit I developed: treat every cloud resource as temporary and disposable, but treat every security configuration as permanent and reviewed. Infrastructure drifts; security policies shouldn't.
I completed the AWS Cloud Solutions Architect program with emphasis on security topics including VPC architecture, IAM policy design, and encryption configuration.
