Certified - AWS Certified Cloud Practitioner

When organizations move into the cloud, one of the first questions they ask is, “Who is responsible for keeping everything safe?” This is where the AWS shared responsibility model comes in. It is a framework that divides security and compliance duties between AWS and the customer. Rather than assuming AWS handles everything or that the customer is on their own, the model makes clear which side covers which tasks. Understanding this model is not only essential for using the cloud safely, but it is also a major focus of the Certified Cloud Practitioner exam. It defines the rules of partnership between AWS and every customer, from small start-ups to global corporations.
At its core, AWS is responsible for what we call the security of the cloud. This includes protecting the physical facilities, the networking hardware, and the systems that form the backbone of the platform. Think of AWS as the landlord of a large apartment building. The landlord is responsible for keeping the building safe, maintaining the locks on the main doors, and ensuring the elevators and fire alarms work properly. In the same way, AWS ensures that the data centers are secure, the servers are protected, and the infrastructure runs reliably. Customers can trust that these foundational layers are safeguarded by AWS experts.
On the other hand, customers are responsible for security in the cloud. This means they must properly configure the services they use, control who has access, and manage their own data. Continuing with the apartment analogy, the tenant is responsible for locking their own front door, deciding who to give keys to, and keeping valuables safe. AWS provides the secure building, but customers control what happens inside their unit. If a customer fails to set up strong passwords, ignores encryption, or leaves sensitive data exposed, those mistakes fall under their responsibility. This distinction is critical to keeping cloud systems safe.
Examples of AWS-managed security help make this clearer. AWS handles physical security by guarding its data centers with fences, cameras, biometric scans, and professional staff. They also protect the networking hardware that connects regions and availability zones. In addition, AWS manages the hypervisors, the software layer that creates and runs virtual servers, ensuring they are patched and secure. Customers never need to worry about these layers because AWS owns and maintains them. By handling this work, AWS allows organizations to focus on using the services rather than worrying about the hidden foundation underneath.
Now let’s look at examples of customer-managed security. Customers are responsible for setting up firewalls called security groups, deciding which users can log in through identity and access management, and classifying data to determine what requires encryption. They must also configure backups, monitor logs, and ensure applications follow compliance standards. AWS provides the tools, but it is up to customers to use them correctly. If you think of AWS as giving you a toolbox, customer responsibility is choosing the right tool and applying it properly. Misconfiguration is one of the most common security risks in the cloud, and it lies squarely on the customer side.
Physical security is one area completely managed by AWS. Customers never need to think about the guards, locks, or sensors protecting the servers. These measures are not even visible to customers because they are handled behind the scenes. This allows customers to focus on higher-level decisions about how to structure and protect their data. For instance, a company using AWS does not have to send its own staff to guard buildings or maintain fire suppression systems. Instead, AWS guarantees that the physical layer is secure, freeing customers to focus entirely on their own digital responsibilities.
Data classification, however, rests entirely with the customer. Classification means deciding what level of sensitivity data carries, and how it should be protected. Personal medical records, for example, may need encryption at rest and in transit, while public marketing materials may not. AWS will not decide these things for you—it simply provides the options and tools. Customers must make thoughtful choices about their own information, just as you would decide whether to store important papers in a locked safe while leaving less sensitive items on a bookshelf. Classification drives every other decision about data protection.
Understanding the boundaries between AWS and customer duties is essential. If customers assume AWS handles more than it does, they may leave gaps in their security. Conversely, if they overestimate their responsibilities, they may waste time and resources duplicating what AWS already provides. The shared responsibility model prevents these mistakes by spelling out the limits clearly. Knowing where AWS’s job ends and the customer’s begins creates a solid framework for building safe, reliable systems. This clarity ensures that nothing important is overlooked in the rush to adopt cloud technology.
Compliance adds another layer to the model. Businesses often must follow regulations such as healthcare privacy rules or financial reporting standards. AWS provides certifications and documentation that prove its infrastructure meets global compliance requirements. However, customers are responsible for ensuring their specific applications and data use comply as well. For example, AWS may confirm that its data centers are HIPAA compliant, but a hospital using AWS must still configure its systems to handle patient data properly. Compliance is therefore a shared effort, with AWS covering the foundation and customers managing the details unique to their industries.
Misconceptions about responsibilities are common and can lead to real risks. Some customers believe that because AWS is a trusted provider, all aspects of security are covered automatically. Others may assume the opposite, thinking they must do everything themselves. Both misunderstandings create problems. AWS makes it clear that the division is balanced: they secure the cloud itself, while customers secure their use of the cloud. Recognizing and correcting these misconceptions is one of the first steps in building a secure and effective cloud environment. Clear understanding prevents costly errors and builds stronger systems.
The shared responsibility model also changes depending on the type of service being used. With infrastructure as a service, or IaaS, customers control more layers, including operating systems and applications. With platform as a service, or PaaS, AWS manages more of the underlying environment, leaving customers responsible mainly for data and users. In software as a service, or SaaS, AWS or its partners handle nearly everything, with customers focusing mostly on account management. The responsibilities shift depending on the model, and knowing these differences helps customers plan better and avoid surprises when adopting new services.
Understanding these variations is particularly useful for exam preparation. The AWS Certified Cloud Practitioner exam may ask who is responsible for certain tasks, such as patching servers or configuring access controls. Knowing the shared responsibility model and how it applies across IaaS, PaaS, and SaaS ensures you can answer confidently. More importantly, it helps you think clearly about real-world scenarios, where dividing responsibilities correctly can be the difference between a secure system and a vulnerable one. Mastering this model provides both academic and practical benefits for anyone working with the cloud.
For more cyber related content and books, please check out cyber author dot me. Also, there are other prepcasts on Cybersecurity and more at Bare Metal Cyber dot com.
One of the most important customer responsibilities is encryption. Encryption means locking up data so that only someone with the correct key can read it. AWS provides the tools to encrypt data, such as built-in options for storage and databases, but it is up to the customer to decide when and how to use them. For example, a business may choose to encrypt sensitive customer information at rest, while also encrypting communications in transit. If customers neglect to turn these options on or manage them correctly, the protection is lost. AWS cannot decide which information is sensitive—customers must take charge of encryption as part of their role.
Closely tied to encryption is the responsibility for key management. Keys are the special codes that unlock encrypted data. AWS offers services like Key Management Service to help generate and store keys securely. However, customers are responsible for managing access to those keys and ensuring they are rotated and retired appropriately. Think of it like giving out keys to a building—AWS can provide the locks and a secure box for storing them, but the organization decides who receives a copy, who keeps track, and when locks should be changed. Key management mistakes can undermine even the strongest encryption.
Logging and monitoring are another area where responsibilities are shared. AWS provides tools such as CloudTrail, CloudWatch, and GuardDuty to collect logs and detect suspicious behavior. But it is up to the customer to enable these services, review the data, and act on findings. Simply having logs without monitoring them is like installing cameras around a house but never checking the footage. Customers need to actively analyze the information, set alerts, and respond to potential issues. AWS supplies the infrastructure and tools, while customers provide the vigilance and decision-making needed to stay secure.
Patching and updates highlight another clear division. AWS takes care of patching the infrastructure and systems they manage, such as the physical servers and the hypervisors running virtual machines. Customers, however, must patch and update the resources they control, like their operating systems and applications. If a company launches an EC2 instance with Windows or Linux, it is their responsibility to keep that system up to date with security patches. Failure to do so leaves vulnerabilities open for attackers. AWS maintains the foundation, but customers must keep their part of the house in order.
Identity and Access Management, often referred to as IAM, is a customer’s responsibility. IAM is the system that controls who can log in and what they can do. AWS provides the IAM service, but customers must define users, groups, and policies that reflect the principle of least privilege. This means giving people only the access they need to do their job, nothing more. If a company fails to restrict permissions or leaves root accounts unprotected, the responsibility lies with them. IAM is one of the most critical areas where customer decisions directly affect security outcomes.
AWS provides many tools to support customer responsibilities. Services like Trusted Advisor give recommendations for best practices, while Security Hub brings together findings from multiple tools in one place. GuardDuty analyzes activity for threats, and Macie identifies sensitive information in storage. These services make it easier for customers to uphold their side of the model, but they still must choose to use them effectively. The shared responsibility model is not about leaving customers unsupported—it is about giving them the power and tools to manage their share of the work while AWS handles the rest.
Best practices for dividing tasks include clear documentation, regular reviews, and consistent monitoring. Customers should begin by mapping out exactly which responsibilities belong to them versus AWS. They should then establish internal processes to manage their duties, such as updating systems, training staff, and enabling monitoring tools. Regularly checking permissions and configurations prevents mistakes from lingering unnoticed. In many organizations, creating a shared responsibility checklist helps keep teams accountable. By treating the model as a partnership with defined rules, customers can avoid confusion and ensure both sides are doing their part effectively.
Real-world examples show what can go wrong when the model is misunderstood. Many data breaches in the news involve misconfigured storage buckets that were left open to the public. In these cases, AWS provided secure systems, but customers failed to configure permissions correctly. Another example is companies leaving unused accounts active, which attackers later exploited. These incidents highlight that security failures often result from customer missteps rather than AWS infrastructure problems. Understanding the model reduces the chance of these mistakes and helps organizations build stronger, safer environments in the cloud.
Governance frameworks can support the shared responsibility model. Frameworks like ISO standards or the NIST Cybersecurity Framework help organizations set policies that align with best practices. By following these frameworks, companies can ensure their responsibilities are clearly defined and consistently managed. AWS aligns its own services with many of these frameworks, making it easier for customers to plug into global standards. Governance adds structure to the partnership, ensuring that nothing is left to chance and that roles are well integrated into day-to-day operations.
The model also has implications for audits. When regulators or internal teams audit cloud usage, they look at both AWS and the customer. AWS provides documentation and certifications that prove its part is covered. Customers must provide evidence for their responsibilities, such as access policies, encryption settings, and monitoring reports. Audits therefore reinforce the shared nature of cloud security. They highlight the importance of customers understanding their role clearly and being able to demonstrate that they are fulfilling it properly. Good preparation for audits often overlaps with good security practices in general.
Contractual clarity is another essential element of the shared model. AWS makes its role clear in agreements, but customers may also need to clarify their own obligations in contracts with clients or partners. For instance, a company providing cloud-based healthcare services must explain how it handles patient data under the shared responsibility model. This prevents misunderstandings and ensures accountability. Contracts reflect the reality of shared duties, setting expectations for who is responsible for which parts of the system. This transparency builds trust with stakeholders and avoids disputes later.
Documentation and training are practical tools for making the model effective. Documentation helps teams remember what they are responsible for and how to carry out those tasks. Training ensures employees understand the tools available and the importance of their role. For example, teaching developers how to use IAM securely or how to encrypt data correctly prevents mistakes. Without training, even the best tools can be misused. Documentation and education turn the shared responsibility model from an abstract idea into a daily practice embedded in the organization’s culture.
The shared responsibility model is also a focus of the AWS Certified Cloud Practitioner exam. Questions may ask who is responsible for specific tasks or how duties change across different service types. Mastering this model is not about memorizing a chart—it is about truly understanding the logic behind the division of responsibilities. If you can explain in simple terms what AWS handles versus what customers must handle, you will not only succeed on the exam but also demonstrate practical knowledge useful in real conversations about cloud adoption and security.
As we wrap up this episode, remember that the shared responsibility model is not just a technical detail—it is the foundation for secure and effective use of the cloud. AWS provides a secure, reliable infrastructure, while customers bring their own responsibility for data, access, and configuration. Together, these roles create a strong partnership. Misunderstanding the boundaries can lead to costly mistakes, but mastering them builds confidence and trust. Whether for the exam or in practice, knowing exactly where your responsibility begins is essential to succeeding in the AWS cloud.