Study guide
4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
Google Professional Cloud Architect Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Strategy & Case Study Methodology
1.1 Exam Overview, Structure & Scoring Logistics 1.2 The Professional Cloud Architect Role & Exam Mindset 1.3 Deconstructing GCP Case Studies & Scenario Questions
2 Chapter 2: Designing for Business Requirements
2.1 Mapping Business Objectives, ROI & Total Cost of Ownership 2.2 Cost Optimization Strategies, Pricing Models & Trade-Offs 2.3 Business Continuity, Governance & Compliance Planning
3 Chapter 3: Designing for Technical Requirements & Availability
3.1 Scalability, Elasticity & Capacity Planning 3.2 High Availability, Disaster Recovery Patterns & RTO/RPO 3.3 Performance Optimization & Global Latency Reduction
4 Chapter 4: Compute Selection & Workload Architecture
4.1 Compute Engine Architecture, Sizing & Managed Instance Groups 4.2 Google Kubernetes Engine (GKE) Standard vs Autopilot & Microservices 4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
5 Chapter 5: Storage, Database & Data Warehouse Architecture
5.1 Cloud Storage Architecture, Storage Classes & Lifecycle Management 5.2 Relational Databases: Cloud SQL, AlloyDB & Cloud Spanner 5.3 NoSQL & Big Data Storage: Firestore, Bigtable & BigQuery
6 Chapter 6: Networking, Hybrid Connectivity & Traffic Routing
6.1 VPC Design, Subnets, Shared VPC & VPC Peering 6.2 Hybrid & Multicloud Connectivity: Cloud VPN & Cloud Interconnect 6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS
7 Chapter 7: Identity, Access & Resource Governance
7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts 7.2 Workload Identity Federation, Service Account Impersonation & IAP 7.3 Organization Policies, Tags & Resource Governance
8 Chapter 8: Security Architecture, Data Protection & Compliance
8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM 8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls 8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center
9 Chapter 9: DevOps, Automation & Infrastructure as Code
9.1 Infrastructure as Code (IaC) with Terraform on Google Cloud 9.2 CI/CD Pipelines: Cloud Build, Artifact Registry & Cloud Deploy 9.3 Deployment Strategies (Blue/Green, Canary) & GitOps with Config Sync 9.4 Interacting with Google Cloud Programmatically: Cloud SDK, Cloud Shell & Emulators
10 Chapter 10: Site Reliability Engineering & Operations Excellence
10.1 SRE Fundamentals: SLIs, SLOs, SLAs & Error Budgets 10.2 Observability: Cloud Monitoring, Logging & Alert Policies 10.3 Diagnosing Performance: Cloud Trace, Profiler & Error Reporting
11 Chapter 11: Data Pipelines, Integration & Modernization
11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc 11.2 Stream and Batch Processing: Dataflow & Dataproc 11.3 API Management & Service Integration: Apigee & Cloud API Gateway 11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options
12 Chapter 12: Well-Architected Framework & Official Case Study Solutions
12.1 Google Cloud Well-Architected Framework & FinOps Governance 12.2 Comprehensive Case Studies: EHR Healthcare & Cymbal Retail 12.3 Comprehensive Case Studies: Altostrat Media & KnightMotives Automotive
13 Chapter 13: AI, Machine Learning & Generative AI Architecture
13.1 AI/ML Platform Architecture: Vertex AI, Gemini Enterprise Agent Platform & AI Hypercomputer 13.2 Prebuilt AI APIs, Model Garden, Gemini Cloud Assist & Securing AI
4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
Key Takeaways Explain This Topic AI
Cloud Run is a fully managed serverless platform that runs containerized workloads, split into Cloud Run Services (for HTTP/gRPC/WebSocket request-driven services) and Cloud Run Jobs (for run-to-completion parallel batch processing).
Cloud Functions (2nd gen) is built directly on Cloud Run and Eventarc, delivering simplified function-as-a-service (FaaS) ergonomics with full Cloud Run operational capabilities (up to 32 GB RAM, 60-minute HTTP timeouts, and high concurrency).
Cloud Run supports high container concurrency (up to 1,000 concurrent requests per instance), drastically reducing instance count, cold start frequency, and hosting costs compared to traditional single-concurrency FaaS platforms.
Cold starts and backend load are managed through Min Instances (eliminating initialization latency for user-facing APIs) and Max Instances (throttling concurrency to safeguard downstream databases against connection pool exhaustion).
Direct VPC Egress provides high-throughput, low-latency private VPC connectivity without the operational overhead and scaling bottlenecks of dedicated Serverless VPC Access connector VMs.
Last updated: August 2026
Serverless Architectures: Cloud Run, Cloud Functions & Eventarc
Architectural Objective: Serverless compute on Google Cloud enables developers and architects to build scalable, resilient applications without managing virtual machines, clusters, or operating system runtimes. A Google Professional Cloud Architect must design event-driven systems using Cloud Run Services, Cloud Run Jobs, Cloud Functions (2nd gen), and Eventarc, while optimizing concurrency, cold starts, CPU allocation, and private VPC connectivity.
Cloud Run Platform Architecture: Services vs. Jobs
Cloud Run is Google Cloud's fully managed containerized serverless compute platform. It abstracts all underlying infrastructure while supporting any programming language, framework, or binary that can be packaged into an OCI-compliant container image listening on a configured HTTP port. +---------------------------------------------------------------------------------------------------+
- | CLOUD RUN WORKLOAD ARCHITECTURE |
- +---------------------------------------------------------------------------------------------------+
- | CLOUD RUN SERVICES (Request-Driven) | CLOUD RUN JOBS (Run-to-Completion Batch) |
- +-------------------------------------------------+-------------------------------------------------+
- | - Listens for incoming HTTP/gRPC/WebSockets | - Explicitly triggered via API, scheduler, or CI|
- | - Auto-scales from ZERO to thousands of instances| - Runs an array of parallel container tasks |
- | - Automatic request load balancing | - Executes to completion without HTTP listener |
- | - Max timeout: 60 minutes per request | - Max timeout: 24 hours per task execution |
- | - Use case: Web APIs, microservices, webhooks | - Use case: Nightly ETL, ML batch inference, DB |
- +-------------------------------------------------+-------------------------------------------------+
- Cloud Functions (2nd Gen): Built on Cloud Run & Eventarc
In Google Cloud's modern architecture, Cloud Functions (2nd gen) is built natively on top of Cloud Run and Eventarc infrastructure. When an architect deploys a 2nd gen function, Google Cloud automatically packages the code into an OCI container and deploys it as a managed Cloud Run service.
- Capability Cloud Functions (1st Gen) Cloud Functions (2nd Gen) / Cloud Run
- Underlying Infrastructure Bespoke isolated microVMs Standard Cloud Run container runtime
Concurrency Single concurrency only (1 request per instance) Multi-concurrency (up to 1,000 concurrent requests per instance)
- Max Execution Time 9 minutes (HTTP) / 9 minutes (Event) 60 minutes (HTTP) / 10 minutes (Eventarc events)
- Max Memory & CPU 8 GB RAM / 2 vCPUs 32 GB RAM / 8 vCPUs
Traffic Splitting & Rollback Not natively supported (all-or-nothing) Native revision management & % traffic splitting
- Event Ingestion Engine Legacy background event triggers Eventarc (130+ event sources in CloudEvents standard)
- Concurrency Model, Scaling Dynamics & Cost Optimization
Unlike traditional FaaS platforms (such as AWS Lambda or Cloud Functions 1st gen) that allocate one dedicated container instance per active request, Cloud Run supports multi-concurrency —allowing a single container instance to process up to 1,000 requests simultaneously . TRADITIONAL FAAS (Single Concurrency): CLOUD RUN (Multi-Concurrency = 80):
- 100 Concurrent Requests = 100 Instances 100 Concurrent Requests = 2 Instances
- ┌───┐ ┌───┐ ┌───┐ ┌───┐ ... ┌───┐ ┌────────────────────────┐ ┌────────────────────────┐
- │VM │ │VM │ │VM │ │VM │ │VM │ │ Container Instance 1 │ │ Container Instance 2 │
- └───┘ └───┘ └───┘ └───┘ └───┘ │ (Processes 80 reqs) │ │ (Processes 20 reqs) │
- [!] 100 Cold Starts, High Memory Waste └────────────────────────┘ └────────────────────────┘
- [OK] Fast throughput, 98% fewer cold starts & lower cost
- Sizing Container Concurrency
Default Concurrency: 80 concurrent requests per instance.
I/O-Bound Workloads (Node.js, Go, Python Asyncio, Java Spring Boot): Set concurrency to 80–200 . Because threads spend most of their execution time awaiting database queries or external API calls, a single instance can easily multiplex hundreds of requests without CPU starvation.
CPU-Bound Workloads (Heavy Image Processing, PDF Generation, ML Inference): Set concurrency to 1 to 4 . Forcing heavy CPU tasks to share cores causes thread context switching overhead and degrades latency.
Instance Scaling Calculation Required Instances = ⌈ Peak Requests Per Second (RPS) × Average Request Latency (seconds) Target Concurrency ⌉ \text{Required Instances} = \left\lceil \frac{\text{Peak Requests Per Second (RPS)} \times \text{Average Request Latency (seconds)}}{\text{Target Concurrency}} \right\rceil Required Instances = ⌈ Target Concurrency Peak Requests Per Second (RPS) × Average Request Latency (seconds) ⌉
Example: An API receives 4,000 RPS with an average latency of 0.25 seconds (250ms). If concurrency is set to 80: Required Instances = ⌈ 4000 × 0.25 80 ⌉ = ⌈ 1000 80 ⌉ = 13 Instances \text{Required Instances} = \left\lceil \frac{4000 \times 0.25}{80} \right\rceil = \left\lceil \frac{1000}{80} \right\rceil = 13 \text{ Instances} Required Instances = ⌈ 80 4000 × 0.25 ⌉ = ⌈ 80 1000 ⌉ = 13 Instances
Managing Cold Starts: Min Instances ( --min-instances )
When a serverless service scales from zero, the first incoming request experiences a cold start —the latency required for Google Cloud to allocate compute infrastructure, pull the container image, start the container runtime, and initialize application frameworks (e.g., JVM startup).
Architectural Fix: Configure --min-instances = N (e.g., --min-instances 3 ).
Behavior: Google Cloud maintains N pre-warmed container instances active 24/7. Incoming requests hit warm instances immediately with sub-10ms response times. Additional instances are spun up elastically only when traffic exceeds the serving capacity of the min-instances baseline.
Safeguarding Downstream Systems: Max Instances ( --max-instances )
Serverless compute can scale up to thousands of instances in seconds. However, legacy downstream relational databases (like Cloud SQL or on-premises PostgreSQL) have fixed connection pool limits.
Architectural Fix: Set --max-instances = N (e.g., --max-instances 50 ).
Behavior: Cloud Run caps horizontal scaling at N instances. If traffic surges beyond this ceiling, excess requests are queued in the Cloud Run ingress proxy for up to 60 seconds awaiting available container capacity, preventing database connection pool exhaustion and cascading crashes.
CPU Allocation Strategies: Request-Based vs. CPU Always Allocated
Cloud Run offers two distinct CPU allocation and billing lifecycle models: +-----------------------------------------------------------------------------------+
- | CLOUD RUN CPU ALLOCATION MODELS |
- +-----------------------------------------------------------------------------------+
- | 1. CPU ALLOCATED DURING REQUESTS ONLY (Default Serverless Model) |
- | - CPU is active ONLY while processing an active HTTP request. |
- | - Idle CPU is throttled to ~0% when no requests are in flight. |
- | - Billed per millisecond strictly during request processing. |
- | - Anti-pattern: Background threads or async timers will FREEZE when request ends|
- +-----------------------------------------------------------------------------------+
- | 2. CPU ALWAYS ALLOCATED (Always-On Instance Model) |
- | - CPU remains active 100% of the time, even when zero requests are processing. |
- | - Supports continuous background processing, polling, WebSockets, thread pools.|
- | - Billed continuously for the entire lifecycle of the container instance. |
- +-----------------------------------------------------------------------------------+
- Architectural Trade-offs
Dimension CPU Allocated During Requests Only CPU Always Allocated
Billing Basis Billed per 100ms increment during request execution. Billed continuously for the full instance uptime.
Background Execution Forbidden. Background threads freeze immediately when the HTTP response returns. Supported. Background threads run continuously between requests.
Warm-Up / Cache Refresh Cannot perform background polling or periodic in-memory cache warming. Can run periodic background cron routines and telemetry flushes.
Ideal Workload Classic REST APIs, webhooks, stateless microservices with intermittent traffic. High-throughput APIs, services with background workers, Pub/Sub pull subscribers.
Event-Driven Architectures with Eventarc & CloudEvents
Eventarc provides a standardized, fully managed event routing bus that captures events from Google Cloud services, custom applications, and third-party SaaS platforms, delivering them to Cloud Run, GKE, or Cloud Workflows in the industry-standard CloudEvents format . +-----------------------------------------------------------------------------------+
- | EVENTARC EVENT ROUTING PIPELINE |
- +-----------------------------------------------------------------------------------+
- | EVENT SOURCES: |
- | - Cloud Storage (Direct Object Create / Delete / Archive) |
- | - Cloud Audit Logs (130+ GCP Services: IAM updates, BigQuery table creation) |
- | - Cloud Pub/Sub Topics (Custom application events) |
- +-----------------------------------------+-----------------------------------------+
- |
- v
- +-----------------------------------------------------------------------------------+
- | EVENTARC ROUTER (Filters on event type, service, bucket name, method) |
- +-----------------------------------------+-----------------------------------------+
- |
- v
- +-----------------------------------------------------------------------------------+
- | EVENT DESTINATIONS (CloudEvents HTTP JSON Delivery): |
- | - Cloud Run Services - Cloud Functions (2nd Gen) |
- | - GKE Services - Cloud Workflows Orchestration |
- +-----------------------------------------------------------------------------------+
- Key Event Routing Patterns
Direct Cloud Storage Triggers: Eventarc routes mutations ( google.cloud.storage.object.v1.finalized ) directly from Cloud Storage to Cloud Run with sub-second latency, bypassing the need to manually configure Pub/Sub notifications.
Cloud Audit Log Triggers: Any administrative or data access action recorded by Cloud Audit Logs can trigger serverless execution. For example, capturing compute.instances.insert events across an organization to automatically trigger a Cloud Run service that verifies whether the newly launched VM complies with corporate security tags.
The CloudEvents Standard: All Eventarc events conform to the CNCF CloudEvents v1.0 specification, providing standard HTTP headers:
ce-id : Unique identifier for the event (enables deduplication).
ce-source : URI identifying the event producer (e.g., //storage.googleapis.com/projects/_/buckets/my-bucket ).
ce-type : The event schema type (e.g., google.cloud.storage.object.v1.finalized ).
ce-subject : The specific resource modified (e.g., objects/invoices/2026-08-invoice.pdf ).
Private Backend Connectivity: Serverless VPC Access vs. Direct VPC Egress
By default, Cloud Run instances execute in a Google-managed multi-tenant VPC with outbound access to the public internet only. To connect securely to private resources inside a customer VPC (such as Cloud SQL private IPs, internal Load Balancers, Memorystore for Redis, or on-premises databases over Cloud Interconnect), architects configure VPC egress. SERVERLESS VPC ACCESS CONNECTOR (Legacy) DIRECT VPC EGRESS (Modern Architectural Standard)
- ┌──────────────┐ ┌──────────────┐
- │ Cloud Run │ │ Cloud Run │
- └──────┬───────┘ └──────┬───────┘
- │ (Tunnel) │ (Native NIC Attachment)
- v v
- ┌─────────────────────────────┐ ┌─────────────────────────────┐
- │ Connector VMs (/28 Subnet) │ │ Customer VPC Subnet │
- │ (Throughput Bottleneck) │ │ (Direct Pod/Container IP) │
- └──────────────┬──────────────┘ └──────────────┬──────────────┘
- v v
- ┌─────────────────────────────┐ ┌─────────────────────────────┐
- │ Private Cloud SQL / Redis │ │ Private Cloud SQL / Redis │
- └─────────────────────────────┘ └─────────────────────────────┘
- Architectural Comparison: Connector vs. Direct VPC Egress
Architectural Attribute Serverless VPC Access Connector Direct VPC Egress (Recommended)
Mechanism Provisions a set of underlying e2-micro or e2-standard-4 connector VMs in a dedicated /28 subnet. Attaches virtual network interfaces directly to the customer VPC subnet.
Throughput & Bandwidth Scaled manually/autoscaled (200 Mbps to 1 Gbps max throughput per connector). Multi-gigabit line-rate throughput ; no intermediary VM bottlenecks.
Cold Start / Provisioning Connector VM creation takes 5–10 minutes; scaling latency during traffic bursts. Instantaneous scaling matching Cloud Run container provisioning.
Cost Profile Incurs fixed monthly charges for running connector VM instances 24/7. Zero connector VM charges ; standard network egress pricing only.
Subnet Sizing Requires a dedicated, isolated /28 subnet CIDR block. Uses available IP addresses from any standard existing VPC subnet.
VPC Egress Routing Configurations
private-ranges-only (Default): Only traffic destined for RFC 1918 private IP addresses ( 10.0.0.0/8 , 172.16.0.0/12 , 192.168.0.0/16 ) is routed through the VPC. Traffic destined for the public internet or public Google APIs traverses Google's default internet gateway.
all-traffic : All outbound network traffic (including internet traffic) is routed through the VPC subnet. This allows architects to enforce enterprise security controls, such as inspecting all outbound traffic through a Next-Generation Firewall (NGFW) or directing internet traffic through a Cloud NAT gateway with a fixed static public IP address for third-party IP whitelisting.
- Concrete Architectural Scenario: Event-Driven Document AI Pipeline
- Scenario Profile
Workload: Financial services document processing pipeline ingesting 100,000 PDF invoices daily.
Requirements: Ingest PDFs via Cloud Storage, trigger OCR transformation within 5 seconds, extract metadata into a private Cloud SQL (PostgreSQL) database, and run nightly batch analytics without managing servers.
Security Mandate: Cloud SQL must have no public IP address, and all egress must be encrypted over private internal networks.
Solution Architecture Blueprint
Event Ingestion: PDF invoices are uploaded to a regional Cloud Storage bucket. Eventarc captures the object.v1.finalized event and delivers the payload to a Cloud Run Service .
Real-Time OCR Service: The Cloud Run Service is configured with --min-instances 2 to eliminate cold starts and --concurrency 10 . It attaches to the customer VPC via Direct VPC Egress ( private-ranges-only ), writing parsed invoice records directly to the private IP of Cloud SQL.
Nightly Batch Analytics: A Cloud Scheduler job triggers a Cloud Run Job at midnight. The job spawns 50 parallel container tasks that read the day's raw invoice archive, perform reconciliation calculations, and output financial summary reports to BigQuery.
Important
Exam Watch: On the Google Professional Cloud Architect exam, whenever a scenario requires executing batch or scheduled tasks to completion (such as nightly database backups or bulk data conversions) without maintaining an active HTTP listener, choose Cloud Run Jobs . If a serverless workload must securely access a private Cloud SQL instance without public IP exposure, choose Direct VPC Egress (or Serverless VPC Access connector) with private IP routing. If an event-driven design requires capturing changes across GCP services in a standardized format, select Eventarc with CloudEvents .