Situation and constraints
Harbor Health is moving a small appointment application to AWS. The team is considering three ways to run important parts of it:
- host the application on an Amazon EC2 virtual server;
- place its relational database in Amazon RDS; and
- run a reminder function with AWS Lambda.
One manager says, “AWS is secure, so AWS handles security now.” Another says, “We always own everything because it is our application.” Both statements are too broad.
The AWS Shared Responsibility Model divides cloud security between AWS and the customer. The exact customer work changes with the service. AWS takes on more of the underlying stack for a managed database or serverless function than for a virtual machine, but Harbor never gives away responsibility for its data, identities, code choices, and service configuration.
This scenario asks a foundational question: how does Harbor identify the responsibility boundary without memorizing a separate slogan for every AWS service?
The decision to make
Harbor must choose services with a clear understanding of which security and operational tasks remain with the company.
The first distinction is stable:
- AWS is responsible for security of the cloud—the physical facilities, hardware, networking, and software that run AWS services.
- The customer is responsible for security in the cloud—including its data, identities and permissions, application choices, and configurations.
The second distinction depends on the service. With Amazon EC2, Harbor controls a guest operating system and therefore manages more of the stack. With Amazon RDS, AWS manages the database service's underlying infrastructure and operating platform. With AWS Lambda, AWS manages the server fleet and execution platform. As AWS manages more, Harbor can spend less time administering that layer—but customer responsibility does not disappear.
A practical mental model
Think about three ways to use a workplace.
An EC2 instance is like renting an empty office. The property owner manages the building, but Harbor installs and maintains much of what is inside its space.
Amazon RDS is like renting a managed specialist workspace. The provider maintains more of the equipment and operating environment, while Harbor decides who may enter, what information belongs there, and how its work is organized.
AWS Lambda is like hiring access to a managed workbench only when a task runs. Harbor supplies the instructions and materials; AWS operates the workbench and underlying facility.
The analogy has limits, but it exposes the central rule: the more abstracted the service, the more AWS manages below the customer configuration. Harbor still owns what it puts into the service and who it allows to use it.
The shared AWS Shared Responsibility Model reference develops this model across more service categories.
Compare the options without hiding the tradeoffs
| Responsibility area | Amazon EC2 | Amazon RDS | AWS Lambda |
|---|---|---|---|
| Physical facilities, hardware, and foundational networking | AWS | AWS | AWS |
| Guest operating system | Harbor patches and configures it | AWS manages the service operating system | AWS manages the execution environment's operating system |
| Database engine platform | Harbor if it installs one | AWS operates the managed database engine and patching process | Not the function's role |
| Application code and dependencies | Harbor | Harbor for the application using the database | Harbor for function code and included dependencies |
| Identities, permissions, and access configuration | Harbor | Harbor | Harbor |
| Customer data and classification | Harbor | Harbor | Harbor |
| Service configuration and encryption choices | Harbor | Harbor | Harbor |
The table is a learning model, not a substitute for each service's current documentation. Some responsibilities are shared at different layers. Patch management is a classic example: AWS patches infrastructure it manages, while Harbor patches the EC2 guest operating system and its own application dependencies. In RDS, AWS manages operating-system and database-engine maintenance as part of the service, but Harbor still schedules or configures relevant maintenance behavior and tests its application. In Lambda, AWS manages the service platform, while Harbor maintains function code and dependencies it supplies.
The service choice therefore creates a tradeoff between control and management burden. EC2 gives Harbor operating-system control, which may be necessary for specialized software. RDS removes database-server administration work. Lambda removes server management for event-driven code. More management by AWS can reduce undifferentiated work, but it may also reduce low-level control.
Recommended reasoning
For every service, Harbor should ask three questions.
What layer does AWS operate? This normally includes the facilities and underlying cloud infrastructure, plus additional layers for managed services.
What does Harbor place or configure in the service? Customer data, code, identities, permissions, network exposure, resource settings, and encryption choices remain customer concerns.
What control does Harbor need? If the application requires operating-system access, EC2 may be appropriate and the team must accept operating-system administration. If Harbor wants a managed relational database, RDS shifts those platform tasks to AWS. If a short event-driven task fits Lambda, Harbor can focus on code and permissions rather than servers.
Data protection cuts across all three. Harbor must classify sensitive health information, grant access using least privilege, configure appropriate encryption, avoid exposing resources, retain or delete data according to policy, and monitor how the workload is used. AWS securing a data center cannot correct an overly broad permission or unsafe application code.
The safest mental habit is not “AWS secures managed services.” It is “AWS manages more layers of managed services, while the customer still secures its use of those services.”
Where the manifest services fit
Amazon EC2 provides resizable virtual servers. Harbor selects and configures the instance, guest operating system, software, storage, network access, and permissions. AWS protects the physical infrastructure and virtualization layer. Use the shared Amazon EC2 reference for its broader compute role.
Amazon RDS is a managed relational database service. AWS handles work such as provisioning the database infrastructure, maintaining the underlying operating system, and supporting database engine patching, backups, and availability features. Harbor chooses and configures the database, controls access, manages its schemas and data, and makes appropriate protection and recovery choices. The Amazon RDS reference explains those capabilities in context.
AWS Lambda runs code without Harbor provisioning or managing servers. AWS operates the compute fleet, operating system, and managed execution platform. Harbor owns its function code, supplied dependencies, permissions, triggers, configuration, and data handling. The AWS Lambda reference covers the serverless model in more depth.
These service descriptions help with task statements 3.3 and 3.4 because they connect compute and database categories to different management boundaries. They are not an instruction to replace every EC2 workload with Lambda or every self-managed database with RDS.
Common exam confusion
- “AWS is responsible for security” versus shared responsibility: AWS secures the cloud infrastructure. Harbor secures its data, access, code, and configurations.
- Managed service versus no customer responsibility: Managed means AWS operates more layers. It does not mean AWS decides who may access Harbor's data.
- EC2 host patching versus guest patching: AWS maintains underlying hosts and infrastructure. Harbor patches the guest operating system it controls.
- RDS management versus database design: AWS manages the service platform. Harbor still owns data, access, schema, queries, and workload configuration.
- Lambda serverless versus securityless: Harbor does not manage servers, but it still secures code, dependencies, permissions, and event sources.
- Encryption capability versus encrypted correctly: AWS may provide encryption features. Harbor decides how to configure and use them for its data.
- Responsibility versus control: Choosing more customer control generally brings more customer management responsibility.
Recall prompts
- What does “security of the cloud” include?
- Why does Harbor patch an EC2 guest operating system but not the operating system under RDS?
- Which responsibilities remain with Harbor across EC2, RDS, and Lambda?
- How does a managed service change responsibility without eliminating it?
- Why is Lambda serverless but not responsibility-free?
- Which service should Harbor consider when it wants a managed relational database rather than operating the database server itself?
Summary
AWS and Harbor share responsibility for security. AWS protects the facilities, hardware, networking, and service infrastructure. Harbor protects its data, identities, permissions, code, and configurations.
The boundary shifts with the service. Harbor manages the guest operating system on EC2. AWS manages more of the database platform for RDS and more of the compute platform for Lambda. At Cloud Practitioner depth, the key is to recognize that abstraction moves selected infrastructure tasks to AWS while customer accountability for secure use remains.
Official references: CLF-C02 Domain 2, CLF-C02 Domain 3, the AWS Shared Responsibility Model, Amazon RDS, and Lambda shared responsibility.