What Bare Metal Solution is, and why Google created it.

A server is a computer that other computers connect to in order to get work done, such as storing records or answering questions. A bare metal server is a physical server given to one customer alone, with no virtualization layer in the middle. The phrase “bare metal” simply means you are working directly on the metal, the actual processors, memory, and disks, instead of on a slice of a shared machine.

Google Cloud introduced Bare Metal Solution in 2020. At that time, many large companies wanted to move to the cloud but were stuck. Their most valuable systems, often big Oracle databases, could not simply be copied into virtual machines. Oracle is a very widely used database product, and many banks, hospitals, retailers, and telephone companies depend on it. These databases were tuned over many years for particular hardware, licensed in strict ways, and so important that nobody dared to change them. Google’s idea was practical: if the workload cannot come to the cloud, bring a small piece of the cloud to the workload. So Google placed certified physical servers inside special facilities close to its own regions, then connected them with a fast private network.

Bare Metal Solution is not the answer to every problem. It is a bridge, a specialist tool for workloads that need physical hardware. Understanding when to use it, and when not to, is as important as understanding how it works.

Before learning the solution, understand why some software refuses to move to ordinary cloud machines.

Imagine a large insurance company. Its claims system runs on a huge database that was first built fifteen years ago. Hundreds of other programs depend on it. The cost of rewriting it would be enormous, and the risk of breaking it is frightening. Meanwhile, the company wants to close its old data center, because the building is expensive and the hardware is ageing. This is a common story, and it creates several kinds of difficulty.

Bare Metal Solution tackles these problems by giving you the physical server your software expects, while moving the building, power, cooling, and network into Google’s care. The old problem of “we must keep our own data center just for this one database” goes away. The new design lets the database sit on dedicated hardware while the application servers, analytics tools, and web front ends run in the normal cloud right beside it.

The words you will meet again and again. Learn them once, and the rest of the guide becomes easy.

Virtualization and the hypervisor

Virtualization is a technique that lets one physical computer pretend to be many smaller computers. The program that does this pretending is called a hypervisor. Each pretend computer is a virtual machine, or VM. Bare metal means there is no hypervisor between you and the hardware.

Regional extension

A regional extension is a small, specially built site that holds the Bare Metal Solution hardware. It is located near a Google Cloud region, which is a geographic area where Google runs its data centers. The extension is not inside the main Google data center, but it is close enough, and connected well enough, that the two feel like neighbors. Google builds, powers, cools, and secures the regional extension.

Server (instance)

In Bare Metal Solution, a server is one physical machine reserved for you. It comes in a few standard sizes, with different numbers of processor cores and amounts of memory. You pick the size that fits your workload.

Volume and LUN

A volume is a portion of storage reserved for you. Inside a volume, you may create one or more LUNs, which stands for Logical Unit Numbers. A LUN looks to the server like an ordinary disk, even though it actually lives on a big shared storage system. There are also NFS shares, which are folders that servers can reach over the network.

Network and VLAN

A network in this world is a private communication lane. A VLAN, short for Virtual Local Area Network, is a way of separating traffic on a physical network into private lanes, like painted lanes on a road. Bare Metal Solution uses different networks for talking to Google Cloud and for talking between your own servers.

Interconnect

An interconnect is the high-speed private cable-like link between two locations. Here, it joins your regional extension to your Google Cloud network, so traffic never travels over the public internet.

Several Google Cloud products sound alike. Here is how they differ.

Google Cloud offers more than one way to get computing power, and beginners often mix them up. The key question is always the same: how much of the machine is yours, and how much of the software layer between you and the hardware is managed for you?

The ladder of control

Think of a ladder. At the bottom is a standard VM: cheap, flexible, and quick to create, but you share a host and cannot see the hardware. A step higher is a sole-tenant node, where nobody else’s VMs share your host, but a hypervisor still runs. At the top is bare metal: the whole physical machine is yours with no hypervisor. Each step up gives more control and predictability, and each step also takes away some speed of creation and some flexibility, because physical machines cannot be copied in seconds the way VMs can.

The big picture: how the pieces connect from the bare metal rack to your cloud applications.

Every Bare Metal Solution setup has three major zones. The first is the regional extension, where your servers and storage live. The second is the connection, the private high-speed link. The third is your Google Cloud project, including your VPC network, where applications and management tools run.

graph LR
  subgraph RE["Regional Extension - Google managed site"]
    S1["Bare Metal Server 1"]
    S2["Bare Metal Server 2"]
    ST["Enterprise Storage - Volumes, LUNs, NFS"]
    PN["Private Network between servers"]
  end
  S1 --- PN
  S2 --- PN
  S1 --- ST
  S2 --- ST
  IC["Private Interconnect and VLAN Attachment"]
  S1 --> IC
  S2 --> IC
  subgraph GCP["Google Cloud Region"]
    VPC["Customer VPC Network"]
    CE["Compute Engine Application Servers"]
    GCS["Cloud Storage Backups"]
    MON["Cloud Monitoring and Logging"]
  end
  IC --> VPC
  VPC --> CE
  VPC --> GCS
  VPC --> MON
    

What Google handles and what you handle

Google takes care of the building, electricity, cooling, physical security, hardware repair, and the network and storage equipment. You take care of the operating system, the database or application software, backups, patching, user access, and tuning. This division matters a great deal, and we return to it in the security chapter.

Because the machines are real, getting one is more like ordering a car than clicking a button.

When you create a virtual machine in the cloud, it appears in seconds because software simply carves a piece out of a big shared machine. A physical server cannot be created from nothing. Hardware must be reserved, installed, cabled, and tested. For this reason, Bare Metal Solution follows a planned onboarding path.

sequenceDiagram
  participant C as Customer
  participant G as Google Cloud Team
  participant RE as Regional Extension
  participant P as Google Cloud Project
  C->>G: Discuss needs - size, region, storage, network
  G->>C: Confirm availability and agreement
  G->>RE: Reserve and prepare servers and storage
  G->>P: Enable service and link to customer project
  C->>P: Define networks, IP ranges, volumes
  RE->>P: Interconnect brought online
  C->>RE: Log in, configure operating system and database
  C->>P: Monitor and manage from console
    

Step by step

Planning and agreement. You work with Google or a partner to decide which region you need, how many servers, how much storage, and what network ranges will be used. Because hardware must be ready, there is a commitment period, and the paperwork happens first.

Preparation. Google reserves the servers and storage in the regional extension and prepares them, including loading the operating system image you chose.

Network design. You choose private IP address ranges that do not clash with your other networks. An IP address is the numeric address of a computer on a network. Choosing ranges carefully at the start prevents painful rework later.

Connection. The interconnect is established, and VLAN attachments link the regional extension to your Google Cloud network.

Access and setup. You log in, usually using a secure remote login method called SSH, often through a protected jump host in your VPC. You then configure the operating system, install your database, and attach storage.

Operation. From then on, you use familiar Google Cloud tools to see server status, change certain settings, and control power. A special remote console can help when a server will not start normally.

What a dedicated server looks like from the inside and how you operate it.

Sizes

Servers come in a set of standard shapes. Smaller ones have fewer processor cores and less memory, while larger ones offer many cores and very large memory, measured in terabytes. A core is one independent working unit inside a processor. More cores means more tasks can run at the same moment. Since licensing for databases is often counted in cores, choosing the right size has a direct effect on both speed and cost. Offerings change over time, so confirm current sizes in the official documentation.

Operating systems

An operating system, or OS, is the main program that manages a computer’s hardware and runs other programs. Bare Metal Solution commonly supports enterprise Linux versions, such as Red Hat Enterprise Linux, SUSE Linux Enterprise Server, and Oracle Linux, and may support others depending on the arrangement. You choose the image at ordering time. You are responsible for keeping the OS patched and secure.

Access

Servers sit on private networks, so you reach them through your Google Cloud VPC. A common design is a small bastion host, a hardened virtual machine that acts as the only guarded doorway. Engineers log in to the bastion first, then continue to the bare metal server. Servers also have a serial console, which works like plugging a keyboard and screen directly into the machine. It helps when the network settings are broken and normal login fails.

Power and maintenance

You can start, stop, and restart servers from the console. Google maintains the hardware. If a part fails, Google repairs or replaces it. Planned maintenance, such as firmware updates, is announced in advance so you can arrange for your database to fail over to a partner machine while one server is serviced.

Databases live and die by their storage. Here is how it is organized.

Servers in Bare Metal Solution use a professional, shared storage system that sits inside the regional extension. Even though the storage hardware is shared among many customers, each customer’s data is logically separated and cannot be seen by others.

Block storage and LUNs

Block storage breaks data into fixed-size pieces called blocks and offers them to a server as a raw disk. Databases love block storage because they can organize data in their own way. The server sees each LUN as a disk and can format it or hand it to a database storage manager. For Oracle databases, a feature called ASM, short for Automatic Storage Management, often manages these disks directly.

File storage and NFS

NFS, the Network File System, shares folders over the network. It is useful when several servers need the same files, such as installation software, shared logs, or backup staging areas.

Performance tiers

Storage comes in tiers with different speed levels, usually described by how many operations per second and how much data per second they can move. Faster tiers cost more. A good design places hot data, such as active database files and log files, on the fast tier, and cooler data, such as backups and archives, on a cheaper tier.

Snapshots

A snapshot is a quick, point-in-time picture of a volume. It records the state of the disk at one moment without copying everything right away, so it is fast and uses little extra space. Snapshots are excellent for quick recovery from mistakes, but they live on the same storage system, so they are not a replacement for copies stored elsewhere.

The network is what turns a faraway hardware site into a neighbor of your cloud.

Two kinds of networks

Bare Metal Solution servers typically use two kinds of networks. The client network carries traffic to and from your Google Cloud environment, such as application servers asking the database questions. The private network carries traffic between your own bare metal servers and to storage. Keeping them separate gives better security and lets cluster software, such as Oracle RAC, use a dedicated lane for its constant internal conversations.

The interconnect and VLAN attachments

The regional extension is joined to Google Cloud through a private high-capacity interconnect. Inside it, VLAN attachments connect the extension to your VPC, much like a numbered door between two buildings. Traffic over this link does not use the public internet, so it is faster, more stable, and safer. Google describes the round-trip delay between the regional extension and Google Cloud as very low, which is what lets applications in Compute Engine talk to a database in bare metal without feeling any big distance.

graph TD
  APP["App Servers in Compute Engine"] --> VPC["Customer VPC"]
  VPC --> ATT["VLAN Attachment"]
  ATT --> ICN["Private Interconnect"]
  ICN --> CN["Client Network in Regional Extension"]
  CN --> DB1["Bare Metal Server - Database Node 1"]
  CN --> DB2["Bare Metal Server - Database Node 2"]
  DB1 --- PRV["Private Network - cluster traffic"]
  DB2 --- PRV
  DB1 --- STO["Storage Network and Volumes"]
  DB2 --- STO
  OPS["Admin via Bastion Host and SSH"] --> VPC
    

IP planning

Planning IP address ranges is one of the most important early tasks. Ranges used by Bare Metal Solution must not overlap with ranges in your VPC, your office network, or any other connected network. Overlaps cause routing confusion that is hard to repair after servers are live. Many teams draw an address plan on paper, share it with network and security colleagues, and store it with their documentation.

Names and bandwidth

Like other servers, bare metal machines are easier to use with friendly names, handled by DNS, the internet’s phone book that turns names into numeric addresses. Remember also that the connection to Google Cloud has a fixed bandwidth, meaning a limit on how much data can flow each second. Large database exports or backups sent to Cloud Storage can use much of it, so schedule them wisely.

Follow one customer action through a hybrid system that uses both normal cloud services and bare metal.

Let us follow a real example. A customer of a large online retailer taps “Place order” on a phone. The retailer’s web servers and application servers run on Compute Engine in a Google Cloud region. The order records live in an Oracle database running on Bare Metal Solution in a nearby regional extension.

The hybrid advantage

This pattern shows why the product exists. The heavy, license-sensitive database stays on dedicated hardware, while everything else can use flexible cloud tools. Web servers can grow and shrink with traffic. Reporting teams can use modern analytics services. Over time, small pieces of the old system can be moved away from the database one at a time, which is far safer than a one-big-bang rewrite.

The workload this product was designed around.

Oracle Database is a relational database, which means it stores information in tables and lets programs ask detailed questions using the SQL language. It is famous for strict accuracy, rich features, and heavy use in business systems. Several Oracle features are especially relevant to Bare Metal Solution.

Licensing in plain words

A license is the legal permission to use software, usually with rules about how many cores or users are covered. With Bare Metal Solution, customers generally bring their own Oracle licenses, which is called BYOL, short for Bring Your Own License. Because the servers are physical, counting cores is straightforward and matches the way Oracle contracts have traditionally worked. Licensing terms change, and each contract is different, so always review your agreement with Oracle and your own legal team. Do not guess about license rules.

Support

Google supports the infrastructure, which means the servers, storage, network, and facility. Oracle supports the database software. When a problem occurs, finding out whether it lies in the hardware layer or the database layer is the first step, and good monitoring makes that job easier.

Oracle is the headline, but it is not the only guest on bare metal.

Any software that needs certified physical hardware, has core-based licensing, or cannot run well under a hypervisor may be a candidate. Examples that organizations explore include the following.

Before choosing bare metal for any of these, ask one question: “Can this workload run well on normal cloud machines?” If the answer is yes, ordinary machines will almost always be cheaper, faster to create, and easier to change. Bare metal should be chosen for a real reason, not for habit.

Moving a database is like moving a hospital: patients must stay safe the whole time.

Choosing a copy method

The right method depends on how much downtime the business can accept. A backup and restore method is simple but needs a longer outage. A standby-and-switchover method, using Data Guard, keeps the new database nearly in step with the old one, so the final switch takes only minutes. Very large databases often use the second approach, because moving many terabytes takes days, and the business cannot stop that long.

graph LR
  OLD["Old data center database"] -->|"Initial backup copy"| NEW["New database on Bare Metal Solution"]
  OLD -->|"Continuous change shipping"| NEW
  NEW --> TEST["Application and performance tests"]
  TEST --> SW{"Ready for cutover?"}
  SW -->|Yes| CUT["Switchover in a short window"]
  SW -->|No| FIX["Fix issues and retest"]
  FIX --> TEST
  CUT --> LIVE["Applications now use new database"]
    

What happens when something breaks, and how to design so that users barely notice.

High availability, or HA, means designing a system so that a single failure does not stop service. Disaster recovery, or DR, means being able to restart the service somewhere else after a very large failure, such as a whole site becoming unavailable. Two measures guide every DR plan. The RTO, or Recovery Time Objective, is how long you can accept being offline. The RPO, or Recovery Point Objective, is how much recent data you can accept losing, measured in time.

Layers of protection

Within one server: Google replaces failed parts such as fans and power supplies, and servers have redundant connections so one broken cable does not disconnect them.

Across servers: Oracle RAC runs the database on two or more servers at once, so if one dies, others continue. This protects against a single machine failing.

Across sites: A standby database in another region, kept updated with Data Guard, protects against loss of a whole regional extension. This usually needs a second Bare Metal Solution location or another disaster plan in a different place.

Across time: Backups protect against human mistakes, like a wrongly deleted table, and against corruption, which replication would simply copy to every copy.

graph TD
  subgraph R1["Region 1 Regional Extension"]
    N1["RAC Node 1"]
    N2["RAC Node 2"]
  end
  subgraph R2["Region 2 Regional Extension or Alternative Site"]
    SB["Standby Database"]
  end
  N1 --> SB
  N2 --> SB
  N1 --> BK["Backups in Cloud Storage"]
  N2 --> BK
  APP["Application Tier"] --> N1
  APP --> N2
  APP -.->|"After a disaster"| SB
    

Security is shared between Google and you. Knowing exactly where the line sits is half the battle.

This idea is called the shared responsibility model. Google secures the physical site, the hardware, and the underlying network and storage systems. You secure everything you place on top. Many incidents happen on the customer side of the line, so it deserves careful attention.

Identity and access

IAM, short for Identity and Access Management, controls which people and programs may do which actions in Google Cloud. Apply least privilege, giving each person only the permissions they truly need. Someone who only views server status should not be able to delete volumes. Separate the roles of people who manage infrastructure from those who manage databases.

Server login

Use SSH keys, which are long digital keys used instead of simple passwords, and keep them safe. Limit login so that servers are reachable only through a guarded bastion host, and record every session. Remove access promptly when someone leaves the team.

Data protection

Encrypt data in transit and at rest wherever your design allows. Oracle offers features such as Transparent Data Encryption, which scrambles stored database files. Store secrets, such as database passwords, in a proper vault like Secret Manager and not inside scripts. Keep backups in a protected location with strict access.

Network defenses

Keep the bare metal networks private. Use firewall rules in the VPC to limit which application servers can reach database ports. Consider network inspection tools if your rules require them, and monitor for odd traffic patterns, such as sudden large downloads.

You own the software layer, so you must also watch it.

Observability is the ability to understand what is happening inside a system by looking at the signals it gives off. For a database on bare metal, there are several layers worth watching, from hardware up to the application.

Numbers to watch

Track latency, the time operations take. Track throughput, how many operations or how much data moves per second. Track errors, including failed logins and failed backups. Track saturation, how full resources are, such as processor use, memory, storage capacity, and the bandwidth of the interconnect. Watch replication lag for any standby database, since a large lag means a disaster could lose recent data.

Alerts

Set alerts that reach a real person quickly and say clearly what is wrong. Avoid alert floods, because too many warnings teach people to ignore all of them. Alert on symptoms that matter to users, such as slow orders, and on early warnings, such as storage reaching eighty percent full.

Bare metal is billed differently from virtual machines. Knowing why prevents surprises.

Virtual machines are billed by the second, and you can switch them off to stop paying. Physical servers are reserved for you, so Bare Metal Solution is typically billed on a committed term basis, such as monthly plans with a minimum length and lower prices for longer promises like one or three years. Storage and networking are priced separately. Exact prices change and vary by region, so use Google’s current pricing information and speak with Google sales for a quote.

The hidden big number: licenses

For many Oracle customers, the software license costs more than the hardware. That is why core counts matter so much. Choosing a server with more cores than you need can multiply license costs, even if the server price itself looks small. Measure real workload peaks, test on candidate sizes, and then decide.

An honest look at what Bare Metal Solution does well and where it hurts.

The trade-off triangle

Most infrastructure choices balance control, convenience, and flexibility. Bare Metal Solution gives high control and keeps your familiar way of working, but it gives up some convenience and flexibility. That is a fair deal when the workload truly needs it, and a poor one when it does not.

Lock-in considerations

Bare metal can reduce lock-in in one way, because your database remains standard Oracle software that you can move elsewhere. It can increase lock-in in another, because contracts and network designs tie you to a particular region and term. Keep your backups and scripts portable, document your design, and review your plan every year.

A simple decision path for picking where a workload should run.

graph TD
  START["Workload to place"] --> Q1{"Can it run well on normal virtual machines?"}
  Q1 -->|Yes| GCE["Compute Engine or a managed cloud service"]
  Q1 -->|No| Q2{"Is it an Oracle database?"}
  Q2 -->|Yes| Q3{"Prefer a database service run with Oracle tooling?"}
  Q3 -->|Yes| ODB["Oracle database service inside Google Cloud data centers"]
  Q3 -->|No| BMS["Bare Metal Solution"]
  Q2 -->|No| Q4{"Needs certified or dedicated physical hardware?"}
  Q4 -->|Yes| BMS
  Q4 -->|No| ST["Sole-tenant nodes or reconsider the design"]
    

Always confirm the current products, regions, and features. Cloud offerings evolve quickly, and a choice that was best last year may have a better alternative today.

Reusable good ideas, and the common bad ones to avoid.

Patterns that work well

Anti-patterns to avoid

A practical checklist for teams starting out.

Best practices

• Start with a written assessment. Know every database, its size, its peak, its dependencies, and its license before you design anything.
• Right-size from measurements. Use real performance data to choose cores and memory, since licenses and commitments depend on them.
• Design for failure from day one. Combine clustering, standby systems, and tested backups.
• Test the network early. Measure delay and bandwidth between the application tier and the database before moving data.
• Automate builds and patches. Scripts make servers repeatable and reduce human mistakes.
• Use dedicated access paths. Allow logins only through a hardened bastion host with strong keys and session records.
• Separate duties. Different people should manage infrastructure, databases, and security settings.
• Document everything. Keep diagrams, address plans, runbooks, and contact lists up to date.
• Practice recovery. Run restore tests and failover drills every few months and record the results.
• Review the plan yearly. Check whether workloads could now move to managed or virtual platforms.

Common mistakes

Typical situations where organizations consider Bare Metal Solution. These are illustrations of patterns, not statements about specific companies.

Quick answers to the questions beginners ask most often.