The logs stay in your account.
The search stays in Datadog.
Bring Your Own Cloud Log Management, Datadog's BYOC Logs, runs the log store inside your own cloud on object storage you own, with Log Explorer and Bits AI querying it from the Datadog platform. It is a new product. We implement it where data residency or volume makes SaaS log storage the wrong answer, and we run the cluster that holds it.
Quick facts
Related
- Log Management, the SaaS indexes most logs should stay on
- Observability Pipelines, shaping and routing logs before either store sees them
- Audit Trail, the record of who changed the configuration
The log store inside the perimeter, the search outside it
A regulated customer asks where the logs are stored, and the honest answer is a Datadog region. For most workloads that is fine. For some, it is a contract clause that cannot be met, or a volume that cannot be paid for at SaaS rates. BYOC Logs moves the store into your own account and keeps the search where the engineers already are.
Storage you already pay for. Logs land in your S3, Google Cloud Storage or Azure Blob, at your negotiated rate, with your retention policy and your encryption keys on the bucket.
Search that still looks like Datadog. Log Explorer, dashboards, monitors and Bits AI query the store over a secure connection. The engineer on call does not learn a second tool.
Compute that scales to the query, not the volume. The engine separates storage from compute. Indexers write to object storage, the search layer is stateless, and both scale independently inside your account.
Residency you can evidence. Where the logs are, who holds the keys and who can reach the cluster are facts in your cloud account, which is what the questionnaire asks for.
A product that is new, a cluster that is yours to run, and a feature list that has not finished growing
How it bills. BYOC Log Management has no published rate on Datadog's pricing page, and its product page describes the pricing only as aligned to business needs. The storage and compute it runs on are billed by your cloud provider on your account. We publish nothing here. What we can say is which costs move to the cloud bill, and that the cluster has to be sized and run by somebody.
The configuration traps. This is a new product. Datadog first showed it as CloudPrem and introduced it as BYOC Logs in late 2025, so the feature list is moving and not every Log Management capability is matched yet: Live Tail and Watchdog, for two, are not supported. The cluster is infrastructure in your account: it needs a Kubernetes platform, a metastore, object storage and somebody watching all three. Sized for today's volume, it struggles on the first bad deploy that logs a stack trace per request. Sized for that, it idles. The Agents have to be pointed at it deliberately, and any Agent left on Datadog's SaaS endpoint keeps paying SaaS rates.
Field noteThe most common gap we see in a self-hosted log store is the metastore. Object storage is durable by nature. The small database that knows which segments exist is not, and its backup is the part the sizing exercise leaves out.
Field noteThe pattern we keep finding is a split estate. Half the Agents are repointed to the new store, half are not, and the bill is a SaaS bill plus a cluster bill until the inventory is finished.
Field noteThe cluster is deployed with the quickstart defaults. They are written to prove the product in an afternoon, not to hold a production ingest rate, and the first high-volume day is the one that finds the limit.
Field noteResidency is the reason for the project, and the logs already held in the old SaaS indexes stay in a Datadog region until their retention runs out. Moving the store does not move the history, and the questionnaire asks about both.
Prove the residency case first. Then size it. Then move the Agents, all of them.
We start with a Datadog HealthScan. It is read-only and fully automated, and it reports log volume per source and per index, which of it is bound by residency, and what the SaaS indexing of the rest costs today, so the case for BYOC Logs is made on numbers rather than on principle. Then the sequence is a platform build and a migration, in that order.
- Confirm the scope. Which sources are bound by residency or volume, which are better left on SaaS indexes, and what the questionnaire actually asks.
- Deploy the platform. The BYOC Logs cluster on your AWS, GCP or Azure, with object storage, a metastore with a tested backup, and the Datadog connection established.
- Size it for the bad day. Ingest and search capacity set from the peak day in the HealthScan, not the average, with the scaling rules written down.
- Repoint the Agents. Every Agent and forwarder in scope, from an inventory, with the SaaS endpoint closed behind them so nothing drifts back.
- Rebuild what the move does not carry. Pipelines, monitors and dashboards checked against the supported-features list, and the gaps named rather than discovered.
- Hand over, in writing. The cluster design, the sizing, the backup procedure, the sources in scope, and the volumes on the day we finished.
Access is admin on the Datadog organisation plus deploy and operate access to the cluster and storage in your account, scoped to that workload. We run the cluster as part of the service. The data never passes through an account we control.
A log store in your account is a system to run, and it is ours to run
Datadog ships the platform quickly while it is new. Volume grows. A new service logs to the SaaS endpoint by default. Managed Observability runs the cluster as part of the service, not as a favour.
Every month, we review the volumes. Ingest per source against the capacity, storage growth against the bucket policy, and query load against the search layer, so the scale decision is taken before the bad day.
The cluster is kept current. Upgrades are tested, scheduled and applied by us, with the metastore backed up before each one.
Coverage follows the estate. A new service or a new Agent that logs to the SaaS endpoint by default is found in the review and repointed before it becomes a line on the SaaS bill.
The incident is ours to take. Under Critical Support a cluster that stops ingesting or a search layer that stops answering pages our engineers, 24x7, and they restore it rather than report it.
We operate the stack. You own the product.
A self-managed log store is a decision to own the infrastructure and the residency it gives you. We do not try to talk anyone out of that. We make it operable: the cluster, the storage, the upgrades and the backups are run by us, in your account, and documented so you can take them over whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Bring Your Own Cloud Log Management, answered plainly
How is Datadog Bring Your Own Cloud Log Management billed?
Datadog publishes no rate for it on its pricing page, and its product page describes the pricing only as aligned to business needs. The storage and compute it runs on are billed by your cloud provider, on your account, at your rates. We do not publish prices. What we can say before a quote is which costs move from the Datadog bill to the cloud bill, and what the cluster needs to run.
Is Datadog BYOC Log Management generally available?
It is a new product. Datadog first showed it as CloudPrem, introduced it as Bring Your Own Cloud Log Management in late 2025, and its documentation now sits under the BYOC Logs name, with the old CloudPrem paths redirecting. Datadog does not label it Preview on its product page, and it is not supported on the US government sites. The feature set is still growing, so we check the supported-features list for each capability before we promise it.
What stays in Datadog and what stays in our account?
The log data, the index segments and the object storage stay in your account, on your AWS, GCP or Azure. The platform runs on a Kubernetes cluster in that account. Datadog hosts the user interface: Log Explorer, dashboards, monitors and Bits AI send queries to your cluster over a secure connection and show the results. Datadog's documentation carries the detail of what metadata crosses that connection.
Should we move all of our logs to BYOC?
Usually not. The sources bound by a residency rule or a contract, and the high-volume sources where SaaS indexing is the biggest line on the bill, are the candidates. Logs that drive monitors and incidents and are small in volume are often better left on Datadog's own indexes, with Flex Logs and archives doing their jobs. The HealthScan makes that split on volumes rather than on principle.
What does Critical Cloud do with BYOC Log Management every month?
Managed Observability runs the cluster. We review ingest and query capacity against the month's peaks, and storage growth against the bucket policy. We test and apply platform upgrades with the metastore backed up first. We repoint Agents that drifted back to the SaaS endpoint. Under Critical Support our engineers take the ingest or search outage, 24x7.
- Datadog products: every product, and how we implement and run each one
- Datadog Log Management: the SaaS indexes, Flex Logs and archives the rest of the estate stays on
- Observability Pipelines: routing and shaping logs before they reach either store
- Datadog logs pricing: what drives the SaaS log bill and where the volume comes from
- Log management guides: setup, parsing, retention and archiving, step by step
Logs in your account. A search your engineers already know.
Tell us what the contract says about residency. We will show you which logs it binds, what BYOC Logs would carry, and what it takes to run it.