CLOUD CONCEPT

Public Cloud

Public cloud is a deployment model in which a third-party provider offers computing resources for use by many customers on provider-operated infrastructure.

Cloud Concepts Hub →

What is Public Cloud

Organizations provision public cloud resources on demand rather than purchasing and operating all underlying physical infrastructure themselves. Understanding this model helps engineers distinguish cloud-based, hybrid, and on-premises deployments and evaluate their operational responsibilities, costs, and security requirements.

Public cloud describes a deployment model, not a particular product or application architecture. A provider operates infrastructure and offers computing resources to a broad customer base through services such as virtual machines, object storage, databases, and serverless execution. Customers typically provision these resources through a console, command-line tools, or APIs, with usage-based pricing and optional pricing commitments.

The provider manages physical facilities, hardware, and foundational infrastructure. Customers retain responsibilities that depend on the services they choose. With virtual machines, customers generally manage guest operating systems, application patches, and workload configuration. With managed databases or serverless services, the provider handles more of the underlying operation, but customers still manage their data, access permissions, and application behavior. Moving to public cloud changes operational responsibilities; it does not eliminate them.

For example, a retailer can deploy an application on cloud compute resources, store product images in object storage, and use a managed database for orders. The retailer can configure scaling policies to add capacity during busy periods and remove it afterward. This avoids purchasing hardware sized for peak demand, although elasticity requires suitable application design, configuration, service quotas, and available capacity. Public cloud does not make every application automatically scalable.

For deployment-model questions, distinguish a cloud-based deployment from an on-premises deployment and a hybrid deployment. In a cloud-based deployment, the application’s components run in cloud infrastructure, whether migrated from an existing environment or built there. In an on-premises deployment, workloads run in the organization’s own facilities or other infrastructure it manages. A hybrid deployment integrates cloud and on-premises environments, such as a cloud-hosted application accessing a database retained in a company data center through private connectivity. Merely maintaining unrelated workloads in both places does not demonstrate meaningful hybrid integration.

Public cloud is also distinct from private cloud. A private cloud is provisioned for exclusive use by one organization and may be operated on or off premises. An ordinary on-premises data center is not necessarily a private cloud: it may lack cloud characteristics such as on-demand self-service and resource pooling. Likewise, a logically isolated virtual network within a public cloud does not turn the deployment into a private cloud.

The word public refers to the provider’s offering, not to the visibility of customer data or workloads. Public cloud resources can use private IP addresses, restricted access policies, encryption, and private network connections. Providers commonly pool infrastructure across customers while enforcing tenant isolation, and some services offer dedicated hardware options within the public cloud model.

Trade-offs include reduced upfront hardware investment and faster provisioning versus ongoing service charges, network dependencies, data-transfer costs, and provider-specific dependencies. Engineers must also evaluate data residency, service availability, recovery requirements, and compliance controls. Provider infrastructure does not automatically make an application highly available: teams must choose appropriate locations, design redundancy, test recovery, and control spending through monitoring and resource lifecycle management.

Key aspects of Public Cloud

Public cloud combines provider-operated infrastructure, on-demand services, isolated customer environments, and metered consumption while retaining customer responsibilities for secure and reliable workloads.

Provider-operated infrastructure

The provider operates the physical facilities and underlying infrastructure. Engineering teams consume services instead of procuring and maintaining every hardware component.

On-demand provisioning

Teams can request resources through APIs, command-line tools, or consoles. Infrastructure as code makes these deployments repeatable, while quotas and permissions constrain what can be provisioned.

Resource pooling and tenant isolation

Providers commonly serve multiple customers using pooled infrastructure with isolation controls. Dedicated hardware options can still be part of a public cloud offering.

Elastic capacity and metered costs

Resources can be added or removed as demand changes, with charges determined by service-specific pricing. Scaling policies, application design, and cost controls are necessary; neither automatic scaling nor lower total cost is guaranteed.

Shared operational and security responsibilities

The provider and customer divide responsibilities according to the service model. Customers remain responsible for areas such as data handling, access control, and workload configuration.

Deployment model independent of public access

A public cloud workload can be isolated from the public internet. Private networking changes connectivity and exposure, not the underlying deployment model.

Cloud services for Public Cloud

A public cloud application can use Amazon VPC for network isolation, Amazon EC2 for virtual-machine workloads, Amazon S3 for objects, and Amazon RDS for relational data. AWS Lambda can handle event-driven tasks without customer-managed servers. These services show how one deployment model supports different levels of operational abstraction: customers manage more of the software stack on virtual machines and less of it in managed or serverless services. Across all of them, access control, data protection, availability design, and cost management remain essential. Private networking and restricted access keep workloads nonpublic without making the environment a private cloud.

Amazon EC2 image Amazon EC2

Amazon EC2 provides virtual compute capacity on AWS-operated infrastructure. It illustrates public cloud infrastructure consumption while leaving customers responsible for guest operating systems, applications, and instance-level configuration.

Open Amazon EC2 →
Amazon Simple Storage Service image Amazon S3

Amazon S3 provides managed object storage without requiring customers to operate storage hardware. Buckets and objects can remain private, demonstrating that public cloud storage does not mean publicly accessible data.

Open Amazon S3 →
Virtual private cloud VPC_32 image Amazon VPC

Amazon VPC provides logically isolated virtual networking within AWS. Private subnets and controlled routing support nonpublic workloads without changing their classification as public cloud deployments.

Open Amazon VPC →
Amazon RDS image Amazon RDS

Amazon RDS provides managed relational databases, shifting tasks such as infrastructure maintenance and configured backup operations to the provider. Customers still control database access, data, and relevant availability and recovery settings.

Open Amazon RDS →
AWS Lambda image AWS Lambda

AWS Lambda executes code without customers provisioning or managing servers. It illustrates a public cloud service with greater provider operational responsibility, while customers manage code, permissions, dependencies, and execution configuration.

Open AWS Lambda →