Data transfer, the mother of all costs.
Let's talk about data transfer now that we've discussed indexing concerns. Customers are typically charged for data moved from system a to system b by cloud providers. A system could be your own virtual machine or a third-party service. Databases are not an exception to this rule. Charges are based on the volume of data transferred between the system and the database. If you don't pay attention, this can quickly escalate.
Following are some best practises to follow:
- Projected db queries reduce the quantity of data transferred between systems. Filter and get the data from the database query itself, rather than collecting all the data and filtering it on the server side.
- Keep the instances in the same availability region as much as possible. Keep your database in the same region as your server, for example, if your server is in us-east-1 keep you db in the same region. You will save money and the transfer will be quicker as a result of less distance to travel.
- Configure vpc peering. If the servers are in the same availability zone, you will pay no money at all.
The preceding is true for both regular and micro services. To save the most money, use internal ips for communication between services and set up vpc peering. Make sure you're not communicating with services utilising public ips and load balancer urls, as hidden data transfer charges might add up quickly before you realise it.
For the time being, that's all there is to it. I'll be seeing you around.