Understanding your network charges within AWS can often be a confusing task; whether you know what your current estate traffic amounts too, or you are building from fresh and don’t really have a full picture of how demand and usage will develop. Even with the best preparation and planning, charges can often seem to be higher or lower and it can take time and effort away from development to understand why. Below I will go through one or two small charges that are often overlooked, but can add up.
It’s important to understand that when developing within any other Public Cloud provider you are running on someone else’s facilities, equipment and core infrastructure which which is shared amongst all users. The Cloud provider is paying the full upfront costs for implementing the facilities and keeping the lights on within that infrastructure, and in turn the users pay for their shared utilisation of this, effectively paying for it as a metered utility.
AWS are clear and upfront on their charges, but sometimes when developing complex and resilient infrastructure designs, understanding where these charges are applicable can become very complex. Often leading to areas or traffic charges being missed. In general rule of thumb there are 2 main principles people tend to live by:
- traffic Inbound is FREE (with the exception of some traffic processing services such as loadbalancers)
- traffic Outbound is CHARGEABLE
However when looking to design infrastructures that are able to support outages and failures, these rules start to become blurred, mainly because we need to clarify what is actually seen to be Inbound and what is seen as Outbound, what are the lines of demarcation?
This leads us to the first often overlooked and mistaken traffic/data charge, Cross AZ Data Charges. When designing a resilient infrastructure within a single region (geographical area) using servers in multiple Availability Zones (AZ), you will be charged for this traffic even though the traffic has not travelled outbound of AWS. This is most likely due to site to site links having a higher cost to install and maintain by AWS and any 3rd parties (such as ISP’s or dark fibre suppliers). In scenarios where data is leaving a AZ to another within the same region, data is charged, not only outbound of the source AZ but also inbound at the target AZ. For this reason, its important to understand what replication will be undertaken locally to instances within a AZ (local to one another) as this would normally be free, but also be aware of replication that may take place to failover/HA or backup instances within another AZ as this data will be charged.
Expanding on the above, another flow of traffic that stays within AWS that would be charged is Cross Region data transfer. This again has the same reasoning for additional charges whilst staying within the AWS estate, additional cross site links need to be maintained and installed by AWS. However, it does have a different charge pattern to cross AZ data charges, in that rather than being charged for traffic in and out, at both AZ’s, you are charged only for traffic outbound of the region, inbound is free. This charging pattern matches the fact each region is ultimately its own independent AWS company, with its own AZ tolerances, infrastructure offerings and pricing, and when your data flows into one of these “independent AWS'” traffic is free, but outbound is charged.
Lets briefly examine the cost difference between Cross AZ and Cross Region. You may think that because unlike cross AZ charges, you are not paying for inbound that setting up HA or fail-over in another region rather than AZ may be a cheaper way to go (because hey! you get inbound free right?), sadly, this is not the case and in fact both methods more or less balance out. This is due to each charge for cross AZ (inbound and outbound) is around half the cost of the single outbound traffic of cross Region. In reality creating a cross region HA or failover can be allot more costly in terms of compute and your own time in maintenance needed to maintain a infrastructure that can route between regions.
Another oversight and gotcha with charges can come from incorrectly configuring DNS or target IP addresses. If you misconfigure your DNS (either company hosted, or AWS hosted) and these resolutions point to external IP’s (or you simply use instances external IP rather than needing to configure internal and external rules), you will be charged for outbound traffic, as it will leave your “private” cloud and route back into the external public address. Be especially careful of this happening when using cross VPC peers, check your DNS support settings.
When discovering all of these little grey area’s of charges when looking to design HA solutions, I came across a great diagram created and published on Github for the “Open Guide to Amazon Web Services“.
Although the cost may change, I find this diagram a useful tool in being able to quickly and easily see where charges may take place when trying to determine traffic cost