Is there any way to actually enforce this in reality? Eventually some leaf service is going to need to hit an API on an upstream node or even just 2 leaf nodes that need to talk to each other.
Said less snarky, it should be trivial to define and restrict the dependencies of services (Although there are many ways to do that). If its not trivial, that's a different problem.
Ah, you don't mean enforce a novice making a mistake, you mean ensure from a design purity perspective?
I don't think its true that you need requests to flow both ways. For example, if a downstream API needs more context from an upstream one, one solution is to pass that data down as a parameter. You don't need to allow the downstream services to independently loop back to gather more info.
Again, it depends on the business case. Software is simply too fluid to be able to architect any sort of complex system that guarantees an acyclic data flow forever.
Restricting arbitrary east-west traffic should be table stakes... It should be the default and you opt into services being able to reach each other. So in that sense its already done.
The solution requires AWS since the gp thinks that's the only access control mechanism that matters. So I doubt there is going to be little cost about it.
