[kerng]

This is incorrect, at least from a logical POV and why it's hard to trust what cloud vendors say. A statement like this is either naive (most likely) or actively attempting to mislead.

Technically, its absolutely possible. Most likely you'll just need a support ticket or bug, and then you can troll around as engineer.

Also, security teams also usually have access to stuff when things get interesting.

Better to say that access is strictly on a case by case basis and monitored thoroughly.

Ideally customer is notified each time it happens - that would be cool, but likely technically not possible since data ends up in so many systems (like logs, SIEM, telemetry, debug files, backups, data scientist desktops,....)

[donavanm]

> Ideally customer is notified each time it happens - that would be cool, but likely technically not possible

You're underestimating the investments that AWS (and Amazon at large) make in to security, confidentiality, and auditing. You're also missing a fundamental implication of building AWS on AWS primitives.

As a relevant example there is only one AWS IAM and one CloudTrail. It's a core tenant of AWS IAM to put that control and root of trust in to the customers control. That means when developer support is helping with your ticket they do so via your accounts AWSServiceRoleForSupport role. That means you can control whether that role exists, which principals can assume it, the capabilities it has, and you can see those same API calls in your CloudTrail logs. Although it would make support difficult you're welcome to delete that service linked role and prevent support.amazonaws.com from assuming said role in your account.

https://docs.aws.amazon.com/awssupport/latest/user/using-ser...

[kerng]

Yes, those are great features for compliance. But you seem to believe that your AWS instance is indeed yours. IAM is a concept built on top of lower level primitives that you do not control, but Amazon does.

I'm not talking about Amazon SSH into your EC2 instance - but of course they can do that also - at will, without you authorizing it.

Lower level disks, logs, hypervisor, telemetry, etc.. are accessible beyond your control.

[donavanm]

> IAM is a concept built on top of lower level primitives that you do not control, but Amazon does.

Of course there are lower level primitives. And if the public documentation and observed behavior is insufficient I encourage you to inquire more about the various compliance, certification, and third party auditing programs in place https://aws.amazon.com/compliance/programs/. However at some point this approaches solipsism and I can’t prove a negative in a HN thread.

> I'm not talking about Amazon SSH into your EC2 instance - but of course they can do that also - at will, without you authorizing it.

No. Extraordinary claims need evidence. Either you have serious non public information counter to many AWS statements ... or you misunderstand some fundamentals of SSH and public key cryptography.

> Lower level disks, logs, hypervisor, telemetry, etc.. are accessible beyond your control

I would encourage you to read the AWS data privacy statements https://aws.amazon.com/compliance/data-privacy-faq/. Particularly the definitions of “customer content” and the “shared responsibility model.”

[ikiris]

This really isn't how modern security works at most cloud companies. Even if you have root class credentials or the ability to escalate to them in some way (and that's a big if by itself), its a LOT of steps to get access to customer data, almost always involving broken glass, many protection layers, and often requires cooperation of multiple other root level people/credentials from completely different teams.

Depending on how the infrastructure is built, or what the particular service set up, it may not even be possible to gain access to specific data without extraordinary means, possibly involving replacing physical hardware.

[whoisjuan]

I already corrected my statement in another reply. You're right. I said probably only a handful of people can access customer data to do their job. I personally never met one. The goal of my comment was to illustrate that in my experience handling customer data there was a big deal. It's not like something you can casually query to see if a particular customer has a good business or not.