Skip to main content
Tuning lets an origin request supply a backend-specific choice that the origin API does not otherwise express. The shared mechanism uses tags named t9:tuning:<path>, where <path> identifies a supported field in the target API. For example, a supported tuning field might change a target resource’s display name. Other fields can affect runtime behavior. The accepted fields, values and update behavior depend on the service and backend; the prefix does not make every target field writable. The tuning examples are the authoritative list of tuning directives currently documented here.
Tuning fields are service-specific. Use only a path published for the exact origin-to-target mapping in the examples.

​
Supply tuning through the origin API

Use the tag carrier supported by the origin operation, such as a create request’s tag map. The adapter interprets recognized tuning tags as target-field directives. A tag on resource creation is not automatically a per-request override for every later read or write. Likewise, changing a tag after creation only changes the backend if that service implements the corresponding update behavior. Do not assume a data-plane operation accepts tags because its service supports resource tagging elsewhere.

​
Decide whether to tune

Examples must stay mapping-specific. An S3-to-Cloud Storage mapping may publish a target storage-class choice; an SSM-to-Secret Manager mapping may publish a target replication field. Neither example authorizes the same tag on KMS or on a different direction. Use the exact path and value syntax documented in the example for the selected mapping. Target identity fields and fields managed by the adapter can be restricted. A field’s existence in the target cloud’s API is insufficient evidence that it can be tuned through the adapter.

​
Keep the directive types separate

Acknowledgements require an understanding of the named difference. They do not restore missing behavior. Each service decides which acknowledgement kinds and tokens it supports; do not copy a token from an unrelated service. t9:tuning:backend is not the backend selector. The selector is t9:backend.

​
Use a measured tuning loop

  1. Record the workload, adapter version, backend and current effective settings.
  2. Identify one supported field that addresses the observed behavior. Read its scope and constraints.
  3. Apply the change to test resources using the supported origin operation.
  4. Verify the resulting target setting and repeat the same workload.
  5. Compare the outcome and keep or reverse the change using the service’s supported update path.
Measure latency, throughput and error rates under comparable conditions. A configuration change alone does not prove a performance improvement. Cost comparisons also need workload volume and the target service’s applicable prices.

​
Use explain to understand a choice

The explain interface distinguishes the default adaptation from a tuning override and describes relevant limits. Confirm the result by inspecting the test resource’s effective target settings. An explanation of a mapping is different from evidence that a particular live request used it. Preserve relevant resource state and tag history when debugging a tuning issue.