AWS Security Basics

Reviewed by the Fully Compliance editorial team

Short answer: AWS gives you full control over your cloud infrastructure, which means security is entirely your responsibility from the operating system upward. Default configurations are not secure. You must intentionally build in IAM least-privilege access, restrictive security groups, private S3 buckets, encrypted storage, and active monitoring through CloudTrail and CloudWatch to avoid becoming one of the predictable, preventable breaches that dominate cloud security incidents.

AWS is the largest cloud infrastructure provider and it gives you control over nearly everything you build. That control is powerful and dangerous. AWS lets you do almost anything, which means you can build secure infrastructure or insecure infrastructure with equal ease. The default AWS configuration is not secure — security is something you have to build in intentionally. According to Gartner, through 2025, 99% of cloud security failures are the customer's fault, not the provider's. Organizations deploy into production without basic security controls in place and find out only after an attack or audit that they were vulnerable. AWS will give you the rope to hang yourself with, and that rope is attractive and easy to use.

AWS Manages Infrastructure — You Manage Everything Else

AWS manages security of the infrastructure — the data centers, power, cooling, network backbone, hypervisor that isolates virtual machines from each other. You are responsible for everything running on top of that infrastructure. Your data, your applications, your operating systems, your access controls, your network configuration. This distinction is clear in theory but often missed in practice.

Most AWS breaches happen because organizations believed AWS was responsible for security that actually was their responsibility. A public S3 bucket exposing data to the internet is not AWS's fault. The bucket owner made it public. An EC2 instance running an unpatched operating system with known vulnerabilities is not AWS's fault. You own that server and its patching. An overly permissive security group allowing access from anywhere on the internet is not AWS's fault. You configured that rule. 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 step one. The next step is executing 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. Understanding the concept is necessary but not sufficient. You have to actually do it.

IAM Is Where Security Stands or Falls

Identity and Access Management — IAM — is the AWS service that controls who can do what in your account. Every user, service, and application that interacts with AWS has an identity and permissions. IAM is powerful and complex. It supports role-based access control where you create roles and assign permissions to roles. It supports resource-based policies where you define policies on specific resources. It supports conditional access where you grant access based on conditions like time of day or IP address.

The basic principle is least privilege: users and services get minimum permissions needed for their job. But least privilege in IAM is hard because permissions are granular — you have permissions for individual API calls. Getting IAM wrong is a common gap. A developer who should only create test resources might be granted general permission that allows creating production resources. Service accounts used by automated systems often end up overprivileged because it's easier to grant broad permissions than specific ones. The correct approach: start with deny-all, explicitly allow what's needed, review and refine over time.

A practical structure is using IAM roles instead of user credentials for applications and services running in AWS. An application running on an EC2 instance can use an IAM role to access other AWS services without having credentials embedded anywhere. If the instance is compromised, the attacker gets access to whatever the role allows, but they don't get permanent credentials they can use elsewhere. IAM also supports federation where you can use your own identity provider like Azure AD instead of creating separate AWS accounts. This is valuable in large organizations where you have an existing identity system you want to use.

EC2 Instances Require Active Security From Day One

EC2 is AWS's virtual machine service. When you launch an EC2 instance, you get a server in the cloud. Security from the operating system upward is entirely your responsibility. You choose the operating system image, you patch it, you configure it, you secure it. If you run an outdated OS for months without patching, that's your problem. If you install unnecessary software that creates vulnerabilities, that's your problem. If you leave default credentials in place, that's your problem.

The 2024 Verizon Data Breach Investigations Report confirms that exploitation of vulnerabilities as an initial access vector increased 180% over the prior year — and unpatched servers with public exposure are the primary target. 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 they absolutely need to be. Put web servers behind load balancers or bastion hosts. Enable detailed monitoring so you see what's happening on the instance. Use IAM roles, not access keys, for applications running on EC2 — this allows the instance to access AWS services without storing credentials on the instance.

Encryption should be enabled for data on the instance. AWS provides encrypted volumes that encrypt data at rest. Data in transit should use TLS encryption. These are standard security practices that should be automatic but often aren't configured. The common mistake is creating an EC2 instance, leaving it with default security, and thinking that being in AWS somehow makes it secure. AWS provides the infrastructure. You provide the security.

S3 Buckets Are Private by Default — Keep Them That Way

S3 is AWS's object storage service, and it's one of the most commonly misconfigured AWS services. S3 buckets often contain sensitive data — customer data, backups, logs, intellectual property. S3 buckets are private by default, which is good. But if you explicitly allow public access or use incorrect bucket policies, they become readable by anyone on the internet. Thousands of S3 buckets with sensitive data have been publicly exposed, often discovered by security researchers scanning the internet.

S3 security basics are straightforward: keep buckets private by default, use bucket policies to explicitly grant access to who needs it, enable versioning to protect against accidental deletion, enable encryption to protect data at rest, enable logging to track who accesses what. Many of these are not enabled by default. You have to configure them explicitly. Access control should use IAM roles and policies, not hardcoded access keys. If you need temporary access to an S3 bucket, use presigned URLs that grant time-limited access rather than embedding permanent credentials.

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. A common failure is not understanding the difference between private and public. Someone assumes a bucket is private and doesn't verify. Data gets exposed. Verification is simple — check the bucket policy and access control settings regularly. But it requires deliberate action.

Security Groups Must Be Restrictive, Not Convenient

Security groups in AWS are stateful firewalls. They control what traffic can enter and exit instances. The default is deny-all inbound (good), allow-all outbound (sometimes risky). You create rules like "allow SSH from my office IP" or "allow HTTP from anywhere." Mistakes here are common. A rule allowing access from 0.0.0.0 (anywhere) when you should restrict to specific IPs. A rule created for testing and never removed. A rule that's too broad and allows more than intended.

Network Access Control Lists — NACLs — provide additional network-layer control at the subnet level. Most organizations rely on security groups and skip NACLs. For additional security, configure both. Security groups should be as restrictive as possible. Only allow traffic that's actually needed. Overly permissive security groups are a security gap that often goes unnoticed until a breach happens.

Encryption Protects Data — But Key Management Determines Who Controls It

AWS provides multiple encryption options. Data at rest can be encrypted with AWS Key Management Service keys or customer-managed keys. Data in transit should use TLS encryption. The distinction matters: encryption is only useful if you control the keys. AWS-managed encryption is convenient — AWS handles the keys — but it means AWS holds the encryption keys. If you need to prevent AWS from accessing your data for compliance reasons, you use customer-managed keys where you control the keys.

Most organizations use AWS-managed encryption because it's simpler, and that's often appropriate. For high-security environments or regulated data, customer-managed encryption provides additional control. Encryption should be the default for databases, storage, and backups. Many organizations only enable encryption for sensitive data, but encryption has minimal performance impact and should be ubiquitous. Unencrypted backups or unencrypted databases are security gaps.

CloudTrail and CloudWatch Are Your Eyes — If You Actually Watch Them

CloudTrail logs all API calls and administrative activity in your AWS account. This is crucial for compliance and for forensics if something goes wrong. CloudTrail is not enabled for all services by default — you have to configure it. Once enabled, you have a record of what happened in your AWS account. You can see who did what, when they did it, and from where. This is foundational to understanding your security posture.

CloudWatch is AWS's monitoring and logging service for operational data — CPU usage, disk usage, application logs. You can set alarms based on thresholds and trigger actions. Most organizations collect these logs but don't act on them. Generating logs and doing nothing with them is just creating storage costs. The key is setting up meaningful alerts and reviewing them. If you're being breached, CloudWatch and CloudTrail are how you'll know. If you're not monitoring them, you won't know until the damage is visible some other way. The Ponemon Institute's 2024 Cost of a Data Breach report found that organizations with security AI and automation — including active log monitoring — identified and contained breaches 108 days faster than those without, saving an average of $2.22 million per incident.

Most AWS Security Failures Are Predictable and Preventable

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. Logging not being configured or monitored. These aren't sophisticated attacks. They're basic misconfiguration. Organizations often think about security after they've built the infrastructure, and by then it's expensive to redesign.

The correct approach: consider security from the start. Use least privilege from day one. Use AWS Config or third-party tools to identify misconfiguration automatically. AWS also provides Security Hub, which aggregates security findings from various AWS services and shows you a consolidated view of your security posture. This is valuable for understanding what's broken and what needs fixing.

Build Security Into the Architecture — Not Onto It

AWS security fundamentals are not complicated: enable IAM with least privilege, configure security groups restrictively, keep S3 buckets private, harden EC2 instances, enable encryption, and enable logging and monitoring. None of these are advanced or surprising. But they require intentional configuration. When you're designing your architecture for AWS, allocate time for security design and configuration. Don't treat security as an afterthought or a checkbox.

The organizations with secure AWS environments are the ones that thought about security during design. The organizations with breached AWS environments are often the ones that did the minimum to get something running and assumed the rest would be fine. It won't be. Security is not automatic in AWS. It's something you have to build in intentionally, understand the gaps in, and execute on. The tools AWS provides are good, but tools aren't security. Correct use of tools is security.

Frequently Asked Questions

Is AWS secure by default?
No. AWS secures the underlying infrastructure — data centers, hypervisors, network backbone — but everything from the operating system upward is your responsibility. Default configurations for services like EC2, S3, and IAM are permissive, not hardened. You must intentionally configure security at every layer.

What is the most common cause of AWS security breaches?
Customer misconfiguration. Gartner projects that through 2025, 99% of cloud security failures will be the customer's fault. The most frequent culprits are overly permissive IAM policies, publicly accessible S3 buckets, unpatched EC2 instances, and security groups that allow unrestricted inbound traffic.

Should I use AWS-managed encryption or customer-managed keys?
AWS-managed encryption is appropriate for most organizations — it's simpler and provides solid protection. Customer-managed keys are necessary when compliance requirements mandate that you, not your cloud provider, retain sole control over encryption keys. The operational complexity of customer-managed keys is higher, so use them when the regulatory requirement demands it.

How do I monitor for security issues in AWS?
Enable CloudTrail to log all API calls and administrative actions. Enable CloudWatch for operational metrics and application logs. Configure meaningful alerts rather than just collecting data. Organizations that actively monitor and automate responses to security events contain breaches significantly faster and at lower cost than those that don't.

What should I do first to secure an existing AWS environment?
Start with an IAM audit — identify overprivileged users and service accounts and enforce least privilege. Then check S3 bucket policies for unintended public access, review security group rules for overly broad inbound permissions, verify encryption is enabled on all storage and databases, and confirm CloudTrail is active and monitored. AWS Security Hub provides a consolidated view of these findings.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about AWS security fundamentals as of its publication date. AWS capabilities, features, and best practices evolve — consult with qualified cloud security architects for guidance specific to your environment and requirements.