Prepare and test your skills
Prepare and test your skills
Traffic management and rate limiting is the practice of controlling how much API traffic reaches backend services so backends stay available and access stays fair. In Google Cloud, Apigee (opens in a new tab) applies traffic-management policies such as quotas and SpikeArrest at the API proxy layer. Global external Application Load Balancers (opens in a new tab) and front-end filtering distribute requests across healthy backends. Together these controls protect services from resource exhaustion caused by sudden spikes or sustained overload.
Excess load means more requests arrive than the application or the resources it depends on can handle, which can make the application slow or unavailable. Even with enough infrastructure, an application can fail when request volume rises rapidly or stays high for a long time. Rate-limiting mechanisms sit between API consumers and backend services so extra requests are rejected before they exhaust the backend.
Common causes of excess load include:
A quota in Google Cloud limits the number of API requests that a service can receive over time to protect the backend from sustained overload. Traffic flows from API consumers to the quota check and then to the backend service, and requests above the quota are denied so the backend only handles its designed capacity. Project-level quotas for specific resources also limit the billing that a project can incur for those resources. Choose quotas when the goal is equitable, long-term access control and cost protection rather than stopping a seconds-long burst.
The SpikeArrest policy in Apigee guards a target service against sudden traffic spikes from increased usage, buggy clients, or malicious attacks. The policy is evaluated in the API proxy flow before the request reaches the target service, and when the number of requests exceeds the configured rate the API returns an HTTP 429 error. The proxy therefore protects the backend service because only traffic within the spike limit flows from the proxy endpoint to the target endpoint.
To add the SpikeArrest policy to an API proxy:
Distributing and filtering traffic before backends is the ordered front-end path that blocks attacks, serves cached responses, and sends only valid requests to healthy servers. The global external Application Load Balancer distributes HTTP and HTTPS traffic across multiple backend instances across multiple regions. The load balancer depends on health checks to route application traffic to only the backends that are responsive, so a virtual machine in the RUNNING state with crashed application software stops receiving traffic.
Requests from the internet first reach the global front end, where Google Cloud Armor (opens in a new tab) security policies evaluate the request starting with edge security policies. If the request is allowed and Cloud CDN can serve it from cache, the cached content flows from the cache back to the user without touching the backend. If the request results in a cache miss, the request is evaluated by backend policies and then, according to the policy rules, the request is denied or flows to the backend server for fulfillment. This order — filter at the edge, serve from cache when possible, then filter again before the backend — blocks Layer 7 attacks and volumetric DDoS traffic before it reaches load-balanced backend services.
Exam tip: Use a quota for sustained request limits and cost control, and use SpikeArrest for sudden bursts where excess requests receive HTTP 429.
API security and authentication mechanisms are the controls that verify who is calling an API and decide what that caller is allowed to do. In Google Cloud, Apigee (opens in a new tab) acts as a proxy layer that checks credentials such as keys, tokens, or certificates before traffic reaches backends, while API Gateway (opens in a new tab) relies on authenticated-only backends and service-account permissions. Together with Transport Layer Security (TLS), private networking, and bundled access rules, these controls create consistent security even when backend teams and architectures differ.
An API product is a bundle of one or more operations that is published for application developers to consume. Each operation in an API product names an API proxy and the resource paths that can be accessed on that proxy, and the operation can further limit access by HTTP method and by quota. A developer application is associated with one or more API products, and Apigee then restricts access to those proxies with an API key.
This structure enforces fine-grained access management because different consumers receive different keys tied to different operations. For example, a customer mobile application can be limited to only POST on https://$DOMAIN/v1/payments, while a call-center application can be allowed to use PUT or DELETE on https://$DOMAIN/v1/payments/1234 to revert payments. When a request arrives, Apigee executes its security policies to allow or deny the request and can route the request to different backends based on the client, the request, or both.
OAuth 2.0 is the mechanism used to exchange Google Cloud credentials for a short-lived access token that proves identity for API calls. For management of Apigee itself, the caller first authenticates with gcloud auth login and then obtains a token with gcloud auth print-access-token. That token is sent in the Authorization: Bearer $TOKEN header when calling https://apigee.googleapis.com, and the token does not need to be exchanged again until it expires.
A service-account path provides the same result for automation without interactive login. The operator creates a service-account key file, sets the GOOGLE_APPLICATION_CREDENTIALS environment variable to that file path, and then requests an OAuth 2.0 token for that service account. Short-lived service-account credentials are preferred over long-lived keys because they grant limited access to trusted service accounts and reduce risk if a credential is exposed.
The secure request flow moves traffic from the client through shared edge controls to Apigee, and only then to backends. The client sends the request to the external Application Load Balancer with application credentials such as a key, token, or certificate. The load balancer routes the request to Apigee, Apigee executes security policies to allow or deny it, and Apigee forwards legitimate requests to the selected backend system.
The ordered forwarding path preserves trust boundaries between Google Cloud, the data center, and third parties:
Because Apigee sits in front of payments, accounts, and money-transfer services, different teams no longer enforce security and logging in different ways. If Apigee determines the request is not legitimate, it can return a 403 response instead of forwarding the request to any backend.
Securing Apigee-to-backend connections combines encrypted transport with private networking. VPC Network Peering (opens in a new tab) peers the Apigee runtime in its tenant project with the customer Google Cloud project, so traffic to GKE-hosted services such as money-transfer stays on internal IP addresses. Traffic to on-premises payments and accounts services travels from Apigee through Cloud Interconnect, which provides a direct private path to the data center.
Apigee also provides keystore management to secure TLS handshakes from Apigee to backends. The keystore holds the identity material Apigee presents, while the truststore holds the certificates Apigee trusts when it validates the backend. Together, private paths plus managed TLS mean backend services are not exposed directly to the internet and every hop from Apigee outward remains authenticated and encrypted.
Securing API Gateway backends means preventing public access and authorizing only the gateway service account to invoke the backend. The pattern has two parts: the backend permits only authenticated access, and the gateway service account associated with the API config is granted an invoker role. Access can be scoped to an individual service or function with service-level Identity and Access Management (IAM), or to all services in a project with project-level IAM.
The required role depends on the backend platform:
| Backend | How access is locked down | Gateway service account needs |
|---|---|---|
| Cloud Run | Services deploy privately by default and require run.routes.invoke permission | roles/run.invoker role |
| Cloud Run functions | HTTP functions require authentication by default; background functions can only be invoked by their subscribed event source | roles/cloudfunctions.invoker role with cloudfunctions.functions.invoke permission |
| App Engine | Identity-Aware Proxy (IAP) is enabled for the project so requests are authenticated | IAP-secured Web App User role |
Exam tip: Cloud Run uses roles/run.invoker, while Cloud Run functions uses roles/cloudfunctions.invoker — a rejected gateway request usually means the gateway service account is missing the matching invoker role.
Observability and performance analytics is the practice of using logs, metrics, and usage data from the API layer to understand API health, speed, and adoption. In Google Cloud, Apigee (opens in a new tab) provides this visibility through an API proxy layer that sits between backend services and client apps, so all API traffic passes through and is processed by Apigee. API Gateway (opens in a new tab) provides similar visibility as a distributed API management system that fronts backend services with a consistent REST interface. Because every request flows from the client to the gateway or proxy and then to the backend, the proxy layer can record latency, errors, and traffic patterns without changing the backend services.
Measurability is the API producer challenge of proving that backend services are available, used correctly, and performing well for client applications. API producers expose services over the web to mobile apps, browser apps, and partner systems, but different teams often build those backends with inconsistent logging and security practices. Without a central proxy layer, each team must monitor its own service and track its own consumers. Centralized observability solves this by collecting the same signals for every API in one place.
API producers use observability to answer four related questions:
When these four signals flow from the Apigee runtime to Google Cloud services for logging, analytics, and metrics, operations teams can detect downtime, spot quota violations, and plan capacity. That shared view also supports billing accuracy, because tracked usage shows which developer apps and API products generate the most calls.
Apigee API insights is the set of built-in capabilities that lets API producers secure access, monitor uptime with alerting, and analyze how APIs are used. All API traffic passes through containerized runtime services in a Kubernetes cluster that Google maintains, and those runtime services send operational data to Google Cloud services for identity management, logging, analytics, metrics, and project management. Backend services then provide runtime access to data, while Apigee records what happened at the proxy layer. This separation means producers can diagnose a slow or failing API at the proxy before changing any backend code.
| Capability | What it tracks | Producer outcome |
|---|---|---|
| Advanced API Security | Access attempts and threat signals | Secure access to services from unauthorized use |
| API Monitoring | Uptime, traffic, and error conditions with alerting | Detect outages and latency issues quickly |
| Analytics | API usage patterns and consumer behavior | Gain insight into who uses services and how |
The three capabilities depend on the same proxy-layer position. Advanced API Security determines whether a request is legitimate, API Monitoring reports whether the proxy and backends respond on time, and Analytics aggregates successful and rejected calls into usage trends. Together they let a producer move from a single alert, to the affected proxy and backend route, to the broader pattern of which apps, operations, and resource paths are affected.
Exam tip: API Monitoring is for uptime and traffic alerting, while Analytics is for usage patterns and consumer insight.
API Gateway observability is the combination of hosting, logging, monitoring, traffic management, authorization, and monitoring features built into the gateway for concurrent API calls. App developers send requests to backend services through API Gateway, and the gateway processes each call consistently regardless of whether the backend runs on Cloud Run, Cloud Run functions, or the App Engine standard environment. Because the public API stays stable even when the backend implementation changes or moves architectures, logs and metrics remain comparable over time. This consistency makes it easier to diagnose whether added latency comes from the gateway policy, the backend service, or a change in client usage.
Gateway telemetry connects directly to Google Cloud observability services. Cloud Logging is a real-time log-management system with storage, search, analysis, and monitoring support that stores request and platform logs. Google Cloud Observability monitors the behavior, health, and performance of applications using those logs and metrics. For backend protection, API Gateway also relies on service-account authorization, so rejected calls from an unauthorized gateway identity appear as permission errors rather than backend failures.
Performance analytics is the use of observability data and caching to reduce latency, handle traffic spikes, and lower backend load. Cloud CDN serves content closer to users by caching frequently accessed responses at a Google Front End (GFE) at the edge of the Google network, which keeps data as close as possible to users for the fastest access. When a response flows back to the client, Cloud CDN caches it so future calls with the same cache key can return from cache. This approach helps organizations handle seasonal spikes, improves reliability and user experience, and minimizes web server load, compute, and network usage.
Reliability improvements also come from isolating API consumers from backend changes. Apigee proxies let producers execute security, traffic management, and efficiency policies at the proxy level while keeping a consistent interface for consumers. Producers can therefore update a backend service, fix a slow operation, or shift traffic to a new backend without interrupting client applications. Observability confirms the result by showing whether error rates fall, response times improve, and traffic distributes as expected after the change.
Use a quota when the goal is equitable, long-term access control and cost protection for sustained API request volume over time, with requests above the quota denied so the backend only handles its designed capacity. Use the SpikeArrest policy when the goal is guarding a target service against sudden traffic spikes, where excess requests are rejected with an HTTP 429 error before they reach the target service.
API Gateway backends must allow only authenticated access, with the gateway service account granted an invoker role for the backend platform. The gateway service account needs roles/run.invoker for Cloud Run and roles/cloudfunctions.invoker for Cloud Run functions, so a rejected gateway request usually means the matching invoker role is missing.
Apigee API Monitoring tracks uptime, traffic, and error conditions with alerting so producers can detect outages and latency issues quickly. Apigee Analytics tracks API usage patterns and consumer behavior so producers can gain insight into who uses services and how usage is changing over time.
Last updated