AWS | Resource Center

It’s essential to choose the right tool for the job. I have an old, sturdy screwdriver that I use for lots of odd DIY jobs around my house, like cleaning gutters, opening paint cans, and general maintenance on my lawnmower. However, when I’m performing an upgrade on my computer, a large, rusty screwdriver isn’t the best tool to remove the screws anchoring my motherboard.

Cloud-native and serverless come hand in hand. One of the initial motivations to move business workflows to the cloud was related to cutting costs related to provisioning infrastructure and elasticity that on-demand allocation of resources is offering. The serverless approach takes this to the next level, where infrastructure is provisioned only for the time of code execution, and the whole stack below the executed code, including application components, OS, and hardware (of course) is provided by the cloud vendor. No surprise this approach takes more and more traction, although it’s nothing new.

One of Amazon Web Services’ (AWS) most well-known services is AWS DynamoDB. Some of AWS’s most notable customers use DynamoDB for their database needs – companies such as Netflix, The Pokemon Company, and Snapchat.

Amazon Redshift is a cloud-based data warehousing solution that makes it easy to collect and analyze large quantities of data within the cloud. Cloud data warehouse services like Redshift can remove some of the performance and availability pain-points associated with on-premises data warehousing, but they are not a silver bullet. Getting the most out of Redshift requires carefully monitoring Redshift clusters in order to identify stability issues and performance bottlenecks.

We at Sumo Logic believe in an open, flexible, community-driven approach to collecting observability data. Those reasons are outlined in one of my recent blogs. In that publication, I share the belief that an application’s observability gains traction from the fact that telemetry signals are designed, composed, and produced by an application developer/vendor in compliance with industry standards, and are not a proprietary, black box component of the monitoring vendor.

Modern applications are often built, deployed, and managed as container images. At the same time, however, developers are drawn to serverless technologies for running their code without having to worry about infrastructure. AWS is now helping you bridge the gap between these two paradigms by allowing you to build and deploy serverless AWS Lambda functions with container images. This allows you to harness the power of AWS Lambda without having to rewrite or modify your development workflows.

Today Amazon announced Amazon EKS Distro, a distribution for Kubernetes based on and used by Amazon EKS. Amazon EKS Distro enables you to create secure and reliable Kubernetes clusters using the same versions of Kubernetes and its dependencies deployed by Amazon EKS. Each Amazon EKS Distro release follows the EKS process, verifying new Kubernetes versions for compatibility. The Amazon EKS Distro source code, open source tooling, binaries, and container images as well as configuration are provided for reproducible builds via public Git and S3 storage locations.

We’re happy to partner with AWS on their launch of AWS Network Firewall by providing a cloud-native integration that gives customers real-time visibility into network traffic and automated correlated events surfaced by AWS. Too often, virtual private cloud (VPC) traffic is a black box leaving many security operations teams unable to connect potential threats to their broader infrastructure. This lack of visibility only serves to increase the time it takes security analysts to investigate and respond to potential threats, thereby reducing the organization’s security posture.

As more and more applications move to the cloud, the complexity of application architectures inevitably increases. It is a burden we willingly take on because the benefits—flexible deployment, technology diversity, independent scaling, and much more— tend to far outweigh the costs. But along this transition, most organizations face a dilemma, to divert resources to the necessary tooling for effective monitoring and troubleshooting of these systems – i.e. observability – or slow the rate of migration to the cloud.