When companies move to the cloud, they often look for better performance and increased availability. But without the right insights, these companies can run into a number of problems, discusses Kevin Woods, head of product marketing at Kentik.
Cloud networking involves deployment across applications, clouds and data centers, leaving a complicated trail of data sources. The migration often means visibility and understanding of the network are decreased. Unlike the physical network topologies of the past, the network in the cloud is virtualized, highly automated, and thus largely out of sight.
Many companies lack information on how they are using cloud resources. Not to mention, mistakes can occur when deploying cloud resources quickly. In many cases, poor configuration choices can lead to inefficiencies because of the old notion that you can “always go back and fix things.†Unfortunately, it’s also harder to see suboptimal choices after the fact.
See More: 3 Ways To Prepare Organization Networks for the Hybrid Work Era
Five Cloud Networking Deployment Mistakes
If you’re deploying your applications in the cloud, there are five common cloud networking deployment mistakes you’ll want to avoid.
Mistake 1: Repetition of services and unclear dependencies
When organizations have their networks in silos, they may duplicate their services and maintain separate domain name system (DNS) services. A DNS matches the domain name of a website to an IP address. Organizations pay extra for duplicate DNS services rather than combining them into a shared system.
In addition, companies sometimes make one app dependent on a particular DNS service that disappears. Cloud workloads may have moved, causing obscure cloud dependencies. When deploying your network in the cloud, you want to avoid creating a messy set of interdependencies, which can cause outages.
Avoid overlap and duplication while maintaining proper software development hygiene.
Mistake 2: Traffic or request hairpinning
When moving your network infrastructure to the cloud, avoid increasing latency through hairpinning, that is, a bottleneck in the shape of a hairpin in which network traffic is sent back in the direction it came. It involves a service communicating over a long path rather than a short, fast and expedient one.
Hairpinning can occur due to IP routing misconfiguration, resulting in a pricey cloud data transfer bill. Another case involves a DevOps team that moved an application server to the cloud but still has a web frontend and database in a legacy data center. This example brings a drop in performance and an increase in costs. Web requests lead to a chain of calls and extra navigation of cloud interconnects, which are connections between two networks. Â
Mistake 3: Unnecessary inter-region traffic
When companies send cloud data unnecessarily from one geographic region to another, they pay a lot more per gigabyte for inter-region data transfer than intra-region data transfer. The cloud provider naturally incurs more costs, and so they pass those costs along to you. With Google Cloud, for example, data egress between zones will cost 1 cent per gigabyte, but egress between regions costs 11 to 22 cents per gigabyte.
To avoid this problem:Â
- Gain some insight into what contributes to excess inter-region internet trafficÂ
- Move workloads to avoid unnecessary inter-region communicationÂ
- In addition, combine workloads when possible to avoid wasting resources
Mistake 4: Accessing cloud services over the internet from local VPCs
Cloud application developers often use cloud services such as S3, SNS or Route 53. They are convenient and easy to deploy. These services are accessible to the internet using IP address ranges representing services running in a single region.
When cloud engineers stand up new VPCs, they must also set up routing rules that determine how traffic will be forwarded to non-local destinations. Traffic bound toward the internet always follows a default route that points toward a gateway device. Traffic that crosses such a device is defined as internet egress traffic, and AWS charges a rate for egress traffic, even if it’s not necessary for the traffic to egress the cloud.
Luckily, most cloud providers have released new features that are commonly referred to as “endpoint services†that are designed to keep this traffic away from the public internet, thus reducing both data transfer costs and security risks associated with sending traffic over the internet. Endpoint services allow users to configure local network interfaces with private IP addresses inside their VPC subnets. These interfaces then act as proxies for any traffic destined toward the services configured on the endpoint. The end result is that traffic to these services stays local, private and enjoys lower egress pricing.
Mistake 5: Using default internet traffic delivery
Reducing unnecessary egress traffic is important. However, if you provide a cloud-based digital service, at some point, the traffic will egress towards users. It’s important to look at ways to reduce these costs as well.
Consider alternatives to deploying your applications using a default internet egress. They include using content delivery networks (CDN), which cache frequently requested objects on nodes throughout the world and saves companies money on a per gigabyte basis. CDNs also lower latency and increase performance. Also, consider packaging large objects within an app rather than over a network. Route internet traffic over cloud interconnects to the point of presence (PoP) to save money on IP transit. A PoP is a network access point.
By avoiding these mistakes, you’ll have cloud deployments with lower costs and higher performance.
See More: A Safety Net for 5G and Edge: How OOB Network Management Helps Create More Resilient Networks
A Key Reminder for Networking in the Cloud
Clouds make the deployment of horizontally scaled applications significantly easier. It can be easy to believe that much of the network within the public cloud is automated or even invisible. While there is some truth to this, the fact is that cloud providers do not manage the network on your behalf — and they certainly have a conflict of interest when it comes to helping you figure out ways to reduce costs.
Ultimately, you are responsible for the network in the cloud. You need to make cloud networks observable and have the necessary tools to identify costs and performance issues and explore alternatives.
Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.