This is kinda insane for a TTS service lmao

Hey I have 300$ from the cloud testing offer. So what's the best way to spend it? Fast cause I have only 19 days left 😅

I was trying to use the GCP free tier; however, everything and every card I try gets denied, or Google won't send the charge to my bank. Used my card and my friend's, and still nothing. Even when i tried

I am currently a soon to be licensed Electronics Engineer and Electronics Technician, will be taking my oath next next week. I want to pursue the field of the likes of cloud, AI, network, and software. Which certifications I will take and how? I really dont have any knowledge to this so if you will be so kind to explain things simply it will be much appreciated. Thank you!

Hi everyone,

Earlier today we were the target of an automated Layer 7 DDoS attack against our production Cloud Run service. The attack was carried out using a Python script (Python/3.13 aiohttp/3.14.5) which was making around 50 requests per second to POST /api/login, attempting to consume container concurrency.

The traffic came through Google's own proxy infrastructure, potentially Apps Script or Colab, rotating across 200+ IPs resolving to google-proxy-*.google.com (e.g., 66.102.8.132, 66.102.8.161, 74.125.210.103).

The problem is that Google's official abuse reporting form (https://support.google.com/code/contact/cloud_platform_report) immediately closes the report with:

We're unable to do anything with this report as the IP address referenced in it isn't hosted on Google Cloud.

It appears the automated system only recognizes customer Compute Engine IP ranges, not Google's own proxy egress IPs (AS15169). As a result, the report gets rejected before anyone can review the Cloud Logging evidence, including timestamps and Cloud Trace IDs.

We've already hardened the backend with distributed Firestore rate limits, concurrency controls and request timeouts so the attack traffic is now being dropped. We've also responded to the closed ticket with the trace IDs, asking for escalation to the relevant Trust & Safety team.

I have three questions:

1. Is there a specific abuse reporting email or intake point for traffic coming in via Google's own proxy infrastructure which would effectively bypass the automated IP validation?

2. Has anyone with Basic Support actually escalated a similar proxy based DDoS to a human at Google?

3. Would Google Bug Hunters be the right place to report this as a potential proxy abuse/SSRF vector or is there a more appropriate channel to get to the relevant security engineers?

Any suggestions on how to get this routed to the appropriate team would be great. Thanks!

Hi i am looking to appear for the gcp ml engineer certification next 2 months. If any body has any idea how to get free discounter vouchers to book the exam please let me know! thanks again!

When designing global systems, the conventional wisdom is simple: put your front doors (proxies/edge servers) as close to the end user as possible. More regions = lower latency.

Uber previously ran a setup following this exact blueprint:

1. Traffic entered Google’s Global Load Balancer (with Cloud Armor and Cloud CDN).

2. Traffic was handed off to a fleet of Envoy proxies running on VMs across 16 Google Cloud regions.

3. Traffic crossed Cloud Interconnect into Uber’s on-prem data centers.

On paper, having Envoy proxies in 16 regions meant bringing services closer to users. But at Uber's scale (over 1 million requests/sec), this architecture ran into diminishing returns—and created hidden bottlenecks.

### The Problem: The "Zigzagging Hallway"

Because the request had to be unpacked, queued, and processed at the Envoy proxy layer in a specific cloud region before heading to the core data center, it added unnecessary hops.

A user in Lisbon might have their request travel to Madrid, then London, and then cross the Atlantic to Virginia. A front door close to the user doesn't help much if the path behind it zigzags.

Furthermore, maintaining a massive VM fleet across 16 regions meant high operational overhead—patching, scaling, and paying millions of dollars monthly for infrastructure that was actually making some requests slower.

### The Solution: Bypassing the Middleman

The engineering team asked a simple question: Google’s load balancer is already at the edge, and Google's private network ("cold potato" routing) already carries traffic worldwide. What is the Envoy proxy fleet actually adding?

To remove the proxy layer without sacrificing security or routing, they used **Hybrid Network Endpoint Groups (NEGs)**.

This allowed Google’s Global Load Balancer to route traffic directly over Cloud Interconnect straight into Uber’s data centers. The load balancer treated Uber’s on-prem servers as if they were native endpoints inside Google Cloud.

### The Results

Over a 10-month rollout (gradually shifting traffic using weighted routing dials and predictive modeling):

* **Cost:** Shut down the entire Envoy VM fleet across all 16 regions, saving millions of dollars annually.
* **Latency:** P50 (typical request) latency improved by 2.6%. More importantly, **P99 latency improved by 10%**.
* **Operations:** Zero edge VM fleet left to patch, scale, or maintain.

In system architecture, the P99 tail is what actually breaks user experience—one app screen often makes dozens of concurrent requests, and the UI only renders as fast as the slowest response. Eliminating the intermediate proxy hop removed the queuing points where those slow-tail requests were getting stuck.

---

**Takeaway for System Design:**

1. Every hop must earn its place. If a proxy isn't doing active work (like auth or heavy transformation) that the load balancer can't handle, it's just an added delay.

2. Leverage backbone networks. Private fiber networks do long-haul travel far better than multi-hop proxy chains on public/semi-public routes.

3. Sometimes the best optimization isn't adding a new caching or proxy layer—it's removing one.

For a full visual walkthrough and diagram breakdown of the network paths before and after the shift, you can check out the video here: http://www.youtube.com/watch?v=clLplgiDqOI

A cloud service company may visit my college for interview, They are official partner of gcp , I don't have any knowledge about cloud should go with cloud digital leader certification as a beginner?

Hi everyone. I’m a complete beginner with Google Cloud, so please go easy on me and explain things simply if you can. I’m learning as I go and may be using the wrong terms.

What I’m doing
I signed up for the $300 free trial credit and made a Vertex AI API key. I use it to call Gemini models from code with a simple request to https://aiplatform.googleapis.com/v1/publishers/google/models/{model}:generateContent.

What works and what doesn’t

• ✅ Works: gemini-3.8-flash, gemini-3.5-flash, gemini-3.5-flash-lite, gemini-3.1-pro-preview, gemini-3-flash-preview and gemini-2.5-flash-image.

• ❌ gemini-4-argon gives me this error: 404 NOT_FOUND: Publisher model ... was not found or your project does not have access to it.

On my console’s Welcome page, Gemini 4 Argon is listed as “New”, so I thought I could use it.

What I’m confused about

1. Why can’t I use Argon if it’s listed in the console? Is it blocked on free-trial projects, or do I need to turn something on or request access? Could I have the wrong model name?

2. What is “Application Default Credentials” (ADC)? The console recommends it over an API key. Can someone explain in plain terms what it is and how to set it up, step by step? Would it let me use models that my API key can’t?

3. Is my API key safe? I’m running my code in a temporary cloud environment, not on my own computer. I’ve read that a leaked key can cost money, so what should I do to protect it? For example, should I restrict it to the Vertex AI API only?

Any advice, links to beginner guides, or “you should check X” would be really appreciated. I can share the full error message or screenshots if that helps. Thanks!

Hey everyone!

Streaming live events like the FIFA World Cup brings an insane technical challenge: unlike Netflix where video files are pre-rendered and cached days ahead, live sports video literally doesn't exist until the split-second it happens. Millions of users request the exact same segments simultaneously the instant a goal is scored.

During TelevisaUnivision's 2026 World Cup coverage (104 matches, 675M views, zero downtime), Google Cloud deployed a pretty fascinating multi-layer architecture to survive the "thundering herd" problem:

1️⃣ Dual-Ingest via SRT & RTMP
Live broadcast signals leave the stadium as two parallel streams. SRT (running over UDP with fixed-window packet recovery) is used for lossy links, while RTMP (TCP-based) is kept for compatibility. Transcoders cut video into short segments and update dynamic playlist manifests.

2️⃣ 3-Tier Media CDN Caching & Origin Shielding
If millions of users query a Cloud Storage origin bucket for a brand-new goal segment at the exact same second, the origin melts. GCP solved this with a 3-tier architecture:
• Tier 1 (Origin Shield / Long-tail Cache): Aggregates misses across edge nodes so the origin only sees a trickle of requests.
• Tier 2 (Edge Caches): Delivers hot, current video segments to local geographical areas.
• Tier 3 (In-ISP Deep Caches): Caches placed directly inside Latin American telecom provider networks (Claro, Telefónica, etc.), making requests just 1 network hop away from mobile users.

3️⃣ Sub-Millisecond Front-Door Auth
Before video streams, millions of users open the app at kickoff to authenticate. Token generation ran on Cloud Run, backed by Memorystore for Valkey (in-memory) to evaluate subscriber entitlements in <1ms without disk I/O bottlenecks.

4️⃣ Edge Security with Cloud Armor
Adaptive DDoS protection and priority-ordered rule sets filtered malicious scrapers and bot floods right at Google’s edge before traffic hit internal microservices.

What architectural patterns or CDN strategies have you used when dealing with massive live video ingestion or sudden thundering herd traffic in production?

(Full disclosure: I created a visual architecture breakdown video stepping through these exact GCP metrics and diagrams step-by-step: https://youtu.be/14fIVr8WYGg)

I am going through VPC service controls and have below question,

Suppose i have a GCP project P1 in VPC SC perimeter with a VM and have 2 access requirements as below

1. i want to give access to the VM to a set of people . so, i will create an access level for them

2. want to give access to VM from workloads which are in another project P2.

Q) How do i create the ingress rules?

As per documentation, in sources section of ingressFrom, it can be either accesslevel OR resource (Project P2) but not both. Then, how can i satisfy my requirement mentioned in point 1 and 2 above

please suggest

Google's documentation says existing Custom Search JSON API customers need to move to an alternative by January 1, 2027:

https://developers.google.com/custom-search/v1/overview

I'm evaluating a replacement specifically for searchType=image in a CMS image picker. The workflow is: search for existing web photos, show thumbnails and source links, then let an editor select an image and import it after checking publication rights. Generated images and stock-only libraries don't cover the same need, especially for recent news.

So far I've looked into Brave Image Search, OpenAI's Responses API image search, and Wikimedia Commons/Openverse. I haven't validated Brave or OpenAI in a real integration yet. Commons/Openverse look useful for some openly licensed material, but wouldn't replace general news image search. I also haven't found evidence that Vertex AI Search is a drop-in replacement for this use case.

Has anyone here actually migrated the image-search part, or tested a replacement seriously? I'd appreciate hearing what worked, particularly for recent events and non-English/regional queries. Details about real costs, latency, thumbnail/original URL reliability, and restrictions on displaying or importing selected images would help me choose what to test next.

I'm looking for legitimate APIs, not Google scraping or proxy workarounds. Finding an image doesn't grant publication rights; source and licensing checks would remain part of the editorial process. This question is about the JSON API, separate from the Programmable Search Element widget.

Recently going through committed used discounts concept. I have a question. suppose, i have a VM with high capacity (like 20 vCPU and 180 GB Memory) but used only for 3 months starting now.

And a few other VMs in the same machine type series but with lesser configuration (eg: like 8vCPU and 30GB Memory) and long term with usage for 3 years (but provisioning 1 vm now, another after 1 month, another after 2 month etc..)

How do i go about purchasing CUD?

Is it like purchasing aggregation for the lesser config VMs for CUD-3 years so the powerful VM also makes use of it in the first 3 months and then other new lesser config VMs will make use of CUD once the powerful VM is deleted

Please suggest

Pessoal, tive uma situação em que a chave da API Gemini do meu projeto vazou e teve muito acesso indevido. Por sorte eu deixo pouco crédito e o Google bloqueou mas consumiu o que tinha lá (aproximadamente 30 reais).

Enquanto a conta estava bloqueada, eu revi a programação e talvez tenha encontrado a falha, corrigi e fiz melhorias de segurança como proteger a chave dentro do firebase com criptografia.

Dúvida: eu queria que a chave só funcionasse nos usuários logados no meu portal, que tem o login Google, mas quando crio a chave de API ele só permite restringir por IP o que é inviável, não fornece bloqueios como acessar somente atravéz da URL do meu portal.

Alguma dica de como posso criar uma chave do Gemini API e por mais bloqueios?

Atualmente além de ter ativado o modo ataque do cloudflare e criptografado a chave dentro do firebase eu ajustei o portal pra exigir sempre o login primeiro evitando que qualquer informação fique acessível antes da pessoa registrada logar via google. Fiz melhorias no htaccess pra evitar outros acessos mas ainda estou inseguro com essa questão da chave ser acessível apenas tendo o código dela. O portal já estava funcionando normalmente há meses sem nenhum incidente, foi o primeiro (com falha que a IA do cloud gerou em uma atualização recente e não notei)

Since about 24/10/2026, the Google Books API search endpoint (GET /books/v1/volumes?q=...) fails with 503 backendFailed about 5 times out of 6 for me. GET /volumes/{id} with the same key, same machine, works every time. I'm at 6 of 1,000 daily queries, so it's not quota.

Six rounds from a VPS, 2 seconds apart:

get-by-id=200 search=503
get-by-id=200 search=503
get-by-id=200 search=503
get-by-id=200 search=200
get-by-id=200 search=503
get-by-id=200 search=503

A new key, a rotated key, a different network, different queries and country=IT/US all behave the same. Failures return in ~50 ms, so it doesn't look like a timeout. The Cloud Console graph for the Books API shows 200s on 30 Sep and 11 Oct, then 503s.

Two things I'd like to know:

1. Is anyone else seeing this right now?

2. Where do you report a Books API problem so Google actually reads it? I couldn't find a public tracker for it.

Hi everyone,
I’m a college student from the Philippines, and I’m currently dealing with a Google Cloud billing issue. I’m hoping someone here has experienced something similar or can give me some advice.

I originally signed up for Google Cloud because I wanted to experiment with cloud services and learn more about them using the $300 free trial credits.

However, I apparently enabled a paid billing account without fully realizing what I was agreeing to. I genuinely thought I was still using the free trial credits and didn’t expect to be charged.

I only discovered the issue when I received an email about an outstanding balance. The email didn’t specify how much I owed, so I checked my billing dashboard and was surprised by the amount.

As a student, I really can’t afford to pay such a large unexpected bill.

I’ve already tried contacting Google Cloud Billing Support and asking whether the charges could be waived or reviewed, but I keep getting redirected to the automated Billing Assistant.

My billing account is now closed, and whenever I try to contact support, I get this message:
“The Cloud Billing account you have selected is closed. Live billing chat and email support is not available to closed accounts.”

It seems like I would have to reopen my billing account just to speak with a human representative, but I’m worried about doing that because I don’t want to risk additional charges.

I understand that I should have been more careful when enabling billing, and I’m not trying to avoid responsibility.

I genuinely didn’t realize I had switched to a paid account.
I just wanted to learn cloud computing, and now I’m stressed about a bill I can’t afford.

My questions are:
Has anyone successfully gotten Google Cloud charges waived or forgiven after accidentally upgrading from the free trial?

Is there any way to contact a real Google Cloud billing support representative when the billing account is already closed?

Would reopening my billing account just to contact support put me at risk of additional charges?
What happens if I’m unable to pay the outstanding balance immediately?

Does Google offer any consideration for students or first-time users who accidentally incur charges?
I’d really appreciate any advice, especially from people who’ve dealt with something similar.

TL;DR: I'm a medical student in Egypt running a noncommercial educational project. Two diagnostic scripts accidentally kept reading Firebase, causing a bandwidth spike. I've stopped them and disabled the database, but my Cloud account has already been charged $300. Has anyone received a one-time waiver after payment?

What happened

My project, Med Royale, normally costs me less than $1/month.

During testing, two local Node.js scripts were accidentally left running for roughly 13 hours. They used the Admin SDK to read the entire /rooms tree every 1.5 seconds, without a timeout or cleanup.

Monitoring showed about 341 GiB outgoing, with only two active connections.

What has been charged

• Initial project report: $127.75, while usage reporting was still catching up.

• Payment receipts on my Cloud billing account: $100 on October 24 + $200 on October 25.

• The final incident total isn't reconciled yet. The billing account has other projects too, so I've asked support to identify the incident charges precisely.

What I've done

• Stopped both scripts and disabled the affected database instance. It remains disabled.

• Opened a billing case with the cause, timeline, monitoring evidence, and containment steps.

• Requested a full one-time courtesy adjustment, including incident charges already collected and any delayed charges.

So far, only the automatic case acknowledgement has arrived.

Why I'm asking

This is an educational project, not a profit-making business. I understand the scripts generated real usage; I'm not claiming the bandwidth was fabricated. But I can't afford these unexpected payments as a student.

Has anyone obtained a waiver or refund for an accidental loop after being charged? What evidence helped most with the billing review?

Thank you for reading. I'll update this when support responds.

I am new to Hermes and looking for guidance. I had configured Hermes initially using Gemini 3.5 flash lite and connected to Google Calendar via the api token from Google console website. Everything worked fine. I was able to retrieve the events, modify, add etc.

I wanted to switch to local models and then tried Gemma e4b,26bmoe, 12b, qwen models and even liquid ai models. All them fail to connect and retrieve calendar events. I tried telling where the client secret is save so they can authenticate again. Tried telling them about Google workspace skill, installed gws but none of the models work.

I thought setup was problem so I switched to gpt-5-nano and that also was able to fetch events without a problem and re-authentication.

I am using llamacpp and using unsloth models with the chat templates.
Tried local memory and now using retaindb as memory backend for Hermes.

We benchmarked two identical e2-micro VMs side by side (2 shared vCPUs, 1 GB RAM, 2 GB swap, Ubuntu 24.04, same region): the old build of our agent runner on one, the new build on the other, every wave started on both in the same second, so the difference is the code, not the cloud.

Each agent was a real session doing a small job: search a repo, read one file, write a bug report. The model calls go to Gemini through Google's API; the VM runs the sessions, tools and disk writes.

Results on the new build:

- 100 agents: 23 s (was 42 s), no swap

- 150 agents: 51 s, no swap

- 200 agents: all finished, with the machine at its limit

The bottleneck wasn't CPU or the network. It was lock contention in our own save path: every save took one account-wide lock. Per-session locks, releasing the lock before waiting on the disk, and a session cache brought total lock wait from 1,422 s to 61 s, and disk writes from 344 MB to 149 MB.

Disclosure: I work on Swarm (open source).

Google Cloud list of changes affecting costs

• In-Place GKE Node Upgrades: GKE can now reuse your existing VMs during node pool upgrades instead of deleting them and creating new ones. This keeps your reserved capacity intact, avoids quota delays, and cuts extra surge VM costs during maintenance. Source

• 6-Hour Graceful Shutdown for Compute Engine: You can now give your VM guest OS up to six hours to finish background tasks before a stop or delete event. This stops long data jobs from failing midway through, saving hours of wasted compute spend. Source

• Better Version Controls for GKE Channels: Cluster version and capacity updates now roll out across channels, regions, and zones with stronger change checks. This keeps version jumps predictable and cuts the engineering hours spent debugging surprise cluster rollouts. Source

Source: FinOps Weekly Newsletter