AWS architecture: API Gateway in microsesrvices

Question

Premises

https://aws.amazon.com/blogs/compute/architecting-multiple-microservices-behind-a-single-domain-with-amazon-api-gateway/
This question is inspired by "Central API account" section in this page.

Background

I am thinking about an AWS architecture with 3 accounts: one for public API (API account), two for different microservices (Microservice1 account and Microservice2 account).
Resources in two microservice accounts should not be accessible from the internet.
These two microservices need to get data from each other.

Ideas (The picture is posted at the end)

Pattern1
I create 2 APIs in API account. Each API is connected to microservice's Lambda function. The problem is there is no internal API, so if microservice1 needs microservice2's data, it may have to use the public API in API account or it directly accesses microservice2's resources (without going through APIs).

Pattern2
To prepare internal APIs, I come up with this architecture: Internet --> Public API Gateway (API account) --> Private API Gateway (Microservice account) --> Lambda (Microservice account). In this case, Microservice1 can use microservice2's private API to get data, and vice versa.

Pattern3
In this pattern, public accesses don't go through private APIs. There are two flows. Public Access: Internet --> Public API Gateway (API account) --> Lambda (Microservice account) Private Access: Lambda (Microservice1) --> Private API Gateway (Microservice2) --> Lambda (Microservice2).

Questions　　

1. Is pattern2 possible? I couldn't find a way to make Public API access Private API.
2. Is pattern3 the most recommended? Is there any other better structure?

Answer 1

1. Is pattern2 possible? I couldn't find a way to make Public API access Private API.

Yes, this is possible. In fact, probably this would be the easiest way of doing it. You can create a private API Gateway in each account and share these gateways with other accounts using VPC endpoints. Each Lambda will have its own trigger inside its own account.

2. Is pattern3 the most recommended? Is there any other better structure?

While the third architecture might work as well, I think it would be more challenging to implement it. It would require something like cross account Lambda integration. Moreover, the Lambda functions will still require their own internal API gateway, so it would not be more effective in saving costs anyway.