Profiles and capacity
The Marketplace form can expose workload, capacity, topology, and optional feature choices. The available combinations depend on the approved offer and plan.
The current Marketplace source defines the following planning choices. Confirm that the same labels and descriptions appear in the approved live offer before using them.
Workload profiles
| Profile | Marketplace intent | Planning evidence to collect |
|---|---|---|
| Observability | Logs, metrics, and traces | Daily ingest, event size, retention, query patterns, dashboards, and concurrent users |
| Search | Full-text, vector, and AI-oriented search | Document count and size, update rate, query mix, latency target, relevance tests, and vector dimensions |
Capacity profiles
| Capacity | Marketplace planning range | Interpretation |
|---|---|---|
| Small | Up to 100 GB/day ingest and up to 2 TB stored | Starting range for lighter workloads |
| Medium | 100–500 GB/day ingest and up to 10 TB stored | Starting range for growing workloads |
| Large | At least 500 GB/day ingest and more than 10 TB stored | Starting range for heavy workloads |
These are planning ranges from the source definition, not performance, retention, cost, or service-level guarantees. Validate a representative workload before production.
Topology choices
| Topology | Source-defined purpose | Availability |
|---|---|---|
| All-in-one | A high-availability-ready layout without data tiering | Search and Observability |
| Master/data | Dedicated master and data roles for balanced scale | Search and Observability |
| Master/hot/warm | Dedicated masters with hot and warm data tiers | Observability in the current source definition |
| Optional ML | Adds machine-learning capability when selected | Requires deployment support and an eligible Elastic license |
Node counts, Azure VM sizes, JVM heap, usable disk, replica policy, availability-zone placement, and horizontal scale increments are not published until the runtime configuration and live offer are verified.
Require a versioned sizing record
Before approving a production profile, obtain a sizing record for the exact Marketplace plan and platform release. It must include:
| Required value | Why it matters |
|---|---|
| Platform and Elastic versions | Connects the sizing statement to a reproducible release |
| Elasticsearch instance count and roles | Establishes the physical topology behind the profile label |
| AKS node-pool VM size and count | Identifies the Azure compute consumed by the platform |
| CPU, memory, and Elasticsearch JVM heap | Supports workload and concurrency review |
| Disk per instance and usable storage after replicas | Prevents treating raw disk as customer-usable capacity |
| Example daily ingest and retention assumptions | Explains the workload model used for planning |
| Baseline availability and placement | Supports resilience and recovery review |
| Horizontal scale increment | Shows the operational effect of a capacity change |
| Azure infrastructure-cost estimate and assumptions | Supports commercial review in the customer's region |
| Limits and excluded workloads | Prevents unsupported use of a general size label |
If the seller, approved offer, or service schedule does not provide these values, treat the physical sizing and cost as unresolved. The Small, Medium, and Large ranges alone are not enough for production approval.
All-in-one
All-in-one keeps Elasticsearch roles together. The three instances illustrate the source-defined minimum description, not a capacity guarantee.
Dedicated master and data
The master/data topology separates cluster coordination from data and query workloads.
Dedicated master, hot, and warm
The hot/warm topology separates active and historical data tiers. Lifecycle movement and retention still require an approved policy.
Select a profile
- Start with measured or estimated ingestion, retention, query, and user requirements.
- Review the resources and limitations displayed for each available choice.
- Confirm that the topology meets your availability requirements.
- Confirm that licensed features required by the workload are available.
- Validate the choice with representative ingest and query tests.
- Record the selected values and the evidence used for the decision.
Avoid unsupported assumptions
- A size label is not a service-level objective.
- Retention is not automatically implied by a topology.
- Machine learning availability depends on both deployment configuration and the Elastic license.
- A capacity change can affect cost, maintenance, and performance.
After deployment, monitor actual ingestion, shard count, disk use, query latency, and growth. Use health and capacity before requesting a profile change.