A destination defines where your audit logs are delivered once they've been collected and batched by a stream. It represents the storage location or endpoint that receives the log data. Each stream sends logs to a single configured destination. Once logs are delivered, you are responsible for managing access, storage, and downstream use of that data.

When configuring a destination, consider how logs will be secured, who needs access, and how they will be consumed by downstream systems.

Destination types

Logs supports the following destination types:

• Akamai Object Storage. This stream type delivers logs to an Object Storage bucket.
• Custom HTTPS endpoint. This stream type deliver logs to an external service over HTTPS, such as a log ingestion service or a webhook endpoint.

All destinations include the following settings:

• Type. The type of destination, such as Akamai Object Storage or Custom HTTPS.

• Name. A unique name for the destination. Creation fails if the name already exists.

Object Storage destinations

If you're configuring delivery to an Object Storage destination, ensure that:

• An Object Storage bucket exists where logs can be delivered
• The bucket is accessible from the log delivery service
• You've generated access keys with write permissions
• You can write to the bucket using those credentials
• You've configured any required bucket settings, such as lifecycle policies or Object Lock, in accordance with your organization's requirements for security, retention, and access control

For guidance on securing Object Storage destinations, see Protect logs in Object Storage.

Object Storage settings

Object Storage destinations include the following additional settings:

• Endpoint. The Object Storage service endpoint associated with your bucket's region.

• Bucket. The name of the Object Storage bucket that receives log data.

• Path. The prefix used to organize log files within the bucket.

• Access key ID. The access key used for authentication.

• Secret access key. The confidential security credential used with the access key ID.

Custom HTTPS destinations

If you're configuring delivery to a custom HTTPS destination, ensure that:

• You have a valid HTTPS endpoint that can receive log data
• The endpoint is accessible from the log delivery service
• You're configured any required authentication method, such as headers or certificates

Custom HTTPs settings

Custom HTTPS destinations include the following additional settings:

• Endpoint: The HTTPS URL that receives log data.
• Authentication type. The authentication method used for requests: None, which requires no authentication, or Basic, which requires a username and password.

Additional options include:

• Content type. The value of the Content-Type header included with each request. It defines the format and character encoding of the delivered log data.
• Custom HTTPS Headers. Optional headers included with each request, each defined by a name and value.
• TLS hostname. The hostname used to verify that the service certificate matches the expected identity. If not provided, the hostname is derived from the endpoint URL.
• CA certificate. The certificate authority (CA) used to verify the origin server's certificate. Provide the certificate in PEM format if the endpoint uses a non-standard or private certificate authority.
• Client certificate. The certificate used to authenticate requests to the destination. Provide the certificate in PEM format.
• Client key. The private used with the client certificate. Provide the key in PKCS#8 format.

📘

TLS certificate requirements and dependencies

TLS certificate fields are optional, but may be required depending on your endpoint configuration. These fields are interdependent. For example, if you provide a client certificate, you must also provide the corresponding client key. A CA certificate may also be required if the endpoint uses a private certificate authority.

Destination versions

Each time you create or update a destination, a new version is generated. For example, updating bucket details, authentication settings, or endpoint configuration creates a new version.

Versioning provides visibility and traceability for long-lived or frequently updated destinations.

Versioning behaves as follows:

• Previous versions are retained.
• The version with the highest version number is the active version.
• You can retrieve a destination's version history to review past configurations and understand how the destination has changed over time.