how to cache AWS API calls in automation

TL;DR

AWS API calls in automation should be cached aggressively: most Describe and List results do not change second to second. Cache in memory for short-lived scripts, in a shared store for distributed automation, and set TTLs based on how fast the underlying resource actually changes. Throttling errors almost always mean you are re-fetching what you already know.

The query

how to cache AWS API calls in automation

Use this when

• Automation hits "rate exceeded" or throttling errors
• Scripts loop over resources calling Describe on each one
• Lambda functions fetch the same config on every invocation
• CI pipelines query AWS for state repeatedly

Not for when

• Caching application data for end users
• DynamoDB or S3 data-plane caching (different services, different rules)
• One-off CLI usage

Steps

Step 1: Find the repeated calls

Add logging or check CloudTrail for your automation's API calls. The pattern is always the same: the same Describe or List call, same parameters, many times per minute. Those are your cache candidates. Expected output: a short list of the most-called APIs with call counts. Usually two or three dominate.

Step 2: Cache in the cheapest layer that works

For a single script run, an in-memory dict with a TTL is enough. For Lambda, cache outside the handler so warm invocations reuse it. For distributed automation, use a shared cache like ElastiCache or DynamoDB with TTL attributes. Expected output: repeated identical calls within the TTL return cached data with zero API calls.

Step 3: Set TTLs from resource change rates, not guesses

VPC and subnet lookups can cache for hours. Instance state might need minutes. Auto-scaling group desired counts might need seconds during a deploy. Match the TTL to how stale you can tolerate, per resource type. Expected output: a TTL table per resource type, documented next to the cache code.

Step 4: Invalidate on write, not on timer alone

When your automation changes a resource, drop that resource's cache entry immediately instead of waiting for TTL expiry. Stale-after-write is the bug that makes people distrust caches and rip them out. Expected output: read-after-write inside the automation always sees fresh data.

Step 5: Add jitter and backoff anyway

Caching reduces calls but does not eliminate bursts (cold starts, cache stampedes). Keep exponential backoff with jitter on the API client so the calls you do make behave well under throttling. Expected output: throttling errors drop to near zero even during deploys and scaling events.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zn0nXF8O1RqtjNgJizU4Hg