Yeah

> For example, while running EC2 instances were unaffected by this event

That ignores the 3-5% drop in traffic I saw in us-east-1 on EC2 instances that only talk to peers on the Internet with TCP/IP during this event.

I guess you have to read this kind of items hidden in careful language, running the instances had no problem, it is different matter they had limited connectivity!from AWS point of view they don't seem to see user impact but services from their point of view.

Perhaps that distinction has value if your workloads did not depend on network connectivity externally for example say S3 access without vpc and only compute some DS/ ML jobs perhaps.

How are you measuring this? Remember that cloudwatch was apparently also losing metrics, so aggregating CW metrics might show that kind of drop.

Yeah, I know. This was based off instance store logging on these instances. For better or worse, they're very simple ports of pre-AWS on-prem servers, they don't speak AWS once they're up and running.

Do you use VPC endpoints for S3? The next sentence explained failures I observed with S3: "However, access to Amazon S3 buckets and DynamoDB tables via VPC Endpoints was impaired during this event."

No, I use the normal endpoint.

I could not modify file properties in S3, uploading new or modified files was spotty, and AWS Console GUI access was broken as well. Was that because of VPC endpoints?

"Customers also experienced login failures to the AWS Console in the impacted region during the event"

DAX, part of DynamoDB from how AWS groups things, was throwing internal server errors for us and eventually we had to reboot nodes manually. That's separate from the STS issues we had in terms of our EKS services connecting to DAX.