Skip to main content

CompTIA Security+View full course outline

Cloud Deployment Models and Shared Responsibility(OBJ.3.1)

By Jonathon Eades — Founder & IT InstructorUpdated

11 min read

In 2019 an attacker abused a misconfigured web application firewall in Capital One's AWS environment, used it to obtain temporary credentials for a role that had far more access than it needed, and copied records on about 106 million people out of cloud storage. Amazon's data centers, hardware and hypervisors were never breached. The firewall rules, the role's permissions and the data were all Capital One's to configure.

That split, between what the provider secures and what the customer secures, is the center of cloud security. On the CompTIA Security+ SY0-801 exam it sits under objective 3.1, which expects you to compare the security implications of different architecture models. This lesson covers the four cloud deployment models, the three service models, and how the shared responsibility model and a responsibility matrix assign each security task to someone.

Cloud computing means renting pooled infrastructure that you configure yourself

NIST Special Publication 800-145 gives the definition most of the industry uses. A cloud service offers on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Each of those traits has a security consequence.

Self-service means anyone with the right permissions can create a server, a database or a public storage bucket in seconds, without a purchase order or a change ticket. The cloud console and its API become the place where many mistakes, and many attacks, happen. Broad network access means that console is reachable from the internet, so a phished cloud administrator account can do more damage than a phished laptop, and MFA on those accounts is a baseline control.

Resource pooling means multitenancy: your virtual machines may run on the same physical host as a stranger's, and the hypervisor and the provider's controls are what keep you apart. Elasticity means resources appear and disappear by the minute, which makes asset inventory and logging harder. Measured service means every resource costs money, which matters when an attacker uses your account to mine cryptocurrency.

NIST's definition also gives this lesson its shape: four deployment models that say who shares the infrastructure, and three service models that say how much of the technology stack you rent.

Public, private, and community clouds differ in who shares the infrastructure

A public cloud is owned and run by a provider such as AWS, Microsoft Azure or Google Cloud and sold to anyone with a credit card. Customers get the provider's scale: physical security, redundant power, a large security team and independent audits such as SOC 2 Type II reports and ISO/IEC 27001 certification. In exchange, they share hardware with other tenants, can't inspect the data center themselves, and have every misconfiguration one setting away from the internet.

A private cloud serves one organization. It can sit in the organization's own data center or in a provider's facility on dedicated hardware. A private cloud is not just "servers we own": it still offers self-service and pooled resources, but only to internal teams. The organization gets full control and no unknown neighbors, and pays for it with the cost of buying capacity, staffing operations and securing every layer itself. Its elasticity ends where the purchased hardware ends.

A community cloud is shared by a defined group of organizations with common requirements, such as several government agencies, a consortium of hospitals or a state university system. It may be run by one member, by the group, or by a provider on the group's behalf. Some government cloud offerings, open only to vetted public-sector customers and their suppliers, are often described this way. Members split the cost and the compliance work, and every tenant has been vetted. The security questions are about governance: who sets the baseline, who leads an incident that touches several members, and what happens to a member's data when it leaves. A weak member is also everyone's problem, because shared resources are only as safe as the least careful organization with access to them.

This lesson is part of ExamWizardz Pro

Unlock every lesson, unlimited practice tests, and the AI tutor.

See Pro pricing

or start with a free account

Test yourself on this topic: free Architecture Models practice questions — no account needed.