Known Limitations

kumolo aims for high fidelity, but some behaviors differ from real AWS by design or as a known gap.

DynamoDB

ConsumedCapacity values are not computed

ReturnConsumedCapacity is fully supported and ConsumedCapacity is included in responses when set to TOTAL or INDEXES. However, kumolo always returns CapacityUnits: 1.0 — actual RCU/WCU are not calculated.

Number precision is limited to float64

DynamoDB number attributes are internally stored and compared using float64. Values with more than 15 significant digits may not sort or compare correctly. Real AWS DynamoDB uses arbitrary-precision decimal arithmetic.

KMS

Grant-based access control is not enforced

CreateGrant, ListGrants, RevokeGrant, RetireGrant, and ListRetirableGrants are fully implemented. However, kumolo does not restrict KMS operations based on a grant’s Operations list or Constraints — all operations succeed regardless of whether a grant authorises them.

Automatic key rotation does not run on a schedule

EnableKeyRotation stores the rotation configuration and GetKeyRotationStatus returns it correctly. However, kumolo does not rotate keys automatically at the configured interval. Use RotateKeyOnDemand to trigger a rotation in tests.

S3

Bucket Policy is not enforced

PutBucketPolicy, GetBucketPolicy, and DeleteBucketPolicy succeed and persist the configuration. However, kumolo does not evaluate the stored policy on subsequent requests — all requests are permitted regardless of the policy content.

ACL: individual grant headers are not supported

ACL is stored and enforced on object reads. However, PutObjectAcl does not support individual grant headers (e.g. x-amz-grant-read). Use the canned ACL or the XML request body form instead. The versionId query parameter on GetObjectAcl and PutObjectAcl is not supported.

SigV4 signatures are not verified

kumolo parses SigV4 headers and presigned URL parameters to extract request metadata (e.g., expiry time), but does not cryptographically verify the signature. Any non-empty aws_access_key_id / aws_secret_access_key pair is accepted. This is intentional for local development — you do not need to manage real credentials.

Presigned POST: policy conditions are not evaluated

For browser-based uploads via POST Object, kumolo stores and returns the POST policy but does not evaluate its conditions (content-length-range, key prefix constraints, expiration, etc.). Any conforming form submission is accepted regardless of policy content.

Replication: same-instance only

PutBucketReplication is accepted and replication runs synchronously within the same kumolo instance. Cross-instance and real-AWS destinations are not supported.

Logging: one log object per request

Access logs are written to the target bucket, but each request produces exactly one log object. Real AWS batches multiple access log records into a single file. Fields not tracked by kumolo (bucket-owner, request-id, object-size, etc.) are emitted as -.

STS

AssumeRole does not simulate distinct roles

AssumeRole always returns the same fixed credentials regardless of the RoleArn specified in the request. If your code relies on different roles returning different permissions or identities, kumolo cannot simulate that behavior.