Out of curiosity, how do people handle communication between services that are in different accounts? VPC peering to connect all accounts? Public Internet and OAuth? Another method?
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.
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.
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...
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".
PrivateLink endpoints between accounts and VPCs if the service must remain private [1], public TLS endpoints either with or without TLS fingerprinting for services that must be public.
"You can create your own application in your VPC and configure it as an AWS PrivateLink-powered service (referred to as an endpoint service). Other AWS principals can create a connection from their VPC to your endpoint service using an interface VPC endpoint. You are the service provider, and the AWS principals that create connections to your service are service consumers."
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.