Skip to main content
Google Cloud Platform (GCP)
CHAPTER 14

API Gateway and Cloud Endpoints

Updated: May 15, 2026
20 min read

# CHAPTER 14

API Gateway and Cloud Endpoints

1. Introduction

In the previous chapter, we built a Cloud Function API. However, sharing a raw Cloud Function URL with external developers or mobile apps is an architectural anti-pattern. What if a malicious user spams the URL a million times a second? What if you need to require an API Key? What if you need to track which specific client is utilizing the most bandwidth? To solve these enterprise challenges, Google provides API Gateway and Cloud Endpoints—intelligent gatekeepers that sit in front of your backend services to provide security, rate limiting, and observability.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the role of an API Management layer.
  • Differentiate between API Gateway and Cloud Endpoints.
  • Understand the OpenAPI (Swagger) specification format.
  • Implement API Key authentication to protect a backend service.
  • Understand Rate Limiting and Quotas.

3. Beginner-Friendly Explanation

Imagine an exclusive nightclub (Your Backend API).
  • Without API Gateway: The club has no front door. Anyone from the street can walk straight in, take whatever they want, and overload the dance floor. It's chaos.
  • With API Gateway: You hire a massive, intelligent Bouncer to stand on the street.
  • The Bouncer checks IDs (API Keys/Authentication).
  • The Bouncer counts people. "You have already entered 50 times today, you are cut off" (Rate Limiting).
  • The Bouncer keeps a ledger of exactly who entered and when (Analytics/Logging).
  • Only after the Bouncer approves does the guest actually reach the nightclub inside.

4. API Gateway vs. Cloud Endpoints

Google offers two distinct services for API management:
  1. 1. API Gateway: The modern, fully managed, serverless solution. It is designed specifically to protect serverless backends like Cloud Functions and Cloud Run. You upload a configuration file, and Google magically deploys a highly available gateway.
  1. 2. Cloud Endpoints: The older, more complex solution. It requires you to deploy a highly specialized NGINX proxy container (the Extensible Service Proxy) directly alongside your application. Typically used for legacy architectures or complex Kubernetes environments.

*For new, serverless projects, always default to API Gateway.*

5. The OpenAPI Specification (Swagger)

How do you tell the API Gateway how to route traffic? You use the industry standard OpenAPI Specification (formerly known as Swagger). It is a YAML file that acts as a blueprint for your entire API. It defines your endpoints (e.g., /users), the HTTP methods allowed (GET, POST), and exactly which Google Cloud Function the traffic should be forwarded to.

6. Securing the Backend

The fundamental security architecture of an API Gateway is simple:
  1. 1. You deploy a Cloud Function, but you make it completely Private. It rejects all traffic from the internet.
  1. 2. You grant the API Gateway a highly specific IAM Service Account.
  1. 3. The API Gateway is Public. The user hits the Gateway, the Gateway validates their API key, and then the Gateway uses its Service Account to securely access the Private Cloud Function on the user's behalf.

7. Mini Project: The Gateway Blueprint

Deploying an API Gateway requires multiple services to interact. Let's look at the conceptual OpenAPI YAML required to configure it.

The OpenAPI Blueprint (api-config.yaml):

yaml
12345678910111213141516171819202122232425 
swagger: '2.0'
info:
  title: My Serverless API
  description: Protected by API Gateway
  version: 1.0.0
schemes:
  - https
produces:
  - application/json
paths:
  /hello:
    get:
      summary: Says Hello
      operationId: helloWorld
      # This tells the Gateway to require a Google Cloud API Key
      security:
        - api_key: []
      # This is the MAGIC line. It tells the Gateway where to forward the traffic!
      x-google-backend:
        address: https://us-central1-myproject.cloudfunctions.net/hello-world-api
securityDefinitions:
  api_key:
    type: apiKey
    name: key
    in: query

*When you upload this YAML to the GCP Console, Google automatically provisions a global URL. If a user visits https://gateway-url.com/hello?key=12345, the Gateway verifies the key and forwards the request to your Cloud Function.*

8. Real-World Scenarios

A weather data company sells access to their forecasting API. They have three tiers of customers: Free, Pro, and Enterprise. They place an API Gateway in front of their backend.
  • Free users are given an API Key configured with a Quota of 1,000 requests per day.
  • Pro users are given a Key configured for 100,000 requests per day.
If a Free user writes a buggy script that accidentally requests data 50,000 times in an hour, the API Gateway instantly blocks them at request 1,001, returning a 429 Too Many Requests error. The backend server never even sees the traffic, saving the company from massive compute costs.

9. Best Practices

  • Never Trust the Client: Always perform rate limiting and authentication at the Gateway level, not inside your application code. If you authenticate inside your Cloud Function, the malicious traffic still triggers the function, meaning you still have to pay Google for the compute time! Block malicious traffic at the perimeter.

10. Common Mistakes

  • Leaking API Keys: Beginners often hardcode their API Keys into the frontend JavaScript code of their React or Angular websites. Because JavaScript runs in the user's browser, any user can right-click, "Inspect Element", steal the API Key, and use it to spam your Gateway. Frontend web apps should generally use OAuth 2.0 (JWT Tokens), while API Keys should be reserved for Server-to-Server communication.

11. Exercises

  1. 1. What is the fundamental difference between deploying a public Cloud Function and protecting a private Cloud Function behind an API Gateway?
  1. 2. Explain the purpose of the x-google-backend extension within an OpenAPI YAML specification.

12. FAQs

Q: Do I have to use an API Gateway? A: If you are building a simple, internal tool for your own company, no. If you are exposing an API to the public internet, to third-party developers, or building a mobile app with thousands of users, yes. The security and rate-limiting features are mandatory for production survival.

13. Interview Questions

  • Q: Describe the architectural paradigm of "Defense in Depth" as it relates to protecting backend microservices using Google API Gateway.
  • Q: A developer has deployed a backend API protected by API Gateway. During a stress test, the backend servers crash due to overwhelming traffic. Identify the missing configuration within the API Gateway that allowed this incident to occur, and describe how to implement it.

14. Summary

In Chapter 14, we established a secure perimeter for our infrastructure. We recognized the dangers of exposing raw backend services directly to the internet and introduced API Gateway as the intelligent, serverless bouncer protecting our architecture. We explored the industry-standard OpenAPI (Swagger) specification used to define routing, and understood how implementing API Keys, Rate Limiting, and Quotas at the network edge protects our backend compute resources from malicious abuse and catastrophic scaling costs.

15. Next Chapter Recommendation

Our architecture is secure and scaling autonomously. But if an error occurs deep inside a Cloud Function, how do we find out? We cannot manage what we cannot measure. Proceed to Chapter 15: Monitoring and Logging.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Cloud Functions Serverless Computing
Next Chapter Monitoring and Logging

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

❓ Related Quizzes 6