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.

Logs supports two types of destinations: Akamai Object Storage buckets and Custom HTTPS endpoints.

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

Object Storage destinations

Configure an Akamai Object Storage destination if you want logs to be delivered to an Object Storage bucket.

Before configuring your 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.

An Object Storage destination requires the following:

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

• 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. The access key used for authentication.

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

Custom HTTPS destinations

Configure a Custom HTTPS destination if you want logs to be delivered to an external service over HTTPS, such as a log ingestion service or a webhood endpoint.

Before configuring your destination, ensure that:

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

A custom HTTPS destination requires the following:

• Destination name. A unique name for the destination. Creation fails if the name already exists.
• Endpoint URL: The HTTPS endpoint for audit log delivery.
• Authentication type. The authentication method used for requests sent to your HTTPS endpoint: None requires no authentication, while Basic, which requires a username and password.

Optionally, specify the following client certificate authentication settings:

• 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.
• TLS hostname. The hostname used to verify the server's certificate, which needs to match a Subject Alternative Name (SAN) in the certificate. If not provided, the hostname is derived from the endpoint URL.
• Client certificate. The client certificate used to authenticate requests to the HTTPS endpoint. Provide the certificate in PEM format.
• Client private key. The private key used with the client certificate. Provide the key in PKCS#8 format.
• CA certificate. The CA certificate used to verify the certificate presented by the HTTPS endpoint. If the certificate is not signed by a well-known certification authority, enter the CA certificate in the PEM 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.

Optionally, you can also add HTTPS headers. If you do so, you'll need to provide the name and value for each custom header.

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 use the API to retrieve a destination's version history to review past configurations and understand how the destination has changed over time.