My notes on "Things you wish you didn't need to know about S3"

My notes on Things you wish you didn't need to know about S3

This article is a list of surprising facts about S3, several of them were new to me.

I really liked this comment:

In recent years, AWS has done a stellar job confiscating foot guns they previously distributed.

There are a lot of things that the S3 API does wrong and it's pretty much impossible to fix these problems without breaking changes. So we're stuck with things like public-writable buckets and non-encrypted objects, though both have a sensible default now.

What is interesting is that pretty much everything is in the uploader's control. The article discusses storage classes that can be abused by uploading a lot of small object to a deep archive tier incurring extra deletion and storage costs, or more extremely:

My personal favourite is Object Lock, which allows legal and compliance teams to retain objects for reasons comma legal. It only works if a bucket has been configured with object locking enabled, but it’s too fun not to mention.

Why it's fun is that the only way to delete the object is to delete the AWS account.

When engineered properly, this is not a big problem: uploads should be done via signed URLs where the backend defines all the fields. But it's just all too easy to grant permissions to users via Cognito Identity Pools (which I'm yet to see a good use-case for) and unless some high-sorcery is done in the IAM policies it gives users too much power.

I find it a recurring theme in AWS: there are many ways to do things and usually some of them are terrible but for reasons not immediately apparent. Putting secrets in Lambda environment variables? Creating an IAM user and hardcoding its credentials? Using Cognito Identity Pools instead of User Pools? Everything works perfectly, but still a terrible idea.

Originally published on LinkedIn.