Reduce AWS Costs: What a Fintech Can Cut Without Failing an Audit

Every fintech we work with has a version of the same conversation. Someone asks why the AWS bill went up, someone else says "compliance", and the meeting ends. We have started asking a follow-up: which clause? Usually nobody knows, because the line item is not a clause. It is a default nobody turned off.

That matters because the regulator's list is short and specific. CERT-In wants 180 days of logs held in India. The RBI wants a DR you have actually tested, backups, and an audit trail that names people. Neither says the logs must sit in CloudWatch at $0.50 a gigabyte, or that every account needs its own CloudTrail, or that traffic to S3 must go through a NAT gateway.

Our position: to reduce AWS costs on a regulated account, separate the lines the regulator names from the lines someone labelled compliance, and cut the second set first. That is most of AWS cost optimisation for the fintechs we meet, and the second set is usually the larger one.

What does the regulator actually make you keep?

Four things, in our reading of the Indian texts we have written about before. Logs for 180 days, within Indian jurisdiction, which we set out in the six-hour reporting post. Payment data and its backups in India, per the localisation circular covered in the data localisation post. A disaster recovery arrangement that is drilled, and centralised logging that a named person can read, both from the 2026 direction we mapped onto an account in the NBFC post. And the audit trail itself: CloudTrail, on, everywhere.

Notice what they do not say. None of them names a storage class, a log tier, a network path or an instance type. They say what must exist and for how long, not what it must cost. The rest of this post is that gap.

Why are you paying for CloudTrail twice?

Because the account was set up twice. The CloudTrail pricing page is clear that "you can deliver one copy of your ongoing management events to your Amazon Simple Storage Service (S3) bucket for free by creating trails", and then charges $2.00 per 100,000 management events for every copy after that. Data events are $0.10 per 100,000 from the first event.

The pattern in most landing zones: an organisation trail in the log archive account, created by Control Tower or whoever built the landing zone, plus a per-account trail the security team created earlier, plus sometimes a third from a compliance tool that wanted its own bucket. The first copy is free. The second and third are billed on every API call in the account, and a busy account with autoscaling makes a lot of them. The regulator wants one complete, tamper-evident trail. It does not want three.

Data events are the other half. S3 data events turned on for every bucket, because someone was told PCI wanted object-level logging, bill every GetObject on the static assets bucket at the same rate as the one holding card tokens. Scope the selectors to the buckets that are in scope and leave the CDN origin alone.

What is the NAT gateway charging you to talk to S3?

Per gigabyte, for traffic that never needed it. AWS's VPC pricing page lists the NAT gateway at $0.045 an hour plus $0.045 for every gigabyte processed in US East (Ohio); pick your region on that page for the exact figure. The same page says "there are no data processing or hourly charges for using Gateway Type VPC endpoints", and the gateway endpoint documentation confirms it: "There is no additional charge for using gateway endpoints."

So look at what goes through the NAT gateway in a fintech account. Database backups to S3. The 180-day log copy being shipped to S3. Container image layers pulled from ECR, which are stored in S3. DynamoDB reads from a private subnet. Every one of those is a gateway-endpoint candidate, and every gigabyte of it through NAT is a charge that exists only because the route table has no endpoint route. We have seen the nightly RDS export alone be the largest NAT line, because nobody looked at where it was going.

One caveat from the same documentation: the prefix list is regional, so traffic to a bucket in another region still goes out through the internet gateway or NAT. If your DR copy is cross-region, that leg stays.

Does the 180-day log copy need to live in CloudWatch?

Not in the Standard class. The CloudWatch pricing page puts Standard ingestion at $0.50 per gigabyte and Infrequent Access at $0.25 in US East (N. Virginia), with storage at $0.03 per gigabyte-month in both. The log classes documentation is explicit that the two "differ in ingestion costs only", and lists what Infrequent Access gives up: metric filters, subscription filters, Live Tail, anomaly detection and the GetLogEvents API. It keeps Logs Insights queries, KMS encryption, export to S3 and cross-account access.

That is the compliance-copy profile exactly. Nobody alerts on the audit trail from six months ago; they query it when CERT-In or an auditor asks. So the on-call log groups stay Standard with a short retention, and the forensic groups go to Infrequent Access at 180 days, or to S3 with a lifecycle rule. One trap: "after a log group is created, its log class can't be changed", so this is a new log group and a change to the agent config, not a setting.

If you run Datadog on top of CloudWatch, the same argument applies one layer up, and we made it in the Datadog post: the compliance copy belongs in an S3 bucket in Mumbai, and the searchable index can be as short as on-call needs.

What is still on gp2, and what is attached to nothing?

More than you think, because gp2 was the default for years. AWS announced gp3 with "up to 20% lower price-point per GB than existing gp2 volumes" and a "baseline performance of 3,000 IOPS and 125MB/s at any volume size", and the announcement notes that Elastic Volumes lets you change the type "without interrupting your Amazon EC2 instances". A gp2 volume under a terabyte gets fewer baseline IOPS than gp3 gives free, so the migration is cheaper and faster at once. The exceptions are large gp2 volumes that were relying on burst above 3,000 IOPS; check CloudWatch before you move those.

Then the volumes attached to nothing. Instances get terminated with "delete on termination" off, snapshots pile up from an old backup script, and the DR account has AMIs from every release since launch. Compute Optimizer flags idle resources alongside rightsizing, across EC2, EBS, RDS, NAT gateways and more, from 14 days of CloudWatch data once you opt in; the 93-day lookback is a paid extra. It deletes nothing, which is right, because the snapshot from the migration weekend might be the one the DR drill relies on. It gives you the list.

For the compliance archive in S3, use lifecycle rules rather than Intelligent-Tiering. The Intelligent-Tiering documentation says an object under 128 KB "is not monitored and is not eligible for automatic tiering", and CloudTrail and log-shipper objects are mostly under that. A plain transition to a colder class at 30 days does the job for those.

What can you run on Monday to reduce AWS costs?

Two commands. The first turns the bill into line items by usage type, the level where "compliance" stops being an answer. It lists last month's 25 most expensive usage types:

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[0].Groups | sort_by(@, &to_number(Metrics.UnblendedCost.Amount)) | reverse(@) | [:25].[Keys[0], Metrics.UnblendedCost.Amount]' \
  --output table

Look for NatGateway-Bytes, DataProcessing-Bytes, PaidEventsRecorded, DataScanned-Bytes and EBS:VolumeUsage.gp2 in the first column. Each maps to a section above, and the amount next to it is what gets the change approved.

The second is the fix for the most common line. It adds a gateway endpoint for S3 to the route tables of your private subnets, after which S3 traffic from those subnets stops touching the NAT gateway:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-endpoint-type Gateway \
  --service-name com.amazonaws.ap-south-1.s3 \
  --route-table-ids rtb-0aaaaaaaaaaaaaaaa rtb-0bbbbbbbbbbbbbbbb

Repeat for com.amazonaws.ap-south-1.dynamodb if you use it. The security groups need an outbound rule to the S3 prefix list on 443. Scope the endpoint policy to your own buckets while you are there; it is also a data-residency control, because it stops an instance in that subnet writing to a bucket you do not own.

When is the bigger bill the right answer?

When the line is one the regulator named. A second region for DR that is actually drilled is worth what it costs. S3 data events on the token vault bucket are the audit trail for the most sensitive object you hold. Standard-class logs with metric filters on the payment service are how the six-hour clock starts on time. And a three-person team should leave the rightsizing list alone until the change process can carry it, because a mis-sized database during settlement costs more than a quarter of savings.

The test: can someone name the clause, or the on-call reason, for each expensive line? If yes, leave it. If the answer is "that is how the landing zone came", that is the line to cut.

The short version

Run the usage-type query and write the regulator's four requirements down the side. Delete every CloudTrail copy after the first and scope data events to in-scope buckets. Add gateway endpoints for S3 and DynamoDB to every private route table. Create Infrequent Access log groups for the 180-day copy and shorten the Standard ones to what on-call uses. Modify gp2 to gp3, then work through Compute Optimizer's idle list with the DR snapshots excluded. Put lifecycle rules, not Intelligent-Tiering, on the log archive.

None of that removes a log, a backup or a region the regulator asked for. It removes the defaults. If you cannot say which lines are which, that is where to start.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.