Cloud migration creates plenty of technical challenges. But one of the most common problems is much simpler than that.
Too many organisations still do not have a clear view of who is responsible for what in AWS.
That might sound basic. It is not. When shared responsibility is misunderstood, security gaps grow quickly. Controls become inconsistent. Ownership gets blurred. And teams end up assuming someone else is covering risks that are, in reality, still theirs to manage.
That is one of the most telling findings in Secure by Design: The New Blueprint for Cloud Migration, our joint report with AWS and SentinelOne. The research found that 77% of respondents believe their public cloud provider is responsible for securing all aspects of their environment.
That is exactly where problems begin.
The AWS shared responsibility model explains which parts of security AWS manages and which parts remain the customer’s responsibility.
In simple terms, AWS is responsible for the security of the cloud. Customers are responsible for security in the cloud.
That distinction matters. AWS secures the infrastructure that runs its services, including the physical facilities, hardware, networking foundations and core platform services. But once an organisation starts building and running workloads in AWS, it still owns a large part of the security and governance model around them.
That includes how access is managed, how data is protected, how environments are configured, and how risks are monitored and controlled over time.
Because misunderstanding it leads to real operational risk.
When teams assume AWS is securing everything, they are more likely to leave critical areas under-owned. Identity becomes inconsistent. Logging is incomplete. Permissions are too broad. Compliance evidence is harder to produce. And when something goes wrong, it is not always clear who is meant to respond.
This is one of the reasons cloud migration programmes slow down after the initial move. The platform may be in place, but the operating model behind it is still unclear.
Shared responsibility is not just a technical definition. It shapes how organisations assign ownership, design controls and run cloud environments securely at scale.
AWS secures the underlying cloud infrastructure.
That means AWS is responsible for the physical data centres, the core networking, the hardware, and the foundational software that supports AWS services. This is one of the major advantages of cloud adoption. Organisations do not need to build and protect that infrastructure themselves.
But that does not mean responsibility ends there.
AWS gives customers a secure foundation. It does not remove the need for customers to design, govern and operate their own environments properly.
Customers still own a significant part of security and governance in AWS.
They are responsible for how identities are created and controlled, how permissions are granted, how workloads are configured, how data is protected, and how monitoring, alerting and compliance controls are applied.
The exact line depends on the AWS services being used. For example, responsibility looks different in a fully managed service than it does in a more infrastructure-heavy environment. But the principle stays the same: moving to AWS does not mean handing over all responsibility for security.
The customer still owns the way the environment is designed and run.
Because cloud adoption often moves faster than cloud maturity.
Many organisations start using AWS before they have fully defined who owns identity, logging, compliance, workload protection and operational security across the estate. Early on, those gaps may not be obvious. But as environments grow, teams multiply and workloads spread across more accounts and services, those unclear boundaries become harder to manage.
That is when shared responsibility stops being a theory problem and becomes an operating problem.
The issue is often made worse by the number of teams involved. Platform teams, security teams, infrastructure teams, application owners and partners may all own part of the picture. Without a clear internal model, responsibility becomes fragmented. And when responsibility is fragmented, risk tends to hide in the gaps.
It affects almost every major decision.
During migration, organisations are making choices about identity, access, account structure, logging, network design, compliance controls and workload protection. None of those decisions work well if internal ownership is vague.
If teams assume AWS is covering more than it actually is, important decisions get delayed. Control patterns become inconsistent. Security gets introduced too late. And once workloads go live, rework becomes far more expensive.
This is why the shared responsibility model matters so much during migration. It is not background information. It is part of the foundation.
Usually in identity and access.
AWS provides powerful identity and access capabilities, but organisations still need to decide who gets access, how privilege is controlled, how roles are structured, and how access is monitored and reviewed over time.
If those decisions are weak, security quickly becomes hard to govern.
Identity is often the clearest example of customer responsibility in action. AWS provides the tools. The customer still has to apply the discipline.
Because compliance depends on clear ownership.
If an organisation cannot clearly explain who owns access control, data protection, logging, retention and remediation, it becomes much harder to prove that the environment is being governed properly.
This is where shared responsibility and compliance come together. If responsibility is unclear, compliance becomes slower, more reactive and more fragile. Audit questions take longer to answer. Gaps stay open longer. Confidence in the operating model starts to weaken.
In other words, unclear ownership is not just a security issue. It is a governance issue too.
A good internal responsibility model takes the AWS principle and turns it into something practical.
It should make it clear who owns identity, who owns logging and monitoring, who owns network governance, who owns data protection, and who is responsible for remediation when issues are found.
The most important word here is clarity.
The AWS shared responsibility model only works properly when an organisation has a clear internal view of its own responsibilities too. Otherwise there are two layers of ambiguity: one between AWS and the customer, and another inside the customer’s own teams.
That is where cloud security becomes messy.
The first step is to stop assuming everyone already understands the model.
From there, organisations need to define ownership more clearly, especially across platform, security and application teams. That ownership then needs to be reflected in how the environment is designed, not just written down in governance documents.
This is why a well-designed AWS landing zone matters. It helps turn responsibilities into working patterns, with clearer guardrails, more consistent controls and better visibility from the start.
It is also why identity should be treated as a priority, not an afterthought. In many AWS environments, identity is where weak ownership becomes visible first.
Finally, responsibility should be reviewed as the estate grows. What works for a small first-wave cloud footprint often does not scale cleanly as more teams, accounts and services are added.
The AWS shared responsibility model is not a technical detail. It is one of the foundations of secure cloud migration and long-term cloud governance.
AWS provides a highly secure platform. But customers still own how their environments are configured, governed and protected. If that line is misunderstood, risk grows quickly. If it is clear, organisations are far better placed to scale AWS with confidence.
That is why shared responsibility should be treated as a design issue, not just a training issue.
Want the full picture behind these findings?
Download Secure by Design: The New Blueprint for Cloud Migration — our joint report with AWS and SentinelOne — to explore the research behind today’s cloud migration challenges, based on insights from 300 UK IT and security leaders.
Download it here.
The AWS shared responsibility model explains which security responsibilities belong to AWS and which remain with the customer. AWS secures the infrastructure of the cloud, while customers are responsible for how they configure and manage what they run in the cloud.
No. AWS secures the underlying cloud infrastructure, but customers still own important areas such as identity, data protection, configuration, monitoring and many compliance controls.
It creates risk because teams may assume AWS is covering controls that are actually still the customer’s responsibility. That can lead to gaps in ownership, weaker governance and inconsistent security.
Customers own the way their AWS environment is configured and governed. That typically includes identity and access, workload settings, data protection, monitoring, logging and compliance controls.
If you want to reduce ambiguity in your AWS environment, Cloud Bridge can help you define a clearer operating model for security, governance and ownership — so your migration strategy is built on stronger foundations. Contact us today.