AWS Security: An Overview

Security on AWS is not a single product you turn on. It is a stack of layers — identity, network, data, detection, and posture — and your real risk is decided by the weakest layer, not the strongest. You can run every fancy threat-detection service AWS sells and still get breached because one S3 (Simple Storage Service) bucket was public or one IAM (Identity and Access Management) user had admin rights they never needed. This page maps the AWS security toolkit so you can see how the pieces fit, and where the basics matter most.

The shared responsibility model

AWS splits security into two halves. AWS secures the cloud itself — the physical data centers, the hardware, the hypervisor, the global network. You secure what you put in the cloud — your data, your IAM permissions, your network rules, your patches. This is the shared responsibility model, and it is the foundation of everything below.

The line shifts depending on the service. For EC2 (Elastic Compute Cloud, virtual servers) you patch the operating system; for a managed service like Amazon RDS (Relational Database Service) AWS patches the engine but you still control access and encryption. The constant is this: AWS never secures your access controls or your data for you. That is always your job, and it is where almost all real-world incidents happen.

Gotcha: The two biggest causes of AWS breaches are over-broad IAM permissions and publicly exposed S3 buckets. Both sit squarely on your side of the responsibility line. No detection tool fixes a door you left unlocked.

Layer 1: Identity (who can do what)

Identity is the first and most important layer. IAM controls every API (Application Programming Interface) call in your account through policies — JSON documents that say which principal can perform which action on which resource.

When to use this: always, for everything. There is no “later” for IAM. Every human and every workload needs an identity scoped to exactly what it needs (least privilege) and nothing more.

Key practices:

• Use IAM roles (temporary credentials) for applications and EC2 instances, not long-lived access keys.
• Enforce MFA (Multi-Factor Authentication, a second login factor like a phone app) on every human user, especially the root account.
• Centralize users with IAM Identity Center (formerly AWS SSO) instead of creating individual IAM users per account.

Check who has dangerously broad access with the CLI (Command Line Interface):

aws iam list-users --query 'Users[].UserName' --output table
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

Output:

-------------------
|   ListUsers     |
+-----------------+
|  deploy-bot     |
|  alice          |
-------------------
0

Warning: AccountMFAEnabled: 0 means the root user has no MFA. Fix that before anything else — root can do literally everything.

Layer 2: Network (who can reach what)

Once identity is sorted, you control the network paths into your resources. This layer lives mostly inside a VPC (Virtual Private Cloud, your isolated network in AWS).

Control	What it protects	When to use
Security groups (SG)	Stateful firewall on each instance/ENI	Always — your primary instance firewall
Network ACLs	Stateless rules at the subnet edge	Coarse subnet-wide deny rules
AWS WAF	HTTP/HTTPS application traffic (Layer 7)	Block SQL injection, XSS, bad bots at ALB/CloudFront
AWS Shield	DDoS (Distributed Denial of Service) attacks	Always (Standard, free); Advanced for high-risk apps

A security group rule that opens SSH to the world (0.0.0.0/0 on port 22) is one of the most common findings in a security audit. Lock it to your own IP range:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0a1b2c3d \
  --protocol tcp --port 22 \
  --cidr 203.0.113.10/32

Output:

{
    "Return": true,
    "SecurityGroupRules": [
        {
            "SecurityGroupRuleId": "sgr-0a1b2c3d4e5f",
            "CidrIpv4": "203.0.113.10/32",
            "FromPort": 22,
            "ToPort": 22
        }
    ]
}

When NOT to over-rely on this layer: the network is a wall, but identity and data controls matter just as much. A locked-down VPC with a public S3 bucket attached is still wide open, because S3 access is governed by IAM and bucket policy, not by your VPC.

Layer 3: Data (protect it even if reached)

Assume an attacker gets in. Encryption means stolen data is useless. AWS makes encryption nearly free to enable.

• AWS KMS (Key Management Service) creates and controls the encryption keys used by S3, EBS (Elastic Block Store), RDS, and most other services.
• Encryption at rest scrambles stored data; encryption in transit (TLS, Transport Layer Security) protects data moving over the network.
• AWS Secrets Manager and Parameter Store keep passwords and API keys out of your code.

Enable default encryption on a bucket so every new object is encrypted automatically:

aws s3api put-bucket-encryption \
  --bucket my-app-data-0a1b2c3d \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'

Cost note: A KMS customer-managed key costs about $1/month plus $0.03 per 10,000 requests. Trivial next to the cost of a breach.

Layer 4: Detection (know what’s happening)

You cannot protect what you cannot see. These services tell you when something is wrong.

Service	Watches	What it gives you
CloudTrail	Every API call	The audit log — who did what, when
AWS Config	Resource configuration changes	History + rules (“no public buckets”)
GuardDuty	Logs + threat intel	Detected threats (crypto-mining, recon, leaked keys)

When to use: turn on CloudTrail and GuardDuty in every account on day one. They are cheap, account-wide, and the first thing an auditor or incident responder asks for.

Layer 5: Posture (am I configured safely?)

The detection layer finds active threats; the posture layer finds the weaknesses before they’re exploited.

• AWS Security Hub aggregates findings from GuardDuty, Inspector, and others into one dashboard, scored against standards like CIS and AWS Foundational Security Best Practices.
• Amazon Inspector scans EC2 instances, container images, and Lambda functions for known software vulnerabilities (CVEs).
• Amazon Macie uses machine learning to find sensitive data (like credit card numbers) sitting in S3.

Turn on Security Hub with one command:

aws securityhub enable-security-hub --enable-default-standards

Output:

{
    "SubscriptionArn": "arn:aws:securityhub:us-east-1:111122223333:hub/default"
}

How the layers fit together

Picture a request reaching your app: Shield absorbs DDoS, WAF blocks malicious HTTP, the security group allows only the right ports, IAM authorizes the action, KMS keeps the data encrypted, and CloudTrail/GuardDuty record and flag anything unusual. Remove any one layer and the others still stand — that is defense in depth. But remove the basics (least privilege, MFA, no public data) and the expensive layers can’t save you.

Best Practices

• Lock down identity first. Enable MFA everywhere, use roles over access keys, and grant least privilege. This single layer prevents most breaches.
• Never make data public by accident. Turn on S3 Block Public Access at the account level and treat any exception as a reviewed decision.
• Encrypt by default. Enable KMS encryption on S3, EBS, and RDS — it costs almost nothing and removes a whole class of risk.
• Turn on the free detection services everywhere. CloudTrail, GuardDuty, and Security Hub should be active in every account from day one.
• Restrict network access tightly. No 0.0.0.0/0 on management ports (22, 3389); use Session Manager instead of open SSH.
• Patch and scan continuously. Let Inspector find vulnerabilities so you fix them before attackers do.
• Measure your weakest layer, not your strongest. Review IAM and public exposure regularly — that is where your real risk lives.

Related Topics

• AWS KMS (Key Management Service)
• Encryption at rest and in transit
• Amazon GuardDuty
• AWS Security Hub
• Security best practices