22 Cloud Design Anti-Patterns You Must Avoid to Save Time and Earn Respect
Before You Learn Cloud Security Best Practices.
Hey There,
Most beginners in cloud security stumble not because they don’t know what to do — but because they don’t know what not to do.
If you’re a cloud security beginner or analyst aiming to grow into an architect, these patterns are the same mistakes that lead to 80% of real-world breaches and failed audits.
Spotting them early saves you wasted hours and embarrassing reviews.
In this guide, I’ll share the 22 awful patterns I’ve seen again and again in Cloud architecture reviews.
Let’s dive in.
Policies Without Specific Principal/OrgID
Use conditions like aws:PrincipalOrgID to make sure only the principals from the accounts in your organization can access AWS resources. This prevents unauthorised access to your resource.
Wildcard Actions/Permission leading to over-permissive roles
IAM permission with “*”known as Wildcard. Wildcard permission must be replaced with specific Actions, Resources or Prinicipals.
IMDSv1 enabled, allowing metadata theft.
SSRF(Server Side Request Forgery) via AWS IMDSv1 leading to theft of service credentials.
Lock everything to IMDSv2 and deny role changes via SCP.
No scanning at regular cadence to find public/shared snapshots.
Public/shared snapshots, Old EBS, AMIs, or RDS backups are often accidentally exposed. Scan for these regularly.
Cross-account roles without org-level conditions leads to unauthorised role assumptions.
Set org-level condition in IAM Policy to prevent role assumption by unauthorised AWS account. Provide strong control when deploying multi-account workload.
Unmonitored data egress allowing attacker to Sneak data out quietly.
Force traffic through NAT.
Use GuardDuty/Macie.
Monitor odd KMS or S3 usage.
Distributed account for Security functions
Centralised security account enables centralised log collection and tooling to efficiently detect and mitigate security risks.
Not using native tools for detection, waiting for fancy solution.
Leverage cloud native without spending on fancy tools such as AWS Config for drift detection, AWS Security Hub, AWS Guard Duty, AWS Macie, AWS Access Analyser, AWS Inspector etc.
Overly Permissive Security Groups
Many organisation use leave security group wide open either for Internet or for service that doesn’t need to interact with the workload. Review Security Group at regular cadence.
Not Securing Root Account Access
Orgs still have root access keys active. Using root user for regular operations is a top misconfiguration.
Root user bypasses many restrictions, audit, oversight. Compromise of root often means full account compromise.
Follow least privilege. Use IAM roles for applications. Use temporary credentials (STS). Use AWS Secrets Manager or Parameter Store for secret storage. Rotate creds. Enable MFA on root and highly privileged accounts.
Poorly Managed Key Management Service (KMS)
Lack of centralised Key Management. No rotation policy, no audit trail, no resource policy to restrict over access of the keys.
Single Account/Lack of Account or Environment Segmentation increases Blast Radius.
Lateral movement becomes trivial if all subnets/VMs talk to each other unrestricted. East-west traffic left unchecked expands breaches.
Adopt default-deny network rules
Micro-segmentation (security groups, NSGs)
Use private subnets for workloads
Publish only necessary services via load-balancers/API gateways
Not Using Infrastructure as Code(IaC) leading to Config Drift, inconsistent security controls and errors.
IaC has 3 major benefits -
Keeps the configuration same across multiple teams and environment.
Can be rolled back quickly.
Can be version controlled to detect the changes.
APIs/Public Endpoints Without Proper Authentication/Authorization
Insecure endpoints lead to data exfiltration, injection attacks, abuse and account takeover. API attacks are increasing.
What you can do -
Deploy API Gateway for centralised ingress API traffic.
Use OAuth 2.0 for authentication and authorisation.
Enforce Rate Limiting
Validate Input
run automated API fuzzing/security scans.
Monolithic architectures deployed in single AZ/single instance.
A single EC2, or a monolith service, no redundancy; regional failures or AZ failures take everything down.
AWS does not guarantee zero downtime in AZ or hardware failure. Single point of failure. No automatic recovery.
Design for failure: use Multi-AZ, multi-region if needed. Use managed services (RDS Multi-AZ, DynamoDB global tables, etc.). Use autoscaling groups across AZs. Use stateless service design.
Lambda pinball/over-chaining Lambdas
Many small Lambda functions each calling one another in sequences for simple tasks. Data passed via triggers; orchestration is brittle.
Increased latency, complexity of tracing/debugging, harder to guarantee security boundaries, potential cost inefficiencies (each invocation, cold starts etc.). Also harder to monitor or enforce logging/tracing/security across chains.
Combine where logical; limit depth of chains; use step functions or orchestration where needed; ensure each function has clear purpose. Use good observability (tracing, logging). Bound permissions per function.
Poor Data Classification for Sensitive Data
By identifying and categorising sensitive data, organisations can implement appropriate security controls to protect sensitive data from unauthorized access and breaches.
Not producing Golden Image for Containers
Team install packages, make changes to container in production, run the container as root, pull images from public registry.
This leads to inconsistent security baseline, increase supply chain attacks, lack of detection, potential vulnerable component.
Applying security controls and patches during Golden image creation, organizations ensure that every instance launched from a golden image starts with a consistent and secure baseline, reducing misconfigurations and vulnerabilities.
Dangling DNS records leading to Subdomain Takeover.
Misconfigured CNAME often lead to dangling DNS records leading issue such as Subdomain Takeover.
To prevent this, maintain an inventory of all active DNS records and regularly audit processes to ensure that if any DNS entries are no longer required, their resources have been deleted too.
https://github.com/EdOverflow/can-i-take-over-xyz
Relying on perimeter security/no zero-trust mindset
Cloud workloads are distributed; perimeter controls alone (VPN/firewall) fail if credentials are compromised or services are misconfigured.
Build with Zero Trust principles — authenticate and authorise every request, short lived tokens, MFA, device posture checks, and least privilege for machine identities.
Shadow IT/Sprawling Architecture Without Governance
Teams spin up their own infra, services, pipelines, possibly in separate accounts or cloud regions, without oversight or shared standards. Lots of duplication and inconsistent security patterns.
Why it's bad: Hard to enforce security, cost control, compliance; blind spots for risk; duplicate work; inconsistent patching or vulnerability management.
What to do instead: Establish a cloud governance model, strong landing zone, central security/ops policies, shared architecture standards, account/project/folder structure, teams collaborating via a Cloud Center of Excellence.
Lack of Threat Modelling / Ignoring Security in Early Design
Security is added as an afterthought, after coding or once production start; design decisions don’t include threat analysis, or consider worst cases.
Why it's bad: Leads to fundamental design flaws (e.g., insecure data flow, poor partitioning, missing checks) that are costly or impossible to fixed later; higher risk of breaches or data loss.
What to do instead: Do threat modelling early (during architecture design), map data flows, identify trust boundaries, assign data classification, consider regulatory/compliance constraints, design with defense-in-depth. Use security design patterns early. Use cheat-sheets like OWASP Secure Cloud Architecture.
Conclusion
The sooner you learn these anti-patterns, the faster you will grow in Cloud Security, learn to look at the bigger picture and become go-to person for Seniors.
Chat Soon,
Kushal
What did you think of today’s newsletter?
❤️ Loved it? → Refer it to a friend or drop a ‘Like‘ below.
🥳 Just joined? → Start here: 9 Security Principals Beginners Must Know
💡 Have ideas? → Hit reply and tell me how I can make this more useful for you.