Even when using Amazon Web Services (AWS), you can't entrust all security measures to AWS. AWS protects data centers, physical infrastructure, and virtualization platforms. On the other hand, you are responsible for managing your data, permissions, network, applications, logs, and backups in the cloud.
This framework for defining responsibilities is the AWS shared responsibility model. Without a proper understanding of it, you may overlook risks such as excessive IAM permissions, incorrect Amazon S3 public settings, insufficient log monitoring, and unverified backups.
This article explains the basics of the AWS shared responsibility model, the scope of responsibility for both AWS and the user, and the differences between services such as Amazon EC2, Amazon RDS, Amazon S3, and AWS Lambda. It also outlines the security measures that should be implemented in-house and the boundaries of responsibility that should be confirmed when outsourcing.
The AWS Shared Responsibility Model is a mechanism that separates the responsibilities of AWS and the user regarding the security of the AWS environment.
AWS protects the cloud infrastructure, and users manage their data, permissions, settings, applications, monitoring, and backups on AWS.
While using AWS reduces the management burden of infrastructure, it doesn't automatically guarantee security for cloud-based configuration and operation. The shared responsibility model requires you to decide how much to entrust to AWS and how much to manage in-house.
AWS protects the foundation for providing cloud services. This includes the physical protection of data centers, hardware, network equipment, and virtualization infrastructure.
Users are responsible for protecting the environment they build and operate on AWS. This includes managing permissions, data, network, OS/middleware, applications, logs, backups, and more.
For example, AWS manages the infrastructure for Amazon S3. However, the user is responsible for configuring bucket visibility, access permissions, and encrypting stored data. Incorrect configuration can lead to data breaches, even if the AWS infrastructure is secure.
AWS's shared responsibility model divides responsibility into "cloud security" and "security within the cloud."
"Cloud security" is an area of responsibility for AWS. This includes infrastructure, data centers, hardware, networks, and virtualization platforms.
"Security within the cloud" is an area where users are responsible. Users design and manage which services to use, what data to store, who to grant access to, and what extent to expose their data to the internet.
AWS and the user's responsibilities are divided by what they are managed. AWS manages the cloud infrastructure, while the user manages the data, permissions, settings, applications, and operations on AWS.
Classification | Scope of AWS responsibility | Scope of user responsibility |
physical environment | Data center, power supply, air conditioning, physical access control | In principle, no action is required. |
Infrastructure | Servers, storage, network equipment, virtualization infrastructure | Selection and configuration of services to be used |
OS and middleware | Host OS, managed services infrastructure | Amazon EC2 guest OS, middleware, and application management |
Data | Mechanisms that support the durability and availability of the underlying infrastructure. | Data classification, encryption, access control, backup design |
Access management | IAM and other feature provision | Designing IAM users, roles, policies, MFA, and least privilege. |
network | Protecting AWS Global Infrastructure | Amazon VPC, security groups, NACLs, and access scope settings. |
Monitoring and logging | Features such as AWS CloudTrail, Amazon CloudWatch, and Amazon GuardDuty are provided. | Log acquisition settings, alert design, and post-detection verification and response. |
Recovery Response | Infrastructure operation with disaster preparedness in mind | Backup acquisition, recovery procedure, restore verification |
AWS is responsible for the infrastructure that enables cloud services. This includes physical facilities, hardware, network equipment, virtualization infrastructure, and the foundational components of managed services.
Users do not need to directly manage these physical facilities or infrastructure. The burdens of server procurement, equipment maintenance, and data center management that previously occurred in on-premises environments are shifted to AWS.
However, even though AWS protects the infrastructure, it does not automatically manage the settings of user-created environments. The security of the infrastructure and the security of the user environment must be considered separately.
Users are responsible for the environment they build and operate on AWS. This includes data, permissions, network settings, applications, log monitoring, backups, and recovery verification.
It's especially important to note that misconfigurations can directly lead to security risks. Issues such as granting excessive permissions in IAM policies, opening unnecessary ports in security groups, or unintentionally exposing Amazon S3 buckets are the user's responsibility.
In AWS, the scope of user responsibility varies depending on the services used. The differences lie in who manages the OS, middleware, configuration, data, and code.
The more flexible a service is, like Amazon EC2, the wider the scope of management required from the user. On the other hand, using managed services like Amazon RDS or AWS Lambda allows you to delegate some of the infrastructure management to AWS. However, this doesn't mean you're completely free from configuration, data, and permission management.
Services | AWS's primary responsibility | Main responsibilities of the user | operational load |
Amazon EC2 | Physical infrastructure, network infrastructure, virtualization infrastructure | Guest OS, middleware, applications, patching, security groups, IAM | high |
Amazon RDS | Database infrastructure, host management, and managed functionality provision. | DB configuration, access control, encryption, backup settings, data management | moderate |
Amazon S3 | Storage infrastructure and mechanisms supporting durability | Bucket publishing settings, access permissions, encryption, lifecycle settings | Depending on the settings |
AWS Lambda | Execution platform, OS management, scaling platform | Check function code, IAM role, environment variables, dependent libraries, and logs. | The level is low, but design responsibility remains. |
Amazon EC2 is a service that allows you to flexibly build virtual servers. While it offers a high degree of freedom, it also expands the scope of responsibility for the user.
AWS manages physical servers and virtualization infrastructure, but users are responsible for managing guest operating systems, middleware, applications, and security patch application on Amazon EC2 instances. Security group configuration, IAM role assignment, log monitoring, and backup design are also managed by the user.
When using Amazon EC2, you need to consider the operation of the instance after it has been created. Neglecting OS updates or leaving unnecessary ports open will make the environment vulnerable, even if the AWS infrastructure is secure.
Amazon RDS is a managed service that reduces the operational burden of databases. AWS provides the necessary functions to support DB server infrastructure management, host maintenance, backups, and patching.
However, you can't entrust all database operations to AWS. You need to design things like the data to be stored, the connection source, encryption, and backup retention period.
In particular, incorrect settings regarding the scope of access and permissions can lead to unauthorized access and data breaches. While Amazon RDS reduces the burden of infrastructure management, the responsibility for data and configuration remains with the user.
Amazon S3 is a storage service that can store files, logs, backup data, and more. AWS manages the aspects that support the durability and availability of the storage infrastructure.
On the other hand, users configure the bucket's public access settings, access permissions, and encryption of stored data. Because Amazon S3 can be made publicly accessible depending on the settings, incorrect permission management can lead to unintended data disclosure.
Simply using a bucket as a storage location does not guarantee its safety. You need to check the combination of bucket policies, ACLs, public access blocks, and IAM policies to avoid unnecessary exposure.
AWS Lambda is a service that allows you to run code without managing servers. Because AWS handles much of the OS management, execution infrastructure, and scaling, the burden of infrastructure operation is reduced compared to Amazon EC2.
However, the user is responsible for addressing vulnerabilities in the function code, managing dependent libraries, granting IAM role permissions, handling environment variables, and checking logs. Granting excessive IAM permissions to an AWS Lambda function can allow it to access unintended AWS resources.
AWS Lambda reduces server management, but it's a service where code and permission design are crucial. You need to think of it as the focus of responsibility shifting from server management to application and permission management.
Even with an understanding of the shared responsibility model, in actual operation, we sometimes overestimate the scope of what we can entrust to AWS. This is especially true with managed services, backups, and outsourcing, where misunderstandings about the scope of responsibility are likely to occur.
Using AWS is a way to reduce the burden of infrastructure management, but it does not eliminate the need to manage accounts, permissions, networks, applications, and data.
Granting excessive permissions to IAM users or opening unnecessary ports in security groups increases the risk of unauthorized access. While using AWS reduces the burden of infrastructure management, it does not eliminate the responsibility for configuration and operation.
Managed services like Amazon RDS and AWS Lambda reduce the management burden of the OS and infrastructure. However, users are responsible for configuring access permissions, encryption, sharing scope, logging, and backup settings.
Misconfigurations such as allowing a wide range of connections to Amazon RDS or unintentionally exposing an Amazon S3 bucket are risks for the user, even when using managed services. Managed services are designed to reduce operational burden, not to eliminate configuration responsibility.
Even with backups in place, recovery isn't always guaranteed. If the backup targets, retention period, recovery procedures, permissions, and recovery time goals aren't clearly defined, you might be unable to restore operations in the event of a failure.
In a production environment, operations include not only whether backups are made, but also the restore procedure and verification of operation after recovery. Even when using AWS Backup or snapshots, the company decides which data to restore, how often, and to what extent.
Even if you outsource the construction and operation of AWS to an external partner, your company's management responsibilities do not disappear. You must clearly define the scope of work handled by the outsourcing partner and the scope of work that you, as a company, must decide, approve, and verify.
If the scope of monitoring targets, initial response in case of failure, backup recovery verification, approval of permission changes, and proposed security improvements remains unclear, responses to problems will be delayed. It is necessary to clarify not only the contract details but also who checks what as part of the daily operational flow.
AWS offers services to support each area. However, simply implementing these services is not enough. You need to define what needs to be protected, who will be responsible for verification, and the scope of response in case of anomalies, all within the operational framework.
In the AWS environment, users, roles, and policies are managed using IAM. The basic design principle is to limit permissions to only necessary operations and avoid granting broad administrator privileges.
Multi-factor authentication (MFA) should be set up for administrator accounts and users performing critical operations. If access keys are used, it is also necessary to delete unnecessary keys, conduct regular inventory checks, and monitor usage.
In access control, we not only check "who can do what," but also whether the permissions of former or transferred employees remain, and whether strong permissions intended for testing remain in the production environment.
Protect your data on AWS by organizing its storage location, importance, and access scope. For services like Amazon S3, Amazon RDS, and Amazon EBS, verify the encryption settings for your data at rest.
Furthermore, managing the scope of access is essential. Incorrect public access settings for Amazon S3 buckets, connection sources for Amazon RDS, and security group settings can lead to unintended external exposure.
Even with encryption, risks remain if access permissions are too broad. Data protection requires checking both encryption and access control together.
In an AWS environment, you can track who performed what action and when. AWS CloudTrail allows you to review records of API operations and management events.
Amazon GuardDuty can detect suspicious API operations, suspected misuse of credentials, and unusual communications. However, simply accumulating logs and detection results is not enough for it to function.
Unless you define who will review the report after an anomaly is detected, the escalation criteria, and the scope of initial response, you'll only end up with an increase in notifications and delayed responses.
Even if an AWS environment is configured securely during setup, its state can change due to modifications during operation. Adding permissions, network changes, and services can accumulate and deviate from the original design.
AWS Security Hub allows you to aggregate detection results from multiple security services. AWS Config lets you view the history of resource configuration changes and rule violations.
The key point to consider is not the number of detection results, but rather who reviews the high-severity issues and in what order they are addressed. Without continuously monitoring the configuration, risks will accumulate during operation.
Simply creating backups is not enough. You must also ensure that in the event of a failure or user error, you can restore the necessary data to the required point in time, within the required timeframe.
AWS Backup allows you to centrally manage backups for multiple AWS services. However, you design the backup targets, frequency, retention period, and recovery procedures yourself.
In a production environment, verifying the restore procedure is essential. Even if backups exist, if the necessary permissions and procedures for recovery are not clearly defined, the resumption of operations in the event of a failure will be delayed.
Once you've clarified the scope of responsibility, the next thing to check is whether your company has the infrastructure in place to continue operations internally.
If you cannot handle access control, monitoring, incident response, backup, recovery verification, and security improvements internally, outsourcing is an option. However, outsourcing is not a transfer of responsibilities without clear boundaries. You must clearly define the scope of work handled by the outsourcing company and the scope of work that your company will decide and verify.
If you choose to manage your AWS system in-house, you need a system in place to continuously handle AWS configuration changes and incident response. Simply having someone in charge is not enough; you need to ensure that you can handle permission changes, log checks, alert responses, backup checks, and vulnerability responses as part of your daily operations.
What's particularly important to observe is the response after an anomaly is detected. Even if notifications are received by Amazon CloudWatch or Amazon GuardDuty, they won't function effectively in a real-world environment unless the person responsible for reviewing the notification, the criteria for determining urgency, and the scope of recovery measures are clearly defined.
We will check whether there are people within the company who can make decisions regarding AWS design and operation, whether they can handle outages during nights and holidays, and whether there are procedures in place to hand over responsibilities without relying on specific individuals. If you continue to operate in-house without a sufficient system in place, problems such as overlooking notifications, neglecting permissions, and not having proper recovery procedures will accumulate.
When outsourcing, it's crucial to clarify the specific scope of services rather than simply using a broad phrase like "we'll handle AWS operations." The scope of support during an outage will vary significantly depending on whether it's just monitoring, includes initial response, or encompasses root cause investigation and recovery work.
Items to check | Things to check |
Monitoring range | Which resources, metrics, and logs should you monitor? |
Actions taken after notification | Should I just send a notification, or should I also perform initial troubleshooting? |
Troubleshooting | Scope of cause investigation, recovery work, and escalation |
backup | Target data, frequency, retention period, and notification upon failure. |
Recovery Confirmation | Does this include the restoration process and recovery testing? |
Security improvements | Should we just report the detection results, or should we also provide suggestions for improvement? |
Even if the contract appears to cover operational support, in reality, it may only extend to "notification" or "report submission." Unless you confirm the extent of support provided in the event of a problem, the scope of your company's response will only become clear after the issue occurs.
Even when outsourcing operations to an external partner, the company ultimately retains responsibility for understanding the situation. In particular, the company is responsible for determining the impact on business operations, the importance of the data, approving access permissions, prioritizing recovery, and defining acceptable security limits.
While the outsourcing partner can provide expertise in AWS operations, they cannot determine your company's business requirements or risk tolerance on your behalf. Decisions regarding which systems to prioritize for recovery, which data to strictly protect, and which permission changes to allow all involve the business's judgment.
To make outsourcing effective, it's necessary to clearly define the scope of work entrusted to the contractor and the scope of work that your company will handle. If the roles of monitoring, incident response, backup, and security improvement are not clearly defined, gaps in responsibility will occur.
In the AWS Shared Responsibility Model, AWS takes on the cloud infrastructure, while users manage data, permissions, settings, applications, monitoring, and backups on AWS. While this reduces the management burden of physical and virtualized infrastructure, it does not mean that AWS can handle the configuration and operation of your own environment.
The scope of responsibility varies depending on the service. With Amazon EC2, the user is responsible for managing the OS and middleware, while with Amazon RDS and AWS Lambda, the burden of infrastructure management is reduced, but users are still required to manage data, permissions, settings, and code.
For secure operation, a system that continuously manages access rights, protects data, monitors logs, verifies settings, and prepares for recovery is essential. Even when outsourcing, it is important to clearly define the scope of monitoring, incident response, recovery procedures, approval of access rights changes, and improvement suggestions, and to clarify the responsibilities that your company must understand.
