Reducing API Gateway and DynamoDB Costs

TLDR;

• Move public REST APIs to HTTP API, saving roughly 71 percent on per-request charges versus REST API.
• Enable API Gateway caching at 0.5 GB tiers to cut DynamoDB reads for read-heavy endpoints by 40 to 70 percent.
• Pick on-demand or provisioned DynamoDB capacity based on traffic predictability, then add auto scaling above 70 percent utilisation.
• Apply TTL, sparse indexes, and single-table design to trim storage and GSI write cost.

API Gateway DynamoDB cost reduction is the discipline of matching each read and write to the cheapest configuration that still meets latency and durability targets.

For a typical SaaS running 100 million API calls a month against a 200 GB table, these two services can account for 40 to 60 percent of the total serverless bill. The good news is that AWS offers multiple tiers, pricing models, and caching layers that let you cut this line item in half without rewriting application code.

According to the API Gateway pricing page, HTTP APIs cost USD 1.00 per million requests in eu-west-1 while REST APIs cost USD 3.50, an immediate 71 percent reduction for any workload that does not need request validation or API keys.

How API Gateway and DynamoDB Billing Work

API Gateway charges by request count, data transfer, and optional cache GB-hours. REST APIs add features like usage plans and WAF integration at a premium. HTTP APIs cover 80 percent of modern use cases at a fraction of the price. WebSocket APIs bill per message plus connection minutes, relevant for real-time dashboards.

DynamoDB has two capacity models. On-demand charges USD 1.25 per million writes and USD 0.25 per million reads in eu-central-1, scaling instantly. Provisioned capacity costs USD 0.000714 per write capacity unit (WCU) hour and USD 0.000142 per read capacity unit (RCU) hour, cheaper by up to 60 percent once traffic is predictable.

Storage bills USD 0.25 per GB-month, and every global secondary index (GSI) duplicates writes at full cost. According to the DynamoDB pricing documentation, the free tier covers 25 GB and 200 million requests per month, enough for many early-stage EU startups to run production workloads at zero cost.

Step-by-Step Cost Reduction

Start by auditing which APIs still run on REST API when HTTP API would suffice. The CDK snippet below shows a minimal HTTP API with JWT authorisation and CloudWatch access logs sized for GDPR retention.

// infra/api-stack.ts (AWS CDK v2)
import { HttpApi, HttpMethod, HttpStage, CorsHttpMethod } from "aws-cdk-lib/aws-apigatewayv2";
import { HttpLambdaIntegration } from "aws-cdk-lib/aws-apigatewayv2-integrations";
import { LogGroup, RetentionDays } from "aws-cdk-lib/aws-logs";

const accessLogs = new LogGroup(this, "ApiLogs", {
  retention: RetentionDays.ONE_MONTH, // 30-day GDPR-aligned retention
});

const api = new HttpApi(this, "CheckoutApi", {
  corsPreflight: { allowOrigins: ["https://app.eu.example.com"], allowMethods: [CorsHttpMethod.ANY] },
  defaultIntegration: new HttpLambdaIntegration("OrdersFn", ordersFn),
});

new HttpStage(this, "Prod", {
  httpApi: api, stageName: "prod", autoDeploy: true,
  accessLogSettings: { destination: accessLogs, format: JSON.stringify({ requestId: "$context.requestId" }) },
});

Next, turn on API Gateway caching for read-heavy endpoints. According to the API Gateway caching documentation:

For frequently mutated data, use key-based cache invalidation rather than disabling the cache entirely.

For DynamoDB, move write-heavy tables to provisioned capacity once traffic exceeds a stable 10,000 requests per minute, and configure auto scaling.

# template.yaml (SAM) - provisioned table with auto scaling
Resources:
  OrdersTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: orders-eu
      BillingMode: PROVISIONED
      ProvisionedThroughput: { ReadCapacityUnits: 50, WriteCapacityUnits: 25 }
      TimeToLiveSpecification: { AttributeName: expiresAt, Enabled: true }
      AttributeDefinitions:
        - { AttributeName: pk, AttributeType: S }
        - { AttributeName: sk, AttributeType: S }
      KeySchema:
        - { AttributeName: pk, KeyType: HASH }
        - { AttributeName: sk, KeyType: RANGE }
      SSESpecification: { SSEEnabled: true }
      PointInTimeRecoverySpecification: { PointInTimeRecoveryEnabled: true }

According to the DynamoDB auto scaling documentation, setting the target utilisation to 70 percent balances cost and burst headroom. Add TTL on ephemeral records, for example session tokens, so DynamoDB reclaims storage without extra code. Finally, consolidate access patterns into a single-table design so a table avoids scattering GSIs across many small tables, which doubles write cost per index.

HTTP API: $1.00/million requests vs REST: $3.50/million – 71% savings. Caching: 60-80% hit rate, $0.020/hour.

Cost Optimization Best Practices

Use sparse GSIs: only project attributes actively queried so each GSI consumes fewer WCUs. Batch writes with BatchWriteItem to amortise network overhead. Compress large attributes before storing because DynamoDB rounds to 1 KB write units.

For API Gateway, enable payload compression on responses above 1 KB to cut data transfer, which costs USD 0.09 per GB egress from eu-west-1. Keep client retries idempotent to avoid double-charging for duplicated writes.

According to the AWS Well-Architected Serverless Lens, teams that pair caching with provisioned capacity on predictable workloads report 45 percent lower combined API-plus-database costs.

Monitoring and Troubleshooting

Monitoring Metrics:

Tag tables with DataClass=gdpr-personal so FinOps reports surface residency-relevant spend separately.

Review DynamoDB Streams and global tables carefully. Stream records cost USD 0.02 per 100,000 reads from the shard, and a noisy consumer can double the read bill on a busy table.

Global tables replicate writes cross-region and charge full replicated WCUs, so only enable cross-region replication for tables that truly need multi-region availability. For EU-only workloads, keep tables single-region in eu-central-1 with point-in-time recovery instead, which covers most disaster recovery scenarios at a fraction of the cost.

Conclusion

API Gateway DynamoDB cost reduction is less about any single trick and more about stacking the right defaults: HTTP API for new endpoints, targeted caching, the correct capacity mode, TTL, and disciplined index design. Teams that apply this playbook typically halve the combined bill in one quarter while keeping latency flat.

If your European SaaS platform needs a partner to audit current spend, migrate legacy REST APIs, and design GDPR-aligned DynamoDB tables in eu-central-1 or eu-west-1, EaseCloud offers dedicated serverless FinOps engagements that deliver measurable savings within 30 days.

Frequently Asked Questions

When is HTTP API not a good fit compared to REST API?

Stick with REST API when you need:

• Request validation
• Per-method IAM authorizers
• WAF integration
• Private APIs
• Usage plans with API keys

For most public JSON APIs without these requirements, HTTP API delivers the same functionality at roughly one-third the price.

Should a new EU workload start with on-demand or provisioned DynamoDB?

DynamoDB capacity model decision:

Does API Gateway caching conflict with GDPR?

Not if you cache only non-personal keys such as product catalogue responses. Avoid caching endpoints that return personal data or keep the cache TTL under 60 seconds and exclude the cache key from any response containing customer identifiers, consistent with data minimisation principles.