10 ms·

When I worked in aws, this is primarily used to check for permissions of an object. I know how dumb customers can be, for the most part this is used to see why

When I worked in aws, this is primarily used to check for permissions of an object. I know how dumb customers can be, for the most part this is used to see why a customer cannot delete a bucket or object those sort of things. I don't remember having ability to see actual customers data only metadata is accessible. Edit: Based on what I know, I'm pretty sure support will not be able see any of the customers data.

StreamBright 5y ago
> I know how dumb customers can be Or how broken is the tooling for IAM + S3 + other services (for example Athena and Glue). Several times I had to explain to support that we do not want s3:* anywhere in our infra because they insisted that is the easiest solution so they do not need to waste their precious (paid by us) time on figuring out which exact permission is missing that I as a customer have no way of figuring out. Many of us working on cloud infra for 10+ years and we still struggle some times to set up especially new services. I really like how you conclude that this is somehow the customer's fault. I find it entertaining how the decent support staff of amazon admits that the tooling is subpar, because they got a different system internally to check out why S3 throwing a 403. As a customer we do not have anything just the API. And no, this is not because the customers are dumb. I can't wait the moment when AWS has to actually compete with other cloud providers because this arrogance has to go.
- time0ut 5y ago
  This. The tooling and error messaging around IAM is inconsistent and lacking. I’ve even seen AWS support be completely wrong about why IAM is denying something, so I am guessing their internal tooling isn’t much better.
  - isbvhodnvemrwvn 5y ago
    I caught on the fact that they have much more finely grained logging than the users do (e.g. underlying specific access denied errors which are covered by a generic one users get), and sometimes report what they see there, with no consideration on the effect on the users. You can sometimes get some details on how the services work underneath. It happened several times with Glue mentioned by the user two replies above (usually schema registry which requires *s in resource element of the policies to work).
trzmiel4 5y ago
> I know how dumb customers can be I find this insulting as a customer. Is AWS usually contemptuous of its customers? I don't think I've ever called my customer "dumb", and working as a consultant I've seen all kinds of interesting things. People make mistakes. They're always in a hurry. They may have a hard time understanding ambiguous, complex or incomplete documentation. The interface may be confusing and lead them to bad solutions. Come on, support is there to help. Take it easy, shall we?
- cgio 5y ago
  As a customer, I don’t take it as an insult, we all can (as per gp) be dumb on occasion, without actually being dumb in general. On the other hand, the comment did not offer much assurance with regards to the topic at hand either.
- twosugars 5y ago
  You sound like never worked in support area.
  - grumple 5y ago
    I've had many AWS support engineers (and higher engineers) look at things in our env and say "I've never seen that before" and have no clue what was happening. It's a two way street. Everybody can't know everything. And remember that many devs in the real world have much broader domains than AWS engineers - I have to know every nuance about 30 AWS services, as well as my own applications and my own domain. An AWS engineer would be limited to having a deep understanding of one or a few services, and has internal experts on individual services to reach out to when they don't have some information. But sometimes even AWS devs might not be aware of a little line in the Lambda docs like "Background processes or callbacks that were initiated by your Lambda function and did not complete when the function ended resume if Lambda reuses the execution environment. Make sure that any background processes or callbacks in your code are complete before the code exits." [1] There are gotchas like this with every service, and missing a single line within the novella of docs AWS provides for each service is not a significant failing. There are also issues and concerns that are completely undocumented and are only learned with experience. As a developer for a SaaS, I have to spend some time on support every day, including for devs who have refused to read our documentation for a particular service we provide (and the only one these devs use). It's frustrating, I know. You should assume that the developers who are your customers are unlikely to be stupid, and are instead just not informed about something or haven't read the docs (maybe they didn't know where to look, or like many, they are too busy to justify spending a day reading the docs for lambda). Best thing to do is direct them to the relevant parts of the documentation and do your best to help those people. 1. https://docs.aws.amazon.com/lambda/latest/dg/runtimes-context.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-contex...
fivea 5y ago
> I know how dumb customers can be (...) This sort of personal attack is unwarranted and extremely unfair. AWS is renowned for it's byzantine and ever-changing and expanding nature, to the point it's outright practically impossible to know extremely basic things such as what are you paying for and how much you are paying.
- go_blue_13 5y ago
  the sensitivity is unreal...in what world is this a personal attack?
- twosugars 5y ago
  Not a personal attack definitely.
Lorkki 5y ago
> I know how dumb customers can be Maybe a more constructive way to look at this would be that people simply do "dumb" things. In customer support where you only see those moments, it might not always seem that way, but dealing with people's simple mistakes is also educating them to do better next time.
- antihero 5y ago
  People can be ignorant, lazy, not give a shit about the work they are doing, have poor learning ability and or skills, and cross their fingers, mashing buttons, hoping everything just works, and then expect everyone else around them to help them out of their screw ups. If you've ever worked in CS, or known anyone that works in CS, you know that there are an absolute fucking shitload of these people. Often in roles they are unqualified for and with privileges and power no sane person would ever give them.
  - staticassertion 5y ago
    That's true. It's also true that AWS's IAM system is pretty complex and not incredibly well designed. AWS internally makes mistakes with it with some regularity.

StreamBright 5y ago

> I know how dumb customers can be Or how broken is the tooling for IAM + S3 + other services (for example Athena and Glue). Several times I had to explain to support that we do not want s3:* anywhere in our infra because they insisted that is the easiest solution so they do not need to waste their precious (paid by us) time on figuring out which exact permission is missing that I as a customer have no way of figuring out. Many of us working on cloud infra for 10+ years and we still struggle some times to set up especially new services. I really like how you conclude that this is somehow the customer's fault. I find it entertaining how the decent support staff of amazon admits that the tooling is subpar, because they got a different system internally to check out why S3 throwing a 403. As a customer we do not have anything just the API. And no, this is not because the customers are dumb. I can't wait the moment when AWS has to actually compete with other cloud providers because this arrogance has to go.

time0ut 5y ago
This. The tooling and error messaging around IAM is inconsistent and lacking. I’ve even seen AWS support be completely wrong about why IAM is denying something, so I am guessing their internal tooling isn’t much better.
- isbvhodnvemrwvn 5y ago
  I caught on the fact that they have much more finely grained logging than the users do (e.g. underlying specific access denied errors which are covered by a generic one users get), and sometimes report what they see there, with no consideration on the effect on the users. You can sometimes get some details on how the services work underneath. It happened several times with Glue mentioned by the user two replies above (usually schema registry which requires *s in resource element of the policies to work).

trzmiel4 5y ago

> I know how dumb customers can be I find this insulting as a customer. Is AWS usually contemptuous of its customers? I don't think I've ever called my customer "dumb", and working as a consultant I've seen all kinds of interesting things. People make mistakes. They're always in a hurry. They may have a hard time understanding ambiguous, complex or incomplete documentation. The interface may be confusing and lead them to bad solutions. Come on, support is there to help. Take it easy, shall we?

cgio 5y ago
As a customer, I don’t take it as an insult, we all can (as per gp) be dumb on occasion, without actually being dumb in general. On the other hand, the comment did not offer much assurance with regards to the topic at hand either.
twosugars 5y ago
You sound like never worked in support area.
- grumple 5y ago
  I've had many AWS support engineers (and higher engineers) look at things in our env and say "I've never seen that before" and have no clue what was happening. It's a two way street. Everybody can't know everything. And remember that many devs in the real world have much broader domains than AWS engineers - I have to know every nuance about 30 AWS services, as well as my own applications and my own domain. An AWS engineer would be limited to having a deep understanding of one or a few services, and has internal experts on individual services to reach out to when they don't have some information. But sometimes even AWS devs might not be aware of a little line in the Lambda docs like "Background processes or callbacks that were initiated by your Lambda function and did not complete when the function ended resume if Lambda reuses the execution environment. Make sure that any background processes or callbacks in your code are complete before the code exits." [1] There are gotchas like this with every service, and missing a single line within the novella of docs AWS provides for each service is not a significant failing. There are also issues and concerns that are completely undocumented and are only learned with experience. As a developer for a SaaS, I have to spend some time on support every day, including for devs who have refused to read our documentation for a particular service we provide (and the only one these devs use). It's frustrating, I know. You should assume that the developers who are your customers are unlikely to be stupid, and are instead just not informed about something or haven't read the docs (maybe they didn't know where to look, or like many, they are too busy to justify spending a day reading the docs for lambda). Best thing to do is direct them to the relevant parts of the documentation and do your best to help those people. 1. https://docs.aws.amazon.com/lambda/latest/dg/runtimes-context.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-contex...

fivea 5y ago

> I know how dumb customers can be (...) This sort of personal attack is unwarranted and extremely unfair. AWS is renowned for it's byzantine and ever-changing and expanding nature, to the point it's outright practically impossible to know extremely basic things such as what are you paying for and how much you are paying.

go_blue_13 5y ago
the sensitivity is unreal...in what world is this a personal attack?
twosugars 5y ago
Not a personal attack definitely.

Lorkki 5y ago

> I know how dumb customers can be Maybe a more constructive way to look at this would be that people simply do "dumb" things. In customer support where you only see those moments, it might not always seem that way, but dealing with people's simple mistakes is also educating them to do better next time.

antihero 5y ago
People can be ignorant, lazy, not give a shit about the work they are doing, have poor learning ability and or skills, and cross their fingers, mashing buttons, hoping everything just works, and then expect everyone else around them to help them out of their screw ups. If you've ever worked in CS, or known anyone that works in CS, you know that there are an absolute fucking shitload of these people. Often in roles they are unqualified for and with privileges and power no sane person would ever give them.
- staticassertion 5y ago
  That's true. It's also true that AWS's IAM system is pretty complex and not incredibly well designed. AWS internally makes mistakes with it with some regularity.