Bare Metal Solution, often shortened to BMS, gives you dedicated physical servers that sit very close to a Google Cloud region and connect to it over a fast, private link.

The Short Definition

Bare Metal Solution is a managed service that provides dedicated, high-performance physical servers for specialized workloads. These are workloads that need direct, low-level access to the hardware, or that are certified to run only on specific hardware. You do not share the machine with any other customer. The server is yours alone, which is called single tenancy.

The servers do not live inside the normal Google Cloud data hall. They live in a facility called a regional extension, placed near a Google Cloud region and connected to it through a managed, low-latency connection. From the point of view of your cloud applications, the bare metal servers feel like a close neighbour on the same private network.

Why It Exists

Many large companies run important software that was never designed for the cloud. Some of it is certified by its vendor only on particular physical hardware. Some of it has strict performance expectations that are hard to meet on shared, virtualized machines. Some of it needs special licensing rules that depend on the physical processors. Rewriting such software can take years and carry high risk. Bare Metal Solution lets these companies move their data centre footprint out of their own buildings and next to the cloud, without changing the software first.

Where It Is Used

The best-known use is running large database systems, especially Oracle databases, that have specific hardware and licensing demands. It is also used for third-party virtualization software and for applications that need direct access to the machine, such as special drivers, unusual operating systems or tightly tuned clustering.

To understand why anyone wants bare metal, first understand what virtualization does and what it costs.

What a Virtual Machine Is

A virtual machine is a software-made computer. A special layer of software called a hypervisor sits on a physical server and slices it into several pretend computers. Each pretend computer thinks it owns its own processor, memory and disks. This is wonderful for flexibility and cost sharing, and it is how most cloud computing works.

What Bare Metal Means

Bare metal means no hypervisor between you and the hardware. Your operating system, or your own hypervisor, runs directly on the physical machine. You see the real processors, the real memory and the real network cards. Nothing is shared and nothing is hidden.

Eight words unlock almost every document about the service.

How the Words Connect

You choose a regional extension, order servers of the shapes you need, and decide how many networks each server joins. Google builds the physical connection to your Google Cloud region. You then create VLAN attachments so that your Virtual Private Cloud can see the bare metal networks and the bare metal servers can see your cloud resources. Storage is carved into volumes and LUNs, and presented to the servers over the private network.

The service is built from three places that work together: the Google Cloud region, the regional extension, and the link between them.

The Big Picture

On one side is the familiar Google Cloud region with your projects, Virtual Private Cloud networks, virtual machines, databases and managed services. On the other side is the regional extension, a colocated facility where Google provides the building, power, cooling, physical security, network security and hardware monitoring. In between is a managed, low-latency Partner Interconnect connection and a fast network fabric inside the extension.

flowchart LR
  subgraph GC["Google Cloud region"]
    VPC["Your VPC network"]
    VM["Compute Engine VMs"]
    MS["Managed services"]
  end
  subgraph LINK["Managed connection"]
    PI["Partner Interconnect"]
    CR["Cloud Router"]
    VA["VLAN attachments"]
  end
  subgraph RE["Regional extension"]
    CN["Client network"]
    SRV["Bare metal servers"]
    PN["Private network"]
    ST["Storage: LUNs and NFS"]
  end
  VPC --> CR
  CR --> VA
  VA --> PI
  PI --> CN
  CN --> SRV
  SRV --> PN
  PN --> ST
  VM --> VPC
  MS --> VPC
        

What Google Provides

What You Provide

You provide the software licenses, the operating system configuration and patching, the applications, the data, and any network encryption you want between Google Cloud and the bare metal environment. This division is called the shared responsibility model, and we look at it closely in a later chapter.

You order real machines, so choosing the right shape up front matters more than in the virtual world.

The Range of Shapes

Servers come in general-purpose, high-memory and memory-optimized families. Across the catalogue, sizes range from small configurations with 16 virtual CPUs and 192 GB of memory up to very large ones with 896 virtual CPUs and about 24 TB of memory. A virtual CPU here means a hardware thread that the operating system sees as one processor. The exact list of shapes available differs by region, so always check the current catalogue for the region you plan to use.

Hyper-Threading

Hyper-threading is a processor feature that lets one physical core present itself as two virtual processors. On Bare Metal Solution it is disabled by default and must be requested at ordering time. This matters because some software licenses and some performance tests behave very differently depending on whether it is on. Decide with your software vendor’s guidance, not by guesswork.

Firmware and Maintenance

Servers run firmware, the low-level software that controls hardware. Google recommends keeping firmware at the latest supported version because older versions can limit the support you receive. A firmware upgrade needs advance notice, takes several hours per server, and is done in small groups of servers at a time so that clustered databases keep running. Plan these windows with your operations calendar.

Networking is the heart of the service. Everything valuable about it depends on a fast, private, well-planned link.

The Two Networks on Every Server

In the standard setup each server has two bonded network connections. Bonding means two physical connections are combined into one logical connection, so that if one fails the other keeps working. These carry two networks.

From the Extension to Your VPC

A Partner Interconnect provides the physical path. On top of it you create VLAN attachments. A VLAN is a way of splitting one physical link into several logically separate lanes. Each attachment connects to a Cloud Router in your Virtual Private Cloud, and the router exchanges routes with the bare metal side so both sides know how to reach each other. Attachments are normally created in pairs for redundancy, so that losing one path does not cut your servers off.

sequenceDiagram
  participant APP as App VM in Google Cloud
  participant VPC as VPC network
  participant CR as Cloud Router
  participant VA as VLAN attachment
  participant PI as Partner Interconnect
  participant BM as Bare metal server
  APP->>VPC: Send request to bare metal IP
  VPC->>CR: Route lookup
  CR->>VA: Forward over attachment
  VA->>PI: Cross the private link
  PI->>BM: Deliver on client network
  BM-->>APP: Reply follows the reverse path
        

Bandwidth and MTU

Bandwidth is ordered in steps of one gigabit per second. MTU, the maximum size of a single network packet, should be kept consistent at 1500 bytes, because very large packets known as jumbo frames are not supported on the VLAN attachments. A mismatch in this number is one of the classic causes of strange, hard-to-find slowdowns.

Advanced Network Options

Beyond the standard design, you can use several VLANs per server, several attachments, connections to more than one Virtual Private Cloud, and network templates that make repeated setups consistent. Adding multiple networks per server may need a quota increase requested through Google Cloud customer support, so plan that early.

Storage is provided from a local storage system in the regional extension and presented to your servers over the private network.

Three Ways to Present Storage

Block versus File Storage

Block storage hands your server a blank disk, and the server’s own operating system decides how to organize it. File storage hands your server a ready-made shared folder, and the storage system decides how files are organized. Databases usually like block storage because they want to control exactly how data is laid out on the disk. Teams usually like file storage for sharing documents or tools.

SSD or HDD

Solid-state storage is fast and consistent. Hard-disk storage is cheaper per gigabyte but slower, especially for random reads and writes. For mission-critical databases, fast solid-state storage is the safer choice. Hard-disk storage fits archives and low-priority data.

Performance Follows Size

On this service, the speed of a volume is tied to its size: larger volumes get more performance. That means a small volume can be a hidden bottleneck even if the media is fast. It also means you should size volumes for the speed you need, not only for the space you need.

Volumes Do Not Stretch Easily

Once a volume is provisioned its size is fixed. Growing a database means creating a new, larger volume and moving data across. This is very different from the elastic disks you may know from virtual machines. Plan capacity for the full contract period, keep spare room, and design your data layout so that adding volumes is a normal, rehearsed operation.

Because the hardware is physical, setting up an environment is a planned process, not a button press.

Step by Step

flowchart TD
  P["Plan region, shapes, networks"] --> O["Submit order"]
  O --> B["Google builds environment"]
  B --> N["Create VLAN attachments"]
  N --> C["Configure OS and storage"]
  C --> M["Migrate data and test"]
  M --> L["Go live"]
  L --> R["Operate, review, renew or exit"]
        

Data Flow in Daily Use

Once running, a typical request enters through your application on Google Cloud, crosses the private link to the database on the bare metal server, and the database reads and writes its disks over the private storage network. The answer travels back the same way. The faster and steadier this loop, the better your application feels. This is why the delay on the link, the speed of the storage and the number of round trips your application makes per request all deserve attention.

Knowing exactly who is responsible for what prevents the most expensive misunderstandings.

Operating Systems and Hypervisors

Google installs the initial operating system or hypervisor image that you ordered. From then on you configure, update and patch it. Google’s technical support focuses on the infrastructure itself: the hardware, the network link and the storage system. For questions about the operating system, drivers or compatibility, you contact the operating system vendor. If you need a custom image, you must open a support case and meet the technical specifications Google publishes.

Bring Your Own License

Bare Metal Solution follows the bring-your-own-license model. You obtain licenses for the operating system, any hypervisor and all applications from their vendors. This is important financially because software licensing, especially for databases, can cost far more than the hardware itself. Always confirm with your vendor how their license rules apply to physical servers, hyper-threading settings and the cloud environment before you order.

Who Does What

The most common reason people choose the service is to run Oracle databases close to the cloud.

Why Oracle Fits Here

Oracle databases are often critical, large and tightly tied to specific hardware certifications and license terms. Moving them to ordinary virtual machines can change the support position and the licensing maths. A dedicated physical server in a regional extension keeps the familiar server style while moving the building and operations away from your own data centre.

Clustering and High Availability

Many Oracle environments use clustering, where several servers share one database for both speed and resilience. This is why shared multipath LUNs and a dedicated private network exist: cluster members must see the same disks and talk to each other very quickly and reliably. Designing a cluster here follows the same principles as in your own data centre, with servers placed so that one failure does not take down the whole system.

flowchart TD
  APP["Applications in Google Cloud"] --> LINK["Partner Interconnect"]
  LINK --> N1["Bare metal node 1"]
  LINK --> N2["Bare metal node 2"]
  N1 |"Private interconnect"| N2
  N1 --> SH["Shared multipath LUNs"]
  N2 --> SH
  SH --> BK["Backup target"]
        

Backups the Database Way

Google’s guidance for Oracle databases favours the database’s own backup tools, such as RMAN, instead of relying only on storage volume snapshots. The reason is that a snapshot of a busy database disk may capture data in the middle of a change, while a database-aware tool understands transactions and can verify that the backup is restorable. Volume snapshots still play a role as an extra safety net, but they are not a substitute for a tested database backup plan.

You cannot walk up to your servers, so remote access has to be safe and reliable.

Ways to Reach a Server

Daily Operations

Day-to-day work resembles running any physical server fleet: patching, capacity checks, log review, backup tests, and coordination of maintenance. What changes is that hardware problems are handled by Google’s on-site team rather than yours, and the network and facility are not your concern. Create a simple runbook that lists who does what, in which order, when something fails.

Infrastructure as Code

Where possible, describe your network pieces, such as Cloud Routers and VLAN attachments, in code so that they are repeatable and reviewable. Server orders themselves are planned and physical, but the cloud-side networking around them can be treated like any other infrastructure definition.

Security is shared between a very secure building and your own careful configuration of everything inside it.

Layers of Defence

A server you cannot see needs good instruments. Decide what to watch before the first day of production.

What to Watch

Bringing It Together

Cloud Monitoring and Cloud Logging can collect numbers and logs from the cloud side of your network, including the Cloud Router and VLAN attachments. For the servers themselves, install an agent or use your existing monitoring tool, and send alerts to the same place your team already watches. A single dashboard that shows application delay, link health and database health side by side makes problems much easier to find.

Three related ideas, often confused: staying up, recovering data, and recovering the whole site.

The Three Ideas

What Snapshots Give You

By default, Google takes daily snapshots of boot volumes and keeps them for seven days. You can also request daily snapshots of data volumes when you order, though these reserve part of the volume, around a fifth, for snapshot space, which reduces usable capacity. Snapshots are a convenient safety net, but they live in the same storage system as the data, so on their own they do not protect against loss of the site.

Building a Real Plan

Every design choice trades something. Here is an honest view of both sides.

The Decision in One Sentence

Choose Bare Metal Solution when a specific workload truly needs dedicated physical hardware, and keep everything else on services where you can scale quickly and pay only for what you use.

Because this is physical equipment set up for you, the commercial model differs from on-demand cloud pricing.

What You Pay For

The bill is built from several parts: the servers, the storage volumes, the network bandwidth you ordered in gigabit steps, and the usual Google Cloud charges for anything running on the cloud side, such as virtual machines, routers and data leaving a region. On top of that sits the cost of your own software licences, which can be larger than all of the above. Contract terms and rates change over time and differ by region, so always get a current quote from Google Cloud.

Ways to Keep Cost Sensible

Several options can host demanding workloads. Choose by requirement, not by name.

A Simple Way to Decide

Ask four questions. First, does my vendor require specific physical hardware for support? If yes, bare metal is a candidate. Second, would a virtual machine on a dedicated host meet the isolation and licensing rules? If yes, sole-tenant nodes may be simpler. Third, am I already running VMware? If yes, look at the VMware-based service. Fourth, could the application move to a cloud-native database with acceptable effort? If yes, that is usually the lowest long-term operating cost.

A pattern is a proven shape for a solution. These recur in successful bare metal environments.

flowchart LR
  U["Users"] --> LB["Load balancer"]
  LB --> APP["App tier on cloud VMs"]
  APP --> CACHE["Cache"]
  APP --> LINK["Private link"]
  LINK --> DB["Database cluster on bare metal"]
  DB --> BKP["Backups to cloud storage"]
  DB --> DR["Standby in another region"]
        

An anti-pattern looks sensible but quietly causes trouble. These are the most common ones.

A checklist of habits shared by teams that run these environments calmly.

Test the Whole Path First

Before moving real data, measure round-trip delay, throughput and failover behaviour between a cloud virtual machine and a bare metal server. Many painful surprises are visible in a simple half-day test.

Keep a Living Runbook

Write down procedures for the events that will happen: a server alert, a failed attachment, a firmware window, a restore request. Review and update after every incident. Good runbooks turn midnight panics into calm checklists.

Plan Capacity Early

Because hardware and volumes are physical, growth takes lead time. Review capacity quarterly, track growth rates, and start ordering extra capacity well before you need it.

These are illustrative scenarios of how organisations typically use the service, not claims about specific customers.

No. A virtual machine is a software-made computer that may share hardware. Here you get a whole physical server that only you use, with no hypervisor unless you install one yourself.

In a regional extension, a secure facility near a Google Cloud region. It is connected to that region through a managed Partner Interconnect connection and a fast network fabric.

You do. Google installs the initial image you ordered, but configuration, updates and patching after that are your responsibility.

Yes. The service follows the bring-your-own-licence model, so you obtain licences for the operating system, any hypervisor and your applications.

Not in place. Volume sizes are fixed once provisioned. To grow, you create a new, larger volume and move data to it, so plan generous headroom.

On this service, larger volumes receive more performance. A small volume may be slow even on fast media, so size for the speed you need as well as the space.

The link is private, not on the public internet, but encryption in transit is your responsibility if you need it. You can add it at the application or database level.

Typically with SSH keys. The interactive serial console is available for troubleshooting when the network configuration is broken, and a jump VM can provide a controlled entry from the internet.

Google monitors the hardware and its on-site team handles physical work, including replacements. You still need your own high availability design so the application survives while repairs take place.

Boot volumes are snapshotted daily and kept for a short period, and data volume snapshots can be requested at ordering time. These are a safety net, not a full plan. Use database-aware backups with copies stored elsewhere.

Because licensing and performance behave differently depending on the setting, and many database workloads are planned with it off. It can be requested at ordering time if your vendor guidance supports it.

Oracle is the best-known use, but the service also fits third-party virtualization software and other applications that need direct, low-level access to server hardware.

Custom images are possible but require opening a support case and meeting the technical specifications Google publishes. Plan extra time for this.

Treating it like an elastic cloud resource. Capacity, volumes and network plans are physical and need lead time, so careful early planning matters more than anywhere else.

Bare Metal Solution places dedicated physical servers in a regional extension right next to a Google Cloud region and joins them with a managed private link. It exists for the workloads that cannot, or should not, be rushed into virtual machines: certified databases, licence-sensitive software and applications that need direct access to hardware. Google provides the building, hardware, storage system and the network link. You provide the licences, the operating system care, the applications, the backups and a thoughtful design.

The best results come from a clear mindset. Use bare metal where there is a real reason, keep everything else elastic in the cloud, plan addresses, capacity and licences early, build every path twice, and prove your recovery by actually restoring. Treated this way, the service is a calm bridge between the world you have and the cloud you are moving toward.