Microservices on AWS
AWS Whitepaper

Auditing

Another challenge to address in microservices architectures with potentially hundreds of distributed services is to ensure visibility of user actions on all services and to be able to get a good overall view at an organizational level. To help enforce security policies, it is important to audit both resource access as well as activities leading to system changes. Changes must be tracked on the level of individual services and on the wider system across services. It is typical in microservices architectures that changes happen very often, which means that auditing change becomes even more important. In this section, we look at the key services and features within AWS that can help audit your microservices architecture.

Audit Trail

AWS CloudTrail is a useful tool for tracking change in microservices because it enables all API calls made on the AWS Cloud to be logged and passed to either CloudWatch Logs in near real time or to Amazon S3 within several minutes.

Note

CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. This includes those taken on the AWS Management Console, the AWS CLI, SDKs, and calls made directly to the AWS API.

All user actions and automated systems become searchable and can be analyzed for unexpected behavior, company policy violations, or debugging. Information recorded includes user/account information, a timestamp, the service that was called along with the action requested, the IP address of the caller, as well as request parameters and response elements.

CloudTrail allows the definition of multiple trails for the same account, which allows different stakeholders, such as security administrators, software developers, or IT auditors, to create and manage their own trail. If microservice teams have different AWS accounts, it is possible to aggregate trails into a single S3 bucket.

Storing CloudTrail log files in S3 buckets has a few advantages: trail data is stored durably, new files can trigger an SNS notification or start a Lambda function to parse the log file, and data can be automatically archived into Amazon Glacier via lifecycle policies. In addition (and as described earlier in the performance monitoring section), services like Amazon EMR or Amazon Redshift can be leveraged to further analyze the data.

The advantages of storing the audit trails in CloudWatch are that trail data is generated in real time and rerouting information to Amazon ES for search and visualization becomes very easy. It is possible to configure CloudTrail to log into both Amazon S3 and CloudWatch Logs.

Events and Real-Time Actions

There are certain changes in systems architectures that must be responded to quickly, and an action to remediate must be performed, or specific governance procedures to authorize must be followed.

Note

CloudWatch Events delivers a near real-time stream of system events that describe changes in AWS resources. Declarative rules associate events of interest with automated actions to be taken.

The integration of CloudWatch Events with CloudTrail allows CloudWatch Events to generate events for all mutating API calls across all AWS services. It’s also possible to define custom events or generate events based on a fixed schedule.

When an event is fired and matches a rule that you defined in your system, the right people in your organization can be immediately notified. This allows them to take the appropriate action. Even better, it’s possible to automatically trigger built-in workflows or invoke a Lambda function.

The following figure shows a setup where CloudTrail and CloudWatch Events work together to address auditing and remediation requirements within a microservices architecture. All microservices are being tracked by CloudTrail and the audit trail is stored in an Amazon S3 bucket. CloudWatch Events sits on top of CloudTrail and triggers alerts when a specific change is made to your architecture.

Resource Inventory and Change Management

To maintain control over fast-changing infrastructure configurations in agile development teams, a more automated, managed approach to auditing and control of your architecture is beneficial.

Note

AWS Config is a fully managed service that provides you with an AWS resource inventory, configuration history, and configuration change notifications to enable security and governance. The AWS Config rules feature enables you to create rules that automatically check the configuration of AWS resources recorded by AWS Config.

While CloudTrail and CloudWatch Events track and respond to infrastructure changes across microservices, AWS Config rules allow a company to define security policies using specific rules and automatically detect, track, and alert violations to these policies.

In the example that follows, a developer team made a change to the API Gateway for his microservice to open up the endpoint to inbound HTTP traffic rather than allowing only HTTPS requests. Because this is a security compliance concern for the organization, an AWS Config rule is watching for this type of noncompliance, identifies the change as a security violation, and performs two actions: it creates a log of the detected change in an S3 bucket (for auditing) and creates an SNS notification.

Amazon SNS is used for two purposes in our scenario: 1) to send an email to a specified group to inform them about the security violation, and 2) to add a message into an SQS queue. The message is picked up from the SQS queue, and the compliant state is restored by changing the API Gateway configuration. This example demonstrates how it’s possible to detect, inform, and automatically react to noncompliant configuration changes within your microservices architecture.