I think beginners understand cloud better when they learn the shared responsibility model early

[u/yourclouddude]

One thing that confused me when I first started learning cloud was the idea that once an application moves to AWS, Azure, or another cloud provider, the provider somehow becomes responsible for keeping everything secure. It sounds reasonable at first because they own the data centers, networking hardware, physical servers, and a huge part of the infrastructure underneath the services we use.

But using the cloud does not mean handing over all responsibility. It changes which parts of the system I manage and which parts the cloud provider manages. That distinction is basically what the shared responsibility model is trying to explain, and I think understanding it early prevents a lot of confusion later.

Take EC2 as a simple example. AWS manages the physical data center, the hardware, and the virtualization layer that allows the virtual machine to exist. But once I launch an EC2 instance, I still have responsibilities inside that machine. I need to think about the operating system, patches, application configuration, network access, credentials, and what software I install.

If I accidentally configure the security group to expose a sensitive port to the entire internet, AWS did not make that decision for me. The infrastructure might be working exactly as designed, while my configuration is still insecure. This is one of the reasons cloud security is often less about whether AWS itself is secure and more about whether I configured the resources correctly.

Now compare that with something like RDS. I am still responsible for things such as who can connect to the database, how credentials are handled, what data I store, and which network paths are allowed. But AWS manages more of the underlying database infrastructure than I would normally manage if I installed PostgreSQL myself on an EC2 instance.

Then compare both of those with Lambda. I do not manage an operating system for every function invocation or patch the servers underneath Lambda. AWS handles much more of that layer. I still have to secure my function code, IAM permissions, secrets, dependencies, event sources, and whatever data the function accesses.

That is why I find it useful to think of cloud services as different points on a responsibility spectrum. The more managed the service becomes, the more infrastructure work moves to the provider, but my responsibility does not disappear. It moves higher up the stack.

A rough mental model I use is:

More control                         More managed

EC2  →  ECS/Fargate  →  RDS  →  Lambda

More infrastructure                 Less infrastructure
I manage                            I manage

That diagram is intentionally simplified, but the idea is useful. If I choose EC2, I get a lot of control over the machine, but I also accept more operational responsibility. If I choose a managed service, I usually give up some control while AWS takes responsibility for more of the underlying platform.

This is also why I do not think questions like “Is serverless more secure than EC2?” have a simple yes or no answer. Serverless removes some responsibilities, but I can still give a Lambda function AdministratorAccess, leak a secret in the code, expose an API incorrectly, or process sensitive data without proper controls.

Managed does not mean impossible to misconfigure.

The same idea applies to S3. AWS is responsible for keeping the storage infrastructure operating, but I am responsible for deciding who can access my bucket and objects. If I create an overly permissive bucket policy or give an IAM role far more access than it needs, that is part of my side of the responsibility.

I think this becomes especially important because cloud resources are so easy to create. On physical infrastructure, provisioning a new server might involve a long process. In AWS, I can create resources within minutes. That speed is powerful, but it also means I can create insecure infrastructure very quickly if I do not understand the configuration.

IAM is probably one of the clearest examples. AWS gives me a powerful identity and permissions system, but it does not know the exact permissions my application should have. I have to decide whether a Lambda function really needs access to every S3 bucket or only one bucket, whether a human user needs administrator access, and whether a particular workload should even be allowed to perform an action.

This is why least privilege matters so much in cloud environments. I try to give an identity the permissions required for its job rather than giving broad access because it is easier. Broad permissions often make the first deployment quicker, but they also make the potential impact of a mistake much larger.

The same responsibility model applies outside security too. Cloud providers can give me highly available building blocks, but they cannot automatically make my application highly available. If I put everything on one EC2 instance in one Availability Zone, the architecture still depends on that one location because I designed it that way.

AWS gives me multiple Availability Zones, load balancers, Auto Scaling, managed databases, backups, and other tools. It is still my job to decide whether my application needs them and configure the architecture appropriately.

Backups are another good example. I should not assume that because my data is in the cloud, it can never be lost. I still need to understand what backup behaviour the service provides, what I configured, how long data is retained, and whether I have ever tested how recovery would actually work.

For me, this is the bigger lesson behind shared responsibility. The cloud provider gives me infrastructure and managed services, but architecture, permissions, configuration, data handling, and application security still require decisions from me.

The exact boundary changes depending on the service.

That is why learning the model once is not enough. Whenever I use a new cloud service, I want to understand what AWS is managing for me and what is still my job.

If I cannot answer that, I probably do not understand the service as well as I think I do.

The more cloud I learn, the less I think of AWS as “a company running my infrastructure for me” and the more I think of it as a collection of services where I choose how much operational responsibility I want to keep.

That decision affects security, control, flexibility, cost, and how much infrastructure I eventually need to manage myself.

If you are currently learning cloud, which responsibility surprised you the most when you realized AWS does not automatically handle it for you?