Limits and checklists
Use this page as a quick operational reference.
Platform limits depend on the Marketplace plan, Azure subscription, deployed platform version, Elastic license, and workload configuration.
Do not assume limits from another deployment apply to yours.
Capacity and service limits
For planning, use the supported Small, Medium, and Large capacity profiles.
Actual supported workload depends on factors such as:
- ingestion rate;
- stored data;
- retention;
- replicas;
- query activity;
- OpenTelemetry volume;
- integrations;
- workload growth.
If usage approaches the current deployment capacity, request a capacity review through iVedha rather than changing managed infrastructure directly.
See Monitor health and capacity.
Before deployment
Use the dedicated Deployment checklist.
Confirm:
- Azure and Marketplace prerequisites;
- target subscription and region;
- workload and initial capacity;
- public-access choice;
- DNS-domain choice;
- maintenance window;
- monitored support email.
Deployment handover
After receiving Your deployment is ready, confirm:
- [ ] The expected Elasticsearch, Kibana, Fleet, and Logstash endpoints are available where applicable.
- [ ] Administrator access has been established.
- [ ] Required network access is configured.
- [ ] DNS resolves correctly.
- [ ] TLS certificates validate.
- [ ] Kibana can be accessed.
- [ ] Elasticsearch can be accessed.
- [ ] Fleet is reachable when enabled.
- [ ] Support contacts and deployment reference are recorded.
- [ ] No passwords, private keys, tokens, or other secrets are stored in handover documentation.
Before onboarding data
Confirm:
- [ ] The intended onboarding path is understood.
- [ ] Required users or API keys use least privilege.
- [ ] Fleet policies and integrations are defined where required.
- [ ] OpenTelemetry instrumentation or Collector configuration is ready where required.
- [ ] Expected data streams, datasets, or indices are known.
- [ ] Retention requirements are understood.
For observability workloads, prefer the supported OpenTelemetry-first architecture.
Before a platform change
Before requesting a capacity, maintenance, SSO, TLS, license, or other managed-platform change:
- [ ] Identify the deployment.
- [ ] Understand the business impact.
- [ ] Confirm the requested configuration.
- [ ] Identify affected applications and users.
- [ ] Define how the change will be validated.
- [ ] Confirm any required rollback or recovery considerations.
Use the supported iVedha workflow for platform-level changes.
Before an upgrade
Confirm:
- [ ] Current platform and Elastic versions are known.
- [ ] Application and client compatibility has been reviewed.
- [ ] Elastic Agent and Fleet compatibility has been reviewed.
- [ ] OpenTelemetry Collector, SDK, and integration compatibility has been reviewed where applicable.
- [ ] Logstash or connector compatibility has been reviewed where applicable.
- [ ] Important workloads have a post-upgrade validation plan.
See Prepare for upgrades.
Before certificate renewal
Confirm:
- [ ] Current certificate expiration is known.
- [ ] Required service hostnames are still correct.
- [ ] The new platform-generated CSR has been obtained.
- [ ] The CSR covers Kibana, Elasticsearch, Fleet, and Logstash where applicable.
- [ ] The approved CA will sign the CSR.
- [ ] The private key remains inside the managed platform.
Before deletion
Confirm:
- [ ] The deployment is no longer required.
- [ ] Ingestion and applications have been stopped or redirected.
- [ ] Data that must be retained has been identified.
- [ ] Required backup or recovery arrangements have been confirmed.
- [ ] Customer-owned Private Endpoints and DNS records have been identified.
- [ ] Credentials and integrations that require cleanup have been identified.
- [ ] Marketplace or billing implications have been reviewed.
Need assistance
Use:
- AI chat:
https://copilot.ivedha.cloud - Support portal:
https://support.ivedha.com/
Do not include passwords, API keys, tokens, private keys, or other secrets in support evidence.