Back to the lexicon

Lexicon · Guide

AWS monitoring built for cost control and data residency

What AWS monitoring covers, why the bill outruns the account it watches, and what changes when the platform runs inside your own AWS environment.

Talk to an architect

Definition

AWS monitoring is the practice of collecting and reading metrics, logs, and traces from the AWS services your applications run on, from EC2 instances and containers through to managed databases and serverless functions, so you can tell whether the platform and the applications on it are healthy. It overlaps with infrastructure monitoring and for most teams it starts with CloudWatch, which is also where the cost question usually turns up for the first time.

Your AWS monitoring bill grows faster than the infrastructure it is meant to explain, and finance wants to know why. Most platforms collect telemetry inside your account, ship it to a vendor's cloud, then charge you again to store what you already paid to generate. This guide covers why that happens, and what changes when the platform runs inside the account instead.

AWS monitoring priced for the account it runs in

AWS monitoring costs tend to rise faster than the infrastructure they cover, and teams end up managing the monitoring bill as closely as the systems it is meant to watch. Three patterns show up again and again once a footprint is large enough to matter.

Monitoring agents collect telemetry inside your AWS account and then ship it to a vendor's cloud to be stored. You pay for S3 and EC2 once inside AWS, then pay again for the same bytes on a second invoice, and egress charges are usually collected on the way out. The gap between the two widens with every service you instrument.

Where Tsuga fits

We built Tsuga for the three problems above, so the architecture is the answer rather than a feature list. It runs where your workloads already run, and the consequences follow from that one decision.

Tsuga Engine installs into your AWS environment through infrastructure as code, typically in under two hours, and runs inside your own VPC encrypted with your own KMS keys. Nothing about the deployment requires telemetry to leave the account that produced it, and our control plane connects over mutual TLS to serve the dashboard without ingesting your data.

Is Tsuga right for you?

At Tsuga we are honest about fit, because AWS monitoring is not one size fits all. Tsuga earns its place when AWS telemetry has become a budget line of its own, typically six figures or more a year, and when data residency or regulatory obligations mean that telemetry cannot sit in someone else's cloud. It also suits teams already running logs, metrics, traces, and APM across a large AWS footprint, and teams who want direct access to the engineers running the deployment rather than a ticket queue.

The opposite conditions point the other way. A small AWS footprint with modest, predictable volume does not yet have the problem this architecture solves, and neither does a team with no compliance or residency obligations to answer to. If you would rather run an in-house open-source stack yourself, or keep the relationship entirely self-serve, you will be better served elsewhere, and we would rather say so now than three months into an evaluation.

Frequently asked questions

CloudWatch stays useful for AWS service metrics and alarms, and Tsuga ingests from it rather than replacing it. What changes is where the long-lived telemetry lives and what it costs to keep, because storage and query run inside your own account instead of a vendor's.

Own your observability

AWS monitoring should not cost more than the infrastructure it watches. Talk to an architect about deploying Tsuga inside your own AWS account, and we will model the cost against the telemetry volume you actually produce.

Talk to an architect

Related terms

Back to the lexicon