Responsibility domain shift
Building on the foundational understanding of the AWS shared responsibility model discussed in Chapter 1; it is crucial to delve deeper into how this model evolves when we transition from monolithic architectures to microservices-based systems. The shift is not merely a technical one; it also involves a significant alteration in the responsibility domain, particularly when these microservices are deployed in cloud environments such as AWS.
Shift in computing models
As we touched upon in Chapter 1, different AWS compute services, such as EC2, Fargate, and Lambda, come with varying levels of responsibility for the customer. In traditional EC2-based monolithic applications, you manage everything from the guest OS upwards. However, with microservices often leveraging managed services, such as Fargate or Lambda, the responsibility shifts more towards AWS. This aligns with the trend we noted earlier: modern applications based on microservices are increasingly using managed cloud-native services due to their agility and ease of use, thereby shifting more responsibility toward the cloud service provider (CSP).
Rethinking access control
Traditional monolithic applications often rely on network-level security controls such as firewalls. However, in a microservices environment running on cloud-native platforms, you lose some of this network-level control. This necessitates a change in how access control is implemented.
Instead of relying solely on network-level security mechanisms, you need to adopt a more granular approach to access control. This involves assigning well-defined roles and policies to different resources and services within your microservices architecture. For example, you might use IAM to define who can access specific services down to the method level in an API. This is crucial because, in a microservices environment, the services often need to communicate with each other, and each interaction is a potential security touchpoint.