NAT'ing is primarily done so that a cloud-hosted VM can initiate connections to network-hosted resources outside of its private network(s) (e.g., so a Linux VM can reach public patch/software repositories when doing patching/updating ...if you aren't simply nuking-and-replacing rather than patching). For intra-cloud communications, NAT is going to be infrequently required (depends how segmented your service-design is). Similarly, for providing a service to external clients (e.g., a cloud-hosted web-service), you're going to be using something like a load balancer or similar type of connection-proxy that's optimized to be performant.
In short, you're not typically going to be doing much actual NAT'ing — at least not compared to other network-based usages — in a production cloud-setup (I'll caveat this to explicitly exclude Docker/Kubernetes clusters ...though those use internal NATs and optimizations to ensure efficient use of network resources).
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.