Many FinOps practioners have missed a smaller but important element in their cloud cost optimization approach. Often, organizations zero in on the actual workloads services to deliver, scale and support end applications to grow the business. This is 100% natural and the correct approach for companies. However, the connectivity options to support public cloud between multiple regions, off-net datacenters, corporate networks and even vendor requirements should be reviewed with expert certainty.
Since FinOps is about building a culture focused on financial accountability across cloud services including the data networking component should be a natural progression. This focus can start at the walk phase as it becomes critical FinOps and Cloud teams take the right architectural approach vs. simply the cheapest option. Zeroing in on how public cloud connectivity can include the Network Team, Ops and Finance will be a welcomed approach.
What is AWS Direct Connect?
AWS Direct Connect is the onramp into their public cloud infrastructure which allows organizations to route traffic directly into your tenancy. More organizations require a direct connection into AWS for their corporate configurations however if not configured correctly, unnecessary time to setup, provisioning pitfalls and hourly/monthly charges can easily cause costs to skyrocket.
AWS Direct Connect Considerations:
Let’s start by slowly going through how Direct Connect is defined, provisioned and costs associated with each option. It should be noted, simply selecting the most cost-effective option is not always the best strategy as it could impact the ability to reach your infrastructure correctly and with minimal latency. There are three main options to route traffic into an AWS environment; Dedicated, Hosted and Sitelink.
AWS Dedicated Connections: Dedicated Connections are the physical connections the Network team has enjoyed or complained about from their carrier, traditionally from a telecommunications carrier. This network connection exists from your network, either from a Wide Area Network (WAN) or a singular connection established such as a Layer 1 Private Line or VPN over the public Internet. The dedicated method your organization provisions is then connected to your AWS network port within the AWS Direct Connect region your infrastructure resides. AWS Feeds for this dedicated port are hours billed as long as that port is provisioned for your infrastructure on Direct Connect.
FinOps Crawl understanding of AWS Dedicated Direct Connect
Cost Considerations for Dedicated Connections unlike traditional components in public cloud can vary. Yes, variable spend exists across application and database tiers, however the variable spend we are referring to in dedicated connections is the 3rd party vendor environments used to route traffic into your AWS instance. This is why many in FinOps should clearly understand you may stay in the crawl phase for a long time as vendors, especially telco carriers do not publish their monthly charges.
How much does AWS Dedicated Direct Connect Cost?
This can be a complicated answer depending upon the use case you encounter. There are two major players in this equation, AWS and how you build your Dedicated connection. Let’s begin with the AWS portion first as there are formulas to help achieve a good budgetary understanding. In the Dedicated Direction Connection scenario, there are three main components to understand, plan and then reallocate costs back into the business: Port Hours, Data Transfer Out (DTO) and Capacity. At Macronet Services, we call this CP+DTO calculation. First let’s define how the CP+DTO calculation covers a dedicated connection.
What is Capacity? Capacity is the highest rate that data can be routed through a network connection which can vary from megabits per second (Mbps) or gigabit per second (Gbps).
What are Port hours? Port Hours is a measurement of the time a port is provisioned for direct connection within your environment. An important item to note, this calculation continues to occur even if you are not routing data through your port, you are still charged.
What is DTO? DTO is the total network traffic that routes from Direct Connect to a destination outside of AWS. This will certainly fluxuate and can be difficult to reduce since lowering traffic volumes would mean requests leaving a destination for your business would be impacted. The good news here, AWS does not charge for any data transferred into your environment, only when it departs.
How to calculate the CP+DTO equation
Below is a fictional example of a customer who requires (2) dedicated ports each with a 1Gbps port capacity for AWS East and West. Assuming the cloud team left the port on/live for an entire month
Capacity & Port
DTO
CP+DTO = ($438 + $4217.46) = $4,655.46 in a 1 Month Window
An important note here, no matter how much traffic you push on an hourly basis, you are charged a Port Hours Rate for having the circuit established to your Direct Connect On Ramp.
However, we are not finished with the total calculation for the month as we still need to factor in the outside connection for direct connect, typically offered by a carrier. If you decide on a telecom carrier connection for example, such as a private line or internet VPN, you must factor those costs into your final allocations. Many FinOps teams forget this piece because it is subtle and varies by vendor or connection method (VPN, ZeroTrust, SDWAN, MPLS etc.)
The final OPEX for AWS Dedicated Direct Connect should calculate as this:
=>CP+DTO + 3rd party Connection Method = Total Cost for Dedicated Direct Connect. However, keep in mind, your DTO will vary and if your cloud teams turn off any ports, these areas will always vary.
Identify 3rd Party Connection Methods that are Cost Effective, Reliable & Secure by contacting Macronet Service her. We can architect and cost out unbiased options across hundreds of carriers.
How to create a FinOps Team focused on Cloud Connectivity?
- Network Experience: That’s right, you will need someone with experience on how general WAN and LAN works across multiple vendors and how your data should route to AWS.
- Cloud Experience: Ultimately your practioners must have some cloud experience. Their ability to articulate the inner workings of how instances are deployed, managed and accounted for into terms Finance can start to understand is the first step. Finance generally does not understand how Kubernetesworks or why it’s deployed or how the Spot market with AWS can support upwards of 90% off in EC2 for short periods (once they understand Spot, invariably the first question they ask is “How can we use Spot all of the time for lowered costs???!!!!” )
- Impartial Information:If they are reporting out on a daily or worst-case weekly basis of cost over runs, this team must expect the engineering organization to execute the changes. Removing the budget and cloud cost allocation away from any one development team, placing it within FinOps will ensure there are no concerns of hidden agendas.
Cloud “Accountability” is a must to have a successful FinOps practice. Knowing that many tech teams are not jazzed about costs and financial terms and Finance teams equally do not understand cloud tech.
“Over 50% over the organizations Macronet Services polled did not even know what FinOps was. The result is there is a huge opportunity to optimize and iterate!” |
Who is involved in the cloud network for FinOps?
- Management:Often the leads of the Network Team, Engineering or CIO/CTO for larger enterprise organizations. In smaller, cloud native companies, this could move closer to the CTO and each leader might have a player/coach role in their cloud dev and product fulfillment thus an even more reason to have a central FinOps practitioner team.
- FinOps Practioners:Titles can vary however in the end it really comes down to who is serving as the practioners between tech and finance to support your org. Many folks should be involved and may look like Cloud Operations, Cloud Cost Optimization Manager, FinOps Analyst and Cloud Operations Manager.
- Dev/Engineering:They are the creators of the platform you deliver to customers using public cloud for example. These highly skilled individuals need to be aware of their good work and how it impacts the bottom line. Providing these teams, a cost KPI/Metric in the same workflow fashion they would receive on performance/IOPS etc. is critical. If Finance truly feels this group does not understand costs associated with their workloads and nobody points it out daily, well, they are right. If you want cost control and awareness but do not provide the numbers (regardless if there is an overrun) how can you expect it to change? Engineering will be the team to rightsize the platform, so you need to provide an output they can relate to, iterate and adjust.
Finance Department: They take the reporting from the FinOps organization to build their modeling, accurately forecasting the cloud contribution to the business. However, if the cloud ops team constantly speaks past them with jargon (take the propeller hat off) and does not break it down, they will be lost. In fact, many organizations have the same definition just a different term associated with various components in cloud. So, one easy knockdown win is to decide holistically as a company, common terms for your business vs. those a vendor would prefer. This might be a Marketing Manager’s worst nightmare not using the cool terms for their platform you are renting hourly but in the end the goal is to speak the same language, not having an interpreter.