You may find the following useful if you need to make use of services developed by other teams in the same organisation or you need to make use of third party services, and you want to be more secure and go faster, without having long term architectural disadvantages.

We got interested in this problem because we were losing time in meetings discussing which networks should be connected with VPNs or VPC peering and what private IP ranges should be assigned, and we suspected it was a distraction from real security work. We needed a simple set of principles to prevent wasting time getting into detail on the wrong type of solution.

The solution concepts were

Classify network traffic as service private, enterprise private, or internet.
With enterprise private there is an exposure reduction versus simplicity balance to optimise considering restricting with private IP whitelisting versus leaving the private network accessible to the whole enterprise by default, and similarly with internet of restricting by public source IP whitelisting versus making the service accessible.
Determine if you are integrating with a public-grade service with robust APIs and authentication versus with a non-public-grade service versus using a building block
If it is a third party public-grade service, default option is to integrate over the internet. If public IP whitelisting is convenient to set up, it might as well be used.
If it is a same-enterprise public-grade service, then if there is a default option to keep the traffic within the private network of the enterprise, then this might as well be used. But the same public-grade authentication should still be used. If private IP whitelisting is convenient to set up, it might as well be used.
If it is a building block rather than a distinct service in itself, then it should be accessed from the service’s private subnet only, so network integration of some form is required.
If it is a same-enterprise non-public-grade service, then the traffic is not suitable for the internet, and it should be over the enterprise private network.

The solution in practice

The network simplicity of accessing third party services using the internet rather than additional network integration layers can increase performance. This might not always be the case but it is worth investigating. Note that the services could be exposed on the internet but they could be in the same physical AWS data centre.

With same-enterprise non-public-grade services, private IP whitelisting is a good practice to minimise exposure, but it introduces friction for any new entity that wants to make use of the service. If public-grade services can be made instead, then they can be made available on the enterprise private network and eliminate that friction, still remaining secure, while they can also be made available publicly with public source IP whitelisting if required.

Other Considerations and References...

It is inconvenient when integrating with a third party vendor which has public grade APIs for primary services, if based on the principles here we choose to integrate over the Internet, then the vendor offers additional integrations that can’t be secured satisfactorily. If those additional integrations aren’t really ready, it may be better to avoid them, and put your effort elsewhere.

If you can avoid IP whitelisting then you can avoid some inconvenience. Mandating multi factor authentication has a cost of some relatively small inconvenience to the user but could improve the security profile enough that IP whitelisting is no longer worthwhile. This can give lower friction adoption of services as well as reduced risk, and some users would perceive the use of MFA positively.