{"id":578,"date":"2026-04-14T14:34:27","date_gmt":"2026-04-14T14:34:27","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-vertex-ai-workbench-instances-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-ai-and-ml\/"},"modified":"2026-04-14T14:34:27","modified_gmt":"2026-04-14T14:34:27","slug":"google-cloud-vertex-ai-workbench-instances-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-ai-and-ml","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-vertex-ai-workbench-instances-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-ai-and-ml\/","title":{"rendered":"Google Cloud Vertex AI Workbench instances Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for AI and ML"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>AI and ML<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p>Vertex AI Workbench instances is Google Cloud\u2019s service for provisioning and running Jupyter-based development environments on dedicated Compute Engine virtual machines (VMs), designed for AI and ML development workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph simple explanation<\/h3>\n\n\n\n<p>If your team wants a ready-to-use JupyterLab environment in Google Cloud\u2014without building a VM from scratch\u2014Vertex AI Workbench instances lets you create a managed \u201cnotebook VM,\u201d open JupyterLab from the Google Cloud Console, and use it to explore data, build features, train models, and run experiments using common ML frameworks.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph technical explanation<\/h3>\n\n\n\n<p>Technically, Vertex AI Workbench instances provisions a Compute Engine VM (in a specific zone) with a supported notebook runtime and an access proxy that integrates with Google Cloud IAM. You control the VM shape (CPU\/RAM), disks, GPUs, network placement (VPC\/subnet), and the VM service account used to access other Google Cloud services (such as Cloud Storage and BigQuery). Operations like start\/stop, access, and lifecycle actions are exposed through the Vertex AI Workbench UI and APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>AI\/ML teams frequently lose time and consistency managing developer environments: installing drivers, frameworks, dependencies, CUDA toolkits, and ensuring secure access to data and services. Vertex AI Workbench instances reduces that friction by providing a repeatable, Google Cloud\u2013integrated notebook VM pattern that is easy to deploy, secure with IAM, connect to data, and operate.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Vertex AI Workbench instances?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Vertex AI Workbench instances provides notebook-based development environments (JupyterLab) for data science and ML tasks on Google Cloud, backed by Compute Engine VMs and integrated with Vertex AI and other Google Cloud services.<\/p>\n\n\n\n<blockquote>\n<p>Naming note (important): Google Cloud has multiple \u201cWorkbench\u201d offerings. Vertex AI Workbench includes <strong>instances<\/strong> and also <strong>managed notebooks<\/strong> (a different offering with a different operational model). This tutorial is specifically about <strong>Vertex AI Workbench instances<\/strong>. Also, older materials may refer to <strong>AI Platform Notebooks<\/strong>\u2014that was the earlier name before the Vertex AI Workbench branding. Verify current product naming in the official docs if you are reading older guides.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provision a notebook VM with a JupyterLab environment suitable for AI\/ML development.<\/li>\n<li>Choose machine type (CPU\/RAM), boot and data disk options, and optional GPUs (where available).<\/li>\n<li>Control network placement (VPC\/subnet, IP configuration) and VM-level security settings.<\/li>\n<li>Use IAM and the Workbench access proxy to control who can open and use the notebook.<\/li>\n<li>Integrate with common Google Cloud data and ML services (for example, Cloud Storage, BigQuery, Artifact Registry, Vertex AI training and endpoints).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Workbench instance<\/strong>: The notebook VM resource you create in a project and zone.<\/li>\n<li><strong>Compute Engine VM<\/strong>: The underlying VM that runs the notebook runtime (and your code).<\/li>\n<li><strong>Instance runtime \/ environment<\/strong>: The OS image and preinstalled ML\/Jupyter components (options depend on what Google Cloud currently offers for Workbench instances\u2014verify in docs).<\/li>\n<li><strong>Service account (VM identity)<\/strong>: The identity used by code running on the VM to call Google Cloud APIs.<\/li>\n<li><strong>Network interfaces<\/strong>: VPC\/subnet configuration, firewall implications, and egress path (public internet or through NAT, depending on design).<\/li>\n<li><strong>Access proxy integration<\/strong>: The mechanism that allows you to open JupyterLab from the Console with IAM-based access control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Category<\/strong>: AI and ML (developer environment \/ notebooks)<\/li>\n<li><strong>Underlying infrastructure<\/strong>: Compute Engine VM-based<\/li>\n<li><strong>Control plane<\/strong>: Managed by Google Cloud (create\/start\/stop\/access through console\/API)<\/li>\n<li><strong>Data plane<\/strong>: Your VM executes code; you are responsible for what runs on it (packages, workloads, outbound connections, etc.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/zonal\/project-scoped)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Project-scoped<\/strong>: Instances are created inside a Google Cloud project.<\/li>\n<li><strong>Zonal resource<\/strong>: A Workbench instance runs in a specific <strong>zone<\/strong> (because it is backed by a Compute Engine VM).<\/li>\n<li><strong>Network-scoped<\/strong>: The VM attaches to a VPC\/subnet in the project (or a Shared VPC, if used).<\/li>\n<li><strong>IAM-scoped<\/strong>: Access is governed by IAM policies at project\/folder\/org level and possibly instance-level permissions depending on configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Vertex AI Workbench instances is typically used as the interactive \u201cworkbench\u201d layer in an AI and ML platform:\n&#8211; <strong>Data<\/strong>: Read\/write datasets in Cloud Storage; query BigQuery; use Dataproc\/Dataplex patterns as needed.\n&#8211; <strong>ML lifecycle<\/strong>: Develop locally in notebooks, then operationalize into Vertex AI training jobs, pipelines, and endpoints (when you\u2019re ready to productionize).\n&#8211; <strong>Security<\/strong>: Use IAM, VPC controls, service accounts, audit logs, and encryption controls consistent with Google Cloud governance.<\/p>\n\n\n\n<p>Official docs entry point (verify the latest navigation and feature set):\n&#8211; https:\/\/cloud.google.com\/vertex-ai\/docs\/workbench\/instances<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Vertex AI Workbench instances?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster onboarding<\/strong>: New team members can get a working notebook environment quickly.<\/li>\n<li><strong>Standardization<\/strong>: You can standardize on approved VM shapes, images, and access patterns.<\/li>\n<li><strong>Cloud proximity<\/strong>: Notebooks run near your Google Cloud data sources, reducing data movement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dedicated resources<\/strong>: Each instance gets its own VM resources (predictable performance compared to shared environments).<\/li>\n<li><strong>Flexibility<\/strong>: You can install custom dependencies and system packages (within OS and org constraints).<\/li>\n<li><strong>GPU-enabled development<\/strong>: When configured, developers can prototype on GPUs (subject to regional availability and quotas).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Start\/stop control<\/strong>: You can stop instances when not in use to reduce compute spend (persistent disks still cost).<\/li>\n<li><strong>Centralized visibility<\/strong>: Instances are visible and manageable in Google Cloud Console and via APIs.<\/li>\n<li><strong>Integration with standard Google Cloud ops<\/strong>: Cloud Logging\/Monitoring and IAM apply to the VM and surrounding services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based access<\/strong>: Access to open the notebook can be governed via Google Cloud IAM.<\/li>\n<li><strong>Network control<\/strong>: Place notebook VMs in private subnets, restrict egress, and design for least exposure.<\/li>\n<li><strong>Auditability<\/strong>: Admin actions are logged via Cloud Audit Logs; VM-level logs can be captured via agents.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scale by provisioning<\/strong>: You can provision multiple instances across teams and zones (within quota).<\/li>\n<li><strong>Performance tuning<\/strong>: Choose machine families optimized for your workload (CPU, memory, GPU).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Vertex AI Workbench instances when:\n&#8211; You want <strong>dedicated notebook VMs<\/strong> with strong Google Cloud integration.\n&#8211; You need <strong>flexibility<\/strong> to install packages and control the OS environment.\n&#8211; You want to keep development <strong>inside your VPC<\/strong> and governed by your org controls.\n&#8211; You\u2019re building an AI and ML platform where notebooks are a supported entry point into Vertex AI workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid or reconsider Vertex AI Workbench instances when:\n&#8211; You need a <strong>fully managed<\/strong> multi-user notebook platform with minimal VM ops (consider Vertex AI Workbench managed notebooks, or other managed platforms\u2014verify fit).\n&#8211; You need <strong>elastic, autoscaling<\/strong> interactive compute without managing individual VM lifecycles.\n&#8211; Your security posture disallows developer-managed VMs or requires stricter isolation than you can practically maintain.\n&#8211; Your users primarily need lightweight notebooks and are better served by a browser-only environment (for example, Colab Enterprise\u2014verify current Google Cloud offerings and constraints).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Vertex AI Workbench instances used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and insurance (model prototyping, feature engineering, risk analytics)<\/li>\n<li>Retail and e-commerce (recommendations, demand forecasting)<\/li>\n<li>Healthcare and life sciences (research workflows, ML-assisted analytics)<\/li>\n<li>Manufacturing (predictive maintenance, quality analytics)<\/li>\n<li>Media and gaming (personalization, content analytics)<\/li>\n<li>Public sector (analytics and forecasting, where governance is strict)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data scientists and applied ML engineers<\/li>\n<li>Data engineers (exploration and validation notebooks)<\/li>\n<li>MLOps and platform teams (standardized development environments)<\/li>\n<li>Security and compliance teams (governed notebook access patterns)<\/li>\n<li>Educators and students (structured labs in Google Cloud)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Exploratory data analysis (EDA)<\/li>\n<li>Feature engineering<\/li>\n<li>Model training prototypes<\/li>\n<li>Hyperparameter experimentation (small\/medium scale)<\/li>\n<li>Evaluation, explainability, and fairness checks<\/li>\n<li>Batch inference prototyping<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Notebook VM in private subnet + Cloud Storage\/BigQuery access via Private Google Access<\/li>\n<li>Notebook VM writing artifacts to Cloud Storage + model registration\/deployment in Vertex AI<\/li>\n<li>Notebook VM integrated with Git + Artifact Registry + CI\/CD<\/li>\n<li>Multi-project setups with Shared VPC and centralized logging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central platform team<\/strong> provides hardened instance templates and IAM patterns; product teams create instances in their own projects.<\/li>\n<li><strong>Regulated org<\/strong> places Workbench instances in a restricted VPC with egress controls and audited access.<\/li>\n<li><strong>Startup<\/strong> uses Workbench instances as the primary development environment, then migrates to Vertex AI Pipelines as they mature.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Best fit<\/strong>: Dev\/test, research, and prototyping.<\/li>\n<li><strong>Production<\/strong>: Notebooks themselves are usually not production runtimes. Production ML should move into repeatable pipelines\/jobs\/services (for example, Vertex AI Pipelines, training jobs, batch predictions, endpoints). Workbench instances can still be used in production-adjacent contexts for troubleshooting, analysis, and controlled maintenance workflows\u2014if your governance allows it.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Vertex AI Workbench instances is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Secure EDA on BigQuery datasets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Analysts need to explore large datasets without exporting data to local machines.<\/li>\n<li><strong>Why this service fits<\/strong>: The notebook runs in Google Cloud, authenticates with IAM, and can query BigQuery directly.<\/li>\n<li><strong>Example<\/strong>: A retail data scientist uses a Workbench instance to explore customer cohorts in BigQuery and writes features to Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Feature engineering with Cloud Storage datasets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Raw data stored as Parquet\/CSV in Cloud Storage must be transformed into ML-ready features.<\/li>\n<li><strong>Why this service fits<\/strong>: Direct access to Cloud Storage with the VM service account; easy iteration in notebooks.<\/li>\n<li><strong>Example<\/strong>: A team reads raw logs from <code>gs:\/\/...<\/code>, computes aggregations with pandas, and writes a cleaned dataset back to Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Prototype training on CPU\/GPU before operationalizing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need to rapidly test model architectures and training scripts.<\/li>\n<li><strong>Why this service fits<\/strong>: Choose VM types and optionally attach GPUs (where available).<\/li>\n<li><strong>Example<\/strong>: An ML engineer prototypes a PyTorch model on a GPU-backed Workbench instance, then ports the final training script to a Vertex AI custom training job.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Reproducible experimentation with Git-based workflows<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Notebook experiments become untraceable and hard to reproduce.<\/li>\n<li><strong>Why this service fits<\/strong>: Standard Linux VM environment integrates with Git; artifacts can be stored centrally.<\/li>\n<li><strong>Example<\/strong>: A team clones a repo, runs notebooks, and saves model artifacts and metrics to Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Data validation and drift investigation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A model\u2019s performance drops; the team needs quick analysis against new data.<\/li>\n<li><strong>Why this service fits<\/strong>: A controlled environment with access to logs, datasets, and monitoring exports.<\/li>\n<li><strong>Example<\/strong>: An on-call ML engineer uses a Workbench instance to pull recent inference logs, compute drift stats, and share results.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Building and testing Vertex AI Pipelines components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Developing pipeline components locally is slow and inconsistent.<\/li>\n<li><strong>Why this service fits<\/strong>: Notebook VM can build, test, and push artifacts (containers, Python packages) in the same cloud environment.<\/li>\n<li><strong>Example<\/strong>: A platform engineer builds pipeline components and stores them in Artifact Registry, then triggers pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Education and internal training labs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Students need consistent environments without local installation.<\/li>\n<li><strong>Why this service fits<\/strong>: Centralized project control, consistent VM images, and easy reset via instance recreation.<\/li>\n<li><strong>Example<\/strong>: An instructor provides a lab where each student creates a small Workbench instance and runs guided notebooks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Private network-only notebook development<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security policy restricts public IPs and internet exposure.<\/li>\n<li><strong>Why this service fits<\/strong>: Workbench instances can be placed in private subnets with controlled egress (design-dependent).<\/li>\n<li><strong>Example<\/strong>: A bank runs notebooks in a private subnet, uses Cloud NAT for outbound package installs, and restricts inbound access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Batch inference prototyping<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need to test batch prediction code and performance characteristics.<\/li>\n<li><strong>Why this service fits<\/strong>: Easy to read from Cloud Storage and write predictions back; can scale VM size for testing.<\/li>\n<li><strong>Example<\/strong>: A team runs a batch inference script over a sample dataset, validating output format and runtime.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Debugging containerized training code<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Training container fails in CI or on Vertex AI; debugging requires an interactive environment.<\/li>\n<li><strong>Why this service fits<\/strong>: Workbench instance offers a controlled environment to run the container interactively.<\/li>\n<li><strong>Example<\/strong>: An engineer pulls a training image from Artifact Registry and runs it locally on the VM to inspect errors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Integrating with enterprise identity and audit<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Need governed access tied to corporate identity, with audit trails.<\/li>\n<li><strong>Why this service fits<\/strong>: IAM controls and Cloud Audit Logs cover admin actions; access can be restricted via org policy.<\/li>\n<li><strong>Example<\/strong>: Security team mandates group-based access to Workbench instances and reviews audit logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Lightweight model evaluation and reporting<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A product team needs periodic evaluation reports for model versions.<\/li>\n<li><strong>Why this service fits<\/strong>: A notebook can run scheduled evaluation manually (or be adapted to scheduled jobs later).<\/li>\n<li><strong>Example<\/strong>: Monthly evaluation notebook generates charts and stores them in Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can differ by region, image, organization policies, and Google Cloud release stage. Verify feature specifics in the official docs: https:\/\/cloud.google.com\/vertex-ai\/docs\/workbench\/instances<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) VM-backed JupyterLab environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provisions a dedicated Compute Engine VM that runs JupyterLab (and related tooling).<\/li>\n<li><strong>Why it matters<\/strong>: Predictable resources; fewer \u201cnoisy neighbor\u201d issues.<\/li>\n<li><strong>Practical benefit<\/strong>: You can choose a machine type appropriate for your workload (from small CPU VMs to larger systems).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: You are responsible for many VM lifecycle concerns (packages, disk usage, process management, OS-level changes).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) IAM-integrated access to the notebook UI<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Google Cloud IAM to control who can open the notebook environment from the Console.<\/li>\n<li><strong>Why it matters<\/strong>: Centralized access control aligned with your organization\u2019s identity model.<\/li>\n<li><strong>Practical benefit<\/strong>: You can grant access via groups and roles rather than sharing VM credentials.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Users still must be authorized to access data sources through the VM\u2019s service account or their configured credentials.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Choice of machine types, disks, and optional GPUs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you configure CPU\/RAM, boot disk, and (optionally) attach GPUs if supported in the zone.<\/li>\n<li><strong>Why it matters<\/strong>: AI\/ML workloads vary widely; right-sizing can reduce cost and improve iteration speed.<\/li>\n<li><strong>Practical benefit<\/strong>: Start small and scale up when needed.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: GPU availability is quota- and region-dependent; you may need to request quota increases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Network placement in your VPC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Attaches the VM to a chosen VPC\/subnet (including Shared VPC scenarios).<\/li>\n<li><strong>Why it matters<\/strong>: Enables private connectivity patterns, controlled egress, and alignment with enterprise network segmentation.<\/li>\n<li><strong>Practical benefit<\/strong>: Reduce exposure by placing notebooks in private subnets and controlling outbound access.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Private networking requires careful design (DNS, NAT, Private Google Access, firewall rules).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Service account identity for accessing Google Cloud APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: The VM runs with a chosen service account to access services (Cloud Storage, BigQuery, Vertex AI, etc.).<\/li>\n<li><strong>Why it matters<\/strong>: Enables least-privilege, auditable access without embedding keys.<\/li>\n<li><strong>Practical benefit<\/strong>: You can scope access tightly (for example, to a specific bucket).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Misconfigured permissions are a common source of \u201cpermission denied\u201d errors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Integration with common AI\/ML tooling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a notebook environment that can work with popular Python ML libraries and Google Cloud client libraries.<\/li>\n<li><strong>Why it matters<\/strong>: Faster setup for typical ML tasks.<\/li>\n<li><strong>Practical benefit<\/strong>: Less time on environment bootstrapping.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Library versions and image contents change; pin dependencies for reproducibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Compatibility with Google Cloud operations tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: As a VM, it can emit logs and metrics via Cloud Logging\/Monitoring (depending on agents and configuration).<\/li>\n<li><strong>Why it matters<\/strong>: Operations teams can monitor resource use, detect issues, and manage costs.<\/li>\n<li><strong>Practical benefit<\/strong>: Better visibility than unmanaged developer laptops.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: You may need to install\/configure the Ops Agent and define log collection explicitly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) API-driven management (automation potential)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Instances can be managed via APIs\/CLI in addition to the Console (exact tooling and command groups can change\u2014verify).<\/li>\n<li><strong>Why it matters<\/strong>: Enables infrastructure-as-code and standardized provisioning.<\/li>\n<li><strong>Practical benefit<\/strong>: Repeatable provisioning patterns across teams.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Ensure your automation uses current APIs and supported fields; validate against official docs and your org policies.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level, a Vertex AI Workbench instance is a Compute Engine VM plus an access layer that lets authorized users open JupyterLab from the Google Cloud Console. Your code runs on the VM and calls Google Cloud APIs using the VM\u2019s service account (or other configured credentials). Data typically lives in Cloud Storage and\/or BigQuery.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\n<p><strong>Control plane (create\/start\/stop\/configure)<\/strong>:\n  1. Admin\/user creates a Workbench instance in a project and zone.\n  2. Google Cloud provisions the underlying Compute Engine VM.\n  3. The Workbench service associates access permissions and manages the \u201cOpen JupyterLab\u201d experience.<\/p>\n<\/li>\n<li>\n<p><strong>Access (interactive notebooks)<\/strong>:\n  1. A user with appropriate IAM permissions opens the instance from the Console.\n  2. The user is routed through the Workbench access proxy to the JupyterLab UI on the VM.\n  3. Notebook kernels execute code on the VM.<\/p>\n<\/li>\n<li>\n<p><strong>Data plane (data + ML artifacts)<\/strong>:\n  1. Code reads data from Cloud Storage\/BigQuery (and other services).\n  2. Artifacts (datasets, model files, reports) are written back to Cloud Storage or registered into downstream systems.<\/p>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services (common patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Storage<\/strong>: datasets, artifacts, checkpoints.<\/li>\n<li><strong>BigQuery<\/strong>: analytics and feature extraction.<\/li>\n<li><strong>Artifact Registry<\/strong>: store containers for training\/pipelines.<\/li>\n<li><strong>Vertex AI<\/strong>: move from notebook prototypes to training jobs, pipelines, model registry, endpoints (verify exact integration paths in current docs).<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: operational monitoring of VM and workflows.<\/li>\n<li><strong>Secret Manager<\/strong>: store API keys or third-party credentials (recommended over plaintext).<\/li>\n<li><strong>Cloud NAT \/ Private Google Access<\/strong>: enable private instances to reach Google APIs and package repos (architecture-dependent).<\/li>\n<li><strong>Cloud IAM<\/strong>: user access and service account permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine (VMs, disks, GPUs)<\/li>\n<li>IAM (users\/groups\/roles; service accounts)<\/li>\n<li>VPC networking (subnets, firewall rules, routes)<\/li>\n<li>Vertex AI Workbench\/Notebooks API (service backend; verify exact API names in docs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model (practical view)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User authentication<\/strong>: Google identity via IAM; users need permissions to access\/launch\/open the instance.<\/li>\n<li><strong>Workload authentication<\/strong>: VM service account provides application default credentials for code running on the instance.<\/li>\n<li><strong>Separation of concerns<\/strong>: User\u2019s ability to open Jupyter \u2260 permission for the notebook code to access data. Data access depends on the VM service account and IAM bindings on data resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Instance is a VM attached to your VPC\/subnet.<\/li>\n<li>Ingress to Jupyter is typically mediated through Google Cloud\u2019s access experience rather than direct open inbound ports (best practice: avoid exposing Jupyter directly on the internet).<\/li>\n<li>Egress depends on whether the instance has external IP, Cloud NAT, and firewall\/route policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Audit Logs<\/strong>: track API calls for instance management and IAM changes.<\/li>\n<li><strong>VM logs\/metrics<\/strong>: install\/configure Ops Agent to capture OS\/application logs and metrics if required by ops standards.<\/li>\n<li><strong>Labels\/tags<\/strong>: apply labels for cost allocation (team, env, cost-center, owner).<\/li>\n<li><strong>Org policies<\/strong>: enforce restrictions (no external IPs, allowed images, allowed regions, CMEK requirements) where needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User (Browser)] --&gt;|Google Cloud Console| C[Vertex AI Workbench UI]\n  C --&gt;|Open JupyterLab (IAM-controlled)| P[Workbench Access Proxy]\n  P --&gt; VM[Vertex AI Workbench instance&lt;br\/&gt;(Compute Engine VM)]\n  VM --&gt; GCS[Cloud Storage]\n  VM --&gt; BQ[BigQuery]\n  VM --&gt; VAI[Vertex AI (training\/endpoints)]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph NetPrj[Network Project (Shared VPC)]\n      VPC[(Shared VPC)]\n      SUB[Private Subnet]\n      NAT[Cloud NAT]\n      FW[Firewall Policies]\n    end\n\n    subgraph MlPrj[ML Project]\n      IAM[IAM &amp; Groups]\n      SA[Notebook VM Service Account]\n      WB[Vertex AI Workbench instances]\n      LOG[Cloud Logging\/Monitoring]\n      SM[Secret Manager]\n      AR[Artifact Registry]\n      GCS[(Cloud Storage Buckets)]\n      BQ[(BigQuery Datasets)]\n      VERTEX[Vertex AI (Pipelines\/Training\/Endpoints)]\n    end\n  end\n\n  User[Developer] --&gt;|SSO\/IAM| IAM\n  IAM --&gt; WB\n  WB --&gt;|VM in Shared VPC subnet| SUB\n  SUB --&gt; FW\n  WB --&gt;|Egress| NAT\n  WB --&gt;|Read\/Write| GCS\n  WB --&gt;|Query| BQ\n  WB --&gt;|Pull\/Push| AR\n  WB --&gt;|Retrieve secrets| SM\n  WB --&gt;|Submit jobs \/ deploy models| VERTEX\n  WB --&gt; LOG\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with access to create and manage resources.<\/li>\n<li>A Google Cloud project with <strong>billing enabled<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles (minimum guidance)<\/h3>\n\n\n\n<p>Roles vary by organization and exact workflow. As a starting point:\n&#8211; For admins who create\/manage instances: permissions to create notebook instances and underlying Compute Engine resources.\n&#8211; For users who open\/use instances: permissions to access\/open the instance plus whatever data access is needed.<\/p>\n\n\n\n<p>Common IAM roles you may see in official docs (verify current role names and recommended least-privilege setup):\n&#8211; Vertex AI Workbench \/ Notebooks roles (for managing and running instances)\n&#8211; Compute Engine roles (if you manage underlying VM settings)\n&#8211; Storage roles for Cloud Storage access (for example, bucket-level access)\n&#8211; BigQuery roles (if querying BigQuery)<\/p>\n\n\n\n<p>Official IAM guidance for Workbench instances (verify current):\n&#8211; https:\/\/cloud.google.com\/vertex-ai\/docs\/workbench\/instances\/access-control<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Billing must be enabled because Workbench instances incur Compute Engine VM and disk costs, and potentially GPU and network egress costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud Console<\/strong> access (sufficient for the lab).<\/li>\n<li>Optional:<\/li>\n<li><code>gcloud<\/code> CLI (Cloud SDK) for enabling APIs and basic verification.<\/li>\n<li>A browser to open JupyterLab.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Workbench instances are zonal; available regions\/zones depend on Google Cloud. Verify the latest supported locations in official documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Common quota areas (verify in your project\/region):\n&#8211; Compute Engine CPU quotas\n&#8211; GPU quotas (if using GPUs)\n&#8211; Persistent disk quotas\n&#8211; Any Workbench\/Notebooks API quotas<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (APIs)<\/h3>\n\n\n\n<p>Typically required (verify in docs and in your environment):\n&#8211; Vertex AI API: <code>aiplatform.googleapis.com<\/code>\n&#8211; Notebooks \/ Workbench API: often <code>notebooks.googleapis.com<\/code> (verify current API name in docs)\n&#8211; Compute Engine API: <code>compute.googleapis.com<\/code>\n&#8211; IAM APIs are generally available, but permissions must be granted.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Vertex AI Workbench instances pricing is primarily the cost of the underlying Google Cloud infrastructure it uses.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>You typically pay for:\n&#8211; <strong>Compute Engine VM runtime<\/strong>: CPU\/RAM while the instance is running.\n&#8211; <strong>Persistent disks<\/strong>: boot disk and any attached data disks (charged even when VM is stopped).\n&#8211; <strong>GPUs (optional)<\/strong>: GPU hourly cost while attached and running (and in some cases while allocated\u2014verify specifics per GPU type).\n&#8211; <strong>Network egress<\/strong>: data leaving a region or leaving Google Cloud to the internet.\n&#8211; <strong>Other services used by notebooks<\/strong>: BigQuery query costs, Cloud Storage operations, Artifact Registry storage\/egress, etc.<\/p>\n\n\n\n<p>There is not typically a separate \u201cVertex AI Workbench instances license fee\u201d beyond underlying resources, but always confirm in current pricing documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine has certain free-tier offerings in specific regions for specific VM types, but applicability to Workbench instances is not guaranteed. Treat free tier as \u201cpossible but not assumed,\u201d and verify in official pricing docs.<\/li>\n<li>In practice, most Workbench instance usage is billable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<p>Major cost drivers include:\n&#8211; Leaving instances running 24\/7 (compute costs accumulate continuously).\n&#8211; Large machine types and high-memory configurations.\n&#8211; GPUs and large disks.\n&#8211; High egress (downloading large datasets to local machines, or cross-region reads\/writes).\n&#8211; Repeated BigQuery scans of large tables from exploratory notebooks.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Stopped VM still costs money<\/strong> due to persistent disks.<\/li>\n<li><strong>Snapshot\/backup storage<\/strong> if you implement disk snapshots.<\/li>\n<li><strong>Package installs and updates<\/strong> can increase egress and can require NAT in private designs (NAT itself is not free).<\/li>\n<li><strong>BigQuery exploration<\/strong> can become expensive if queries scan large partitions repeatedly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep your Workbench instance in the same region as your primary datasets to reduce cross-region costs and latency.<\/li>\n<li>Avoid downloading large datasets to local machines; prefer Cloud Storage or BigQuery access from within Google Cloud.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Stop instances when not in use (and consider automation or policy to enforce).<\/li>\n<li>Right-size machine types; scale up only when needed.<\/li>\n<li>Use smaller disks; store large datasets in Cloud Storage rather than on the VM disk.<\/li>\n<li>Prefer regional colocation (instance, bucket, BigQuery dataset in same region).<\/li>\n<li>Use labels for cost allocation and budgets\/alerts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (model, not numbers)<\/h3>\n\n\n\n<p>A minimal starter setup typically includes:\n&#8211; A small general-purpose VM (CPU-only)\n&#8211; A modest boot disk\n&#8211; A single Cloud Storage bucket for artifacts<\/p>\n\n\n\n<p>To estimate:\n1. Use the <strong>Compute Engine VM pricing<\/strong> page for your region and machine family: https:\/\/cloud.google.com\/compute\/vm-instance-pricing<br\/>\n2. Add <strong>Persistent Disk pricing<\/strong> for your chosen disk type\/size: https:\/\/cloud.google.com\/compute\/disks-image-pricing<br\/>\n3. Add any expected <strong>network egress<\/strong>: https:\/\/cloud.google.com\/vpc\/network-pricing<br\/>\n4. Add any <strong>Vertex AI \/ BigQuery<\/strong> usage if applicable:\n   &#8211; Vertex AI pricing: https:\/\/cloud.google.com\/vertex-ai\/pricing\n   &#8211; BigQuery pricing: https:\/\/cloud.google.com\/bigquery\/pricing<\/p>\n\n\n\n<p>For a more accurate estimate, use the Google Cloud Pricing Calculator:\n&#8211; https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production-like enterprise usage, consider:\n&#8211; Multiple teams each with one or more instances (cost scales linearly with instance count).\n&#8211; Private networking with Cloud NAT and logging requirements.\n&#8211; GPU-backed instances for deep learning experimentation.\n&#8211; Centralized artifact storage and frequent reads\/writes.\n&#8211; Governance tooling (security agents, monitoring agents) that adds overhead.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab creates one Vertex AI Workbench instance, runs a small ML notebook workflow, saves an artifact to Cloud Storage, and then cleans everything up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Provision a <strong>Vertex AI Workbench instance<\/strong>, open <strong>JupyterLab<\/strong>, train a small scikit-learn model on a toy dataset, and write the trained model artifact to a <strong>Cloud Storage<\/strong> bucket using the instance\u2019s service account.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare your Google Cloud project (billing + APIs).\n2. Create a Cloud Storage bucket for artifacts.\n3. Create a dedicated service account for the notebook VM and grant minimal storage permissions.\n4. Create a Vertex AI Workbench instance and open JupyterLab.\n5. Run a notebook cell sequence to train a model and upload it to Cloud Storage.\n6. Validate the artifact exists in Cloud Storage.\n7. Clean up (delete instance and bucket).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Select a project and enable required APIs<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Ensure your project is ready for Vertex AI Workbench instances.<\/p>\n\n\n\n<p>1) In the Google Cloud Console, select (or create) a project:\n&#8211; https:\/\/console.cloud.google.com\/projectselector2\/home\/dashboard<\/p>\n\n\n\n<p>2) Confirm billing is enabled:\n&#8211; https:\/\/console.cloud.google.com\/billing<\/p>\n\n\n\n<p>3) Enable APIs (Console method):\n&#8211; Go to <strong>APIs &amp; Services \u2192 Library<\/strong>:\n  &#8211; https:\/\/console.cloud.google.com\/apis\/library\n&#8211; Enable (at minimum):\n  &#8211; <strong>Vertex AI API<\/strong>\n  &#8211; <strong>Notebooks API<\/strong> (or the current API referenced by Workbench instances docs)\n  &#8211; <strong>Compute Engine API<\/strong><\/p>\n\n\n\n<p>Optional <code>gcloud<\/code> method (verify API names in your environment):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project YOUR_PROJECT_ID\n\ngcloud services enable \\\n  aiplatform.googleapis.com \\\n  notebooks.googleapis.com \\\n  compute.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: APIs show as \u201cEnabled\u201d in <strong>APIs &amp; Services \u2192 Enabled APIs &amp; services<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a Cloud Storage bucket for artifacts<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Create a bucket to store the trained model file.<\/p>\n\n\n\n<p>1) Open Cloud Storage buckets:\n&#8211; https:\/\/console.cloud.google.com\/storage\/browser<\/p>\n\n\n\n<p>2) Click <strong>Create<\/strong> and choose:\n&#8211; A globally unique bucket name, for example: <code>YOUR_PROJECT_ID-wb-artifacts<\/code>\n&#8211; Location: choose a region close to your Workbench instance region (for lower latency and cost)\n&#8211; Default settings are fine for this lab (for production, review encryption, retention, and uniform access)<\/p>\n\n\n\n<p>Optional <code>gcloud<\/code> method:<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Choose a region, e.g. us-central1 (pick one that works for you)\nREGION=us-central1\nBUCKET=gs:\/\/YOUR_PROJECT_ID-wb-artifacts\n\ngcloud storage buckets create \"$BUCKET\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Bucket appears in the Cloud Storage browser.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a service account for the Workbench instance (least privilege)<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Ensure notebook code can write to the bucket without using long-lived keys.<\/p>\n\n\n\n<p>1) Create a service account:\n&#8211; Console: <strong>IAM &amp; Admin \u2192 Service Accounts<\/strong>\n  &#8211; https:\/\/console.cloud.google.com\/iam-admin\/serviceaccounts\n&#8211; Click <strong>Create service account<\/strong>\n  &#8211; Name: <code>wb-instance-sa<\/code>\n  &#8211; ID: <code>wb-instance-sa<\/code><\/p>\n\n\n\n<p>2) Grant the service account bucket-scoped permissions:\n&#8211; Go to your bucket \u2192 <strong>Permissions<\/strong>\n&#8211; Grant <code>Storage Object Creator<\/code> (or <code>Storage Object Admin<\/code> for lab simplicity) to:\n  &#8211; <code>wb-instance-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com<\/code><\/p>\n\n\n\n<p>For example, using <code>gcloud<\/code> (bucket IAM):<\/p>\n\n\n\n<pre><code class=\"language-bash\">SA=\"wb-instance-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com\"\nBUCKET=\"gs:\/\/YOUR_PROJECT_ID-wb-artifacts\"\n\n# Least privilege for uploads:\ngcloud storage buckets add-iam-policy-binding \"$BUCKET\" \\\n  --member=\"serviceAccount:$SA\" \\\n  --role=\"roles\/storage.objectCreator\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The service account exists and has permission to write objects into your lab bucket.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Vertex AI Workbench instance<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Provision the notebook VM.<\/p>\n\n\n\n<p>1) Open Vertex AI Workbench:\n&#8211; https:\/\/console.cloud.google.com\/vertex-ai\/workbench<\/p>\n\n\n\n<p>2) Go to <strong>Instances<\/strong> (ensure you are in the \u201cinstances\u201d section, not \u201cmanaged notebooks\u201d).<\/p>\n\n\n\n<p>3) Click <strong>Create<\/strong> (or <strong>New instance<\/strong>). Configure:\n&#8211; <strong>Name<\/strong>: <code>wb-instance-lab<\/code>\n&#8211; <strong>Region\/Zone<\/strong>: pick a zone near your data (and where quota is available)\n&#8211; <strong>Machine type<\/strong>: choose a small CPU VM to keep cost low (for example, 2 vCPU\/8 GB class)\n&#8211; <strong>GPU<\/strong>: None (for low-cost lab)\n&#8211; <strong>Boot disk<\/strong>: keep modest size\n&#8211; <strong>Service account<\/strong>: select <code>wb-instance-sa<\/code>\n&#8211; <strong>Network<\/strong>: default VPC is fine for a lab; for enterprise, use a controlled subnet<\/p>\n\n\n\n<p>4) Create the instance and wait until its status indicates it is ready\/running.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: You see the instance in the Instances list with a \u201crunning\/ready\u201d state.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Open JupyterLab and run the ML workflow<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Train a small model and upload it to Cloud Storage.<\/p>\n\n\n\n<p>1) In the Workbench instances list, click <strong>Open JupyterLab<\/strong> for <code>wb-instance-lab<\/code>.<\/p>\n\n\n\n<p>2) In JupyterLab, create a new notebook:\n&#8211; <strong>File \u2192 New \u2192 Notebook<\/strong>\n&#8211; Choose the default Python kernel.<\/p>\n\n\n\n<p>3) Run the following cells (copy\/paste). This example:\n&#8211; Loads a small dataset from <code>seaborn<\/code>\n&#8211; Trains a basic model\n&#8211; Writes the trained model to a local file\n&#8211; Uploads it to your Cloud Storage bucket using the VM\u2019s service account<\/p>\n\n\n\n<p><strong>Cell 1: Install dependencies (if needed)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-python\">import sys\n!{sys.executable} -m pip install --quiet seaborn scikit-learn joblib google-cloud-storage\n<\/code><\/pre>\n\n\n\n<p><strong>Cell 2: Train a small model<\/strong><\/p>\n\n\n\n<pre><code class=\"language-python\">import seaborn as sns\nfrom sklearn.model_selection import train_test_split\nfrom sklearn.compose import ColumnTransformer\nfrom sklearn.pipeline import Pipeline\nfrom sklearn.preprocessing import OneHotEncoder\nfrom sklearn.impute import SimpleImputer\nfrom sklearn.metrics import accuracy_score\nfrom sklearn.linear_model import LogisticRegression\nimport joblib\n\n# Load a small dataset (downloads a small CSV; requires outbound internet access)\ndf = sns.load_dataset(\"penguins\").dropna()\n\nX = df[[\"island\", \"bill_length_mm\", \"bill_depth_mm\", \"flipper_length_mm\", \"body_mass_g\", \"sex\"]]\ny = df[\"species\"]\n\nX_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, random_state=42, stratify=y)\n\ncat_cols = [\"island\", \"sex\"]\nnum_cols = [\"bill_length_mm\", \"bill_depth_mm\", \"flipper_length_mm\", \"body_mass_g\"]\n\npreprocess = ColumnTransformer(\n    transformers=[\n        (\"cat\", Pipeline(steps=[\n            (\"imputer\", SimpleImputer(strategy=\"most_frequent\")),\n            (\"onehot\", OneHotEncoder(handle_unknown=\"ignore\"))\n        ]), cat_cols),\n        (\"num\", Pipeline(steps=[\n            (\"imputer\", SimpleImputer(strategy=\"median\")),\n        ]), num_cols),\n    ]\n)\n\nclf = Pipeline(steps=[\n    (\"preprocess\", preprocess),\n    (\"model\", LogisticRegression(max_iter=200))\n])\n\nclf.fit(X_train, y_train)\npred = clf.predict(X_test)\nacc = accuracy_score(y_test, pred)\n\nacc\n<\/code><\/pre>\n\n\n\n<p><strong>Expected output<\/strong>: An accuracy value (for example, around 0.9\u20131.0 depending on split).<\/p>\n\n\n\n<p><strong>Cell 3: Save and upload the model artifact to Cloud Storage<\/strong><\/p>\n\n\n\n<pre><code class=\"language-python\">from google.cloud import storage\nfrom datetime import datetime\nimport os\n\nbucket_name = \"YOUR_PROJECT_ID-wb-artifacts\"  # &lt;-- change this\nlocal_path = \"\/home\/jupyter\/penguins_model.joblib\"  # path may vary by image; adjust if needed\n\njoblib.dump(clf, local_path)\n\nclient = storage.Client()\nbucket = client.bucket(bucket_name)\n\nstamp = datetime.utcnow().strftime(\"%Y%m%d-%H%M%S\")\nblob_path = f\"models\/penguins_model_{stamp}.joblib\"\n\nblob = bucket.blob(blob_path)\nblob.upload_from_filename(local_path)\n\nprint(\"Uploaded:\", f\"gs:\/\/{bucket_name}\/{blob_path}\")\nprint(\"Local file size (bytes):\", os.path.getsize(local_path))\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The notebook prints a <code>gs:\/\/...<\/code> path confirming upload.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Validate the artifact in Cloud Storage<\/h3>\n\n\n\n<p><strong>Goal<\/strong>: Confirm the upload worked and permissions are correct.<\/p>\n\n\n\n<p>1) Go back to the Cloud Storage bucket in the Console:\n&#8211; https:\/\/console.cloud.google.com\/storage\/browser<\/p>\n\n\n\n<p>2) Navigate to <code>models\/<\/code> and confirm you see the <code>penguins_model_*.joblib<\/code> object.<\/p>\n\n\n\n<p>Optional <code>gcloud<\/code> validation:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage ls \"gs:\/\/YOUR_PROJECT_ID-wb-artifacts\/models\/\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The object is listed in the bucket.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully completed the lab if:\n&#8211; The Workbench instance is running and JupyterLab opens from the Console.\n&#8211; The model trains and returns an accuracy score.\n&#8211; A model artifact is uploaded to <code>gs:\/\/YOUR_PROJECT_ID-wb-artifacts\/models\/...<\/code>.\n&#8211; The object is visible in Cloud Storage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>JupyterLab won\u2019t open \/ access denied<\/strong>\n&#8211; Confirm you have the required IAM permissions to open\/run Workbench instances.\n&#8211; Check whether organization policies restrict notebook access or external access.\n&#8211; Verify the instance is in a \u201crunning\/ready\u201d state.<\/p>\n\n\n\n<p>2) <strong><code>403 Forbidden<\/code> when uploading to Cloud Storage<\/strong>\n&#8211; Confirm the Workbench instance is using the intended VM service account (<code>wb-instance-sa<\/code>).\n&#8211; Confirm bucket IAM includes <code>roles\/storage.objectCreator<\/code> (or stronger) for that service account.\n&#8211; If you changed bucket name\/region, verify you updated <code>bucket_name<\/code> correctly.<\/p>\n\n\n\n<p>3) <strong>Package installation fails (pip cannot reach internet)<\/strong>\n&#8211; If your instance is in a restricted network without internet egress, you may need Cloud NAT or allowlisted egress to Python package repos.\n&#8211; For locked-down environments, prebuild images or use internal package repositories (enterprise pattern).<\/p>\n\n\n\n<p>4) <strong>Quota errors when creating the instance<\/strong>\n&#8211; Check Compute Engine CPU quota in the chosen region\/zone.\n&#8211; If using GPUs, check GPU quota and GPU availability in the zone.<\/p>\n\n\n\n<p>5) <strong>Kernel keeps disconnecting<\/strong>\n&#8211; VM might be underprovisioned (too small) or running out of disk.\n&#8211; Check VM CPU\/memory in Compute Engine metrics and resize if needed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, clean up resources:<\/p>\n\n\n\n<p>1) Delete the Workbench instance:\n&#8211; Vertex AI \u2192 Workbench \u2192 Instances\n&#8211; Select <code>wb-instance-lab<\/code> \u2192 <strong>Delete<\/strong>\n&#8211; If prompted, delete associated disks (review carefully; disks are billable even if the VM is deleted).<\/p>\n\n\n\n<p>2) Delete the Cloud Storage bucket (if you don\u2019t need it):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud storage rm -r \"gs:\/\/YOUR_PROJECT_ID-wb-artifacts\"\n<\/code><\/pre>\n\n\n\n<p>3) Optionally delete the service account:\n&#8211; https:\/\/console.cloud.google.com\/iam-admin\/serviceaccounts<\/p>\n\n\n\n<p>4) Optionally disable APIs (usually not necessary, but can reduce accidental usage):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services disable notebooks.googleapis.com aiplatform.googleapis.com compute.googleapis.com\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate dev and prod projects<\/strong>: Put Workbench instances in dev projects; keep production data access tightly scoped.<\/li>\n<li><strong>Keep data in managed stores<\/strong>: Prefer Cloud Storage\/BigQuery over large local VM disks.<\/li>\n<li><strong>Colocate resources<\/strong>: Place instances near the data region to reduce latency and egress costs.<\/li>\n<li><strong>Plan for reproducibility<\/strong>: Treat notebooks as prototypes; extract stable logic into modules, scripts, or pipeline components.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege for VM service accounts<\/strong>: Grant bucket\/dataset-specific access, not broad project-wide roles.<\/li>\n<li><strong>Use groups<\/strong>: Bind IAM roles to groups instead of individuals.<\/li>\n<li><strong>Avoid service account keys<\/strong>: Use workload identity via the VM service account; do not download long-lived keys to the VM.<\/li>\n<li><strong>Review who can \u201copen\u201d instances<\/strong>: Opening a notebook often implies access to the environment where credentials and data may be reachable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Stop instances when idle<\/strong>: Build team habits and automation. Disks still cost\u2014right-size them.<\/li>\n<li><strong>Label everything<\/strong>: <code>env<\/code>, <code>team<\/code>, <code>owner<\/code>, <code>cost-center<\/code>, <code>purpose<\/code>.<\/li>\n<li><strong>Use budgets and alerts<\/strong>: Set project budgets to detect runaway notebook usage.<\/li>\n<li><strong>Beware of BigQuery scans<\/strong>: Teach teams to use partition filters and preview data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Right-size VM and disk<\/strong>: Use SSD when IO-bound; scale CPU\/RAM for large pandas workloads.<\/li>\n<li><strong>Use efficient formats<\/strong>: Prefer Parquet\/ORC for large datasets in Cloud Storage.<\/li>\n<li><strong>Avoid local-only storage for critical artifacts<\/strong>: Store artifacts in Cloud Storage for durability and sharing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Treat the VM as ephemeral<\/strong>: Back up critical work to Git\/Cloud Storage.<\/li>\n<li><strong>Use persistent storage appropriately<\/strong>: Keep essential notebooks in source control; keep minimal state on the VM disk.<\/li>\n<li><strong>Snapshots (when needed)<\/strong>: For important environments, consider disk snapshot policies\u2014balanced against cost and governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central image strategy<\/strong>: If your org supports it, standardize images or base environments to reduce drift.<\/li>\n<li><strong>Logging\/monitoring<\/strong>: Install\/configure the Ops Agent if you need OS\/application logs beyond default.<\/li>\n<li><strong>Patch cadence<\/strong>: Define how and when images and packages are updated; uncontrolled updates harm reproducibility.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming convention example:<\/li>\n<li><code>wb-{team}-{env}-{purpose}-{zone}<\/code> (keep within GCP name limits)<\/li>\n<li>Label examples:<\/li>\n<li><code>team=data-science<\/code>, <code>env=dev<\/code>, <code>owner=alice<\/code>, <code>app=recsys<\/code>, <code>cost-center=cc1234<\/code><\/li>\n<li>Enforce policies via org policy and IaC where possible.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User access<\/strong>: Controlled by IAM. Ensure only authorized users can open Workbench instances.<\/li>\n<li><strong>Workload access<\/strong>: Controlled by the VM\u2019s service account and IAM on downstream resources.<\/li>\n<li><strong>Recommendation<\/strong>: Separate \u201cwho can open the notebook\u201d from \u201cwhat the notebook can access\u201d using least-privileged service accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>At rest<\/strong>: Compute Engine disks and Cloud Storage are encrypted by default with Google-managed keys; CMEK options may be available depending on service and org policy.<\/li>\n<li><strong>In transit<\/strong>: Access to the notebook UI uses HTTPS via Google Cloud\u2019s access path.<\/li>\n<li><strong>Recommendation<\/strong>: For regulated workloads, evaluate CMEK requirements and verify current support for Workbench instances and attached resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid exposing Jupyter directly to the internet.<\/li>\n<li>Prefer private networking and controlled egress (Cloud NAT, firewall policies) for enterprise deployments.<\/li>\n<li>Restrict outbound access if data exfiltration is a concern (requires careful planning; notebooks often need package downloads).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store secrets in notebooks or plaintext files.<\/li>\n<li>Use <strong>Secret Manager<\/strong> and retrieve secrets at runtime with the VM service account.<\/li>\n<li>If you must access external services, avoid embedding API keys; rotate and audit.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Audit Logs<\/strong> capture admin actions and API calls.<\/li>\n<li>Consider additional VM-level logging depending on compliance requirements (Ops Agent).<\/li>\n<li>Ensure logs are routed and retained per policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Consider data residency: choose instance zones and data locations aligned with policy.<\/li>\n<li>Apply org policies (no external IPs, restricted services, allowed regions).<\/li>\n<li>For highly regulated environments, consider VPC Service Controls around data services (verify applicability and design carefully).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Using overly permissive service accounts (for example, project-wide Editor).<\/li>\n<li>Leaving instances running with broad internet egress and no monitoring.<\/li>\n<li>Storing secrets in notebooks or in home directories.<\/li>\n<li>Granting too many users access to open the instance without reviewing what data the VM can access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a dedicated service account per environment\/team with tightly scoped IAM.<\/li>\n<li>Place instances in a private subnet; control egress through NAT and firewall policy (enterprise pattern).<\/li>\n<li>Use OS-level hardening consistent with your org standards (patching, vulnerability scanning, approved images).<\/li>\n<li>Implement lifecycle policies: instance TTLs, auto-stop policies (where supported), and periodic access reviews.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>These are common practical constraints. Always confirm current limits and behavior in official docs and quotas pages.<\/p>\n<\/blockquote>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Zonal nature<\/strong>: Instances are tied to a zone; moving zones typically means recreating and migrating data.<\/li>\n<li><strong>No inherent autoscaling<\/strong>: An instance is a single VM; scaling is manual (resize or add instances).<\/li>\n<li><strong>Environment drift<\/strong>: Over time, package installs and OS changes make notebooks less reproducible.<\/li>\n<li><strong>Disk costs persist<\/strong>: Stopping an instance stops compute billing, but disks remain billable.<\/li>\n<li><strong>GPU availability and quota<\/strong>: GPUs can be hard to obtain in some regions; quota requests may be needed.<\/li>\n<li><strong>Network restrictions can block pip\/apt<\/strong>: Private networks without NAT or allowlisting often break dependency installs.<\/li>\n<li><strong>IAM confusion (user vs VM identity)<\/strong>: Users may have access to open the notebook, but notebook code may still fail to access data if the VM service account lacks permissions.<\/li>\n<li><strong>Data locality<\/strong>: Cross-region reads (for example, instance in one region, bucket in another) can add latency and cost.<\/li>\n<li><strong>Long-running notebooks<\/strong>: Interactive kernels can die or disconnect; operationalizing workloads into jobs\/pipelines is more reliable.<\/li>\n<li><strong>Compliance posture<\/strong>: If you require strict change control and artifact traceability, notebooks alone are insufficient\u2014use CI\/CD and pipelines.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Vertex AI Workbench instances is one option among several notebook and ML development approaches.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Within Google Cloud<\/strong>:<\/li>\n<li>Vertex AI Workbench managed notebooks (more managed experience; different control model)<\/li>\n<li>Compute Engine VM with self-managed Jupyter\/JupyterHub<\/li>\n<li>Colab Enterprise (if available\/approved in your org; verify capabilities and governance)<\/li>\n<li>\n<p>Dataproc + notebooks (for Spark-centric workflows)<\/p>\n<\/li>\n<li>\n<p><strong>Other clouds<\/strong>:<\/p>\n<\/li>\n<li>AWS SageMaker (Studio \/ notebook environments)<\/li>\n<li>\n<p>Azure Machine Learning compute instances \/ notebooks<\/p>\n<\/li>\n<li>\n<p><strong>Open-source\/self-managed<\/strong>:<\/p>\n<\/li>\n<li>JupyterHub on Kubernetes (GKE or elsewhere)<\/li>\n<li>VS Code remote development on VMs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Vertex AI Workbench instances (Google Cloud)<\/td>\n<td>Dedicated notebook VMs with IAM integration<\/td>\n<td>Flexible VM control, integrates with Google Cloud data\/AI services, familiar Jupyter workflow<\/td>\n<td>You still manage VM-like concerns (patching, drift, sizing), zonal resource<\/td>\n<td>You want notebook VMs that fit into Google Cloud governance and VPC design<\/td>\n<\/tr>\n<tr>\n<td>Vertex AI Workbench managed notebooks (Google Cloud)<\/td>\n<td>More managed notebook experience<\/td>\n<td>Reduced ops burden vs raw VMs (verify exact features), easier standardized environments<\/td>\n<td>Less low-level control than VM instances<\/td>\n<td>You want simpler ops and standardization over deep VM customization<\/td>\n<\/tr>\n<tr>\n<td>Self-managed Jupyter on Compute Engine<\/td>\n<td>Maximum customization<\/td>\n<td>Full control over OS, packages, network, authentication patterns<\/td>\n<td>Highest ops burden; you must build secure access and lifecycle management<\/td>\n<td>You have strict customization requirements and strong ops capacity<\/td>\n<\/tr>\n<tr>\n<td>Colab Enterprise (Google Cloud)<\/td>\n<td>Lightweight interactive notebooks<\/td>\n<td>Fast start, browser-first UX<\/td>\n<td>Governance\/networking and integration model differs; verify enterprise controls<\/td>\n<td>You need quick experimentation and your org approves the model<\/td>\n<\/tr>\n<tr>\n<td>AWS SageMaker notebooks \/ Studio<\/td>\n<td>AWS-centric ML environments<\/td>\n<td>Tight AWS integrations, managed ML tooling<\/td>\n<td>Not Google Cloud; migration overhead<\/td>\n<td>Your platform is primarily on AWS<\/td>\n<\/tr>\n<tr>\n<td>Azure ML compute instances<\/td>\n<td>Azure-centric ML environments<\/td>\n<td>Tight Azure integrations<\/td>\n<td>Not Google Cloud; migration overhead<\/td>\n<td>Your platform is primarily on Azure<\/td>\n<\/tr>\n<tr>\n<td>JupyterHub on GKE (self-managed)<\/td>\n<td>Multi-user notebook platform<\/td>\n<td>Centralized multi-user environment, Kubernetes scaling patterns<\/td>\n<td>Complex to operate securely; requires platform engineering<\/td>\n<td>You need a multi-user platform with custom auth\/storage policies<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Regulated financial services ML development<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A bank needs notebook-based ML experimentation, but must comply with strict network controls, least privilege, and audit requirements.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Shared VPC with private subnets for all Workbench instances<\/li>\n<li>Cloud NAT for controlled outbound access (package installs, allowed endpoints)<\/li>\n<li>VM service accounts per team, with bucket- and dataset-scoped permissions<\/li>\n<li>Centralized Cloud Logging\/Monitoring, audit log retention, and budget alerts<\/li>\n<li>Artifacts stored in Cloud Storage; training and deployment moved to Vertex AI services<\/li>\n<li><strong>Why Vertex AI Workbench instances was chosen<\/strong>:<\/li>\n<li>Dedicated VM environments allow controlled access and predictable performance.<\/li>\n<li>Works with enterprise VPC design and IAM governance.<\/li>\n<li>Enables iterative research while keeping data within Google Cloud boundaries.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster experimentation without unmanaged laptops.<\/li>\n<li>Reduced risk of data exfiltration through tighter IAM and network controls.<\/li>\n<li>Cleaner path from notebook to production ML pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Rapid prototyping for a recommendation model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small team wants to prototype recommendation features quickly using Cloud Storage data and later deploy to a serving endpoint.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>One or two low-cost CPU Workbench instances for experimentation<\/li>\n<li>Cloud Storage bucket for datasets\/artifacts<\/li>\n<li>Git-based workflow for notebook versioning and scripts<\/li>\n<li>Transition from notebook training to Vertex AI training jobs as workloads grow<\/li>\n<li><strong>Why Vertex AI Workbench instances was chosen<\/strong>:<\/li>\n<li>Quick to set up; minimal platform engineering overhead.<\/li>\n<li>Easy access to Google Cloud storage and future Vertex AI workflows.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster prototype cycles and clearer collaboration through shared cloud artifacts.<\/li>\n<li>Cost control via start\/stop and right-sizing.<\/li>\n<li>A clean upgrade path to production ML services as traction increases.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>What exactly is a Vertex AI Workbench instance?<\/strong><br\/>\nA Vertex AI Workbench instance is a notebook environment (JupyterLab) running on a dedicated Compute Engine VM, managed through Vertex AI Workbench in Google Cloud.<\/p>\n\n\n\n<p>2) <strong>Is Vertex AI Workbench instances the same as Vertex AI Workbench managed notebooks?<\/strong><br\/>\nNo. They are different offerings under the Workbench umbrella. Instances are VM-backed and more \u201cuser-managed.\u201d Managed notebooks typically reduce VM-level management. Verify the latest differences in official docs.<\/p>\n\n\n\n<p>3) <strong>Do I pay extra for Workbench instances beyond Compute Engine?<\/strong><br\/>\nIn most cases, cost is driven by the underlying Compute Engine VM, disks, GPUs, and other services you use. Always confirm current pricing: https:\/\/cloud.google.com\/vertex-ai\/pricing<\/p>\n\n\n\n<p>4) <strong>Can I stop the instance to save money?<\/strong><br\/>\nYes, stopping the VM stops compute charges, but persistent disks still incur storage charges.<\/p>\n\n\n\n<p>5) <strong>How do notebook users authenticate to Google Cloud APIs from within the notebook?<\/strong><br\/>\nTypically via the VM\u2019s service account (application default credentials). The notebook code uses that identity to access Cloud Storage\/BigQuery\/etc.<\/p>\n\n\n\n<p>6) <strong>What\u2019s the difference between \u201cwho can open the notebook\u201d and \u201cwhat data the notebook can access\u201d?<\/strong><br\/>\nOpening the notebook is governed by user IAM permissions. Data access is governed by the VM service account permissions (and any other configured identities).<\/p>\n\n\n\n<p>7) <strong>Should I use service account keys inside the notebook?<\/strong><br\/>\nUsually no. Prefer the VM service account and IAM. Avoid downloading long-lived keys to the VM.<\/p>\n\n\n\n<p>8) <strong>Can I use GPUs with Vertex AI Workbench instances?<\/strong><br\/>\nOften yes, depending on zone availability and quota. GPU configuration is subject to regional capacity and quota approvals.<\/p>\n\n\n\n<p>9) <strong>How do I keep my notebook environment reproducible?<\/strong><br\/>\nUse dependency pinning (<code>requirements.txt<\/code>), store notebooks\/scripts in Git, and prefer building repeatable training code outside notebooks.<\/p>\n\n\n\n<p>10) <strong>Are Workbench instances suitable for production workloads?<\/strong><br\/>\nThey are mainly for development, exploration, and prototyping. Production workloads are better moved to repeatable jobs\/pipelines\/services (for example, Vertex AI training and pipelines).<\/p>\n\n\n\n<p>11) <strong>Can I put a Workbench instance in a private subnet with no public IP?<\/strong><br\/>\nOften yes, but private access patterns require correct VPC design (NAT, DNS, Private Google Access). Verify the current recommended architecture in official docs.<\/p>\n\n\n\n<p>12) <strong>How do I control outbound internet access from notebooks?<\/strong><br\/>\nUse VPC firewall policies, egress controls, and NAT configuration. For strict environments, consider allowlisting and private package repositories.<\/p>\n\n\n\n<p>13) <strong>What happens if the VM disk fills up?<\/strong><br\/>\nJupyter kernels can crash or become unstable. Monitor disk usage and either clean up, expand disk, or store large data in Cloud Storage.<\/p>\n\n\n\n<p>14) <strong>How can I track costs per team?<\/strong><br\/>\nUse labels on instances and associated disks, set budgets\/alerts, and use Cloud Billing reports filtered by labels\/projects.<\/p>\n\n\n\n<p>15) <strong>How do I migrate from older AI Platform Notebooks guidance?<\/strong><br\/>\nMost concepts map to Vertex AI Workbench, but UI paths, APIs, and feature sets can differ. Use official Vertex AI Workbench instances docs as the source of truth: https:\/\/cloud.google.com\/vertex-ai\/docs\/workbench\/instances<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Vertex AI Workbench instances<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Vertex AI Workbench instances docs \u2014 https:\/\/cloud.google.com\/vertex-ai\/docs\/workbench\/instances<\/td>\n<td>Canonical, up-to-date guidance on instances, access control, and operations<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Access control (Workbench instances) \u2014 https:\/\/cloud.google.com\/vertex-ai\/docs\/workbench\/instances\/access-control<\/td>\n<td>Clear IAM model and role guidance (verify current roles)<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Vertex AI pricing \u2014 https:\/\/cloud.google.com\/vertex-ai\/pricing<\/td>\n<td>Understand what Vertex AI charges and where Workbench fits<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Compute Engine VM pricing \u2014 https:\/\/cloud.google.com\/compute\/vm-instance-pricing<\/td>\n<td>Workbench instances are VM-backed; VM cost is a primary driver<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Disk pricing \u2014 https:\/\/cloud.google.com\/compute\/disks-image-pricing<\/td>\n<td>Persistent disks remain billable even when stopped<\/td>\n<\/tr>\n<tr>\n<td>Official tool<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build estimates using your region, machine type, disk, and network assumptions<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Storage docs \u2014 https:\/\/cloud.google.com\/storage\/docs<\/td>\n<td>Store datasets and artifacts used by notebooks<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>BigQuery docs \u2014 https:\/\/cloud.google.com\/bigquery\/docs<\/td>\n<td>Query data directly from notebooks using IAM-based access<\/td>\n<\/tr>\n<tr>\n<td>Official training\/labs<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs; search within for Vertex AI Workbench \/ notebooks labs<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud Tech (YouTube) \u2014 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product walkthroughs and architecture sessions; search for Vertex AI Workbench content<\/td>\n<\/tr>\n<tr>\n<td>Samples (official\/trusted)<\/td>\n<td>Vertex AI samples (GitHub) \u2014 https:\/\/github.com\/GoogleCloudPlatform\/vertex-ai-samples<\/td>\n<td>Practical notebooks and code patterns for Vertex AI workflows (adapt for Workbench instances)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, platform teams, cloud practitioners<\/td>\n<td>Cloud + DevOps + operational practices that can support AI\/ML platforms<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>DevOps foundations, tooling, and practices relevant to \uc6b4\uc601\/automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops practitioners<\/td>\n<td>Cloud operations and practical cloud management topics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations teams<\/td>\n<td>Reliability engineering practices applicable to notebook\/ML platforms<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>ML ops \/ AIOps learners<\/td>\n<td>Operations and automation patterns for AI-enabled systems<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training content (verify specific offerings)<\/td>\n<td>Engineers seeking guided learning paths<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and workshops (verify catalog)<\/td>\n<td>Beginners to advanced DevOps practitioners<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps consulting\/training platform (verify services)<\/td>\n<td>Teams seeking project-based help<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training services (verify scope)<\/td>\n<td>Ops teams needing implementation support<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact specialties)<\/td>\n<td>Cloud architecture, automation, platform enablement<\/td>\n<td>Designing governed notebook environments; setting up IAM and network patterns; cost controls<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps\/cloud consulting and training<\/td>\n<td>Platform engineering, DevOps processes, operational maturity<\/td>\n<td>Building repeatable provisioning patterns; CI\/CD for ML artifacts; operational best practices<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify scope)<\/td>\n<td>DevOps implementation, automation, operational readiness<\/td>\n<td>Implementing monitoring\/logging standards; policy-as-code; migration planning<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals: projects, IAM, VPC, regions\/zones<\/li>\n<li>Compute Engine basics: VM sizing, disks, service accounts, firewall rules<\/li>\n<li>Cloud Storage and BigQuery fundamentals (common data backends)<\/li>\n<li>Python environment management: <code>pip<\/code>, virtual environments, dependency pinning<\/li>\n<li>Basic security hygiene: least privilege, secret management, audit logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Vertex AI training jobs and model deployment (endpoints, batch prediction)<\/li>\n<li>Vertex AI Pipelines for reproducible workflows<\/li>\n<li>Artifact Registry + CI\/CD for ML (building and versioning artifacts)<\/li>\n<li>Monitoring\/observability for ML workloads (logs, metrics, drift monitoring patterns\u2014service-dependent)<\/li>\n<li>Data governance: Dataplex, IAM conditions, VPC Service Controls (where applicable)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data Scientist<\/li>\n<li>Applied ML Engineer<\/li>\n<li>MLOps Engineer \/ ML Platform Engineer<\/li>\n<li>Cloud Engineer (AI\/ML enablement)<\/li>\n<li>DevOps\/SRE supporting AI and ML platforms<\/li>\n<li>Security engineer reviewing AI\/ML development environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Google Cloud certifications change over time. Commonly relevant options include:\n&#8211; Professional Cloud Architect\n&#8211; Professional Data Engineer\n&#8211; Professional Machine Learning Engineer (if currently offered\u2014verify current certification catalog)<\/p>\n\n\n\n<p>Verify current certifications:\n&#8211; https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a governed Workbench instance pattern with:<\/li>\n<li>dedicated service account<\/li>\n<li>bucket-scoped permissions<\/li>\n<li>labels and budgets<\/li>\n<li>Create a notebook-to-pipeline migration:<\/li>\n<li>prototype in Workbench<\/li>\n<li>convert to a repeatable pipeline (Vertex AI Pipelines)<\/li>\n<li>Implement cost controls:<\/li>\n<li>stop\/start automation<\/li>\n<li>reporting by labels<\/li>\n<li>Security hardening exercise:<\/li>\n<li>private subnet placement<\/li>\n<li>controlled egress design<\/li>\n<li>secrets pulled from Secret Manager<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Vertex AI Workbench instances<\/strong>: VM-backed notebook environments managed via Vertex AI Workbench.<\/li>\n<li><strong>JupyterLab<\/strong>: Web-based interactive development environment for notebooks, code, and data.<\/li>\n<li><strong>Compute Engine (GCE)<\/strong>: Google Cloud service for running virtual machines.<\/li>\n<li><strong>Zone<\/strong>: A deployment area within a region; VMs are zonal resources.<\/li>\n<li><strong>Service account<\/strong>: A Google Cloud identity used by applications and VMs to call APIs.<\/li>\n<li><strong>IAM (Identity and Access Management)<\/strong>: Google Cloud system for permissions and access control.<\/li>\n<li><strong>Least privilege<\/strong>: Security principle of granting only the permissions required for a task.<\/li>\n<li><strong>Cloud Storage<\/strong>: Object storage service on Google Cloud.<\/li>\n<li><strong>BigQuery<\/strong>: Serverless data warehouse on Google Cloud.<\/li>\n<li><strong>Artifact Registry<\/strong>: Google Cloud service for storing container images and artifacts.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Logs of administrative and data access actions in Google Cloud.<\/li>\n<li><strong>Cloud NAT<\/strong>: Managed NAT gateway for outbound internet access from private VMs.<\/li>\n<li><strong>Egress<\/strong>: Outbound network traffic leaving a VPC\/region or Google Cloud.<\/li>\n<li><strong>Reproducibility<\/strong>: Ability to recreate the same environment\/results from the same code and inputs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Vertex AI Workbench instances is Google Cloud\u2019s VM-backed notebook service for AI and ML development, giving teams a practical way to run JupyterLab close to their data with IAM-governed access and VPC integration. It matters because it standardizes interactive ML environments while letting teams control compute sizing, disks, GPUs, networking, and service account permissions.<\/p>\n\n\n\n<p>Cost is primarily driven by Compute Engine runtime, persistent disks (even when stopped), GPUs, and any downstream services (BigQuery scans, storage, egress). Security depends heavily on correct IAM boundaries\u2014especially least-privileged VM service accounts\u2014and on network design to avoid unintended exposure.<\/p>\n\n\n\n<p>Use Vertex AI Workbench instances when you want dedicated, flexible notebook VMs integrated with Google Cloud governance and data services. For the next step, practice operationalizing notebook work into repeatable pipelines and training jobs on Vertex AI, using source control, artifact storage, and CI\/CD to reduce environment drift and improve reproducibility.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>AI and ML<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[53,51],"tags":[],"class_list":["post-578","post","type-post","status-publish","format-standard","hentry","category-ai-and-ml","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/578","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=578"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/578\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=578"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=578"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=578"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}