AWS Security Basics

Reviewed by [Compliance Expert Name], [Certification]

AWS operates under a shared responsibility model: AWS secures the cloud infrastructure (data centers, power, cooling, network backbone, hypervisor isolation), and you secure everything running on top of it—your data, applications, operating systems, access controls, and network configuration. The default AWS configuration is not secure. Enable IAM with least privilege, configure security groups restrictively, keep S3 buckets private, encrypt data at rest and in transit, and enable CloudTrail and CloudWatch logging from day one.

Understanding the Shared Responsibility Model in AWS

AWS secures the cloud infrastructure while you secure what you build inside it. You own the operating system, access controls, and network configuration for every resource. AWS breaches happen because organizations believe AWS handles security that actually falls to them—a public S3 bucket, an unpatched EC2 instance, or an overly permissive security group are your responsibility, not AWS's.

The shared responsibility line means you are responsible for everything from the operating system upward and for all access control at every layer. Understanding this boundary is necessary but not sufficient. You have to actually execute on your responsibility. Too many organizations understand the shared responsibility model but fail at execution. They know they should patch systems and don't. They know they should control access and leave it permissive. They know they should encrypt data and leave it unencrypted.

Identity and Access Management: The Foundation

IAM controls who can do what in your AWS account. Every user, service, and application has an identity with permissions. The foundational principle is least privilege: users and services get only the minimum permissions needed for their job. Start with deny-all, explicitly allow only what's needed, review and refine over time.

IAM supports role-based access control, resource-based policies, and conditional access based on time of day or IP address. In practice, least privilege fails because permissions are granular and it's easier to grant broad permissions than specific ones. A developer who should only create test resources gets general permission that allows creating production resources. Service accounts used by automated systems end up overprivileged.

For applications and services running in AWS, use IAM roles instead of embedded credentials. An application using an IAM role limits attacker access if the instance is compromised—no permanent credentials to steal. IAM also supports federation so you can use your own identity provider instead of creating separate AWS accounts.

EC2 Virtual Machines: Operating System Security Is Your Job

EC2 security from the operating system upward is entirely your responsibility. You choose the OS image, patch it, configure it, and secure it. EC2 breaches happen on unpatched servers that are publicly accessible—an attacker scans the internet, finds a publicly accessible server with a known vulnerability, exploits it, and gains access. This is completely preventable through patching and network configuration.

EC2 instances should not be directly exposed to the internet unless absolutely necessary. Put web servers behind load balancers or bastion hosts. Enable detailed monitoring. Use IAM roles, not access keys, for applications running on EC2. Enable encrypted volumes for data at rest and TLS encryption for data in transit. The common mistake is creating an EC2 instance, leaving it with default security, and thinking that being in AWS makes it secure. AWS provides the infrastructure. You provide the security.

S3 Storage: Simplicity and Misconfiguration

S3 is one of the most commonly misconfigured AWS services. S3 buckets are private by default, but if you explicitly allow public access or use incorrect bucket policies, they become readable by anyone on the internet. [STAT NEEDED: number of S3 bucket exposure incidents reported annually]

S3 security basics: keep buckets private by default, use bucket policies to explicitly grant access, enable versioning to protect against accidental deletion, enable encryption to protect data at rest, enable logging to track access. Many of these are not enabled by default. Access control should use IAM roles and policies, not hardcoded access keys. For temporary access, use presigned URLs that grant time-limited access. AWS provides tools to identify public buckets and overly permissive access, but tools don't fix problems automatically. You have to use them, identify issues, and remediate.

Networking and Security Groups: Restrictive Is Better

Security groups are stateful firewalls that control traffic entering and exiting instances. The default is deny-all inbound (good) and allow-all outbound (sometimes risky). Common mistakes include allowing access from 0.0.0.0/0 (anywhere) when you should restrict to specific IPs, or creating testing rules that are never removed.

Security groups must be as restrictive as possible. Only allow traffic that's actually needed. Overly permissive security groups are a security gap that goes unnoticed until a breach happens. Network Access Control Lists (NACLs) provide additional network-layer control at the subnet level. Configure both security groups and NACLs for defense in depth.

Encryption: Protecting Data at Rest and in Transit

AWS provides multiple encryption options. Data at rest is encrypted with AWS Key Management Service (KMS) keys or customer-managed keys. Data in transit uses TLS encryption. AWS-managed encryption is convenient—AWS handles the keys—but means AWS holds the encryption keys. Customer-managed encryption gives you control over the keys if compliance requirements demand it.

Encryption should be the default for databases, storage, and backups. Encryption has minimal performance impact and should be ubiquitous. Unencrypted backups or databases are security gaps.

Logging and Monitoring: Visibility Through CloudTrail and CloudWatch

CloudTrail logs all API calls and administrative activity in your AWS account. This is crucial for compliance and forensics. CloudTrail is not enabled for all services by default—you have to configure it. Once enabled, you have a record of what happened: who did what, when they did it, and from where.

CloudWatch monitors operational data—CPU usage, disk usage, application logs—and triggers alarms based on thresholds. Most organizations collect these logs but don't act on them. Generating logs without acting on them is just creating storage costs. Set up meaningful alerts and review them. If you're being breached, CloudWatch and CloudTrail are how you'll know.

Common AWS Misconfigurations and Prevention

The most common AWS security failures are predictable and almost entirely preventable: IAM policies that are overly permissive, security groups that allow all inbound access, S3 buckets that are publicly readable, EC2 instances running unpatched operating systems, and logging not being configured or monitored. These aren't sophisticated attacks—they're basic misconfiguration.

Use least privilege from day one. Use AWS Config or third-party tools to identify misconfiguration automatically. AWS Security Hub aggregates security findings from various AWS services and shows you a consolidated view of your security posture.

Putting Security Into the Architecture

AWS security fundamentals are straightforward: enable IAM with least privilege, configure security groups restrictively, keep S3 buckets private, harden EC2 instances, enable encryption, and enable logging and monitoring. They require intentional configuration. When designing your AWS architecture, allocate time for security design and configuration.

Organizations with secure AWS environments thought about security during design. Organizations with breached AWS environments did the minimum to get something running and assumed the rest would be fine. Security is not automatic in AWS. It's something you build intentionally, understand the gaps in, and execute on.

Frequently Asked Questions

What is the shared responsibility model in AWS?

AWS manages security of the cloud infrastructure including data centers, power, cooling, and network backbone. You manage everything from the operating system upward including applications, data, access controls, and network configuration. This division determines where security responsibility lies.

How should I configure IAM for least privilege?

Start with deny-all permissions and explicitly allow only what's needed for each role. Use contributor roles for resource management and reader roles for visibility. Review and refine permissions regularly as job responsibilities change.

Why do S3 bucket exposures happen?

S3 buckets are private by default but become public if you explicitly allow public access or misconfigure bucket policies. Verification of bucket policies and access control settings should be routine. AWS provides tools to identify public buckets—use them.

What's the difference between AWS-managed and customer-managed encryption?

AWS-managed encryption is simpler—AWS handles the keys. Customer-managed encryption gives you control over the keys, required if you need to prevent AWS from accessing your data for compliance reasons. For most organizations, AWS-managed encryption is appropriate.

How do I prevent unpatched EC2 instances?

Use AWS Systems Manager Patch Manager to automate patch deployment. Track patching across instances and regularly audit for missing patches. Unpatched servers are the most common vector for AWS breaches.

What should I monitor with CloudTrail and CloudWatch?

CloudTrail logs all API calls and administrative activity—use it for compliance and forensics. CloudWatch monitors operational metrics and logs. Set up meaningful alerts rather than just collecting logs. If you're breached, these are your primary forensic tools.