> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tuning Examples

> Read target-native tuning paths without confusing them with availability or performance guarantees.

These examples show how the same tag mechanism expresses different target fields. They are fragments of origin API requests, not complete requests.

<Note>
  Tuning fields are service-specific. Use a field only for the exact mapping shown on this page; a field shown for DynamoDB or EKS does not automatically apply to another service.
</Note>

## DynamoDB to provisioned Azure Cosmos DB

The [provisioned Cosmos DB mapping](/cloud-adapter/service-catalog/aws/databases-storage/dynamodb-table#azure-cosmos-db-provisioned) needs a capacity choice for each table container. Send the backend selector and the container size together through the DynamoDB `CreateTable` request's tags:

```json theme={null}
{
  "TableName": "orders",
  "BillingMode": "PAY_PER_REQUEST",
  "Tags": [
    {
      "Key": "t9:backend",
      "Value": "azure::1.0.0::cosmosdb::provisioned"
    },
    {
      "Key": "t9:tuning:container.properties.options.autoscaleSettings.maxThroughput",
      "Value": "40000"
    }
  ]
}
```

`t9:backend` selects the provisioned Cosmos DB mapping. The tuning tag sets the target container's `properties.options.autoscaleSettings.maxThroughput` field, giving `orders` a dedicated autoscale band with a maximum of 40,000 RU/s. These directives do not change the request's DynamoDB billing mode.

Choose a maximum supported by Cosmos DB in the target region. The value must be at least 1,000 RU/s and use 1,000-RU/s increments. Treat 40,000 RU/s as an example, not a recommendation. Verify the effective autoscale maximum on the resulting Cosmos DB container, then measure consumed RUs, throttling, latency and cost under a representative workload.

## EKS node group to a GKE node pool

For the EKS control-plane mapping to GKE, `t9:tuning:config.machineType` selects the GKE node pool's machine type through the `CreateNodegroup` request's tag map:

```json theme={null}
{
  "t9:tuning:config.machineType": "n2d-standard-4"
}
```

This overrides the target machine choice. It does not rewrite the origin request's `instanceTypes`: the origin description preserves what the application requested while the target node pool uses the explicit override. Verify the node pool's effective configuration rather than inferring it from the origin instance-type name.

Check that the target machine type is available and suitable for your region and workload. Selecting a type does not establish quota, capacity, performance or a cost improvement. Compare the same workload against the default mapping, including scheduling requirements and error rates. This example does not promise that an existing node pool can be retuned without replacement.

## Translate the method, not the tag

The general method carries across services: choose a supported target field, send it through the origin operation's supported tag carrier, and inspect the resulting target state. The literal tag does not carry across services unless the selected mapping explicitly supports it.

For a performance-related field, add a repeatable workload and measurements. Do not substitute a descriptive metadata example for a latency, scaling or cost benchmark.

Return to [tuning your adapters](/cloud-adapter/tuning/overview) for defaults, scope, acknowledgements and the measurement workflow.