AWS Security Architecture — InfraTales Hub
AWS security is not a feature you add at the end. This hub covers the architecture patterns that make security a structural property of the system.
AWS Security Architecture
Security on AWS is not about adding a WAF and calling it done. It is about making the architecture itself resistant to the most common failure modes — credential leaks, lateral movement, and misconfigured permissions.
This hub covers the security architecture patterns used in production.
Security Architecture Posts
- AWS Zero Trust Network Architecture: BeyondCorp with CDK
- AWS Security Reference: Zero Trust, DevSecOps, CloudHSM
- Cloud-Native SIEM on AWS: OpenSearch and Security Lake
- AWS CloudHSM Production Platform: FIPS 140-2 Key Management
- Core AWS Infrastructure: VPC, IAM, and Security Foundations
The IAM Mistakes That End Careers
Wildcard actions in production
"Action": "*" in a production IAM policy is a ticking clock. Every AWS security incident in the last 5 years involved overly permissive IAM. Use aws iam simulate-principal-policy to validate before deploying.
Long-lived access keys
Rotate them or — better — eliminate them. EC2 instance profiles, Lambda execution roles, and ECS task roles all use short-lived credentials that rotate automatically. There is no reason for a long-lived access key in a well-designed system.
Not using SCPs
Service Control Policies at the AWS Organizations level are the last line of defence. Even if a role is misconfigured, SCPs can prevent the damage. At minimum: deny root API access, deny disabling CloudTrail, deny creating IAM users without MFA.
Secrets in environment variables
Lambda environment variables are visible to anyone with lambda:GetFunctionConfiguration. Use Secrets Manager or Parameter Store, and fetch at runtime rather than at deploy time.
Security architecture review needed? Work with Rahul