# DynamoDB Pricing Guide: Costs and Tips (2026) By Marielos Chévez · 2026-11-05 · Source: https://www.activepieces.com/blog/dynamodb-pricing-guide-costs-and-tips-2026 --- On DynamoDB you pay per request or per provisioned capacity unit, plus storage by the gigabyte-month, with an always-free allowance on top. There's no plan to pick, so the invoice is whatever your tables did that month, even when that activity comes from a background workflow, such as one built in [Activepieces](https://www.activepieces.com), writing items while nobody is watching. DynamoDB pricing is the usage-based billing model for Amazon's managed NoSQL database, in which you are charged for the reads and writes your tables perform (on-demand or provisioned capacity), the data they store, and optional features such as backups, replication and streams. **If you bill clients, that matters: in a shared AWS account, one client's chatty table is quietly paid for by everyone else unless you tag tables per client.** Treat the four meters below as a checklist, because any meter you can't estimate is where the surprise will come from. ## DynamoDB metered pricing, no plans They're request units for reads and writes, provisioned capacity hours, GB-months stored, and side fees for backup, transfer and streams, with the always-free allowance netted off first. Alone, each meter's small. The cost comes from how they combine, and the parts below take them in turn. ### The two capacity modes in one paragraph If a table sits idle, on-demand mode costs almost nothing on the request meter, because it charges for each request you actually make, but each request costs more. Provisioned mode charges by the hour for read and write throughput you reserve, used or not, and is cheaper per request when load is steady. Pick on-demand when traffic's spiky or unknown, such as an hourly job writing a few records. Pick provisioned when you can forecast load, because reserved capacity you don't use is still on the invoice. ![Mostly empty reserved parking bays, one van waiting outside](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/707bff2b-828a-41bf-8c87-e738e0721834/dynamodb-pricing-guide-costs-and-tips-2026-illus-c8e3a496.webp) ### What's billed besides reads and writes Whether or not anyone reads the data, AWS charges for storage per gigabyte-month, so old records you never delete keep costing you. Backups, point-in-time recovery and restores each carry their own charge. Replicating across regions with global tables multiplies your write cost, and AWS charges transfer for data leaving it. Change streams add charges for reads from the stream. None of these show up in a "reads and writes" estimate, so a quote that leaves them out is too low. Because rates differ by region and change, check the AWS DynamoDB pricing page and the AWS developer documentation for current figures; this page was last checked on 5 November 2026. Confirm the current figures for your region on that pricing page before putting a number on a client invoice. ## Every DynamoDB rate in one table Only four on-demand request rates have a confirmed figure in the table, which lists every DynamoDB meter; take the rest from the AWS pricing page for your region before quoting a client. ![Storage unit of forgotten boxes with a running meter](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/f307bcbd-184b-411a-9d9f-0e4b23dd5729/dynamodb-pricing-guide-costs-and-tips-2026-illus-9113d305.webp) | Meter | Unit | Price | Free allowance | Catch | |---|---|---|---|---| | On-demand RRU / WRU | per million requests | Reads $0.125, writes $0.625 (Standard) | None | Writes cost five times reads | | Provisioned RCU / WCU | per unit-hour | Not quoted here | 25 each | You pay for idle capacity | | Standard and IA storage | per GB-month | Not quoted here | 25 GB | IA charges more per request | | Backups, PITR | per GB-month | Not quoted here | None | Grows with table size | | Global tables | per replicated write | Not quoted here | None | Every region bills writes again | | Streams, export | per read / per GB | Not quoted here | None | Billed outside table capacity | | Reserved | per unit, term | Not quoted here | None | Pays only for steady load | At [$0.125 per million requests](https://dynobase.dev/dynamodb-pricing-calculator/), on-demand Standard reads cost a read-heavy client at ten million reads a month about $1.25. Standard writes cost $0.625 per million, so the same volume of writes costs five times as much. Price the write path first. ![DynamoDB on-demand request prices by table class](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/66fe3ddc-fe86-4f61-aa81-7c7f934ff079/dynamodb-pricing-guide-costs-and-tips-2026-distr-2d57a149.svg "Source: Dynobase") ### Storage and table-class rates On a busy table, Infrequent Access (IA) is uneconomical: IA reads cost $0.155 per million, about 24% above Standard, which means this cost difference grows in proportion to volume on high-volume workloads. IA writes cost $0.78 per million, about 25% above. IA saves on storage, so it only pays for tables that are rarely touched; on a busy table the request premium cancels the saving. Tag and bill backups, point-in-time recovery, global tables, streams and export per table, because a shared account quietly subsidizes the client who enables them. They are separate meters, unquoted here. ## One monthly DynamoDB bill for a five-person team If you want per-table tagging to pay off, you need to know what each table should cost, and you can work that out in six steps before building anything. 1. State monthly reads, writes and average item size. 2. Round each item up: reads to 4 KB, writes to 1 KB. A 1.2 KB item costs two write units, so small overruns double the write bill. 3. Convert to units: one read unit per 4 KB, one write unit per 1 KB. 4. Subtract the free allowance, so a tiny table can price at zero. 5. Price on-demand, then provisioned with auto scaling. 6. Price Standard-IA last. It cuts storage cost but raises request cost, so it only helps tables that are mostly storage. viz type=stackrank title="Where an even read-write DynamoDB bill goes" unit="$ per month" source="LinkedIn (Raheja) - https://www.linkedin.com/pulse/amazon-dynamodb-pricing-explained-detailed-breakdown-examples-raheja-u9bbc"8.75) and reads ($6.25) combined." Writes: 31.25 Storage: 18.75 Reads: 6.25 ### On-demand versus provisioned, line by line Take a 100 GB table with heavy traffic, as in [Raheja's worked example](https://www.linkedin.com/pulse/amazon-dynamodb-pricing-explained-detailed-breakdown-examples-raheja-u9bbc). Writes cost $31.25 a month, so write volume is the line to defend first. Storage costs $18.75, a fixed charge that accrues even if traffic stops. Reads cost $6.25, a fifth of the write charge, so read tuning saves little here. The three lines total $56.25, and nearly 90% of that's writes plus storage, so these two categories are where optimization efforts should concentrate. Run steps 5 and 6 against those lines. Provisioned capacity beats on-demand only when traffic's steady enough to keep reserved units busy. ### What the bill does when access pattern or traffic shifts Same data volume, two different bills. A read-heavy client gets a bill that grows with traffic, while a write-heavy client's bill grows with every update. That is the reversal, and it matters for billing: if both share one account without tags, the quieter workload subsidizes the louder one. What follows is the list of side fees that can still move either estimate. ## Fees and limits that change a DynamoDB bill Seven things move a DynamoDB bill beyond the headline rates: request-size rounding, transactional reads, index writes, cross-region transfer, global table replication, point-in-time backups and the 400 KB item cap. The subsections that follow take them in order. ### Request-size rounding and read consistency $19,425 a month goes to reads in [BoulderKV's analysis](https://boulderkv.com/blog/dynamodb-cost-analysis/), against $3,840 for storage and $972 for writes. Reads are about four-fifths of that bill, so a client with a read-heavy table is where a shared account's cost concentrates. ![Where the money goes in a read-heavy DynamoDB workload](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/d546008f-2330-4bb4-931a-344388843d99/dynamodb-pricing-guide-costs-and-tips-2026-picto-6b68e574.svg "Source: BoulderKV") Because reads round up to 4 KB and writes to 1 KB, **a 4.1 KB item costs two read units** and a 1.1 KB item costs two write units. Transactional reads cost 2 RRU each, double a strongly consistent read, so price any client using transactions at twice the read rate. ### DynamoDB index, replica and transfer costs With three secondary indexes, **a table bills the write four times**, since each base-table write also writes to every index. Global table replication also bills a write in every added region, and AWS charges cross-region transfer on top. Data transfer was only $150 a month in the BoulderKV example, which is small beside reads, but it grows with each region you add, so you cannot ignore this line item if you deploy globally. On a 1 TB table, point-in-time recovery at $0.20 per GB-month adds about $200 a month for restore protection alone, representing $2,400 in annual costs at this table size, a recurring expense you will incur for the lifetime of the table, so you're paying for this protection whether or not you ever need to use it. Put that on the client's line, not the shared overhead. ### Throttling, item limits and support tiers **Past 400 KB, an item hits the cap**. Anything larger has to be split or moved to S3, which means extra requests and extra engineering time you should quote for. Throttling does not add a fee, but a throttled provisioned table forces you to raise capacity, and you pay for the new level around the clock. Support-tier charges are billed at the account level, so in a shared account they land on whoever holds the invoice unless you allocate them. ## DynamoDB against Aurora Serverless, Firestore and Cosmos DB When your traffic is key-based lookups that spike or sit idle, DynamoDB can be a good fit, but it loses when queries are relational or scans are heavy. Support fees land on the invoice holder, and so does this choice, because each engine bills a different unit. ### DynamoDB comparison table across five pricing dimensions No two rows in the table bill the same thing, so the same traffic produces five different invoices. It shows what each service meters and what drives the example-workload cost. No prices are filled in because none were confirmed for this draft. | Service | Unit billed | Free allowance | Example-workload cost driver | Storage price | Egress/replication | Spike behaviour | Check date | |---|---|---|---|---|---|---|---| | DynamoDB | Read and write requests, or provisioned capacity | Confirm on the page | Request count and item size | Per GB-month | Cross-region replication adds write charges | On-demand absorbs it, at a premium per request | Pull from the vendor's pricing page on the day you estimate | | Aurora Serverless | Capacity units while running | Confirm on the page | Hours running and peak capacity | Per GB-month, plus I/O | Replicas and transfer billed separately | Scales within a set range | Same | | Firestore | Document reads, writes, deletes | Confirm on the page | Documents touched per screen | Per GB-month | Network egress billed | Scales automatically, cost scales with it | Same | | Cosmos DB | Request units | Confirm on the page | Request-unit cost per operation | Per GB-month | Each added region multiplies cost | Throttles if provisioned too low | Same | | MongoDB Atlas | Cluster tier per hour | Confirm on the page | Tier you need at peak | Tied to tier | Cross-region and transfer billed | You resize the tier | Same | A number from a blog post isn't an invoice, so each row's check date has to come from that vendor's own pricing page. If you pay only for requests you make, DynamoDB wins: an internal tool used in office hours, or a client portal with a quiet night. You're not funding idle capacity, and a busy client can be metered separately instead of being carried by a quiet one. When the team needs joins and ad hoc reporting, Aurora Serverless is simpler, since DynamoDB makes you design for each access pattern up front. Atlas or Firestore can cost less in engineering time if the team already knows them. Cosmos DB suits a stack already committed to Azure. Cheapest on paper isn't cheapest to run. ## Watching DynamoDB spend with Activepieces As a monitor only, Activepieces fits this problem. It can read your DynamoDB spend on a schedule and tell you when it drifts, and a daily check is about 30 runs a month, one credit each however many steps, against the 1,000 credits a month on the free plan, so you barely dent your free tier. It can't change what you're billed. Once you've estimated the bill, that drift alert is how you find out the estimate was wrong. ### What the workflow reads and where it posts Activepieces has 747 integrations in its open source monorepo, and what you'd build here is a canvas of steps joined by vertical lines: one trigger, a condition, then branches into Slack and email, which means you need only a small fraction of what's available. ![AI Agent Development: What It Takes to Build Agentic Systems](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/036e8332-042b-431c-916f-17ebc1684dbb/building-your-first-wix-chat-automation-without-3bc3c7d3.webp) It's sold for lead routing, but the same canvas works for spend. Swap the trigger for a daily schedule, and the steps below it do the billing work. 1. A schedule trigger fires once a day. 2. An AWS step, or a plain HTTP call signed with credentials you supply, asks Cost Explorer for yesterday's DynamoDB cost, filtered to that one service. 3. A condition compares the figure to a threshold you set from your own estimate. 4. One branch posts the daily number to a Slack channel; the other sends an email when the threshold is crossed. If you run DynamoDB for several clients in one account, the filter matters most. Group by a cost allocation tag and the same workflow posts one line per client. That's where a shared table quietly subsidizes the heaviest user, and a daily per-tag figure shows it before the invoice does. Be clear about the limit. Cost Explorer data lags, so this is a next-day signal, not a live meter. And the workflow only reports. It won't throttle a runaway scan or switch your capacity mode. ### AWS Budgets as the native alternative Without a workflow tool, AWS Budgets does the threshold part. You set a cost budget scoped to DynamoDB, attach alert levels for actual and forecast spend, and have notifications go to email or an SNS topic. There's nothing to host and no third-party credentials to hand over. So the choice is simple. If an email or an SNS alert at a threshold is all you need, use Budgets. Reach for Activepieces when you want a daily figure in a channel the team already reads, per-client lines, or a message formatted for someone who'll never open the AWS console. The credentials worry can be settled by reading code: the core is MIT-licensed, so you can clone the repository and trace the queue and worker path that would hold your Cost Explorer keys, then run it self-hosted or fully air-gapped before it touches an AWS credential. MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production. ## A Monday checklist for pricing your DynamoDB workload Six steps get you from a vague worry to a bill estimate you can defend on a client invoice. Each one turns a meter into a line someone else can read. 1. Measure request counts and item sizes per table. 2. Pick a capacity mode: on-demand or provisioned. 3. Set a Budgets alert on the account. 4. Run the AWS pricing calculator with your measured numbers. 5. Check table class for large tables that are rarely read. 6. Re-check current pricing before you commit to reserved capacity. ### Measure before you choose a mode Because the mode's only a guess until you know your traffic, steps one and two belong together. Pull read and write counts from CloudWatch for each table, and note how big your typical item is, since item size decides how many capacity units one request consumes. If traffic is spiky or unpredictable, that points toward on-demand. A steady, flat pattern is where provisioned capacity can cost less, so a chosen mode means nothing if you picked it before you saw the shape of the load. Do this per table, not per account. In a shared account, one busy client's table quietly raises the average and the quiet clients end up subsidizing it. Tag each table by client so the cost can be split honestly later. ![Equal bill split between a huge platter and a small salad](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/028a8933-9576-40aa-bd43-5aa0da5cf9bd/dynamodb-pricing-guide-costs-and-tips-2026-illus-1357f2e8.webp) ### Set alerts and review in 30 days Set the Budgets alert now, before the first real bill, and point it at the tags you just applied so overruns show up under the right client. Then run the calculator with measured inputs rather than guesses, and keep the output as your baseline. Check table class only for the large tables that are rarely read, since storage is where those tables spend their money. Hold off on reserved capacity until you have a month of real usage and have confirmed the current rates on AWS's pricing page. Committing early locks in an estimate, not a measurement. After 30 days, compare the baseline to the actual bill, and adjust the mode or the invoice line where they disagree, by which point a full month's data will reveal if your assumptions were correct, so incorrect assumptions will go undetected for a full month. ## Frequently asked questions Four questions come up at that 30-day review. AWS answers each one in its own documentation, so the table below gives the short answer and where to check it before you put a line on a client invoice. | Question | Short answer | AWS docs source | |---|---|---| | Free tier | A monthly allowance exists, but it's per account, not per project | DynamoDB pricing page | | Local DynamoDB | Runs on your machine at no charge and doesn't reproduce real throttling | Developer Guide, DynamoDB local | | Capacity-mode switching | Allowed, with a limit on how often a table can change | Developer Guide, read/write capacity mode | | Same-region transfer | No DynamoDB transfer charge from AWS services in the region, but the network path can bill | DynamoDB pricing page, data transfer | | Pre-launch estimates | Model item size and request rates, then price them | AWS Pricing Calculator and DynamoDB capacity guidance | Is DynamoDB free to use? Only up to an allowance. Because it applies to the whole account, every client sharing that account draws from one pool. Past that, one client's traffic quietly spends the others' free usage, so allocate it deliberately. Can I switch between on-demand and provisioned capacity? Yes, but not freely. AWS limits how often a table can change mode, so treat a switch as a planned change after reviewing the bill, not a daily tuning lever. Does DynamoDB charge for data transfer within the same region? Not for the DynamoDB side. The surprise comes from what sits in between: a NAT gateway or a cross-region replica adds its own fees. Those land on the shared account unless you tag and bill them to the client who caused them. How do I estimate DynamoDB cost before launching? Work backward from the invoice. Estimate average item size and reads and writes per second, price them in the AWS Pricing Calculator, and test the access pattern against DynamoDB local first. Local confirms your queries work, not what throttling will cost you. ## Related reading - [Is LiteLLM Enterprise Pricing Worth the Monthly Bill?](https://www.activepieces.com/blog/is-litellm-enterprise-pricing-worth-the-monthly-bill) - [Qdrant Pricing in 2026 and What a Real Bill Costs](https://www.activepieces.com/blog/qdrant-pricing-in-2026-and-what-a-real-bill-costs) - [Jira Pricing in 2026 and How to Work Out Your Bill](https://www.activepieces.com/blog/jira-pricing-in-2026-and-how-to-work-out-your-bill) ## References - [Dynobase](https://dynobase.dev/dynamodb-pricing-calculator/) - [LinkedIn (Raheja)](https://www.linkedin.com/pulse/amazon-dynamodb-pricing-explained-detailed-breakdown-examples-raheja-u9bbc) - [BoulderKV](https://boulderkv.com/blog/dynamodb-cost-analysis/)