[_gfrc]

Oh, sorry, absolutely. I'm actually talking about services that talk to each other using HTTP. One option I've though of is using the public internet to connect them and use OAuth to make sure that they are actually allowed to communicate, solving the security issues on the application level.

Another option would be to allow only access from the internal network, but then you have to connect them somehow.

[yeukhon]

This is a good question. I will simplify this to two rules:

* internal traffic goes through VPC, AWS backone, and Direct Connect / VPN (company and AWS accessing each other). Worth noting that, all S3 requests used to go through the Internet, but now we can enable S3 endpoint so requests originated from VPC is now made within AWS backbones).

* incoming public traffic comes through AWS public infrastructure (e.g. load balancer) before handing off to some EC2 instances (the instance could either be in "public" subnet, or "private subnet")

There is a whole lot of architecture approaches highly dependent on the requirements, and I don't think we can discuss them here.

For one microservice to talk to the other one, if all within the same VPC, you just use security group (Network ACL "defends" subnet, but you are better off just using route table). If not within the same VPC, you can peer. If not within the same account, you can peer. I believe now you can peer region too. In some cases, you have to route traffic from VPC1 to VPC2 through your corporate routing...

[sokoloff]

I'd recommend against the latter in any medium or large organization (and small as well, but sometimes one needs to make trade offs).

That's putting too much trust in the network. You don't want one phished internal user to expose the entire set of services that developers all think of as "on a trusted network".