Shared responsibility model for abstract services

The final model we will look at is the abstract shared responsibility model, shown here:

Right away, from a visual perspective, we can see that the shift in responsibility leans even greater toward AWS.

This model retains the level of security AWS has to manage from both the previous two models (infrastructure and container), with the addition of server-side encryption and network traffic protection. Example AWS services that fall within this model are the Amazon Simple Queue Service (SQS), Amazon DynamoDB, and Amazon S3.

These are defined as abstract services as almost all the control and management of the service has been abstracted away from the end customer; we simply access these services through endpoints. Customers do not have access to the underlying operating system (infrastructure) or to the actual platform that is running these services (container); instead, the customer is presented with the service frontend or endpoint to configure as required.

As a result, the customer has been totally abstracted away from having to maintain security updates for the operating system or any platform patches and security management. This also means that AWS now has the responsibility to implement and control any server-side encryption options, such as Amazon S3 Server-Side Encryption (S3-SSE), where the customer has no control over the access keys used for this encryption method; it's all managed by AWS.

Also, AWS will manage the secure transfer of data between the service components—for example, when S3 automatically copies customer data to multiple endpoints across different Availability Zones. As a customer, we have no control over how this data is transferred, and so the traffic has to be secured by AWS.