In 2006, AWS helped make cloud infrastructure programmable, scalable, and available to teams without waiting for physical hardware. That same flexibility also changed the security problem: risk often comes from small configuration choices repeated across accounts, Regions, pipelines, and teams.
AWS security is built around shared responsibility. AWS secures the underlying cloud infrastructure, while customers configure identities, networks, data protection, logging, workloads, and governance. The most reliable AWS environments usually do not depend on heroic manual review. They use well-designed defaults, preventive guardrails, continuous detection, and clear ownership when something goes wrong.
The AWS Well-Architected Security Pillar and the CIS AWS Foundations Benchmark both point toward the same operating model: define strong identity boundaries, reduce public exposure, protect data by default, collect useful evidence, and test controls continuously. The seven issues below are common because they sit at the point where speed, autonomy, and security policy meet.
1. Over-permissive IAM access
Identity and access management is where many AWS security problems begin. The most persistent mistakes are familiar: attaching AdministratorAccess for convenience, using broad permissions such as Action: "*" or Resource: "*", relying too heavily on AWS managed policies, and failing to restrict what entire accounts may do through AWS Organizations service control policies. These issues can remain hidden for months because nothing appears broken until a key is exposed, a pipeline is compromised, or a user performs an action that was never intended.
Least privilege is easier to describe than to maintain. Production teams change services, add automation, and inherit older roles that no one wants to disturb. A practical approach is to combine role-based access for humans, short-lived credentials, MFA for privileged access, permission boundaries for delegated administration, and scheduled reviews using IAM Access Analyzer and service last accessed information. In multi-account environments, SCPs should prevent dangerous actions that no workload should perform, such as disabling organisation-level logging or leaving approved Regions without governance.
The example below shows a narrow IAM policy for a workload that needs to read objects from one application prefix and list only that prefix in the bucket. It avoids broad actions and avoids account-wide resource access.
Example — Narrow S3 read access for one workload prefix
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListOnlyApplicationPrefix",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::prod-application-data",
"Condition": {
"StringLike": {
"s3:prefix": "orders-service/*"
}
}
},
{
"Sid": "ReadOnlyApplicationObjects",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::prod-application-data/orders-service/*"
}
]
}
This policy is still only one control. It should sit behind role assumption, monitored CloudTrail activity, and automated checks that detect later broadening of the policy. In production, naming standards and tags also help security teams understand which service owns the role and who approves changes.
2. S3 buckets that become public by accident
Amazon S3 public exposure still happens even though S3 Block Public Access has become a standard safeguard. Legacy ACLs may still exist, bucket policies may allow Principal: "*", and static website hosting can be configured in ways that make content public beyond the intended scope. Public access is sometimes legitimate, such as a carefully designed website bucket behind CloudFront, but it should be explicit, documented, and monitored rather than accidental.
Safe defaults usually start with account-level S3 Block Public Access, disabled ACLs where possible, bucket policies that deny insecure transport, and central monitoring for policy changes. Sensitive buckets should also have clear data classification, encryption requirements, access logging or CloudTrail data events, and alerting for policy changes. The risk is rarely the bucket setting alone; it is the combination of public policy, weak review, and missing visibility into object-level activity.
The following bucket policy denies requests that do not use TLS. It is commonly used alongside stronger access controls, encryption, and public access settings rather than as a replacement for them.
Example — Deny insecure transport to an S3 bucket
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::prod-application-data",
"arn:aws:s3:::prod-application-data/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
The wildcard principal is appropriate here because the statement denies insecure transport for everyone. The important verification step is to confirm that no separate bucket policy, access point, or website configuration grants public access where it is not intended.
3. Logging gaps that weaken detection and response
CloudTrail is often enabled, but partial logging can create blind spots. Common gaps include no organisation trail, single-Region trails that miss activity elsewhere, missing log file validation, no S3 or Lambda data events, and logs stored in accounts where administrators can alter or delete them. A security team may believe it has audit coverage while the most useful evidence is absent.
For organisations using AWS Organizations, a centralised organisation trail should usually cover all accounts and all Regions, with logs delivered to a dedicated logging account. Management events are the baseline. Data events should be enabled selectively for sensitive S3 buckets, Lambda functions, and other resources where object-level or invocation-level evidence matters. CloudWatch Logs, EventBridge, GuardDuty, Security Hub, and a SIEM can then consume the signals needed for triage.
The AWS CLI example below creates a multi-Region organisation trail with log file validation. It assumes the command is run from the management account or delegated administrator context with appropriate permissions, and that the target S3 bucket policy already permits CloudTrail delivery.
Example — Create an organisation CloudTrail trail
aws cloudtrail create-trail \
--name org-security-trail \
--s3-bucket-name prod-org-cloudtrail-logs \
--is-organization-trail \
--is-multi-region-trail \
--enable-log-file-validation
aws cloudtrail start-logging \
--name org-security-trail
This creates the audit foundation, but it does not automatically capture every useful event. Teams should add data event selectors for high-risk buckets and functions, verify delivery in each enabled Region, and protect the log bucket with restricted access and retention controls.
4. Flat or overly open networks
AWS networking can become risky when teams treat security groups as temporary convenience settings. In practice, overly broad inbound rules such as unrestricted access from 0.0.0.0/0, unused or misunderstood network ACLs, missing VPC endpoints for S3 and DynamoDB, and inconsistent routing can all expose workloads or send traffic through unnecessary public paths. Application Load Balancer misrouting can add a different problem: a publicly reachable entry point may forward traffic to the wrong target group or environment.
Network security should begin with intended traffic flows. Public subnets should be reserved for components that genuinely need public reachability, while application and data tiers should use private subnets wherever possible. VPC endpoints reduce dependency on public egress for supported AWS services, and egress controls help detect workloads that communicate with destinations outside their expected pattern. Security groups should be owned and reviewed like application code because a single rule can change the exposure of a workload.
Public entry points need a separate decision. For ALB, CloudFront, and API Gateway, AWS-native controls are usually the first place to start: AWS WAF managed rules for common web threats, Shield for DDoS protection, Cognito or another approved identity layer for authentication, and modern TLS or mutual TLS where required. Third-party controls may be justified when an organisation needs custom layer 7 logic or centralised cross-cloud policy, but they should complement rather than obscure the AWS configuration that still determines exposure.
5. Long-lived secrets and weak key management
Secrets problems often appear in delivery pipelines before they appear in runtime systems. Long-lived IAM access keys in CI/CD tools, secrets embedded in Lambda environment variables without adequate controls, permissive KMS key policies, missing rotation routines, and confusion around multi-Region keys can all weaken an otherwise well-designed architecture. Default encryption for services such as EBS and RDS helps, but default encryption does not answer who can use a key, who can administer it, or how key usage is monitored.
A stronger model uses role federation or workload identity instead of static access keys, stores application secrets in AWS Secrets Manager or Systems Manager Parameter Store with KMS protection, and separates key administration from key usage. Key policies deserve particular attention because they can override assumptions made in IAM. Rotation should be planned around application behaviour, not treated as a checkbox, because some systems need deployment changes to reload credentials safely.
6. Public endpoints without enough application-layer protection
Public endpoints are sometimes secured at the network layer while application-layer risk receives less attention. An API Gateway endpoint with weak authentication, a CloudFront distribution without suitable origin protection, or an ALB that accepts traffic without WAF rules can still be exposed even when the surrounding VPC design looks tidy. Attackers often target the behaviour of the application, not simply the port that is open.
Defence should match the type of endpoint. APIs need authentication, authorisation, throttling, logging, and input validation. Web applications often need WAF rules, rate-based protections, secure headers, and well-managed origin access. Internet-facing load balancers should be reviewed for listener configuration, certificate management, target group health, and routing rules. The aim is to make public access deliberate, observable, and limited to the functions that truly require it.
7. Security controls that are not operationalised
Many AWS controls fail because they remain advisory. Security Hub may be enabled without ownership of findings, Infrastructure as Code may deploy resources without policy checks, and teams may review access only after an incident. Good governance turns desired settings into prevention, detection, and accountable follow-up.
At scale, AWS Organizations becomes the foundation for operating security across many accounts. Account vending should apply baseline logging, network, tagging, identity, and encryption settings before a team receives an account. SCPs should enforce non-negotiable boundaries. Tags should identify workload owner, environment, data classification, and cost centre so findings can be routed correctly. Without those foundations, security tooling produces findings but not necessarily action.
Infrastructure as Code guardrails reduce misconfiguration before deployment. CloudFormation Guard can validate CloudFormation templates against policy rules, while Terraform users commonly pair plan reviews with policy engines such as OPA and Conftest. These controls are especially useful for preventing public S3 policies, unrestricted security group rules, missing encryption, and unapproved Regions. In many cases, the most effective control is the one that stops the risky change before it reaches an AWS account.
Security Hub can then act as a governance scorecard by enabling standards such as CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. That score should not be treated as proof of compliance, but it is useful for trend tracking, exception review, and drift detection. A practical cadence includes regular IAM Access Analyzer reviews, service last accessed reviews for privileged roles, Security Hub finding triage, and periodic testing of incident playbooks.
How incident response should work in AWS
Detection has limited value unless teams know what to do next. GuardDuty, CloudTrail, CloudWatch, EventBridge, Security Hub, and central log storage should support a response process that is rehearsed before a real incident. The process should be simple enough for on-call teams to follow and strict enough to preserve evidence.
- Triage the finding in GuardDuty or Security Hub and confirm the affected account, Region, identity, and resource.
- Preserve evidence by protecting CloudTrail logs, snapshots, relevant object versions, and workload logs before destructive remediation.
- Contain the issue by disabling compromised credentials, isolating instances, tightening security groups, or blocking risky policies.
- Eradicate the root cause by removing the exposed key, misconfiguration, vulnerable deployment, or unauthorised access path.
- Recover with monitored redeployment, post-incident access review, and IaC policy updates that prevent the same failure pattern.
This flow also highlights why central logging, account separation, and tagging matter. During an incident, responders need to know who owns the workload, which data is involved, and whether the same pattern exists elsewhere. Environments that lack those basics often spend more time finding context than reducing risk.
Building AWS security that holds up in production
The strongest AWS security programmes treat configuration as an operational discipline. Identity boundaries, S3 exposure controls, logging, network design, secrets management, endpoint protection, and governance all need to work together. Enabling a single service is rarely enough; the value comes from combining preventive controls, meaningful detection, and a response process that teams can execute under pressure.
A practical next step is to choose one production account and assess it against the seven risk areas above. The findings should be converted into reusable guardrails through AWS Organizations, SCPs, account baselines, IaC policy checks, and Security Hub standards. Teams that need a structured way to develop these skills can use Readynez AWS training as part of a broader security capability plan, but the operating model still depends on applying the controls consistently in real environments.
