

# Logging and monitoring in AWS RAM
<a name="security-monitoring"></a>

Monitoring is an important part of maintaining the reliability, availability, and performance of AWS RAM and your AWS solutions. You should collect monitoring data from all parts of your AWS solution so that you can more easily debug a multi-point failure if one occurs. AWS provides several tools for monitoring your AWS RAM resources and responding to potential incidents:

**Amazon EventBridge**  
Delivers a near-real-time stream of system events that describe changes in AWS resources. EventBridge enables automated event-driven computing, as you can write rules that watch for certain events and trigger automated actions in other AWS services when these events happen. For more information, see [Monitoring AWS RAM using EventBridge](using-eventbridge.md).

**AWS CloudTrail**  
Captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see [Logging AWS RAM API calls with AWS CloudTrail](cloudtrail-logging.md).

# Monitoring AWS RAM using EventBridge
<a name="using-eventbridge"></a>

Using Amazon EventBridge, you can set up automatic notifications for specific events in AWS RAM. Events from AWS RAM are delivered to EventBridge in near-real time. You can configure EventBridge to monitor events and invoke targets in response to events that indicate changes to your resource shares. Changes to a resource share trigger events for both the owner of the resource share and the principals that were granted access to the resource share.

When you create an event pattern, the source is `aws.ram`.

**Note**  
Take care writing code that depends on these events. These events are not guaranteed, but are emitted on a best effort basis. If an error occurs when AWS RAM attempts to emit an event, the service tries several more times. However, it can time out and result in the loss of that specific event.

For more information, see the Amazon EventBridge User Guide.

## Example: Alerting on resource share failures
<a name="using-eventbridge-example-sharing"></a>

Consider the scenario where you want to share Amazon EC2 capacity reservations with other accounts in your organization. Doing this is a good way to reduce your costs.

However, if you don't meet all of the [prerequisites for sharing a capacity reservation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html#sharing-cr-prereq), then it can silently fail performing the asynchronous tasks involved in sharing resources. If the share operation fails, and your users in other accounts attempt to launch instances with one of those capacity reservations, then Amazon EC2 acts as if the capacity reservation was full and launches the instance as an on-demand instance instead. This can result in higher than expected costs.

To monitor for resource share failures, set up an Amazon EventBridge rule that alerts you whenever an AWS RAM resource share fails. The following tutorial procedure uses an Amazon Simple Notification Service (SNS) topic to notify all topic subscribers whenever EventBridge discovers a resource sharing failure. For more information about Amazon SNS, see the [Amazon Simple Notification Service Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/).

**To create a rule that notifies you when resource sharing fails**

1. Open the [Amazon EventBridge console](https://console.aws.amazon.com/events).

1. In the navigation pane, choose **Rules**, and then in the **Rules** list, choose **Create rule**.

1. Enter a name and optional description for your rule, then choose **Next**.

1. Scroll down to the **Event pattern** box, and choose **Custom patterns (JSON editor)**.

1. Copy and paste the following event pattern:

   ```
   {
     "source": ["aws.ram"],
     "detail-type": ["Resource Sharing State Change"],
     "detail": {
       "event": ["Resource Share Association"],
       "status": ["failed"]
     }
   }
   ```

1. Choose **Next**.

1. For **Target 1**, under **Target type**, choose **AWS service**.

1. Under **Select a target**, choose **SNS topic**.

1. For **Topic**, choose the SNS topic to which you want to publish the notification. This topic must already exist.

1. Choose **Next**, and then choose **Next** again to see to review your configuration.

1. When you're satisfied with your options, choose **Create rule**.

1. Back on the **Rules** page, ensure that your new rule is marked **Enabled**. If necessary, choose the radio button next to your rule name, and then choose **Enable**.

As long as that rule is enabled, any AWS RAM resource share that fails generates an SNS alert to the recipients of the topic you published to.

You can also confirm that shared capacity reservations are accessible to the accounts you shared them with by attempting to [view them in the Amazon EC2 console from those accounts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html#identifying-shared-cr).

# Logging AWS RAM API calls with AWS CloudTrail
<a name="cloudtrail-logging"></a>

AWS RAM is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in AWS RAM. CloudTrail captures all API calls for AWS RAM as events. The calls captured include calls from the AWS RAM console and code calls to the AWS RAM API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket that you specify, including events for AWS RAM. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Use the information collected by CloudTrail to determine the request that was made to AWS RAM, the requesting IP address, the requester, when it was made, and additional details.

For more information about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).

## AWS RAM information in CloudTrail
<a name="ram-info-in-cloudtrail"></a>

CloudTrail is enabled on your AWS account when you create the account. When activity occurs in AWS RAM, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).

For an ongoing record of events in your AWS account, including events for AWS RAM, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following:
+ [Creating a trail for your AWS account](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [AWS service integrations with CloudTrail logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receiving CloudTrail log files from multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)

All AWS RAM actions are logged by CloudTrail and are documented in the [AWS RAM API Reference](https://docs.aws.amazon.com/ram/latest/APIReference/). For example, calls to the `CreateResourceShare`, `AssociateResourceShare`, and `EnableSharingWithAwsOrganization` actions generate entries in the CloudTrail log files.

Every event or log entry contains information that helps you determine who made the request.
+ AWS account root credentials
+ Temporary security credentials from an AWS Identity and Access Management (IAM) role or federated user.
+ Long-term security credentials from an IAM user.
+ Another AWS service.

For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).

## Understanding AWS RAM log file entries
<a name="understanding-ram-entries"></a>

A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.

The following example shows a CloudTrail log entry for the `CreateResourceShare` action.

```
{
    "eventVersion": "1.05",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "NOPIOSFODNN7EXAMPLE",
        "arn": "arn:aws:iam::111122223333:user/admin",
        "accountId": "111122223333",
        "accessKeyId": "BCDIOSFODNN7EXAMPLE",
        "userName": "admin"
    },
    "eventTime": "2018-11-03T04:23:19Z",
    "eventSource": "ram.amazonaws.com",
    "eventName": "CreateResourceShare",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "192.0.1.0",
    "userAgent": "aws-cli/1.16.2 Python/2.7.10 Darwin/16.7.0 botocore/1.11.2",
    "requestParameters": {
        "name": "foo"
    },
    "responseElements": {
        "resourceShare": {
            "allowExternalPrincipals": true,
            "name": "foo",
            "owningAccountId": "111122223333",
            "resourceShareArn": "arn:aws:ram:us-east-1:111122223333:resource-share/EXAMPLE0-1234-abcd-1212-987656789098",
            "status": "ACTIVE"
        }
    },
    "requestID": "EXAMPLE0-abcd-1234-mnop-987654567876",
    "eventID": "EXAMPLE0-1234-abcd-hijk-543234565434",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "recipientAccountId": "111122223333"
}
```