Enterprise Deployment

Bring Your Own Cloud.
Keep Your Own Data.

Deploy Oodle's observability stack inside your AWS VPC. Your data never leaves your cloud perimeter. Managed by Oodle, owned by you.

Data Sovereignty, By Design

For organizations where regulatory requirements, internal security policies, or data residency laws make it non-negotiable to keep telemetry within your own infrastructure.

When data must stay in your perimeter

Some organizations operate under regulatory, contractual, or internal security policies that require telemetry data to remain within their own cloud perimeter. GDPR data residency, HIPAA controls, PCI-DSS cardholder data isolation, or simply an internal mandate from your security team. The requirement is the same: observability data cannot leave your network.

Self-hosting open-source tools (Prometheus, Grafana, Elasticsearch) addresses the residency requirement but shifts the burden to your engineering team: capacity planning, upgrades, scaling, and incident response for the observability stack itself.

BYOC gives you both: data stays in your VPC, and Oodle handles operations. Total cost of ownership (licence plus infrastructure) is lower than running and staffing an equivalent self-hosted stack.

Typical compliance requirements addressed

GDPRData residency within EU boundaries
HIPAAPHI never leaves your controlled environment
PCI-DSSCardholder data environment isolation
SOC 2Logical and physical access controls
ISO 27001Information security management system
FedRAMPGovernment cloud security requirements

What BYOC Gives You

Every component of the Oodle stack runs inside your cloud account. Here's what that means in practice.

Full Data Control

Telemetry data (logs, metrics, traces) stays in your cloud account. No data ever leaves your network perimeter. You own the storage, encryption keys, and access policies.

Regulatory Compliance

Meet data residency requirements for GDPR, HIPAA, PCI-DSS, and industry-specific mandates. Deploy in the region of your choice. Data never crosses geographic boundaries.

Network Isolation

The entire Oodle deployment runs inside your VPC with no inbound internet access required. Oodle manages the deployment via scoped IAM roles. No standing SSH access, no VPN tunnels.

Your Encryption Keys

Data at rest is encrypted with your KMS keys. You control rotation policies, access grants, and audit trails. Oodle never holds or has access to your encryption keys.

Audit & Access Control

All access is logged via CloudTrail. SSO/SAML integration and RBAC are enforced at the application layer.

Zero Egress Costs

Since data stays within your cloud account, there are no cross-region or cross-account data transfer charges. Ingestion, storage, and querying all happen locally.

How Oodle BYOC Works

Managed simplicity, not transferred complexity

The entire Oodle stack (ingestion, storage, query engine, alerting) runs inside your AWS environment. Deploy into a separately provisioned AWS account with VPC peering, or a dedicated Kubernetes cluster in your existing account. Oodle manages the deployment that you provision and control. No standing SSH access, no VPN tunnels.

Oodle Manages

Via scoped IAM roles
  • Deployment, configuration, and version orchestration
  • Rolling upgrades with zero-downtime deployment
  • Health monitoring and auto-scaling

Runs in Your VPC

Your infrastructure, your data
  • Ingestion endpoints for logs, metrics, and traces
  • Query engine and compaction layer
  • S3-native storage (your buckets, your KMS keys)
  • Alerting, dashboards, and anomaly detection

You Control

Full ownership, revocable access
  • IAM roles and permission boundaries
  • KMS encryption keys and rotation policies
  • Network policies and VPC security groups
  • Audit trail via CloudTrail

BYOC Architecture

Oodle BYOC architecture: full stack deployed in your VPC, managed via IAM

Currently available on AWS. Talk to us for GCP and Azure.

Deployment in Three Steps

Typical BYOC deployment completes in under a day with our engineering team.

1

Provision

Oodle deploys into a separately provisioned AWS account with VPC peering to your account, or into a dedicated Kubernetes cluster within your existing AWS account. You grant scoped IAM roles for deployment and management. Typical setup takes under a day with our engineering team.

2

Connect

Your existing agents (OTel, Fluentd, Prometheus) point to the local Oodle endpoints inside your VPC. No changes to application code.

3

Operate

Oodle manages upgrades, scaling, and health monitoring via IAM-scoped access. You retain full data ownership and can revoke access at any time.

How BYOC Compares to Self-Hosting

BYOC gives you the data residency of self-hosted stacks with the operational simplicity of a managed service, at a lower total cost than self-hosting.

PrometheusGrafanaOpenSearch

vs. Open-Source Stacks

Prometheus, Grafana, Mimir, Elasticsearch, OpenSearch, Loki

Operational overhead

  • Self-hosted: capacity planning, upgrades, compaction tuning, shard management, incident response
  • Typically requires 1-3 engineers part-time to operate
  • Oodle BYOC: operational burden shifts to Oodle. Your team uses the platform, not operates it

Scalability

  • Prometheus/Mimir: federation, sharding, TSDB compaction at scale
  • Elasticsearch: shard rebalancing, index lifecycle management
  • Oodle: S3-native, storage separated from compute. Elastic scaling without re-sharding

Unified platform

  • Self-hosted: Prometheus + Elasticsearch + Jaeger stitched together
  • Oodle: logs, metrics, traces, and AI debugging in a single deployment with correlated queries
Self-hostedOodle BYOC
Ops engineers needed1-30
Upgrade processManualManaged
Scale without re-shard
Unified logs + metrics + traces
ClickHouse

vs. ClickHouse

Self-hosted or ClickHouse Cloud for observability workloads

Schema-less ingestion

  • ClickHouse: upfront schema design (column types, partition keys, materialized views)
  • Schema changes on high-volume tables are expensive
  • Oodle: semi-structured ingestion

Serverless compute, no idle tax

  • ClickHouse Cloud: dedicated always-on compute. You pay for provisioned capacity even when idle
  • Oodle: serverless query engine. Compute scales to zero when no queries are running, no idle tax
  • S3-native storage. Retain months of data at S3 cost, elastic compute scales independently

Purpose-built for observability

  • ClickHouse: general-purpose OLAP. Alerting, anomaly detection, service maps must be built on top
  • Oodle: PromQL, Lucene, trace correlation, AI debugging. All built in
ClickHouseOodle BYOC
Schema design requiredYesNo
Serverless (no idle cost)
Built-in alerting & anomaly detection
AI-native debugging

Deployment Models

Choose the deployment that matches your security and compliance posture.

SaaS

Fully Managed

Oodle manages everything. Fastest path to production. Ideal when data residency is not a constraint.

Zero infrastructure to manage
Up and running in minutes
SOC 2, ISO 27001, GDPR

BYOB

Bring Your Own Bucket

Oodle processes data, but storage lives in your S3 buckets. You own the data at rest.

Your storage, your encryption
Data at rest stays in your account
Quick setup, minimal ops
Maximum Control

BYOC

Bring Your Own Cloud

Full observability stack in your VPC. No data leaves your network perimeter.

Complete data sovereignty
Network isolation, your KMS keys
Zero egress, zero data transfer

Frequently Asked Questions

What infrastructure does BYOC run on?

BYOC is deployed on AWS. Oodle runs on EKS with S3 for storage. Two deployment options: a separately provisioned AWS account with VPC peering to your account, or a dedicated Kubernetes cluster within your existing AWS account. Oodle manages the deployment via scoped IAM roles. GCP and Azure support: contact us to discuss.

What access does Oodle have to my infrastructure?

Oodle manages the BYOC deployment via scoped IAM roles that you provision. These roles grant access to manage the EKS deployment and S3 storage, not to read your telemetry data. You define the permissions, can audit all actions via CloudTrail, and can revoke access at any time.

How are upgrades handled?

Oodle pushes version updates via the scoped IAM access to your EKS cluster. Upgrades are rolling and zero-downtime. You can configure maintenance windows and approval gates to match your change management process.

Can I use my existing observability agents?

Yes. Oodle accepts data from OpenTelemetry, Prometheus, Fluentd, Fluent Bit, Datadog agents, and other standard sources. No proprietary agents required.

What is the infrastructure footprint?

Oodle deploys into a separately provisioned AWS account with VPC peering to yours, or a dedicated Kubernetes cluster within your existing account. Typical deployments use 3-8 EKS nodes depending on ingestion volume. Storage is S3-native with no local disks or persistent volumes required. Query compute is serverless, so there is no idle cost when queries are not running.

How does this compare to self-hosting Grafana/Elastic/Prometheus?

You get the data residency benefits of self-hosting without the operational burden or cost. Oodle handles capacity planning, scaling, upgrades, and incident response. Total cost of ownership (licence plus infrastructure) is lower than staffing and running an equivalent self-hosted stack, and your engineering team focuses on using the platform rather than operating it.

Ready to deploy in your cloud?

Our engineering team will walk you through the architecture, assess your infrastructure, and plan a deployment timeline.

SOC 2 Type II · ISO 27001 · GDPR · 99.9% SLA