African enterprises running on AWS need one observability platform that covers infrastructure, applications, security, and the network in between. Datadog delivers that on a single pane, with native AWS integrations and an Agent that ships at 15-second resolution. This guide walks through the exact setup we use to deploy Datadog on AWS for customers in East and Southern Africa, from the integration role to alert routing.
Key Takeaways
- ✓Connect AWS through CloudFormation in under 10 minutes — no manual IAM role creation needed.
- ✓Use the Datadog Agent for 15-second host metrics, APM traces, and process visibility the AWS integration cannot provide.
- ✓Pick the EU Datadog site (datadoghq.eu) for low latency from African workloads and Frankfurt-resident telemetry.
- ✓Tag everything with env, service, team, and region — Datadog cost control depends on it.
Why Datadog for AWS in Africa
The default observability stack on AWS — CloudWatch, X-Ray, and CloudTrail — works, but lives in three different consoles with three different query languages and inconsistent retention. Teams running production workloads in the AWS Cape Town region (af-south-1) or operating hybrid environments between on-premises and cloud need a single tool to correlate a latency spike with the database query that caused it and the deploy that introduced it.
Datadog covers infrastructure metrics, distributed traces, logs, real user monitoring, synthetic checks, security posture, and network performance under one query layer. Every Kitsilano managed environment uses Datadog as the operational pane of glass, with CloudWatch retained as the system of record for AWS-native alarms and IAM audit logs.
Choosing your Datadog site
Datadog operates several regional sites. The Agent and integrations ship telemetry to whichever site your organisation is provisioned on. For African workloads we recommend the EU site primarily for the lower round-trip latency from af-south-1 to Frankfurt compared with US-East, which keeps Agent overhead and ingestion delays predictable.
| Site | URL | Best fit for African workloads |
|---|---|---|
| EU1 (Frankfurt) | datadoghq.eu | Default recommendation — lowest latency from af-south-1 |
| US1 (Northern Virginia) | datadoghq.com | Use only if a feature is not yet GA on EU1 |
| US3 (Western US) | us3.datadoghq.com | Avoid for African workloads — highest latency |
The site cannot be changed after the organisation is created. Choose carefully, and use sub-organisations if you need to host different environments on different sites.
Step 1: AWS account integration
The AWS integration is the foundation. It gives Datadog visibility into every AWS service — EC2, RDS, ELB, Lambda, S3, ECS, EKS — through the CloudWatch metric stream and the Resource Explorer API. The simplest setup is the CloudFormation quick-start: from Integrations → AWS in Datadog, click Add AWS Account, choose CloudFormation, and Datadog generates a one-click stack URL that creates the IAM role with the correct trust policy and permissions.
For multi-account organisations, run the same stack as a StackSet across all member accounts from the management account, then add each account to Datadog. The integration auto-discovers resources every 10 minutes and tags them with their AWS tags, so any tag taxonomy you maintain in AWS flows straight into Datadog as filter dimensions.
For real-time CloudWatch metrics — useful for autoscaling and alerting — enable a CloudWatch metric stream into Amazon Data Firehose, with Datadog as the destination. This gives second-fresh CloudWatch data without polling, at a marginal cost increase that is usually offset by reducing CloudWatch GetMetricData calls.
Step 2: Installing the Datadog Agent
The AWS integration sees AWS metrics. The Agent sees inside the host. Install it on every EC2 instance, every EKS node, and every on-premises server you want to monitor. The Agent ships host metrics, process data, integration checks for installed services (PostgreSQL, Nginx, Redis, and 700+ others), and acts as the local collector for traces and custom metrics.
For EC2, use Systems Manager Run Command with the Datadog install document, or bake the Agent into your AMI. For EKS, deploy the Datadog Operator with a single Helm chart and a DatadogAgent custom resource — the Operator manages the Cluster Agent, the node Agents as a DaemonSet, and the Cluster Checks Runner pods for you. For ECS, run the Datadog Agent as a daemon task using the official task definition. Always set the DD_TAGS environment variable with at least env, service, team, and region so every host arrives in Datadog already classified.
Step 3: Log collection from AWS
Two log paths matter on AWS. Application logs from EC2, EKS, and ECS workloads are shipped by the Agent — enable logs in the Agent config or via the dd.datadoghq.com/logs annotation in Kubernetes, and they arrive at Datadog with full pod, container, and host tags attached automatically.
AWS service logs — VPC flow logs, ALB access logs, RDS audit logs, CloudTrail — live in S3 or CloudWatch Logs and ship to Datadog through the Datadog Forwarder Lambda. Deploy the Forwarder once per region (via the official CloudFormation template), then subscribe it to the CloudWatch Log Groups you want forwarded. For S3-resident logs, configure an S3 event notification to invoke the Forwarder when new objects land. The Forwarder also delivers Lambda invocation logs and CloudWatch metrics with custom tags applied.
Decide which logs to index, and which to merely archive. Datadog Log Indexing is priced per million indexed events, so use exclusion filters on the pipeline to drop noisy health-check logs and successful auth events before indexing. Send everything to a Datadog Archive in S3 so it remains available for forensic search later at storage-cost-only pricing.
Step 4: APM and distributed tracing
APM gives you the request-level view: which endpoint is slow, which downstream call is the bottleneck, and which deploy regressed performance. Instrument your services with the Datadog tracer library for your runtime — Java, Python, Node.js, .NET, Go, Ruby, PHP, and others — using auto-instrumentation where available. For containers, set the DD_AGENT_HOST environment variable to the node IP using the Kubernetes downward API so the tracer ships spans to the local Agent.
Trace sampling is the cost lever. Run 100% sampling in non-production and the first weeks of production, then move to ingestion sampling tuned per service. Always keep an error-bias sampling rule so failed requests are retained at full fidelity. The Trace Retention Filters page lets you keep specific traces — slow ones, error ones, ones from a particular customer — indefinitely while sampling the rest.
Step 5: Dashboards and monitors
Start with the out-of-the-box AWS service dashboards — Datadog ships pre-built dashboards for every supported AWS service the moment the integration is added. Clone them, tag them with your service tag, and use them as the daily operations view. Build custom service dashboards using the four golden signals: latency, traffic, errors, and saturation. Anchor every chart to a tag, never a hostname, so dashboards survive instance churn.
For alerts, prefer SLO-based monitors over raw threshold alerts. An SLO monitor on a 99.9% availability target lights up only when the error budget is being burned faster than the burn rate threshold, which keeps your on-call rotation sane. Route alerts through PagerDuty, Slack, or Microsoft Teams using Datadog notification channels, and use the @-mention syntax in monitor messages so the right team is paged for the right service.
Keeping Datadog costs predictable
Datadog bills are easy to grow accidentally. Three patterns keep costs in line: tag every host with env, service, team, and region so the Usage page shows you exactly which team is driving spend; apply exclusion filters on log pipelines to drop verbose noise before it is indexed; and watch custom metric cardinality because every unique tag combination on a custom metric counts as a separate metric.
Set usage anomaly alerts on Logs Indexed, Custom Metrics, APM Hosts, and Synthetic Tests at the start of each month. Review the Plan & Usage page weekly during onboarding and monthly after. Kitsilano-managed Datadog tenants ship with a pre-built cost-control dashboard that surfaces the top 10 services by ingest, the top 10 tag dimensions by metric cardinality, and the largest log sources by volume.
Frequently Asked Questions
For workloads running in the AWS Cape Town region (af-south-1), the Datadog EU site (datadoghq.eu) usually delivers the lowest latency from East and Southern Africa. The US1 site (datadoghq.com) is the safer pick if you depend on Datadog products that are not yet available in EU. The Datadog site is set when you create the organisation and cannot be changed afterwards, so confirm before onboarding.
The AWS integration uses CloudWatch metrics, which are polled at 10-minute intervals by default for cost reasons. The Datadog Agent collects metrics directly from EC2, EKS, ECS, and on-premises hosts at 15-second resolution, plus traces and process data the AWS integration cannot see. Production setups should use both: the integration for AWS service inventory and the Agent for high-resolution host and application metrics.
Three controls matter most: tag every host with environment, service, and team so you can attribute spend cleanly; use exclusion filters on the log ingestion pipeline to drop verbose noise before it is billed; and avoid sending high-cardinality custom metrics without sampling. Review the Plan & Usage page monthly and set usage alerts on Logs Indexed, Custom Metrics, and APM Hosts.
Yes, with the right configuration. Enable Sensitive Data Scanner to redact PII before it is indexed, restrict access using RBAC roles and SSO with your IdP, and tune log pipelines so high-risk content is filtered out at ingest. Kitsilano Technologies builds these controls into every Datadog deployment we operate for regulated African customers.
