Cloud computing becomes much easier to learn once the vocabulary stops feeling like a collection of unrelated acronyms. Most beginner confusion comes from mixing together different layers: deployment models, service models, networking, storage, identity, scaling, and operations. Once those layers are separated, unfamiliar product names become easier to classify.<\/p>\n
The twelve terms below are not a complete cloud glossary. They are the concepts that make many other cloud topics easier to understand. Learn what problem each term describes, then attach provider-specific services to the concept afterward.<\/p>\n
This concept-first approach is useful because provider product names change faster than the underlying architecture ideas. Once the operating model is clear, new services can be classified by the responsibility, data, network, identity, or execution problem they solve.<\/p>\n
Cloud computing<\/strong> is the on-demand consumption of configurable computing resources such as compute, storage, networking, databases, and applications from a shared pool that can be provisioned and released with comparatively little manual infrastructure work. The important ideas are on-demand access, resource pooling, elasticity, broad network access, and measured usage.<\/p>\n Shared responsibility<\/strong> explains why moving to the cloud does not move every responsibility to the provider. The provider secures and operates parts of the underlying cloud, while the customer remains responsible for responsibilities that depend on the service used. With a virtual machine, the customer manages more of the operating system and application stack. With a fully managed database or SaaS product, the provider manages more infrastructure, but the customer still controls data, identities, configuration, and appropriate use.<\/p>\n If this distinction is understood early, security questions become easier. \u201cManaged\u201d does not mean \u201csomeone else is responsible for everything.\u201d<\/p>\n A region<\/strong> is a geographic area in which a cloud provider operates infrastructure. An availability zone<\/a><\/strong> is an isolated failure domain within a region. Providers implement these concepts differently, but the architectural idea is the same: placing all capacity in one failure domain creates a larger outage risk than distributing it across independent locations.<\/p>\n Zones are not magic. A multi-zone application can still fail because of a shared database design, bad deployment, identity outage, software bug, or regional dependency. Regions matter for latency, data residency, disaster recovery, and service availability. Good architecture chooses locations based on requirements rather than assuming more regions are always better.<\/p>\n Scalability<\/a><\/strong> is the ability of a system to handle more work by adding or increasing resources. Vertical scaling makes a resource larger; horizontal scaling adds more resources. A database might scale vertically by moving to a larger instance, while an application tier might scale horizontally by adding more instances behind a load balancer.<\/p>\n Elasticity<\/strong> is the ability to adjust capacity as demand changes, ideally adding and removing resources without manual intervention. A system can be scalable without being elastic if engineers can increase capacity but must do so manually. Elasticity is one reason cloud is attractive for variable demand, although poor scaling rules can still add capacity too late or create unnecessary cost.<\/p>\n The distinction matters because architecture questions often describe a workload pattern. A permanently growing database has a different capacity problem from an online service that spikes for two hours each day.<\/p>\n Infrastructure as a Service (IaaS)<\/strong> gives customers fundamental infrastructure such as virtual machines, networks, and storage while leaving operating systems and applications largely under customer control. Platform as a Service (PaaS)<\/strong> moves more runtime and platform management to the provider so teams can focus on application code and data. Software as a Service (SaaS)<\/strong> delivers a complete application that the customer configures and uses.<\/p>\n These are not rigid boxes. Modern cloud services form a spectrum of responsibility. Containers, managed Kubernetes, serverless functions, managed databases, and hosted development platforms each place the responsibility boundary in a different location.<\/p>\n Understanding that spectrum is more useful than memorizing a textbook definition because it lets you ask the real design question: which operational responsibilities does the team need or want to own?<\/p>\n A virtual network<\/strong>\u2014called a VPC in AWS<\/a> and a VNet in Azure\u2014is a logically isolated networking environment used to organize address ranges, subnets, routing, connectivity, and network security. It gives cloud workloads a controllable network topology without requiring ownership of the physical switches and routers underneath it.<\/p>\n Identity and access management (IAM)<\/a><\/strong> controls who or what can perform actions. Human users, applications, virtual machines, containers, pipelines, and cloud services may all need identities. Policies then define what those identities can access. Least privilege means giving only the permissions required for the task rather than broad administrative rights.<\/p>\n Beginners often focus too heavily on the virtual network and too little on identity. Modern cloud security depends on both. A private endpoint is not enough if the workload identity can access everything. An identity policy is not enough if an internet-facing service is unnecessarily exposed.<\/p>\n Object storage<\/a><\/strong> stores data as objects in a flat namespace and is well suited to unstructured files, backups, logs, data lakes, media, and static content. Block storage<\/strong> presents storage volumes to systems such as virtual machines and databases, where the operating system manages a file system or application data structure. File storage<\/strong> exposes a shared hierarchical file system that multiple clients can access.<\/p>\n The right choice depends on access pattern, latency, throughput, sharing, durability, and application compatibility. Object storage is usually not a drop-in replacement for a low-latency database disk. Block storage is usually not the most economical place for massive archives. File storage solves compatibility and sharing problems that neither of the other models handles in the same way.<\/p>\n Learning storage by use case is much more durable than memorizing provider product names.<\/p>\n A managed database<\/strong> is a database service in which the cloud provider takes responsibility for more of the underlying infrastructure and routine database operations. Depending on the service, that can include provisioning, patching, backups, replication, failover, scaling, or monitoring.<\/p>\n Managed does not remove database design. Teams still need to choose the right data model, indexes, keys, consistency behavior, retention, access controls, and scaling strategy. A poorly modeled workload can perform badly on a managed database just as easily as on a self-managed one.<\/p>\n This is one point where beginner cloud literacy grows into architecture. Choosing a managed database<\/a> is therefore an architecture decision: the service has to fit the application’s data model, consistency, scaling, availability, and operational requirements.<\/p>\n3. Region and availability zone explain where resilience begins<\/h2>\n
4. Scalability and 5. elasticity describe two different forms of growth<\/h2>\n
6. IaaS, PaaS, and SaaS describe how much of the stack you manage<\/h2>\n
7. Virtual network and 8. identity and access management create the main control boundaries<\/h2>\n
9. Object, block, and file storage solve different problems<\/h2>\n
10. Managed database means the provider operates more of the database platform<\/h2>\n
11. Serverless and 12. containers are two different ways to package execution<\/h2>\n