Choose an experiment
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.
DynamoDB to provisioned Azure Cosmos DB
The provisioned Cosmos DB mapping needs a capacity choice for each table-owned container. ThisCreateTable fragment supplies the backend selector and capacity together; the complete example also includes the key schema and attribute definitions:
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.
SQS: fewer empty receives
For an existing test queue on a backend supporting long polling, set the default wait:AWS_ENDPOINT_URL_SQS to the adapter endpoint first, as shown in the SQS setup. That setup captures the created queue’s URL in SQS_TUNING_QUEUE_URL; it is a shell variable containing a command result, not an SDK configuration setting. Run these commands in the same shell. The receive request can override the queue’s default wait. Use a client read timeout longer than the wait, allowing for network overhead. A longer wait does not mean a message already available must wait for the entire interval.
Compare empty receives and completed work for the same arrival rate. Long polling can reduce polling overhead; it does not increase database capacity or change the queue’s delivery guarantee. Restore the previous queue attribute to reverse this change.
SQS: allow time for processing
For a PostgreSQL-backed test queue with jobs that may run for several minutes, use the endpoint and queue URL from the PostgreSQL setup. SetSQS_TUNING_QUEUE_URL to that queue’s returned URL before running these commands; do not reuse the Pub/Sub queue from the previous example:
DynamoDB: change a pool without overloading PostgreSQL
The DynamoDB PostgreSQL backend’s process setting is:4 × 2 × 12 = 96 pooled connections. A rollout with one additional process adds up to 24 more. Reserve connections for administration and other workloads before choosing the pool size.
Compare connection wait, query latency, locks and database CPU. If a larger pool just increases contention, revert the process setting and investigate the database or query workload. See DynamoDB on PostgreSQL for the full capacity example.
S3: compare transfer concurrency before changing storage
Use the bounded upload script in Tuning AWS S3. It compares one, four and eight workers, retains the test prefix for inspection, and verifies every object body after the measured upload phase. Keep payload size and retries fixed. More completed objects per second is useful only if errors, tail latency and resource usage stay within your application’s requirements. Run the test from the intended deployment location before using its numbers for production planning.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:
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.
For a complete CreateNodegroup request, put that map in its tags field alongside the normal cluster, node group, role and subnet arguments. Keep ordinary resource tags in the same map. Inspect the resulting GKE node pool and run representative pods before moving traffic; an origin DescribeNodegroup alone cannot prove which target machine type was selected.
See the EKS service profile for target-specific node group behavior. Do not copy config.machineType to AKS or another backend simply because that backend also has virtual machines.