4 ms·

IAM is unnecessarily bad. I recently had to set a trivial policy, and was doing it correctly. The console kept warning me that I was giving root AWS access to

by hedora 5mo ago

IAM is unnecessarily bad. I recently had to set a trivial policy, and was doing it correctly. The console kept warning me that I was giving root AWS access to my external application because they want people to use the locked in AWS path, and I was running off cloud. On top of that, they break copy paste on the web console, so you can’t just ctrl-c ctrl-v and then ask Claude to explain their WTF-ery. Instead, you have to OCR or send a PNG. I honestly did not think they could make IAM worse, yet here we are. Bastards.

hedora 5mo ago
I guess I should also point out that I’ve used AWS at extremely large scale in the past, which is why I’m running this subproject on another cloud. As for simple permissions, go read the UNIX paper. It spends a page or two on their approach and is all you need. Then, read the paper on mapping between NTFS SMB ACLs and NFS. It’s either impossible or undecidable, depending on the deployment. IAM is from the windows acl lineage which is known pessimal from a usability and security perspective.
- cyberax 5mo ago
  IAM is NOT from any lineage. It has grown organically and is complicated, just as any other policy language. AWS even uses an automatic proof assistant to verify IAM policies. However, the secret to IAM in AWS is to NOT use IAM. Just create separate AWS accounts for separate services and only share whatever resources are needed. Then you can have dead simple IAM policies because you won't need to do granular permissions ("AWS role X can access database Y").
  - dotwaffle 5mo ago
    > Just create separate AWS accounts for separate services My understanding is that different AWS accounts have different mappings of availability zones, so it's very easy to suddenly find yourself with an unexpected bandwidth bill due to all the cross-az traffic. I've been irritated at AWS (and the other large cloud providers) that they charge $0.01/GB for cross-az traffic. That's $3.24/Mbps -- about the same I was paying for internet transit (as in: from London to anywhere in the world) 20 years ago, and this is just between two datacenters in the same city controlled by the same organisation, markup must be 10,000x or more considering these places are cross-connected with massive bundles of fiber!
    - cyberax 5mo ago
      > My understanding is that different AWS accounts have different mappings of availability zones, so it's very easy to suddenly find yourself with an unexpected bandwidth bill due to all the cross-az traffic. As far as I remember, accounts within the same organization will have the same mapping. You also can use stable zone names these days, instead of the regular mappings. And yeah, egress traffic pricing is freaking insane at this point. It's the biggest reason to NOT use AWS.
      - dotwaffle 5mo ago
        Insanely high S3 storage charges too. $23/TB/month? Even with the insane HDD pricing that we see today, that's paying off a drive in 1 month (at retail) that will last for 50-100 months. Sure, there's probably some encoding overhead, but it's still mad.
        cyberax 5mo ago
        S3 is pretty competitive if you want similarly-performing storage with consistent millisecond-level latency, high scalability, and at least 3x redundancy. Try looking at how much it's going to cost you in enterprise SSDs :)
        dotwaffle 5mo ago
        Is it 3x redundancy forever? I always just kinda assumed it was RS encoded after a while, so only 30-50% larger than a single copy. Plus, almost all object storage is written to / read from hard disks, not to SSDs. Unless they're in a caching layer that is. I know Azure has done a bunch of work around Pyramid Codes (essentially a locally repairable EC/RS variant), and Google obviously have the Colossus infrastructure that allows variable encodings, I'd be surprised if AWS is still triple-replicated everywhere.
        cyberax 5mo ago
        Yes, and S3 is multiply redundant and is designed to survive a total AZ failure. So your data is physically replicated into at least 2 different AZs and might be multiply-redundant within them. They also provide a crazy SLA for data integrity, meaning that data must never be lost. S3 also has a reduced redundancy tier and infrequent access tiers that are quite a bit cheaper. It _is_ expensive, but once you crunch all the numbers, it's actually not unreasonable. I'd argue that using the real S3 is overkill for most scenarios that don't need infinite scalability.
raffraffraff 5mo ago
You think that you're complaining about IAM, but really you're complaining about the web ui. I rarely use the web console, I use terraform or the cli. I'd you're vibe coding your infra with Claude, point it at the cli / terraform. Skip the ui.
- regularfry 5mo ago
  With terraform you get the amazing experience of having to iterate, one at a time, through the five hundred and thirty seven new permissions you need to grant having decided that a lambda configuration needs to be ever so slightly different than it was yesterday, because there's no documentation linking terraform creation of resources and the IAM permissions required to successfully make the AWS API call behind the scenes. Or those for updating a resource, which are different, so you get to do it all again tomorrow. Or deleting - different again. Fun for the day after.
joshcartme 5mo ago
You could probably open the developer tools, find the console elements and extract the data from there to get around copy/paste limitations. I’m not familiar with the AWS console but let’s say it’s an input, select it in the dev tools and then in the dev tools console do $0.value
pseudohadamard 5mo ago
Agreed on IAM, and TFAs comments that once you see the horrendous complexity in IAM you start seeing it everywhere else in AWS as well. And with IAM, after all the effort you've put in, you can never really tell what is and isn't enabled. If you run your own server you can check permissions, run access-control audit scripts, and so on, and say with a pretty good level of confidence that X is possible and Y isn't. With IAM it's more like "I'm pretty sure I figured out the right silly-walk for X, but I have no way to tell what else might be enabled". AWS: I came, I saw, I threw up in my mouth a little, I left.

by hedora 5mo ago

hedora 5mo ago

I guess I should also point out that I’ve used AWS at extremely large scale in the past, which is why I’m running this subproject on another cloud. As for simple permissions, go read the UNIX paper. It spends a page or two on their approach and is all you need. Then, read the paper on mapping between NTFS SMB ACLs and NFS. It’s either impossible or undecidable, depending on the deployment. IAM is from the windows acl lineage which is known pessimal from a usability and security perspective.

cyberax 5mo ago
IAM is NOT from any lineage. It has grown organically and is complicated, just as any other policy language. AWS even uses an automatic proof assistant to verify IAM policies. However, the secret to IAM in AWS is to NOT use IAM. Just create separate AWS accounts for separate services and only share whatever resources are needed. Then you can have dead simple IAM policies because you won't need to do granular permissions ("AWS role X can access database Y").
- dotwaffle 5mo ago
  > Just create separate AWS accounts for separate services My understanding is that different AWS accounts have different mappings of availability zones, so it's very easy to suddenly find yourself with an unexpected bandwidth bill due to all the cross-az traffic. I've been irritated at AWS (and the other large cloud providers) that they charge $0.01/GB for cross-az traffic. That's $3.24/Mbps -- about the same I was paying for internet transit (as in: from London to anywhere in the world) 20 years ago, and this is just between two datacenters in the same city controlled by the same organisation, markup must be 10,000x or more considering these places are cross-connected with massive bundles of fiber!
  - cyberax 5mo ago
    > My understanding is that different AWS accounts have different mappings of availability zones, so it's very easy to suddenly find yourself with an unexpected bandwidth bill due to all the cross-az traffic. As far as I remember, accounts within the same organization will have the same mapping. You also can use stable zone names these days, instead of the regular mappings. And yeah, egress traffic pricing is freaking insane at this point. It's the biggest reason to NOT use AWS.
    - dotwaffle 5mo ago
      Insanely high S3 storage charges too. $23/TB/month? Even with the insane HDD pricing that we see today, that's paying off a drive in 1 month (at retail) that will last for 50-100 months. Sure, there's probably some encoding overhead, but it's still mad.
      - cyberax 5mo ago
        S3 is pretty competitive if you want similarly-performing storage with consistent millisecond-level latency, high scalability, and at least 3x redundancy. Try looking at how much it's going to cost you in enterprise SSDs :)
        dotwaffle 5mo ago
        Is it 3x redundancy forever? I always just kinda assumed it was RS encoded after a while, so only 30-50% larger than a single copy. Plus, almost all object storage is written to / read from hard disks, not to SSDs. Unless they're in a caching layer that is. I know Azure has done a bunch of work around Pyramid Codes (essentially a locally repairable EC/RS variant), and Google obviously have the Colossus infrastructure that allows variable encodings, I'd be surprised if AWS is still triple-replicated everywhere.
        cyberax 5mo ago
        Yes, and S3 is multiply redundant and is designed to survive a total AZ failure. So your data is physically replicated into at least 2 different AZs and might be multiply-redundant within them. They also provide a crazy SLA for data integrity, meaning that data must never be lost. S3 also has a reduced redundancy tier and infrequent access tiers that are quite a bit cheaper. It _is_ expensive, but once you crunch all the numbers, it's actually not unreasonable. I'd argue that using the real S3 is overkill for most scenarios that don't need infinite scalability.

raffraffraff 5mo ago

You think that you're complaining about IAM, but really you're complaining about the web ui. I rarely use the web console, I use terraform or the cli. I'd you're vibe coding your infra with Claude, point it at the cli / terraform. Skip the ui.

regularfry 5mo ago
With terraform you get the amazing experience of having to iterate, one at a time, through the five hundred and thirty seven new permissions you need to grant having decided that a lambda configuration needs to be ever so slightly different than it was yesterday, because there's no documentation linking terraform creation of resources and the IAM permissions required to successfully make the AWS API call behind the scenes. Or those for updating a resource, which are different, so you get to do it all again tomorrow. Or deleting - different again. Fun for the day after.

joshcartme 5mo ago

You could probably open the developer tools, find the console elements and extract the data from there to get around copy/paste limitations. I’m not familiar with the AWS console but let’s say it’s an input, select it in the dev tools and then in the dev tools console do $0.value

pseudohadamard 5mo ago

Agreed on IAM, and TFAs comments that once you see the horrendous complexity in IAM you start seeing it everywhere else in AWS as well. And with IAM, after all the effort you've put in, you can never really tell what is and isn't enabled. If you run your own server you can check permissions, run access-control audit scripts, and so on, and say with a pretty good level of confidence that X is possible and Y isn't. With IAM it's more like "I'm pretty sure I figured out the right silly-walk for X, but I have no way to tell what else might be enabled". AWS: I came, I saw, I threw up in my mouth a little, I left.