Expected, yes, but it’s not something you’d necessarily think about I guess. I never thought about the containers being able to access the EC2 metadata endpoint since ECS exposes a container specific one (although they obviously could, in hindsight).

As a heavy EC2 user who hasn't used ECS, the behavior makes perfect sense as ECS is running on EC2 but unless I sat and thought about it my first instinct would be that AWS would make it "secure by default" on a container level since containers often have different permission requirements and so the container would be the security boundary.

That said, I'm guessing it would have been obvious to anyone once they start setting up IAM permissions and therefore not much of a pitfall.

So it's a good reminder, but I agree with you, maybe the article doesn't need to be so long to get to the same point.

the article is a bit breathless, which seems par for the course for security blogs these days. And while "containers are not a security boundary" is evergreen and something AWS has been trumpeting since the beginning, they IMO should also try and make it a bit harder for your to get access to the host credentials.

I do know the ECS team highly indexes on maintaining backwards compatibility and minimizing migrations wherever possible, but this seems like a case where it's warranted.

Not when the documentation states (before the recent change) "a container never has access to credentials that are intended for another container that belongs to another task"