Datadog for AWS
implemented and operated in the UK.
We integrate Datadog across your AWS accounts, map it to the services your teams actually name, and run it 24x7. Critical Cloud is an AWS Partner and the world's first Powered by Datadog accredited MSP.
What Datadog gives you on AWS that CloudWatch does not
CloudWatch is where AWS puts its telemetry. It is not where most teams can reason about an incident.
CloudWatch is competent at what it does: metrics, logs and alarms, per service, per account, per region. The difficulty is that a production incident rarely stays inside one service, one account or one region. Correlating an ECS task failure with an RDS connection pool and an ALB latency spike means three consoles and a lot of manual timestamp matching.
Datadog changes the unit of investigation. Infrastructure metrics, APM traces, logs and synthetic checks land in one place with a shared tag model, so a single query spans the estate. That matters most at 3am, when the person on call is not the person who built the service.
We are not arguing you should turn CloudWatch off. AWS-native tooling is the source of truth for a lot of signal, and several of these services have no Datadog equivalent. The useful pattern is CloudWatch as collector, Datadog as the correlation and alerting layer on top.
What we connect, and in what order
A Datadog rollout on AWS is mostly integration work. The order matters more than the tooling.
Accounts AWS account integration Role-based integration per account, with tag collection and resource metadata enabled from the start.
We set up the Datadog AWS integration using IAM roles rather than access keys, across every account in the organisation. Resource collection and tag collection are enabled at the point of integration, because retrofitting tags across an estate that has already grown is materially harder than getting them right on day one.
For organisations using Control Tower or AWS Organizations, we integrate at the organisation level so new accounts inherit the pattern rather than being onboarded one at a time.
Compute ECS, EKS and EC2 coverage Agent deployment sized to the workload, with container and Kubernetes metadata mapped to services.
The Datadog Agent is deployed as a DaemonSet on EKS, as a sidecar or daemon service on ECS, and through your existing configuration management on EC2. What matters is not the deployment mechanism but the tag mapping: container, pod, task, service and environment tags need to resolve to the same service names your teams actually use.
Without that mapping you get a monitoring tool. With it you get an estate you can query by service, which is the difference between Datadog being useful and Datadog being expensive.
Serverless Lambda and serverless tracing Distributed tracing across Lambda, API Gateway and Step Functions, with cold start visibility.
Lambda instrumentation uses the Datadog extension layer, which gives you traces, enhanced metrics and logs without a separate forwarder for most cases. Cold start duration becomes a first-class metric rather than something you infer from p99 latency.
We cover the practical side of cold starts in our guide on reducing AWS Lambda cold starts, which is worth reading before you decide how much provisioned concurrency to buy.
Data RDS, Aurora and DynamoDB Database Monitoring where it earns its place, standard integrations everywhere else.
Datadog Database Monitoring gives query-level visibility on RDS and Aurora, which is valuable on the databases behind your critical paths and hard to justify everywhere. We are deliberate about where it is enabled, because it is one of the easier ways to grow a Datadog bill without a matching gain in signal.
For everything else the standard integrations cover connection counts, replication lag, storage and the usual failure modes.
Signal CloudWatch consolidation Metric streams rather than polling, so you control both latency and cost.
The default CloudWatch integration polls, which costs API calls and adds latency. For estates of any size we move to CloudWatch Metric Streams through Kinesis Data Firehose, which pushes metrics to Datadog in near real time and usually reduces the AWS-side cost of monitoring at the same time.
This is also the point where we decide which CloudWatch namespaces are worth ingesting at all. Ingesting everything is the most common cause of a Datadog bill that nobody can explain.
Cost Cost and usage attribution AWS Cost and Usage Reports alongside the observability data they explain.
Cloud Cost Management ingests AWS Cost and Usage Reports so spend sits in the same timeline as deployments and performance changes. A cost spike and the change that caused it appear together rather than in a monthly review.
This depends entirely on tag discipline, which is why tag collection is step one and not step six.
Data residency, and what it means for a UK AWS estate
Where your telemetry is stored is a separate decision from where your workloads run.
Running in eu-west-2 does not by itself mean your observability data stays in the UK. Datadog has historically operated a US site and an EU1 site, with EU1 storing data in Frankfurt, and has been expanding its data residency options since. For most UK organisations EU1 is sufficient. For those with an explicit UK-only mandate, notably parts of financial services, healthcare and the public sector, it is a question to settle before ingestion begins rather than after.
Moving site region after the fact means re-instrumenting and losing history, so this is worth ten minutes at the design stage. We cover the detail in our guide to Datadog UK data residency, DORA and NIS2.
We operate and evidence the runtime controls that support your compliance obligations: retention configured to your policy, access controlled through SSO and role mapping, and audit trails that show who changed what.
How a Datadog for AWS engagement actually runs
Four named services, used in the order that fits where you are.
Trial FETCH Complimentary trial enablement, so an evaluation produces a real answer.
If you are still deciding, FETCH gets a Datadog trial instrumented properly rather than half-configured. Most trials fail because nothing meaningful was connected, not because the platform was wrong.
Rollout LaunchPad Fully project-managed rollout across accounts and environments.
LaunchPad is the full implementation: integrations, agent rollout, tag model, dashboards, monitors and runbooks, delivered as a managed project rather than a pile of tickets.
Assess HealthScan Read-only assessment of an existing Datadog estate.
If Datadog is already in place and underperforming, HealthScan is an independent read-only review producing a health scorecard and a prioritised backlog. It is the right starting point when the question is what to fix first.
Run Managed Observability Ongoing operation of the platform, powered by Datadog.
We run the platform month to month: monitor tuning, noise reduction, cost governance and coverage as the estate changes. Critical Cloud is the world's first Powered by Datadog accredited MSP.
UK Datadog partner
The world's first Powered by Datadog accredited MSP. What we do, how we work, and the proof behind it.
Read about our Datadog practice →Frequently asked questions
Direct answers to the questions we are asked most often.
Q Do I need Datadog if I already use CloudWatch?
CloudWatch and Datadog solve different problems. CloudWatch is the native collection layer for AWS telemetry and remains the source of truth for many services. Datadog is the correlation layer: it brings metrics, traces, logs and synthetics from across accounts and regions into one queryable view with a shared tag model. Most teams keep CloudWatch as the collector and use Datadog for investigation, alerting and cross-service correlation. The two are complementary rather than alternatives.
Q Does Datadog store UK data in the UK?
Datadog has historically operated a US site and an EU1 site, with EU1 storing data in Frankfurt, and has been expanding its data residency options. For most UK organisations the EU1 site is sufficient. Organisations with an explicit UK-only data residency mandate should settle the site region before ingestion begins, because changing it later means re-instrumenting and losing historical data.
Q How long does a Datadog rollout on AWS take?
It depends on the size of the estate and how many accounts are involved. A single-account environment can be meaningfully instrumented in days. A multi-account organisation with ECS, EKS, Lambda and managed databases is a project measured in weeks, most of which is integration and tag modelling rather than agent deployment. Our LaunchPad service delivers this as a managed project with a defined scope.
Q Will Datadog increase our AWS bill?
It can, if CloudWatch API polling is left at defaults across a large estate. Moving to CloudWatch Metric Streams usually reduces the AWS-side cost of monitoring while also lowering metric latency. The larger cost question is the Datadog bill itself, which is driven by log volume, custom metric cardinality and APM host count. We govern all three from day one rather than treating cost as a later problem.
Get Datadog working properly on AWS
Whether you are evaluating Datadog, rolling it out across accounts, or trying to fix a deployment that is noisy and expensive, we can help.