- Learn about the different observability tools provided by AWS
- Learn about how third-party tools can provide value to an AWS observability strategy
Amazon Web Services, or AWS, is the world’s most popular cloud by market share. That means there’s a good chance that if you use the cloud today, you use AWS.
And if you use AWS, you need to monitor and observe your AWS workloads. AWS observability is critical for keeping ahead of performance or availability issues that could undercut the value of your AWS environment.
To observe most types of AWS workloads, you’ll need a mix of tools. Some, like CloudWatch, are native to the AWS platform. Others – such as LogDNA – are third-party solutions that integrate deeply with AWS but provide additional observability features beyond those offered by AWS.
Keep reading to overview both types of AWS observability tools and what to look for in each.
AWS Observability Tools Provided by AWS
The first category of AWS observability solutions consists of tools that AWS develops and delivers to customers as SaaS solutions. The key offerings in this domain include:
- AWS CloudWatch: CloudWatch is an observability service that can collect data from various other services and workloads running in the AWS cloud. It’s also configurable to generate alerts (or “alarms,” which CloudWatch calls them) to notify your team when observability data pass predefined alerting triggers.
- AWS CloudTrail: CloudTrail logs account activity across an AWS environment. It’s not an observability solution per se; it’s more of a security and auditing tool. Still, the insights that CloudTrail provides can help to contextualize observability data. You can, for example, use CloudTrail to determine whether certain types of account activity or API usage correlate with performance or availability issues.
- AWS CodeGuru: CodeGuru is designed primarily to help developers identify performance and security issues within their code. While not the same as observability, CodeGuru may be useful when you need to trace app-level performance problems back to the code that causes them.
Beyond these tools, which support various cloud services and workload types, many specific AWS services provide basic observability functionality of their own. For example, you can track some simple health information about EC2 instances in the AWS console when managing workloads deployed in EC2. The EKS console provides similar insights for Kubernetes clusters. But these features are just dashboards that are useful for glancing at the status of a specific workload; they’re hardly full-fledged observability solutions.
Advantages and Disadvantages of AWS’s Observability Tools
AWS possesses deeply integrated observability solutions. You don’t need to install or deploy anything in the AWS cloud to use these services; you need to turn them on and access them through the AWS console (or CLI or API, depending on how you choose to deploy the tools and collect data from them).
AWS’s observability solutions’ main limitation is that they only provide essential monitoring and observability functionality. They let you collect performance data from AWS services and workloads, and they can surface some insights about anomalies or disturbing trends, but they don’t provide advanced, correlative data analysis.
A second limitation of AWS’s in-house observability tools is that they work only with AWS. You can’t use them to monitor workloads running in other clouds or on-premises. (Some can be used within a hybrid cloud environment running on AWS Outposts, which provides a limited ability to extend AWS observability to on-premises infrastructure, but only under specific configurations.)
Third-Party AWS Observability Tools
Third-party tools and platforms have a critical role in filling the gaps in AWS’s observability offerings.
Take LogDNA, for example. Compared to solutions like AWS CloudWatch, LogDNA provides several important advanced features:
- The ability to correlate data from various sources and surface complex trends or anomalies.
- More granular and fine-tuned alerting rules.
- Support for archiving (and, if desired, restoring) observability data from various storage solutions.
- Plain-English syntax to enable simple querying of logs.
- The ability to access logs in real time using LogDNA’s live tail feature.
- The ability to observe multiple environments – including but not limited to AWS – through a single tool.
That last point is critical. It means that a tool like LogDNA can serve as a centralized observability hub for all of your workloads, regardless of which combination of on-premises, public, private, or hybrid cloud environments your organization uses.
What’s more, when put together, all of these features help bridge the gap between users’ responsibilities and the cloud provider’s responsibilities under the AWS shared responsibility model. By empowering users to identify, investigate and remediate potential security issues within their AWS workloads, LogDNA helps them hold up their end of the shared responsibility bargain.
The above is not to say that you should never use AWS’s observability tools. Solutions like CloudWatch and CloudTrail certainly have their place in a modern AWS observability strategy. They support essential monitoring and auditing needs. Since the effort to deploy them is zero (since they are built into AWS by default), it never hurts to set them up.
But unless you have a straightforward AWS environment, you’ll benefit from the additional context, alert management, and data lifecycle management features that tools like LogDNA provide. Those features round out an AWS observability strategy while also making it easy to observe all of your environments – including but not limited to AWS – in a streamlined way.