[yeukhon]

You need to define “between services”. You mentioned oauth and VPC peering. One is authentication, the other is networking accessibility. There is no one solution.

Generally you have: VPC peering between accounts, Network Access Control List (NACL) for VPC port control, security groups between instances (and some AWS services which uses SG to limit port access), IAM roles to authenticate and authorized certain AWS services to do things (e.gz Lambda to read S3 bucket) - but IAM and policies (bucket policies, SQS policies) govern authentication and authorization. Finally there is also organization service which allows you to control what AWS services are allowrd in a group of AWS accounts.

Sorry, on mobile so I can’t make a prettier list. I am generally disappointed at the complexity of authentication and authorization mechanisms exists for AWS services to be really honest.

[_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".