AWS Security Primer
Such a shallow dive: there really needs to be a lot more ink spilled on this topic in great depth. I&#x27;ve worked extensively with AWS over the last 4 years, and I can barely wrap my head around the scope of managing security in AWS. We have an entire department dedicated to security in our company, and none of them are remotely close to being experts in AWS security either.<p>I&#x27;m starting to get curious if there even is an expert who could set up and maintain a bulletproof AWS Account. From the dev&#x2F;admin accounts to API Gateway to Lambda to RDS and S3; there&#x27;s just too much to be an expert on. And it&#x27;s all handled differently (not to mention how many times it&#x27;s changed in my mere 4 years of experience).<p>Instances get role data from the metadata service, but containers can&#x27;t access that metadata and should access the local ECS agent instead (which has its own API). Lambdas must assume a role with a dedicated policy to even write logs, but setting up a scheduled lambda adds an entire different permission object (with its own policy) just to allow the cloudwatch alert mechanism to even trigger a lambda. DB access can be authenticated using roles, but you have to manually set up the users (and their DB permissions), and it doesn&#x27;t work with every DB type. S3 buckets can get policies from both built-in bucket policies <i>and</i> from users&#x2F;roles, with inline or managed policies available for each. The API Gateway&#x27;s authentication requires a Lambda function, but only passes through a single token and expects an IAM entity in response...<p>Even AWS&#x27; tutorials and built-in managed policies seem to throw their hands up in despair; throwing out wildcard permissions (like s3:*) left and right just to make things work.<p>No wonder people focus on their network and basic root account security - as frustrating and challenging as network security is, it is still a much more tractable problem.