Public Cloud #

Public Cloud is the most dominant cloud computing deployment model in the industry today. It’s the model the general public universally means when they talk about “moving to the cloud”. In the Public Cloud model, all physical data center infrastructure, data transmission networks, and data storage systems are fully owned and operated by a third-party cloud provider. Those computing resources are then shared and rented to thousands, even millions, of different customer organizations (multi-tenant) over the public internet. Understanding the basic characteristics of Public Cloud architecture, data isolation mechanisms in a shared environment, its financial advantages, and legal compliance considerations is an absolute step for every systems architect before comparing it with alternative deployment models.

How Multi-Tenant Architecture Works #

The fundamental principle of Public Cloud operations is Multi-Tenancy. This concept is similar to how a large apartment building is managed. All apartment residents share the same physical facilities — the building’s foundation, elevators, main lobby, entrance gates, and main water lines. However, each resident has their own room key and lives in a separate, securely locked apartment unit. The neighbor next door can’t see or access the contents of our room without explicit permission.

flowchart TD
    subgraph PhysicalServer["Provider Physical Server (Bare-Metal Hardware)"]
        Hypervisor["Hypervisor (KVM / Xen / Nitro Card)"]
        
        subgraph ComputeInstances["Virtual Instances (Guest OS)"]
            TenantA["Our VM (Tenant A)"]
            TenantB["Organization X's VM (Tenant B)"]
            TenantC["Organization Y's VM (Tenant C)"]
        end
        
        Hypervisor -->|"Isolated vCPU & RAM Allocation"| TenantA
        Hypervisor -->|"Isolated vCPU & RAM Allocation"| TenantB
        Hypervisor -->|"Isolated vCPU & RAM Allocation"| TenantC
    end
    
    DevA["Us (Admin A)"] -->|"Isolated Access"| TenantA
    DevB["Admin B"] -->|"Isolated Access"| TenantB

Hypervisor-Level Isolation Mechanisms #

At the hardware level, physical servers in Public Cloud data centers host several Virtual Machines from different customers (tenants) simultaneously. Strict inter-customer isolation is fully maintained at the virtualization software level called the Hypervisor.

  • The hypervisor uses low-level CPU instruction support (like Intel VT-x or AMD-V) to lock down the RAM and vCPU allocation of one VM so it can’t be accessed or spied on by other VMs running on the same physical CPU.
  • Every virtual network traffic packet entering and leaving a VM is wrapped with unique identification metadata (virtual network tag) at the hypervisor’s virtual router level, guaranteeing no data packet leaks between tenants.

The Noisy Neighbor Phenomenon #

Although the hypervisor performs strict security isolation, there’s one performance challenge in multi-tenant environments known as Noisy Neighbor. This phenomenon happens when one tenant on the same physical server suddenly performs extremely heavy computation, monopolizing shared resources (like memory bus bandwidth or disk I/O throughput) and causing unexpected performance degradation on our VM.

To minimize this risk, modern cloud providers implement aggressive resource limiting policies (rate-limiting/throttling) or offer Dedicated Host instance rental options if our application needs very consistent performance stability.

Fundamental Public Cloud Advantages #

Compared to building our own local data center (on-premise), deploying infrastructure to the Public Cloud provides massive competitive advantages across several aspects:

1. Economies of Scale #

Giant Public Cloud providers (like AWS, Google Cloud, or Microsoft Azure) buy server hardware, hard drives, and power supplies in massive volumes for their hundreds of data centers worldwide. This giant purchasing scale gives them very high price-negotiating power with hardware chip manufacturers, lowering per-unit purchase prices to levels no individual company could achieve. This cost efficiency is then passed on to us in the form of very competitive resource rental rates that keep declining over time.

2. Financial Transformation: CapEx to OpEx #

Before the cloud era, launching a new application required a very large initial capital budget (CapEx - Capital Expenditure) just to buy physical servers, rent data center space, and set up redundant power networks before the first line of application code was written.

In the Public Cloud era, all that initial capital budget is 100% eliminated into monthly operational costs (OpEx - Operational Expenditure). We only pay for what we use on a pay-as-you-go basis. If our application project fails midway, we just delete all those cloud resources and stop paying the bill — with no stranded physical asset investment losses.

3. Unlimited Global Elasticity #

Public Cloud lets us deploy applications to dozens of different geographic regions worldwide within minutes. We can automatically scale server capacity from 5 to 500 instances when traffic spikes, and quickly scale back down when traffic subsides, delivering business agility that’s physically impossible to replicate in a local data center.

4. Instant Access to Service Innovation #

Public Cloud providers invest billions of dollars releasing cutting-edge technology as ready-to-use managed services. We can directly consume vector databases for AI, automated machine learning platforms, Kubernetes infrastructure, and large-scale data analytics systems without hiring specialist teams to assemble that infrastructure from scratch.

Security Myths and Realities in the Public Cloud #

Concerns about data security when it’s “outside our own office building” are the biggest psychological and bureaucratic barrier for many organizations before adopting Public Cloud. However, industry statistics prove this assumption is often the opposite of the field reality.

Myth: "Our local office data center is far more secure because we can see and directly control the physical assets."

Reality: Most mid-size companies' local data centers are often maintained by general IT staff
under-trained in security patching, lack layered physical security systems, and are vulnerable
to physical asset theft.
In contrast, Public Cloud data center buildings are protected with military-standard layered
physical security (biometric sensors, AI CCTV cameras, 24/7 intruder detectors) and have
world-class cybersecurity specialist teams working full-time monitoring threats 24 hours a day.

The Danger of User-Side Misconfiguration #

Under the Shared Responsibility Model framework, most large-scale data leak incidents in Public Cloud don’t happen because hackers breached the data center’s physical security or broke the cloud provider’s hypervisor encryption. Data leaks almost always happen due to misconfiguration by our own engineering teams.

Here’s a visualization of an anti-pattern virtual firewall (Security Group) access configuration that opens sensitive database ports to the public internet, contrasted with the correct, secure configuration following the least privilege principle:

// ANTI-PATTERN: Opening the PostgreSQL database port freely to the public internet
// ✗ Anyone on the internet can try to break into our database via brute-force attack.
resource "aws_security_group_rule" "dangerous_database_rule" {
  type              = "ingress"
  from_port         = 5432
  to_port           = 5432
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"] # DANGER: Open access from anywhere on the internet!
  security_group_id = aws_security_group.db_sg.id
}

// CORRECT: Restrict database access only to our web application server subnet
// ✓ Only internal server instances are allowed to send requests to the database.
resource "aws_security_group_rule" "secure_database_rule" {
  type              = "ingress"
  from_port         = 5432
  to_port           = 5432
  protocol          = "tcp"
  source_security_group_id = aws_security_group.web_app_sg.id # Only allow from Web App Security Group
  security_group_id        = aws_security_group.db_sg.id
}

Regulatory Compliance and Data Sovereignty #

For industries with strict regulations (like banking, healthcare, and government agencies), Public Cloud adoption must be balanced with regional legal compliance:

  • Data Sovereignty: Some countries require their citizens’ sensitive data to never leave their legal jurisdiction. Cloud providers respond by building dedicated regions inside those countries (like the Jakarta ap-southeast-3 region on AWS or asia-southeast2 on Google Cloud) so data stays within Indonesian territory.
  • Built-in Compliance Certifications: Major providers offer formal compliance document repositories (like AWS Artifact) containing globally recognized audit certificates — SOC 2 Type II, ISO 27001, PCI-DSS (finance), and HIPAA (healthcare) — to simplify our application’s compliance audit process.

Selection Criteria: When to Use Public Cloud? #

To simplify architectural decision-making, use the following checklist criteria to determine when Public Cloud is the best choice and when to look for alternatives:

HIGHLY SUITABLE for PUBLIC CLOUD if:
  ✓ Our application workload is highly fluctuating, has seasonal spike patterns (like retail e-commerce during Harbolnas), or is unpredictable upfront.
  ✓ We're a startup team or launching a new product prioritizing release speed (speed to market) with minimal capital (OpEx).
  ✓ The application needs multi-region geographic distribution to serve global users with low latency.
  ✓ The IT team has no infrastructure specialists to maintain physical server hardware and data center cooling.

CONSIDER ALTERNATIVES (Private / Hybrid Cloud) if:
  ✗ National legal regulations absolutely prohibit placing our specific data types on third-party-owned servers.
  ✗ Application workloads run flat, constant, and predictable all year with 100% constant hardware utilization (at this scale, buying physical hardware with CapEx can sometimes be cheaper than renting monthly cloud VMs).

Summary #

  • Public Cloud is a multi-tenant environment where we share physical servers and infrastructure with other organizations, with strict virtual isolation guaranteed at the Hypervisor level.
  • Economies of Scale are the cost-efficiency engine of Public Cloud, keeping compute resource rental rates declining due to the provider’s massive hardware purchasing.
  • The financial model shifts from initial capital (CapEx) to monthly operational costs (OpEx), eliminating investment loss risk if our application project fails midway.
  • User misconfiguration is the biggest security hole in the cloud, not cloud provider system weaknesses. Always strictly apply encryption and network port filtering.
  • Choose a local region to comply with national data sovereignty regulations if our application manages sensitive public data or financial transaction data.
  • Use Public Cloud for maximum business agility, leveraging hundreds of innovative ready-to-use managed services without infrastructure maintenance overhead.

← Previous: Choosing a Service Model   Next: Multi Cloud →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact