AWS costs: OpenSearch - the smallest honest cluster price

The honest smallest OpenSearch cluster costs $0 a month — but only for evaluation. AWS's Free Tier gives you 750 hours of a t2.small.search or t3.small.search instance plus 10 GB of EBS storage, every month, forever. The counterintuitive part: that same instance type, t3.small.search, is explicitly blocked by AWS's own documentation from ever running in the Multi-AZ with Standby configuration AWS recommends for production. Follow AWS's own published best practices for a "production-grade" domain — three dedicated master nodes, current-generation instances, data nodes in multiples of three — and the honest floor is closer to $400 a month, before you index a single document.

Jake runs a phone repair shop and just built a customer-facing site where people can look up their ticket status by typing in a name or IMEI number. A tutorial he watched told him OpenSearch was "basically free" to get started. Then, a week after following it, he opened his AWS bill.

"It said ninety dollars," Jake told Ethan. "For a search box nobody had used yet. I hadn't even put my customer data in there. It was just sitting there, empty, doing nothing, and it cost me ninety bucks."

Ethan's take: "The free tier claim isn't a lie. It's just advertising a toy, and everyone reads it like it's advertising a product. Amazon OpenSearch Service really does give you 750 hours a month of a small instance and 10 GB of storage, forever, for eligible usage. What it doesn't tell you up front is that the moment you click 'Easy create' in the console, or pick a deployment option that isn't the exact free-tier-eligible one, you can land on an instance ten times more expensive without ever seeing a warning."

That's the gap this article closes: not "how much does OpenSearch cost" in the abstract, but the smallest number anyone can honestly claim, for three different definitions of "smallest," each backed by AWS's own documentation rather than a rounded-off estimate — plus what happens the moment your data, your security requirements, or your retention window outgrow that starting point.

What the free tier actually gets you

Amazon OpenSearch Service's Free Tier covers up to 750 hours per month of a single-AZ t2.small.search or t3.small.search instance, plus 10 GB per month of optional EBS storage in either Magnetic or General Purpose form. That's enough instance-hours to run one small node continuously, all month, every month — it isn't a one-time trial that burns down. There is no minimum fee or usage requirement on OpenSearch Service in general, so if you stay inside those numbers, your bill for the domain itself really is zero.

The wrinkle is which bucket that free usage falls into, and it changed recently enough that most tutorials online still describe the old rules. Before July 15, 2025, AWS split free-tier usage into three categories: Always Free (never expires, available to any account), 12 Months Free (expires exactly one year after you create your account), and Short-Term Trials. Under that older system, OpenSearch's free allowance generally sat in the 12-months bucket, tied to your account's sign-up date. For accounts created after that date, AWS restructured onboarding into a Free plan and a Paid plan, and OpenSearch Service's 750 hours now behaves as an always-free allowance on the Paid plan — not a clock that runs out twelve months after you sign up.

Either way, the shape of the offer is the same: 750 hours, single-AZ, t2.small.search or t3.small.search, 10 GB of EBS. Go past any of those three numbers — more hours, a bigger instance, more storage — and OpenSearch Service bills the overage at standard on-demand rates for whatever you actually provisioned. There's also no way to "pause" a domain the way you can stop an EC2 instance. Amazon OpenSearch Service instance hours are billed for every hour the instance is running in an available state, full stop, and partial hours round up to a full hour. If you want to stop the meter, you delete the domain.

The console trap: when you can't even select the free instance

Here's the part that catches people like Jake. AWS's own documentation notes that you can only use t2.small.search or t3.small.search if your domain is configured a specific way, and the console doesn't always make that path obvious. On the Amazon OpenSearch Service pricing page's own developer documentation, t3.small.search is listed as a current-generation instance type — not a legacy one — but with three hard restrictions: it requires Elasticsearch 5.6 or a current OpenSearch version, it only works if your domain is provisioned without standby, and it only works if your domain's total instance count is 10 or fewer. It also can't use UltraWarm storage, cold storage, or Auto-Tune.

"Provisioned without standby" is a specific creation choice, not a default. On the AWS Management Console, the only way to get a domain without standby is to use the Standard Create path and explicitly pick "Domain without standby" as the deployment option. If you use Easy Create, or if you leave the deployment option on its default, OpenSearch Service will build you a Multi-AZ with Standby domain instead — and standby domains only support a specific list of instance families (m5, c5, r5, r6g, c6g, m6g, r6gd, r7g, c7g, m7g, r7gd, i3, or1, or2, om2, and oi2). T2 and T3 aren't on that list. Pick the wrong path, and t2.small.search or t3.small.search simply won't appear as an option — not because AWS revoked the free tier, but because the deployment mode you're in structurally can't host that instance type.

This isn't a hypothetical. Reports from people running into exactly this on AWS's own community forum describe creating a domain, selecting "Domain without standby," and still finding the smallest available instance was something in the r7g family — not t3.small.search — with one user reporting a $90 bill for a single week of an empty domain that ran on an oversized instance they never meant to choose. Availability of instance types varies by Region and by which OpenSearch version you pick when you create the domain, so the exact instance you're offered isn't guaranteed to match what a two-year-old tutorial screenshot shows.

Why the cheapest instance is locked out of production

Ethan's opinion here is blunt: "AWS isn't hiding this. It's right there in their own quotas documentation — they say plainly that they don't recommend T2 or t3.small instance types for production domains. People just don't read the quotas page before they build something real on top of a free-tier tutorial."

The restriction isn't arbitrary. AWS's Multi-AZ with Standby deployment — the one that gets you 99.99% availability with automatic failover in under a minute — only works with a specific set of current-generation, non-burstable instance families. T2 and T3 are burstable instances: they earn CPU credits during idle periods and spend them during spikes, which is a fine model for a dev box but a poor fit for a database node that AWS wants to be able to reliably fail over without a performance cliff. So T3 instances are barred from standby entirely, and T2 instances (previous generation) can't do encryption at rest, fine-grained access control, UltraWarm, cold storage, cross-cluster search, or Auto-Tune on top of that.

That leaves you with a real fork in the road once you outgrow the free tier: keep the cheap instance and accept a domain that AWS itself says it doesn't recommend for production, or move to an instance family that actually supports the resilience story AWS is selling — which immediately puts you on instances priced for real workloads, not evaluation.

Instance family	Generation	Works with Multi-AZ Standby?	Notable restriction
T2 (t2.small.search)	Previous	No	No encryption at rest, no fine-grained access control, no UltraWarm/cold storage, 10-node domain cap
T3 (t3.small.search)	Current	No	Only usable without standby, 10-node domain cap, no UltraWarm/cold/Auto-Tune
M7g (m7g.medium.search)	Current (Graviton3)	Yes	gp3 storage only
C6g (c6g.large.search)	Previous	Yes	Compatible only with other Graviton instance types in the same domain

Building the smallest cluster that still meets AWS's own bar

Once you're past the free tier and you don't want to run on an instance type AWS itself doesn't recommend, the next honest step down isn't "as small as possible" — it's "as small as possible while still being current-generation and off the deprecated path." AWS's own cost-optimization guidance says you only need a dedicated master node once you have three or more data nodes, so a genuinely minimal setup skips the dedicated master entirely and runs two data nodes.

The smallest current-generation general-purpose instance AWS documents pricing for is m7g.medium.search, priced at $0.068 per hour in US East (N. Virginia) in AWS's own published example calculations. Running two of them, without a dedicated master, for a full 730-hour month:

Line item	Rate	Usage	Monthly cost
2 × m7g.medium.search	$0.068/hr each	2 × 730 hrs = 1,460 hrs	$99.28
20 GB gp3 EBS total	$0.122/GB-month	10 GB × 2 nodes	$2.44
Total			~$101.72

That's a domain you can actually keep running for a small production workload without violating AWS's "don't use T2 or t3.small for production" guidance, while accepting Multi-AZ without Standby's 99.9% availability figure instead of the 99.99% figure standby offers. To build it on the console:

1. Open the OpenSearch Service console and choose Create domain, then Standard create (not Easy create — Easy create pushes you toward standby).
2. Under Deployment options, select Domain without standby.
3. Under Data nodes, set Instance family to General purpose and pick m7g.medium.search (or the smallest current-generation option your Region and OpenSearch version offer).
4. Set the data node count to 2, and leave dedicated master nodes off — AWS's own guidance says they're only needed at three or more data nodes.
5. Choose two Availability Zones for the domain, so a single AZ failure doesn't take down every data node at once.
6. Under Storage, choose gp3 and set the volume size as small as your index actually needs — gp3 is priced lower per GB than the older gp2 type and provides better baseline performance at any size.
7. Enable at least one replica per index once your data is loaded, so OpenSearch Service can distribute copies of your data across both zones.

Run the numbers before you commit: if your workload genuinely needs more headroom, going up to r7g.medium.search or a larger m7g size costs proportionally more, but the structure — no standby, no dedicated master, current-generation instance, two zones — stays the honest minimum shape.

What Multi-AZ with Standby actually forces you to add

AWS documentation states that Multi-AZ with Standby is available at no extra cost — and taken literally, that's true. There's no line item on your bill labeled "standby fee." But AWS achieves that 99.99% availability figure by mandating a specific shape: three Availability Zones, three dedicated master nodes, data nodes in a multiple of three, at least two replicas per index (or a multiple of three total copies of data), current-generation instances only, and Auto-Tune turned on. None of those individual requirements cost extra by themselves — but almost nobody's existing "minimum viable" domain already happens to match that shape, so migrating to it typically means adding real infrastructure.

That production-floor math, worked out at AWS's own published rates: three c6g.large.search master nodes at $0.113 per hour, running 730 hours, is $247.47. Three m7g.medium.search data nodes at $0.068 per hour, also 730 hours, is $148.92. Compute alone comes to $396.39 a month. Add a modest 10 GB of gp3 storage per data node — 30 GB total at $0.122 per GB-month — and you're at roughly $400.05 a month, before you've indexed a single real document or added a second replica for extra durability.

Tier	Configuration	Approx. monthly total	Meets AWS's own production guidance?
Free tier	1 × t2/t3.small.search, single-AZ, 10 GB EBS	$0	No — explicitly not recommended for production
Minimal real	2 × m7g.medium.search, no standby, 2 AZ	~$102	Partially — current-gen, but 99.9% not 99.99% availability
AWS-recommended	3 master + 3 data, Multi-AZ with Standby, 3 AZ	~$400	Yes

Jake's reaction was predictable: "So the real answer to 'what's the cheapest OpenSearch cluster' is $400 a month, not free?" Ethan pushed back on the framing: "No — the real answer is that 'cheapest' and 'production-grade' are two different questions, and most articles quietly answer one while claiming to answer the other. Your $102-a-month setup is a perfectly honest choice if a few minutes of downtime during an AZ blip isn't a business emergency for your repair-ticket lookup. The $400 floor is the honest answer to a different, more specific question."

When your data outgrows hot storage: UltraWarm, cold storage, and why the cheapest instance can't use either

Both the free-tier tier and the $102-a-month minimal tier share a limitation nobody mentions until you hit it: once your logs or search indexes grow past what your hot-tier EBS storage can hold cheaply, the next move on a real production domain is usually UltraWarm or cold storage, not simply bigger EBS volumes. AWS describes UltraWarm as a tier that lets you economically retain large amounts of data while keeping the same interactive analysis experience, and cold storage as the lowest-cost tier, which detaches infrequently accessed data into Amazon S3 and only bills compute when you actually query it. Managed storage for UltraWarm, cold storage, and OR1 remote-store data is billed separately at $0.024 per GB per month — a fraction of the $0.122 gp3 rate on hot-tier EBS.

The catch: neither T2 nor T3 instance types can use UltraWarm or cold storage at all. That restriction is documented directly alongside the instance types themselves, not buried in a separate limits page. So a domain built on the free-tier instance, or on t3.small.search after the free tier runs out, can't tier its own aging data to a cheaper storage class on the same instance family — it has to add a genuinely different set of nodes (UltraWarm or OI2 instances) to get there, which means this cost optimization only becomes available once you've already moved off the cheapest instance type in the first place.

UltraWarm instance type	Hourly rate (US East, N. Virginia)	Maximum addressable storage
ultrawarm1.medium.search	$0.238/hr	1.5 TiB
ultrawarm1.large.search	Priced per AWS's calculator by Region	20 TiB

Practically, this means the honest cost curve for a growing domain isn't smooth — it steps. You pay the free or minimal rate until your data volume or retention window forces a decision, and then the next honest number involves adding an entirely new instance family to the same domain, not just resizing what you already have.

Storage: the quiet second bill

Instance-hours get all the attention because they're the bigger, more predictable line item, but EBS storage compounds in ways that catch people off guard. AWS bills storage per GB per node per month — not per domain. A three-node cluster with 500 GB provisioned on each node is billed for 1,500 GB, not 500 GB, because every node needs its own copy of whatever it's holding.

General Purpose SSD (gp3) storage is priced at $0.122 per GB per month in US East (N. Virginia), against $0.135 per GB per month for the older gp2 type — a roughly 10% discount for switching, and gp3 also supports larger maximum volume sizes on several instance families than gp2 does. There's no reason to provision new domains on gp2 today. If you're on an older domain still running gp2, migrating to gp3 is one of the more painless cost reductions available, since it's a configuration change rather than a re-architecture.

Automated snapshots are free and retained for 14 days on every domain, which covers point-in-time recovery for recent mistakes without a separate storage bill. Manual snapshots, if you take them, are stored in Amazon S3 and billed at standard S3 rates — a separate, usually small, line item that's easy to forget exists until you check your S3 bill and wonder why there's a bucket full of index snapshots in it.

The security trade-off nobody mentions in free-tier tutorials

Cost isn't the only thing you're trading away at the bottom of the pricing ladder. AWS's own supported-instance-types documentation lists T2 as unable to support encryption of data at rest or fine-grained access control, on top of its UltraWarm, cold storage, cross-cluster search, and Auto-Tune restrictions. t3.small.search doesn't carry that specific pair of restrictions — its listed limits are about standby, node count, and storage tiers, not encryption or access control — but a wider group of instance families, including T2, T3, R3, I3, C4, M4, R4, C5, M5, R5, C6g, M6g, R6g, and R6gd, all fall outside AWS's VPC Encryption Controls feature, which centrally monitors whether traffic across your VPCs is encrypted in transit.

"Wait," Jake said when Ethan mentioned this, "so if I'd picked t2.small.search off the free-tier list instead of t3, I'd have ticket data sitting there unencrypted at rest?" Ethan's answer: "If you picked t2.small.search specifically, yes — it can't do encryption at rest or fine-grained access control at all, full stop. Between the two free-tier-eligible instances, t3.small.search is the safer default, precisely because it doesn't carry that particular pair of restrictions, even though it carries others."

The practical takeaway for anyone building the minimal or free-tier cluster in this post: check which security features your chosen instance type actually supports before you put anything sensitive in it, rather than assuming "free tier" and "production-ready security" are the same claim. They aren't, and AWS's own documentation says exactly which features go missing on which instance family.

The engine-version trap that doubles your bill

AWS's own example makes the math concrete: an m7g.medium.search instance priced at $0.068 per hour normally costs $1.632 a day. If that instance is running an engine version in the "extended support charges equal your instance cost" bracket, the surcharge adds another $1.632 a day, bringing the total to roughly $3.264 a day — double the base rate, with storage unaffected. For versions in the newer flat-fee Extended Support bracket instead, the math is different: AWS charges $0.0065 per Normalized Instance Hour in US East (N. Virginia), where the normalization factor scales with instance size. For that same m7g.medium.search instance running 24 hours, the surcharge works out to roughly $0.312 a day on top of the $1.632 base — smaller than doubling, but still a real, avoidable addition.

That $0.0065 flat rate isn't uniform across every Region, either. US East (N. Virginia), US East (Ohio), and US West (Oregon) all sit at $0.0065 per Normalized Instance Hour, but US West (N. California) runs $0.0077, Europe (Frankfurt) runs $0.0076, Asia Pacific (Singapore) runs $0.0078, and South America (São Paulo) runs the highest published rate at $0.0103. A domain that's cheap to run in Virginia isn't automatically just as cheap to leave on an old engine version somewhere else.

The fix costs nothing except planning: stay on a currently supported OpenSearch or Elasticsearch version, and check your domain's engine version against AWS's published support timeline before it lapses. Extended Support exists to give you a runway to upgrade, not a permanent discount for staying still.

Reserved Instances and Savings Plans — worth it only once you know your floor

Reserved Instances (RIs) are functionally identical to on-demand instances — same performance, same operations — but you commit to a one- or three-year term in exchange for a lower effective hourly rate. AWS's three payment structures scale the discount with how much you pay upfront: No Upfront gives you 31% off for a one-year term or 48% off for three years; Partial Upfront gives 33% for one year or 50% for three; All Upfront gives the deepest discount at 35% for one year or 52% for three. T3 instances are the exception — their RI discounts are noticeably smaller, at 18% (one-year, No Upfront) up to 32% (three-year, All Upfront), reflecting that burstable instances don't get the same reservation economics as steady-state compute families.

A few details matter more for a small domain than the headline discount percentages. Reserved Instances are purchased for an AWS Region, not for a specific Availability Zone, so the discount applies to matching usage in any zone within that Region. They also aren't capacity reservations — buying an RI doesn't guarantee AWS has spare instance capacity waiting for you, it only guarantees a discounted rate once you're running matching usage. And you can procure up to 100 Reserved Instances in a single purchase, which is more headroom than most small domains will ever need.

There's a real trap here for small domains: Reserved Instances aren't cancelable, aren't refundable, and aren't transferable to another account. You pay for every hour of the term whether you use it or not, and if you resize the instance type later, the reservation stops matching and stops discounting. For a domain you're still sizing — like the minimal two-node setup earlier in this post — committing to a one- or three-year RI before you know your real usage pattern can lock in a bad guess.

Database Savings Plans are the more forgiving option for that situation: rather than locking to one instance type in one Region, a Savings Plan commits you to a dollar-per-hour spend level that flexes across instance families, sizes, Regions, and deployment models, including both provisioned and serverless OpenSearch usage. For a domain that's still finding its final shape, that flexibility is usually worth more than a slightly deeper RI discount tied to a configuration you might outgrow in six months.

Automating the lifecycle so the bill doesn't creep back up

Getting to $102 or $400 a month once is the easy part. Staying there is the part almost nobody automates, and it's the difference between a cluster that's honestly small forever and one that quietly grows back to a much bigger number over six months of unmanaged index growth. AWS documents Index State Management (ISM) policies specifically for this: they automate moving indexes through storage tiers — hot, to UltraWarm, to cold, to deletion — based on the age, size, or document count you configure, and they can trigger rollover policies so an index doesn't keep growing past a size you set, such as 50 GB or 30 days old, whichever comes first.

Auto-Tune is the other automation worth knowing about, precisely because the cheapest instances can't use it: it automatically adjusts JVM heap size and other settings to improve performance and reduce resource waste, but it's on the list of features T2 and T3 don't support. On any instance family that can use it, turning it on is a genuinely free way to stop babysitting JVM heap sizing by hand.

1. Apply cost allocation tags to every OpenSearch domain you run, so spend shows up per team, project, or environment in Cost Explorer rather than as one undifferentiated OpenSearch line.
2. Set an Index State Management policy on any index that grows continuously — logs, tickets, events — with a rollover rule tied to size or age, so no single index balloons unchecked.
3. Chain a tier-migration step into that same ISM policy once your domain has UltraWarm or cold storage available, so aging data moves itself off expensive hot-tier EBS on a schedule instead of on your memory.
4. Turn on Auto-Tune on any instance family that supports it, and let it manage JVM heap sizing rather than adjusting it manually after a slow-query incident.
5. Set CloudWatch alarms on storage utilization, JVM pressure, and CPU now, before you need them, so an unmanaged domain announces itself before the bill does.

Right-sizing without guessing — the CloudWatch signals that actually matter

AWS's own cost-optimization documentation gives specific ranges to watch rather than vague advice to "monitor usage." Sustained CPU utilization below 40%, JVM memory pressure below 50%, or storage utilization below 50% are the documented signs you're over-provisioned and probably paying for headroom you don't use. The optimal sustained ranges AWS points to are roughly 60–80% CPU, 65–85% JVM, and 70–85% storage — comfortably busy, not gasping.

1. Open CloudWatch for your domain and pull up the CPUUtilization metric over at least a two-week window, so you catch normal daily and weekly cycles rather than a single quiet afternoon.
2. Check JVMMemoryPressure alongside it — a domain can look fine on CPU while its JVM heap is quietly close to full, which shows up as slow queries before it shows up as an outage.
3. Check free storage space as a percentage of provisioned capacity, and set a CloudWatch alarm well before it crosses into AWS's recommended free-space threshold, since resizing storage is a configuration change, not an instant fix.
4. If CPU, JVM, and storage all sit below the low end of the ranges above for weeks at a time, that's your evidence to downsize the instance type or reduce node count — not a hunch, a documented pattern.
5. If any of the three sits consistently above the high end, that's the opposite signal: you're under-provisioned, and the fix is to size up before a spike turns into an incident, not after.

Multi-AZ without Standby: the honest middle tier, explained properly

Multi-AZ without Standby still distributes nodes across zones and still offers real resilience — AWS documents it at 99.9% availability, versus 99.99% for the standby configuration — but it puts the sizing decisions in your hands instead of enforcing a fixed shape. That flexibility is also where people get hurt: if a zone fails, the surviving nodes have to redistribute data across the remaining resources to maintain redundancy, and that redistribution itself increases load on a cluster that's already down a third of its capacity. If the cluster wasn't sized with that headroom in mind, availability degrades right when you need it most, which AWS's own documentation says "largely defeats the purpose of multi-AZ."

The practical guidance that follows from AWS's own diagrams: pick three Availability Zones even without standby, since two zones leaves you exposed to a genuine coin-flip outcome if a zone with two of your three dedicated master nodes goes down. And if you're running two or more replicas per index, choose a data node count that's a multiple of three — an uneven count forces OpenSearch Service to overload a single node to keep primary and replica shards balanced across zones, which strains exactly the node you can least afford to lose.

What breaks first when you undersize on purpose

None of this means the minimal $102-a-month tier is a mistake — for a lot of small, genuinely non-critical workloads, it's the right call. But it's worth knowing exactly what fails first so an outage doesn't feel like a mystery. AWS's own sizing guidance ties storage limits to the amount of CPU and memory a node has: an m6g.large.search instance, for example, has a documented maximum EBS volume size of 512 GiB alongside 2 vCPU cores and 8 GiB of memory, and if your workload runs many shards, heavy aggregations, or frequent document updates, that combination of resources can be insufficient well before the storage limit is reached.

On a minimal two-node domain without a dedicated master, the master role runs on the same nodes doing your indexing and search work. Under sustained load, that dual duty is usually the first thing to show stress — cluster state updates start competing with query execution for the same CPU and JVM heap. That's the honest trade-off of skipping the dedicated master at two or three nodes: it's the right call for cost, and it's the first place a genuinely busy workload will feel it.

Self-hosting OpenSearch yourself: what "free software" doesn't include

Every one of the numbers above is for the managed service. Running the OpenSearch project itself — the open-source software underneath Amazon OpenSearch Service — on your own compute is a real option, and it isn't priced by the hour the way the managed service is. But "the software is free" and "running it is free" are two different claims, and it's worth separating them honestly rather than pretending self-hosting is a straightforward zero on the other side of this comparison.

What the managed service is actually charging you for, beyond raw compute and storage, is the work you'd otherwise do yourself: patching the operating system and the search engine, managing snapshots and restores, handling version upgrades without downtime, building your own failover and shard-rebalancing logic, and being the one who gets paged when a node runs out of disk at 2 a.m. None of that shows up as a line item on a self-hosted bill, which is exactly why it's easy to undercount. For a hobby project or an internal tool where downtime is genuinely a shrug, self-managing can be the cheaper path once you account only for compute. For anything Jake's customers actually depend on, the honest comparison isn't "$0 versus $102" — it's "$102 a month versus your own time, indefinitely."

Where Ingestion, Direct Query, and vector pricing fit in — and why they're not in this number

Every dollar figure in this article is for the domain itself — the data and cluster-manager nodes and their storage. The moment you add pipelines to get data into that domain, or query data that lives somewhere else entirely, you add separate meters that AWS bills independently, and none of them are optional add-ons to the price above — they're new bills.

Amazon OpenSearch Ingestion charges only for the compute needed to ingest, transform, and route data, measured in OpenSearch Compute Units (OCUs), where one OCU comprises 15 GB of RAM and 2 vCPUs, billed hourly with per-minute granularity. You can set a minimum and maximum number of OCUs per pipeline to bound the cost, and — usefully for a small project — you can pause a pipeline entirely, at which point it consumes no OCUs at all. Direct Query, which lets you query data sitting in S3, CloudWatch Logs, or Security Lake without ingesting it into your domain, uses a different OCU shape (2 vCPU and 8 GiB of RAM per OCU) at $0.24 per OCU-hour; AWS's own example shows a run-book style workload using 2 OCU-hours continuously costing about $11.52 a day to keep an index current for fast querying. Vector search features — automatic semantic enrichment, GPU-accelerated indexing, and S3 Vectors storage — are billed on entirely separate meters again, keyed to tokens processed, OCU-hours during indexing, and logical vector storage respectively.

None of that is a criticism of how AWS prices these features — it's a reason this article's numbers stop at the domain boundary. If your project needs ingestion pipelines or vector search on top of the cluster, treat this piece as the floor for the search engine itself, and add those meters separately once you know your ingestion volume or vector count.

Data transfer charges you'll actually notice

The last line item worth naming explicitly is data transfer, mostly because it's easy to assume it's included and it isn't. AWS charges standard AWS data transfer rates for data moving in and out of your OpenSearch Service domain, the same as any other AWS service — check the EC2 pricing page for your Region's current rates rather than assuming a flat number, since these vary by Region and direction. The one exception worth remembering: data transferred between nodes inside your own domain is free, so a Multi-AZ setup replicating shards across zones doesn't add a transfer charge on top of everything else covered above.

Frequently asked questions

What is the actual smallest OpenSearch cluster you can run for free?

One t2.small.search or t3.small.search instance, single-AZ, with up to 10 GB of optional EBS storage, for up to 750 hours a month — enough to run continuously all month on a single node, at no charge, as long as you stay inside those three limits.

Can I run a real production app entirely on the OpenSearch free tier?

Technically you can point production traffic at it, but AWS's own documentation says it doesn't recommend T2 or t3.small instance types for production domains, and the free-tier instance is also barred from Multi-AZ with Standby, UltraWarm, cold storage, and Auto-Tune. It's built and priced for evaluation, not for something a customer depends on.

Why can't I select t3.small.search when I create a domain?

t3.small.search only appears if your domain is configured as "Domain without standby" through the Standard Create path. Easy Create, or leaving the deployment option on its default, generally builds a Multi-AZ with Standby domain instead, and standby domains don't support the T2 or T3 instance families at all.

What happens the moment I go over the 750 free hours?

You're billed the standard on-demand rate for whatever instance-hours, storage, or data transfer you used beyond the free allowance. There's no grace period or warning built into the billing itself, so a domain left running past the free limits simply accrues charges at normal rates from that point forward.

Is t3.small.search actually a legacy instance type?

No. AWS's supported instance types documentation lists T3 as a current-generation family, not a previous-generation one. It's restricted, not deprecated — it just can't be used with standby, can't exceed a 10-instance domain, and can't use UltraWarm, cold storage, or Auto-Tune.

Do I need a dedicated master node for a 2-node cluster?

AWS's cost-optimization guidance says dedicated master nodes are only necessary once you have three or more data nodes. On a two-node domain, the master role runs on the same nodes handling indexing and search, which keeps cost down but is the first place performance will strain under sustained load.

What's the real difference between Multi-AZ with Standby and Multi-AZ without Standby?

With Standby offers a documented 99.99% availability target with automatic failover in under a minute and no data redistribution during a failure, but it mandates three Availability Zones, three dedicated master nodes, current-generation instances, and specific replica counts. Without Standby offers 99.9% availability and lets you choose your own zone count, node count, and replicas, but a zone failure forces the surviving nodes to redistribute data, which can degrade performance if the cluster isn't sized with that scenario in mind.

Why does AWS say Multi-AZ with Standby is "no extra cost" if it costs more in practice?

The deployment feature itself doesn't add a separate billing line, which is technically accurate. What increases cost is that standby mandates a specific shape — three dedicated masters, data nodes in multiples of three, current-generation instances only — and most existing "minimum" domains don't already match that shape, so adopting it usually means provisioning more infrastructure to meet the requirement.

How much does storage actually add to the bill?

Storage is billed per GB per month, per node — a three-node domain with 500 GB provisioned on each node is billed for 1,500 GB total, not 500 GB. gp3 storage runs $0.122 per GB per month in US East (N. Virginia), against $0.135 per GB per month for gp2, so switching volume types alone can meaningfully lower the storage line.

Is gp3 storage always cheaper than gp2?

Per gigabyte, yes — gp3 is priced lower than gp2 in AWS's own examples, and gp3 also supports larger maximum volume sizes on several instance families. The only reason to stay on gp2 is if your current instance type doesn't support gp3, which is worth checking before assuming you can switch with no other changes.

What is the Extended Support surcharge and will it hit my small cluster?

It's a fee AWS charges for engine versions running past their standard support window. For some version brackets it equals your full instance cost, effectively doubling your compute bill; for others, it's a flat $0.0065 per Normalized Instance Hour in US East (N. Virginia), scaled by instance size, with slightly different rates in other Regions. It applies regardless of how small your cluster is — the trigger is the engine version, not the node count.

Are Reserved Instances worth it for a small OpenSearch domain?

Only once you're confident in your final instance type and node count. RIs aren't cancelable or refundable, and they stop discounting if you resize the instance type later, though the discount does travel across any Availability Zone in the Region you bought it for. For a domain still being right-sized, a Database Savings Plan — which flexes across instance families and Regions for a committed dollar-per-hour spend — is usually the safer choice.

How do I make sure my empty test domain stops billing me?

Delete the domain. There's no option to pause or stop an OpenSearch Service instance the way you can stop an EC2 instance — instance hours are billed for every hour the domain exists in an available state, whether or not you're actively using it.

Is OpenSearch Serverless cheaper than a provisioned domain for a small workload?

It depends on usage pattern rather than size alone. Serverless bills separately for compute (measured in OpenSearch Compute Units) and storage, and Classic collections carry a documented minimum of roughly 2 OCUs for the first collection in an account, with a lower-cost dev-test mode available that skips redundant standby nodes. For a workload with very light or bursty traffic, that can undercut a provisioned domain's always-on instance-hours; for steady, predictable traffic, a small provisioned domain is often more predictable to budget for.

What CloudWatch metrics tell me I'm oversized (or undersized)?

AWS's own guidance points to three: sustained CPU utilization, JVM memory pressure, and storage utilization. Sustained CPU below 40%, JVM below 50%, or storage below 50% suggests over-provisioning. The documented healthy ranges to aim for are roughly 60–80% CPU, 65–85% JVM, and 70–85% storage for sustained workloads.

What's the honest minimum monthly price for a cluster AWS would actually call "production-grade"?

Using AWS's own published on-demand rates for the smallest instances that qualify for Multi-AZ with Standby — three c6g.large.search dedicated master nodes at $0.113 per hour and three m7g.medium.search data nodes at $0.068 per hour — compute alone comes to roughly $396 a month. Add a modest amount of gp3 storage per data node, and the honest floor lands close to $400 a month, well above the free tier's headline number.

Revision note. Written September 2026, covering Amazon OpenSearch Service's current-generation instance families, Multi-AZ with and without Standby, storage tiering, engine-version Extended Support surcharges, and the Free Tier structure for both pre- and post-July 2025 AWS accounts. This will need a fresh look whenever AWS revises which instance families qualify for standby or changes the Free Tier's instance-type allowance. If a surprise bill sent you here, you're not the first person this console has caught off guard — take a breath, delete what you don't need, and build back up deliberately from here...Happy learning, See you on next post!