Its been a couple of years since I first introduced my solution, and since it is still something that pops up on a regular basis, I thought i’ll provide a couple of updates on how to best proceed with static ip.
Some of you who have written over the years needs static ip for certain services, external apis or database access, so I hope I can provide a bit of insights to everybody.
Current solution
That current solution that I (and many others I feel, based on the number of PMs I have received) use, is proxying any database calls to a service in AWS called Lambda. Bubble itself uses lambda for things like backend workflows. The great thing about Lambda is that it is next to free for any low to medium usage, and you only pay for what you use. It’s a small container that spins up in 100ms and does some work for you and returns an answer. So the basic concept is, that Bubbles api calls your lambda at AWS, and the Lambda calls whatever services needs called and returns an answer.
The Lambda can be configured to run with a static ip address, so that any calls from the lambda to whatever external service you need to connect to, will have the same ip each time. This ip can then be whitelisted.
This works great in many instances, but it’s not without issue. The main issues are:
- Complexity
- Latency
- Pricing
Complexity
There is some code involved by using this solution. First you need som insights into how to navigate the world of AWS. Any mistakes can be quite costly, so any non-developers (and a lot of regular developers without cloud experience) should stay clear of this step! There is no way to set a budget at AWS, and mistakes has been known to bankrupt companies.
Besides coding the infrastructure, the lambda service or services needs to be programmed as well. I might just be a couple of lines of code, but still, you need to know what you are doing.
Latency
Next is latency. As you might know, bubble has to ways to make api calls - from server or client. Making calls from the server is more secure as the client (and anyone looking at network calls) cannot see what data is sent.
But this adds latency. Bubbles servers are running in AWS services in US-West (if im not mistaken!). Consider a user from EU visiting a page and when clicking some button we need to make a call through our lambda.
First, the click happens in EU and sends data to the server in US-West. That’s easily 2-300ms. Then Bubbles backend forwards the call to your lambda. Depending on where you run the lambda from (US-West, EU-Central etc.) you can add anywhere from 50-300 ms again. Then the lambda needs to boot up. That’s anywhere from 0-100ms. Then the lambda needs to make its call to any service. That might be another 100-200ms. Then the response needs to go the same way back.
Om total, you should expect anywhere from 500-2000ms depending on region, whether the lambda is warm or not, external service latency etc. This, for many, is not optimal.
A way to work around this, which I use also, is to make calls from the client. I, and my users, are in EU and so are any services that I use. These calls are not as secure though as the users can potentially see any data being forwarded. It’s fast though, roughly 150-200ms on average. I do use some, again advanced methods, where I create JWT tokens for each user each 15 minutes they are logged in, but this I can explain in another post at another time 
Pricing
As I wrote earlier this solution has been almost free for me to use for several years. That’s because AWS has a very generous free tier, where they provide some of their services for free with certain limits.
This will not continue though. As per February 2024, AWS will charge for any static ips (v4) configured in an account. The price will be $0.005/hour (with regional changes), so still fairly cheap at $3.6/month. They will offer a static ip for new accounts under the free tier model for the first 12 months. Not the end of the world, but should be noted.
Other solutions
So as you might realize, the solution provided above is not optimal. There is some coding involved, and the latency is non-trivial.
I am not going to change my solution in the forseeable future as it’s too much work and the current solution is rock solid for me. But if I were to start over, and had the budget, I would probably do it differently today. Here are a couple of suggestions:
AWS Global Accelarator
The general setup is explained in the post below. I would change it so Api Gateway just proxied its call to any external service.
This setup I reckon would be the optimal, but also the most expensive at roughly $50-60/month. There would be no coding besides infrastructure and the latency will be quite low - probably in the 50-100ms range.
Using an EC2 instance as proxy
Using an EC2 instance with a static ip you could make a catch-all mini-server that just receives any call (from Bubble) and forwards the call. An EC2 can be run for roughly $5/month + the static ip. For added resilience throw in load balancers (ALB and NLB) - but this begins to add some cost!
This solution will add some complexity in the form of code, but will be much cheaper. You will need to monitor the instance/s as well, and update them on a regular basis. None of this is hard, but should be mentioned. Latency will in the same ballpark as with Global Accelerator.
Other providers
It might be obvious, but I am pretty deep into the AWS ecosystem. But there are other providers. I suggest going with one of the big ones, so mainly AWS, Microsoft/Azure, Google or maybe Digital Ocean.
Link to the repo
If you still want to jump into this, or are just curious, you can find the repo right here: https://github.com/simon-dk/BubbleApiProxy.
Good luck, and remember to be extremely cautious if you begin to make any setup in AWS yourself as a beginner. It is not fun to get a $25.000 bill because you put a checkmark in the wrong box.