What solution ensures the LEAST amount of downtime for the CloudTrail log deliveries?
Create an Amazon EventBridge rule for the CloudTrail StopLogging event. Create an AWS Lambda function that uses the AWS SDK to call StartLogging on the ARN of the resource in which StopLogging was called. Add the Lambda function ARN as a target to the EventBridge rule.
Deploy the AWS-managed CloudTrail-enabled AWS Config rule, set with a periodic interval of 1 hour. Create an Amazon EventBridge rule for AWS Config rules compliance change. Create an AWS Lambda function that uses the AWS SDK to call StartLogging on the ARN of the resource in which StopLogging was called. Add the Lambda function ARN as a target to the EventBridge rule.
Create an Amazon EventBridge rule for a scheduled event every 5 minutes. Create an AWS Lambda function that uses the AWS SDK to call StartLogging on a CloudTrail trail in the AWS account. Add the Lambda function ARN as a target to the EventBridge rule.
Launch a t2.nano instance with a script running every 5 minutes that uses the AWS SDK to query CloudTrail in the current account. If the CloudTrail trail is disabled, have the script re-enable the trail.
Explanations:
This option uses an Amazon EventBridge rule to respond immediately to the StopLogging event for CloudTrail. When the event is detected, it triggers a Lambda function that calls StartLogging, enabling quick remediation with minimal downtime since it reacts to the event in real-time.
Although this option utilizes AWS Config to check compliance and can trigger a Lambda function, the periodic interval of 1 hour introduces potential delays in remediation. This means CloudTrail could remain off for up to an hour, leading to more downtime compared to an event-driven approach.
This option schedules a Lambda function to check the CloudTrail status every 5 minutes. However, it lacks the immediate response capability of option A, meaning there could still be a window of time (up to 5 minutes) when CloudTrail remains off. This could lead to increased risk and downtime.
Launching a t2.nano instance to run a script every 5 minutes is less efficient and introduces additional overhead and cost. The instance could take time to start if not running, and the periodic check adds unnecessary delay in remediation. The potential for downtime remains high compared to an event-driven solution.