There are no data transfer charges between AWS resources when the resources reside in the same AZ and use the same VPC and connect via private IP address.

You should leverage this information to architect how your services talk to each other and minimise your data transfer costs.

Unless you know what you are doing, it is better to keep all your resources in same AZ and same VPC. Always use private IP assigned by AWS to communicate between various services.

Multi AZ deployments

Going multi-AZ adds redundancy and fault tolerance to your setup. It however comes at a cost.

  1. In most cases, you’ll be incurring 2X of your existing infrastructure costs. If you have 1 app instance and 1 database instance, you’ll have to create a similar setup in another AZ.
  2. You’ll incur additional charges in data transfer costs between the two AZs. For example data replicating between the databases.

While it makes sense for mission critical applications, in most other cases it does not make sense to go multi-AZ. The costs are too high to justify the minimal impact on business. You can achieve continuity of your business operations by implementing a sound backup and restore strategy.

Going multi-AZ has to be a business/finance decision. Engineering teams must not implement it just to scratch their itch.

Multi region deployments

Multi region deployments are even more expensive and complex than multi-AZ deployments. There are very few reasons to go multi-region.

  1. Data residency requirements which require workloads to operate within a geographical territory and data to reside within those territories.
  2. Improving performance and customer experience by running the workload at a location near to the customer’s geographical location.
  3. Very strict high availability requirements that the company believes can not be met within a single region.

Do you have to be multi AZ or multi region?

It depends on your scale and your business. A banking application will have a different availability requirements as compared to your restaurant’s website. It also depends on the SLA you promise to your customers and if they are willing to pay for those extra 9s. In a vast majority of cases, a carefully crafted backup and restore strategy can be more than enough.

Are you consciously multi AZ or multi region?

In many cases, I have seen that teams unintentionally spin up instances in different AZs. Many a times this happens when there is no clear ownership around resource creation. When everyone in your team has the freedom to spin up instances, some people will inadvertently create misconfigured resources (wrong AZ, region, etc). If this is the case with your org, you should plan and move all your resources to a single AZ over a single VPC and establish all communication over private IP addresses.

Some Tips