It's normally best to use dynamic IP addresses for services, but occasionally a static IP address makes sense. Read on to find out why.
Dewan Ahmed
|RSS FeedSenior Developer Advocate
Subscribe for the latest news and insights on open source, Aiven offerings, and more.
Of the many moving pieces of an infrastructure modernization project, networking is a key one. Imagine that you are a consultant on a modernization project where the data has been migrated to (Aiven) cloud databases but some legacy applications are still on-prem. These legacy applications and their network firewalls expect static IP addresses and ports. In this article, I will discuss the use cases for static IP addresses for data infrastructure and point you to some resources to use them with Aiven resources.
The on-premises enterprise applications for the modernization project need to read from/write to cloud databases but the security engineering organization has a network firewall rule that automatically denies all incoming and outgoing addresses/ports except a few in an allowed list. Here's what the system looks like:
You might have noticed that cloud databases are referred to by their hostnames and not by IP address. This ensures that even if the underlying IP address changes over time (for example, during a maintenance window), clients can still talk to the database instance using the same fully qualified domain name (FQDN) or service name. This is a blocker for your setup since the firewall rules for the legacy applications only accept IP addresses that they can add to an allowlist for any incoming and outgoing connection.
A more common scenario is that your application is hosted on the cloud but your on-premises database is behind a firewall. These situations need a static IP address on the cloud resource so that the firewall can be configured to allow the incoming or outgoing connection.
The client for the modernization project requested that you integrate a third-party metrics collection service and a legacy backup application into the cloud database. You found out that third-party and legacy applications have something in common. Both of these applications expect an IP address rather than a hostname when connecting to a database.
While you can try to add a custom DNS resolver, that could add performance overhead, and would be a larger infrastructure initiative which might be too much to take on just to solve a single point-in-time problem.
Although not widely used, a static IP address can be a great solution to scenarios like the ones above. For the IP-based firewall rule, you can easily allow the IP address and port numbers for your cloud resources.
Keep in mind that these are network firewalls, which are
layer3/layer4
firewalls, and not Web Application Firewalls (WAF),
which are layer7 firewalls.
If your on-premises application is behind a firewall that needs to talk to an Aiven service, you can create static IP addresses on Aiven using the console, Aiven CLI, or Aiven Provider for Terraform. For high-availability and failover, you would want to ensure that there are a sufficient number of static IP addresses allocated for your services.
As a rule of thumb, if you have up to six nodes, you want twice that number of static IP addresses, and if you have more than six nodes, you want number of nodes + 6. There's a cost of consuming static IP addresses but you can assign these IP addresses to any of your Aiven services. Calculate and reserve static IP addresses beforehand and Aiven can provision these static IP addresses on the cloud of your choice for you.
Thanks to appropriate use of static IP addresses and the smooth configuration of Aiven resources, the infrastructure modernization project was completed successfully. Hopefully, you took away some of the use cases of static IP addresses and how you can set one up for your Aiven services.
And if you don't want the hassle of managing your own data infrastructure, please give Aiven a try.
