A civic events app sees unpredictable traffic spikes, while a meter-reading API has steady, well-known load. How should DynamoDB capacity modes be chosen for cost?

Preferring DynamoDB on-demand for unpredictable civic traffic and provisioned capacity with auto scaling when load is steady and known—picking the cheaper fit for each pattern—is the correct capacity-mode strategy for a civic events app with spikes versus a meter-reading API with steady load. On-demand bills per request for spiky festival-like traffic; provisioned with auto scaling often wins when throughput is forecastable. Always using provisioned capacity with no auto scaling for both apps fails because the spiky events app will either throttle or require expensive permanent peak provisioning, and lack of auto scaling removes elasticity. Always using on-demand even when utilization is flat and predictable fails by potentially paying more than a well-tuned provisioned mode for steady meter APIs. Disabling DynamoDB and storing civic data only in instance store fails conceptually: instance store is ephemeral and unsuitable as a durable system of record for civic data. Exam caveat: match DynamoDB capacity mode to access-pattern predictability; do not force one mode everywhere or replace DynamoDB with instance store. Operational check: chart events-app versus meter-API request patterns; assign on-demand to spiky tables and provisioned+auto scaling to steady tables; compare cost after a billing cycle; and revisit modes seasonally as civic calendars change.