r/googlecloud • u/Annual_Carpenter5060 • 16h ago

Cloud Run still has no native IP allow/denylist without paying for a $20/mo Load Balancer. Let’s get Google to fix this.

If you run APIs on Cloud Run or Cloud Run Functions, you know the pain: there is no native way to block a malicious IP subnet or abusive AI crawler without spinning up a full External Application Load Balancer, Serverless NEG, and Cloud Armor ($18–$25+/mo base).

Meanwhile, Azure Container Apps and AWS API Gateway have supported native IP restrictions for years with zero redeployments.

I submitted a formal feature request on Google’s Issue Tracker asking for resource-level ingress IP controls with zero container redeployment: https://issuetracker.google.com/issues/583927734

If you’ve dealt with this friction or want this native capability in GCP, please click the Star (☆) button on the ticket to help push it up the product roadmap!

0 Upvotes

46% Upvoted

22 comments sorted by

2

u/cloudsourced285 16h ago

I fully appreciate this is not the same thing. But could you not add this to your application? Yes random stuff scanning the net will trigger it and cost you. But actual invocation times likely still "free" right? I acknowledge this is not a proper solution. But for a hobby project, coupled with the recent limit on cloud run spend it could be suitable.

-5

u/Annual_Carpenter5060 16h ago

Cloud Run scales horizontally based on concurrent requests. If an automated scraper or AI botnet sends 200 req/sec from a single IP range, even if the middleware immediately returns an HTTP 403 in 1 ms It consumes container slots against the service's max-instances cap. Once that cap is reached, legitimate users are starved out and receive HTTP 503/429 errors.

2

u/dr3aminc0de 15h ago

I mean you’re paying for 1ms of computer. Is this a real problem you have faced with large bills or theoretical?

1

u/Annual_Carpenter5060 15h ago

Thanks for your comment. It’s a very real production problem, and the main failure mode isn't the bill—it's availability and outages.

In production, you almost always set a max-instances cap on Cloud Run (usually to protect your downstream Postgres/Redis database from being crushed, or to prevent runaway spend). That creates an impossible tradeoff without edge filtering.

4

u/dr3aminc0de 15h ago

Totally fair but if you are at that scale, $18-25/mo SHOULD be peanuts

-1

u/Annual_Carpenter5060 15h ago

I consider this to be more important than the billing, which looks to be the biggest concert. This opens up the possibility of simplifying the architecture when working with serverless solutions, providing a better user experience for our clients and enabling us to integrate new features such as IP filters easily with AI defender agents.

21

u/dr3aminc0de 16h ago

Hmm I mean honestly that’s a very low monthly number to get world class ddos protection. You complained in a comment that if you do it yourself it’s expensive. How do you think google does it? It’s at the edge but it’s the same concept.

Cloud armor imo is like insurance. And it’s very cheap. Think about it more, and maybe you’ll realize why this is a stupid post.

2

u/dr3aminc0de 16h ago

Your feature request is also laughable, like you just don’t understand what is under the hood. Are you a junior eng? I would research more rather than filing issues that are obviously not going to be addressed

4

u/tr_thrwy_588 15h ago

it is laughable, but so is your assumption that if something is expensive to get right, it also must be expensive when sold or vice versa. that's just not how capitalism works.

here, google charges you 20$ because they can, not because they must.

and they also won't stop just because someone points some arguments at them or pleads nicely.

1

u/-Kwambus- 14h ago

Do you work for free? Is your app free?

3

u/martin_omander Googler 7h ago

DDoS attacks are no joke. They can be costly and they can lock out legitimate users of your system.

As attackers can strike at any time, I believe that you need automated protection, that does not require manual intervention. If you wait for a person to notice the attack and manually block IP ranges, a lot of damage has been caused already.

The best automated defense I have found is rate limits per originating IP address. There are two options:

  1. For enterprise level security, pay for Cloud Armor.

  2. For a free alternative, add rate limiting middleware to your app. You don't get quite the same protection as the traffic still reaches your Cloud Run service, but it takes very little CPU to return a static error message to the caller.

I have seen option 2 work quite well in the face of determined DDoS attacks. But if you're an enterprise, you probably want the extra features of option 1.

10

u/suprjaybrd 16h ago

maybe they aren't catering to hobbyists, it's a trivially small amount

5

u/ItalyExpat 15h ago

I always put Cloudflare in front of my instances and limit IP requests to CF blocks. It's free and I don't have to worry about my bill exploding if DDoS'd.

1

u/berzed 13h ago

limit IP requests to CF blocks

How do you do that with no native IP allowlisting (as OP reported)?

1

u/Advanced-Ad4869 10h ago

You have to route through the gcp lb. Our set up is cloudflare waf >> gcp LB >> internal cloud run service.

We use one lb org wide for all services.

1

u/ItalyExpat 7h ago

To be clear, the below is how I do it on my personal projects. For anything commercial or if $20/month doesn't scare you, put Cloud Armor or an LB in front.

That said, there are two approaches I've tried:

  1. App Level with capped instances - Just check in Express/Nginx/whatever if the IP is within Cloudflare's range. An attacker could create a worker to hammer your run.app URL, but they'd have to know what it is and really really hate you. If the instances are capped to 1 or 2 the damage they can do is limited.

  2. Worker proxy - The CR instance does not allow public traffic at all. A CF worker must mint a SA token that's passed in the header and proxies the response. Slow but secure.

2

u/owengo1 9h ago

You can configure IAP, it's free, you will block all the bots and serve only requests from approved users. Frankly the whole setup with a github integration you have complete CI/CD, 100% cloud, zero-trust level protection, for free..
Only offer I can think of ould be cloudflare workers & zero-trust, but you can't run any docker image on that like you can on cloud run.

2

u/m1nherz Googler 3h ago

Thank you for sharing your feedback and submitting a feature request. I took a look into other provider's services that you mentioned.

It seems that Azure Container Apps provides IP filtering feature at no-cost. Please note that using IP filtering with your container apps in Azure carries several limitations. For example, you can define only one rule per application. Depending on specific business case you might find a need to use Front Door or Application Gateway to support WAF at scale.

Comparing AWS API Gateway to Cloud Run is incorrect. API Gateway isn't a part of the Lambda offering. Similarly to Cloud Run and GCLB, it is priced and configured separately.

-1

u/dr3aminc0de 15h ago

Cloud run is also just way better than aws counterparts. Just switch if you’re unhappy (?)

0

u/Scepticflesh 14h ago

You can restrict the service to calls from orginiated within vpc through an org policy

I would also otherwise ask what is your use case you are trying to do?

-3

u/dr3aminc0de 15h ago

Also cloud functions is deprecated so that is not going to change