Security

Small Agents, Smaller Blast Radius: Controlling What AI Can Do, (Fri, Oct 16th)

Leave a comment
This post was originally published on this site

I believe the cybersecurity industry may be approaching AI security the wrong way.

AI agents are becoming more powerful every day. Systems like ChatGPT, Claude, and Grok can write and execute code, use command shells, browse the web, call APIs, interact with MCP servers, and access enterprise data. Yet much of the industry is taking these extraordinarily powerful, general-purpose agents and trying to make them safe by building cages around them. We add containers, policy layers, monitoring, guardrails, and humans in the loop.

I think that’s backwards. If the companies building these models struggle to control their behavior, why do we assume we can reliably contain them? And when in human history has requiring a user to click a button before something dangerous happened EVER worked?

Even if you build the perfect cage, the model you tested in your cage will eventually change. Providers retire models, and moving to a replacement means revisiting your assumptions and testing. Your application code may be unchanged, but the component deciding what to do next is different.

In my opinion, we should use these agents, which are very good at coding, to build smaller, single-purpose agents. If an agent only needs to read logs from one directory, why give it functions that can read, write, or execute things anywhere on the system?

This isn’t a new idea. It’s the principle of least privilege and seperation of duties. But somehow, when we build agents, we seem willing to hand over broad access and ask the model to use good judgment.

This is the guiding philosophy behind SANS SEC573: AI-Powered Security Automation, where we learn to vibe code these focused agents into existence. Use the powerful coding agent to build a better agent. Give the resulting agent only the access it needs to do its job. 

An October 15 article from Check Point provides a good case in point.

Imagine asking an AI security agent to investigate a suspicious login. It retrieves authentication logs, checks the source IP, and identifies several potentially affected accounts. Then it disables them. The agent may have correctly identified suspicious activity. Disabling those accounts might even be appropriate. But you asked it to investigate. Somewhere along the way, it expanded its assignment.

Check Point’s article describes its Dangerous Deviation Detection capability, which evaluates proposed tool calls before execution. The problem extends beyond prompt injection. An agent can misunderstand a request or take its assignment too far without an attacker being involved.

The detector sits between the model choosing a tool call and the application executing it. It evaluates the proposed operation and its arguments against the task. The application can then stop the action, request approval, or give the agent feedback so it can try another approach.

According to Check Point’s technical documentation:

  • The beta detector flags actions that are both dangerous and unwarranted. Its danger categories include data leakage, access or privilege escalation, and destruction of persistent resources.

  • It looks for justification in user and system messages. Instructions in tool responses or other external content do not count as authorization.

  • The application submits conversation history, the proposed tool call in the final assistant message, and tool definitions in the top-level tools field of a Guard API request.

  • Setting "breakdown": true returns fields including reason_code, reason, agent_guidance, and debug_info.dev_tips.

The distinction between dangerous and unwarranted is important. An irrelevant but harmless action can pass. A dangerous action supported by trusted instructions can also pass. Check Point separately documents a deterministic tool allow/deny list and describes the beta detector as favoring fewer false positives over catching every marginal case. Its a solid approach.

Those are documented product behaviors, not results from my own testing.

I can see value in checking proposed actions. But my first question comes before that check: Why does the investigation agent have permission to disable accounts?

The human analyst might need that permission. The agent performing this particular task does not. Seperation of Duties and the Prinsicle of Least required access are screaming in their graves.

An investigation agent can collect evidence and recommend containment using narrowly scoped, read-only access. If containment is needed, a separate workflow can perform the authorized operation against the specified accounts.

That boundary needs to exist in code and credentials. Removing a tool from the list shown to the model is not enough if the executor still accepts it. Restricting tools also accomplishes little if the agent has a general-purpose shell running with administrative credentials.

The same rule applies when agents work together. If the investigation agent can freely tell a privileged response agent to disable accounts, it still has an indirect path to that capability. The receiving workflow must check authorization and scope for itself. “The other agent said you approved it” should not be enough.

There is another implementation detail worth watching. Check Point’s detector distinguishes trusted messages from external content. If your application copies an untrusted ticket into a user message, you may blur that distinction. A sentence in a ticket claiming that someone approved an action is evidence to evaluate, not permission to execute it.

You can test these boundaries with ordinary requests:

  • Ask for an incident summary. Does the agent try to close the ticket?

  • Ask for a list of inactive accounts. Does it try to disable them?

  • Put a fabricated approval in a retrieved document. Does the application accept it?

  • Approve an action against one account. Can the agent expand it to several?

  • Deny an action. Can it accomplish the same thing through another tool or agent?

Watch both what the model proposes and what the application allows. An unauthorized attempt that gets blocked tells you a control worked. An agent that happens to behave correctly does not prove the control exists.

I’m not suggesting we abandon monitoring, guardrails, or approval workflows. I’m suggesting we stop making them responsible for containing capabilities the agent never needed.

Before building a better cage, ask why you gave the agent that much access in the first place. Then have the agents build their own cages by writing single purpose agents with only those tools that are required. I'll show you how in SEC573.

Sources: Check Point’s October 15 article and Agent Behavior Defense documentation.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Orphaned VBA Projects Inside DWG Files, (Wed, Oct 14th)

Leave a comment
This post was originally published on this site

Years ago I wrote diary entries about VBA code stored inside AutoCAD drawing files (.dwg).

In a nutshell: the VBA code is stored inside an OLE file, that is embedded inside the DWG file. You can do a brute-force search for the embedded OLE file, or you can follow a pointer inside the header of the DWG file.

I wrote a small Python script (autocad.py) for this second case. It looks at a 32-bit pointer at position 0x24 inside the DWG file. This points to a 16-byte long header, followed by the embedded file. This 16-byte long header contains the length of the embedded file. You use the script together with my tool cut-bytes.py, like this:

cut-bytes.py -S autocad.py -P AutoCAD : 461ed52aeb75384133a8238b2eb481ae5d505d4961effa622673d65a889c8218.vir.zip | oledump.py

 

This command carves the DWG file (inside the ZIP file) and extracts the embedded OLE file, and pipes it into oledump.py for analysis.

When the pointer is zero, there is no embedded OLE file, and cut-bytes.py returns nothing.

Recently, I discovered 2 DWG files that are an exception: their pointer to the embedded OLE file is zero, but if you do a brute-force search, you will find an embedded OLE file with a VBA project.

For example this DWG file.

Its pointer to the embedded VBA project is zero:

But it contains an embedded OLE file:

And right in front of the embedded OLE file, there is the 16-byte long header that contains the lenght of the embedded file.

Using the AutoCAD script to extract the file gives nothing:

But oledump.py can find the embedded OLE file and analyze it:

So while using oledump.py to analyze DWG files you find a VBA project embedded inside a DWG file, then also verify if it is not orphaned: verify that the pointer at 0x24 is not zero (or use the autocad.py script).

Because when a DWG file contains an orphaned VBA project, the VBA code can not have executed when someone opened the DWG file with AutoCAD. AutoCAD "does not see" orphaned VBA projects.

Notice that a default installation of AutoCAD does not support VBA. VBA for AutoCAD is a separate install.

I don't know how orphaning happens, but I did find an AutoLISP command to remove a VBA project from a DWG file: 

(dictremove (namedobjdict) "ACAD_VBA")

Maybe this dictremove command clears the pointer, but does not remove the embedded OLE file.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AWS

AWS Weekly Roundup: Prime Day 2026 by the numbers, Claude Haiku 5.5, Amazon Nova 2.5 Sonic, and more (October 13, 2026)

Leave a comment
This post was originally published on this site

Some numbers are hard to picture until you sit with them for a moment. Last week we published the Prime Day 2026 metrics, and the one that stuck with me is 2.3 quadrillion: the daily requests Amazon ElastiCache peaked at during the event. Prime Day ran back in June, so this post always lands as a retrospective, and that gap is part of what makes it worth reading. By the time the numbers reach you, the only evidence that any of it happened is that nothing went wrong.

The rest of the week pulled in a different direction: smaller, cheaper, and more constrained. Claude Haiku 5.5 arrived on Amazon Bedrock at roughly 75 percent less than Haiku 4.5, Amazon Nova 2.5 Sonic made voice agents quicker on their feet, and Strands Box showed up to put real boundaries around what an agent is allowed to do. Now, let’s get into this week’s AWS news…

Headlines

All the numbers: Amazon Prime Day 2026 powered by AWS is the latest entry in a tradition that goes back to 2016, and the scale is still difficult to hold in your head. Over the four days of Prime Day, Amazon DynamoDB processed more than 59 trillion requests while peaking at 192 million requests per second, and kept single-digit millisecond responses throughout. AWS Lambda handled over 2.3 trillion invocations per day. Amazon EBS peaked above 24.8 trillion I/O operations, moving more than an exabyte of data daily. Amazon ECS launched an average of 158.3 million tasks per day on AWS Fargate, a 47.7 percent jump over last year, and AWS Graviton powered up to 49 percent of the Amazon EC2 compute that Amazon.com used.

The number I keep coming back to, though, isn’t a throughput record. The team ran more than 44,000 AWS Fault Injection Service experiments ahead of the event, more than six times what they ran in 2025. Those are deliberate failures injected on purpose, months in advance, so that the trillions of requests above turn into an ordinary shopping afternoon. If you’re preparing for your own peak moment, AWS Countdown Premium is built for exactly that kind of planning.

Last week’s launches

Here are some launches and updates from this past week that caught my attention:

  • Claude Haiku 5.5 is now available on AWS – You can now use the fastest model in the Claude 5.5 family on Amazon Bedrock and Claude Platform on AWS, at around 75 percent less than Claude Haiku 4.5 for most tasks. It’s the first Haiku with effort controls, so you can tune cost against intelligence per task instead of fixing one setting for a whole workload. It pairs naturally with Claude Opus 5.5: Opus plans and makes the judgment calls, and because Haiku is fast and cheap, you can run many Haiku subagents in parallel for routing, classification, and small code changes across many files.
  • Amazon Nova 2.5 Sonic for voice agents – You can now build real-time voice agents on a speech-to-speech Amazon Nova model with better reasoning, instruction following, and tool-calling accuracy, plus lower latency. That combination matters for multi-step work: a support agent can look up an order, check return eligibility, and start the return inside one conversation. It keeps expressive voices in seven languages, controllable turn-taking, and a 256K context window, and pairs with Strands Bidi Agents, now generally available, to get a production voice agent going in a few lines of code.
  • Amazon GuardDuty RDS Protection now detects data exfiltration and destruction – Amazon GuardDuty now looks past login anomalies to the queries themselves on Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL. RDS Protection for data activity builds behavioral baselines and uses ML-based anomaly detection plus threat intelligence to flag unusual data access, with no agents, extra infrastructure, or database configuration changes. This closes a real gap: once an attacker has valid credentials from phishing or a misconfiguration, their queries can look indistinguishable from your application’s.
  • AWS Lambda supports OAuth for self-managed Apache Kafka event sources – You can now authenticate Lambda Kafka consumers through your enterprise identity provider, such as Amazon Cognito or Okta. Event source mappings previously supported only SASL/PLAIN, SASL/SCRAM, and mTLS, which left teams in regulated industries unable to use Kafka ESM at all. Now you get the automatic scaling, batching, error handling, and event filtering of Kafka ESM with the same identity governance you apply everywhere else. It works with self-hosted clusters and managed offerings including Confluent Cloud, Aiven, and Redpanda.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news

Here are some additional posts and resources that you might find interesting:

  • Introducing Strands Box: AI agent sandboxes powered by Dogwood – As more of us let agents run shell commands and call APIs without approving every step, isolation alone stops being enough. Strands Box is an open source sandbox (Apache 2.0, developer preview) that combines OS-level containment with fine-grained policies written in Dogwood, so permissions can depend on what the agent has already done. You can say “let the agent post to the incident channel, but no more than three times every 10 minutes” and have that enforced from outside the agent’s process. It also keeps real credentials out of the agent’s environment by attaching them at an egress gateway.

Upcoming AWS events

Check your calendar and sign up for upcoming AWS events:

  • AWS re:Invent – re:Invent returns to Las Vegas from November 30 to December 4, and reserved seating is now open. The session catalog is live, so register and claim your spots in chalk talks, workshops, and builders’ sessions before they fill up.

Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.

That’s all for this week. Check back next Monday for another Weekly Roundup!

– Daniel Abib

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

AWS

Announcing AWS Lambda Web Functions

Leave a comment
This post was originally published on this site

Today, we’re announcing AWS Lambda Web Functions, a new form factor that lets you run standard HTTP web applications on Lambda without rewriting your code into an event handler. You can take a standard port-listening server built with Express, Hono, Fastify, Next.js, or any Node.js framework, deploy it with a single command, and Lambda automatically handles scaling, multi-region distribution, and active CPU billing. No adapters, no infrastructure to manage, and no framework lock-in.

With this launch, AWS Lambda now offers three distinct form factors, each built on the same Firecracker isolation technology and designed for a different programming model.

Lambda Event Functions are what you already know as Lambda functions. They use the event-driven, single-concurrent handler model with wall-clock billing. We’re introducing the “Event Functions” name to highlight that programming model: your function receives an event, processes it, and returns a response. The event-driven programming model is ideal for event processing, queue consumers, and invocations triggered by other AWS services.

Lambda Web Functions use an HTTP-native programming model with multi-concurrent execution and active CPU billing. Your code listens on a port and handles standard HTTP requests. That programming model is ideal for web applications, API backends, and interactive HTTP workloads where multiple concurrent requests and I/O-heavy processing are the norm.

Lambda MicroVMs provide isolated, stateful sandbox environments with customer-managed lifecycles for running untrusted or user-generated code.

The three complement each other. An application might use Event Functions for asynchronous backend processing, Web Functions for the user-facing API and server-side rendering layer, and MicroVMs for interactive code execution features, all within the same AWS account and sharing the same operational model.

Why Web Functions

Modern web applications need to serve global audiences with fast, consistent response times while giving developers the freedom to use standard frameworks and iterate quickly. Building this today typically requires assembling multiple infrastructure components, configuring multi-region deployments, setting up latency-based routing, and tuning billing models to avoid paying for I/O wait. Developers often find themselves adapting their application code to fit a specific compute model rather than deploying the HTTP server they already have.

Lambda Web Functions removes this complexity. Each execution environment handles multiple requests simultaneously (up to 128 concurrent requests per environment), which means a burst of incoming traffic can share warm environments instead of mapping each request to a new one. Web Functions meter the CPU time your code uses, so time spent waiting on a database query or an API call consumes little CPU. Memory is metered for as long as the execution environment exists. For I/O-heavy web workloads like server-side rendering, API backends, and AI inference endpoints streaming token responses, this can reduce compute costs.

Let’s try it out

To get started, I wrote a simple Express.js server. This is the same code I run locally with node index.js, no Lambda-specific adapters or wrappers required.

import express from 'express';

const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');

app.get('/', (req, res) => {
  res.json({ message: 'Hello from Lambda Web Functions!' });
});

app.listen(port, host, () => {
  console.log(`Server running on port ${port}`);
});

The only difference from running locally is the AWS_LAMBDA_HTTP_ENDPOINT environment variable, which Lambda sets to the host and port your server must listen on. To run locally, set it yourself, for example AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js.

With my code ready, I deployed using the AWS Command Line Interface (AWS CLI):

aws lambda-web deploy --name my-web-app --code ./my-app

One command. No prior resource setup. The CLI bundled my source, created the Web Function, published its first revision, attached a Web Function endpoint, and returned a live HTTPS URL in under a minute.

A revision is an immutable snapshot of the code I deployed. The endpoint is the HTTPS URL that routes traffic to a revision, or splits traffic across revisions. Those are the resources I use to iterate and to control how traffic moves to new code.

I tested it immediately:

$ curl https://<domain-id>.<shard-id>.lambda-web.us-east-1.on.aws/
{"message":"Hello from Lambda Web Functions!"}

Next, I wanted my application to serve users in Europe and Asia with lower latency. I redeployed with multiple regions:

aws lambda-web deploy --name my-web-app --code ./my-app 
    --regions us-east-1,eu-west-1,ap-northeast-1

Lambda Web Functions replicated my code to all three regions and configured latency-based routing automatically. Each request now routes to the Region with the lowest latency for the caller, on a best-effort basis, through one global URL (<domain-id>.lambda-web.global.on.aws).

When I updated my code and ran the same deploy command again, the CLI detected the existing function, uploaded the new revision, and pointed the endpoint at it. Total turnaround from code change to live: seconds.

For production workflows that require a more gradual rollout, I can shift traffic between revisions with a single API call:

aws lambda-web update-web-function-endpoint 
    --function-name my-web-app 
    --endpoint-name dev 
    --auto-deployment-mode Disabled 
    --revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'

This sends 90% of endpoint traffic to the current revision and 10% to the new one, giving me a canary deployment without additional tooling.

Better together with Amazon CloudFront

For applications that combine static and dynamic content, Web Functions works well alongside Amazon CloudFront. You can select a Web Function endpoint as the origin for your CloudFront distribution. Static assets are served from the cache while dynamic requests route to your Web Function, giving you CDN performance for static content with serverless compute for the dynamic parts.

Web Functions improves the private-origin experience with CloudFront. With this launch, you attach CloudFront origin access control (OAC) to a Web Function endpoint instead. CloudFront signs requests to the origin, and the endpoint allows only your distribution to invoke it. You get the same private-origin pattern CloudFront already provides for Amazon Simple Storage Service (Amazon S3), without exposing the endpoint or adding custom authorization to your app.

Now available

AWS Lambda Web Functions is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland). Web Functions run Node.js 24 (nodejs24.x) on Arm64 at launch and support Amazon Virtual Private Cloud (VPC) connectivity, allowing your function to access resources that exist within a VPC.

To get started, deploy your first Web Function in under a minute:

aws lambda-web deploy --name hello-world --hello-world

For pricing details, visit the AWS Lambda pricing page. To learn more, see the Lambda Web Functions documentation.

Security

Reconstructing AI Agent Activity: Two New Scripts for Forensic Review, (Thu, Oct 8th)

Leave a comment
This post was originally published on this site

We just did a major update to FOR577 and added a lot of new material on day 5 about investigating AI usage in incident response. In the new material we dicsuss 8 of the most popular AI coding assistants and agents including Claude Code, Codex, Gemini CLI, Cursor, Copilot, Warp, Windsurf, and Qwen Code. I've been using Claude Code and a little bit of Codex, but I also have recently been playing with OpenCode and am setting up Hermes. I decided to figure out where the chat history was in OpenCode and where any Hermes evidence might be located.

Security

Scans for Atlassian vulnerablity (CVE-2026-21589), (Wed, Oct 7th)

Leave a comment
This post was originally published on this site

On October 5th, Atlassian published patches for multiple products to fix an "Arbitrary File Access" vulnerability [CVE-2026-21589]. An attacker can read arbitrary files in the web application's directory, potentially exposing sensitive information such as configuration files.

This directory traversal vulnerability is a little bit different from the textbook case. Atlassian products replace slashes with the pattern "::". To avoid this issue, but may, in some cases, undo this escape to access files.  Watchtowr has a great write-up with all the details and proof-of-concept URLs demonstrating the vulnerability [Watchtowr].

Starting yesterday, we saw some exploit attempts hitting our honeypot, using the exploit URLs mentioned in the Watchtowr blog. 

/download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml
/s/1.0/_/download/resources/com.atlassian.bitbucket.server.bitbucket-webpack-INTERNAL:avatar/avatar/..::..::..::..::..::WEB-INF::urlrewrite.xml
/s/1/_/download/resources/com.atlassian.confluence.plugins.dashboard-actions/images/..::..::..::..::..::..::..::..::WEB-INF::web.xml

One condition for successful exploitation is that the file the user attempts to access exists. The exploit uses "WEB-INF/web.xml" as it is a required file for Tomcat applications, and can be used similarly to "/etc/passwd". The "/etc/passwd" file will not work in this case. Access is restricted to the web application's directory. The "::" pattern used in the exploit will be translated to "/" on the server, leading to the directory traversal.

Based on the timing and the targets hit, I believe these scans are all triggered by the same threat actor. Oddly enough, all the source IPs are associated with Digital Ocean. The source IPs I see from our honeypots:

134.199.229.190
134.199.230.82
137.184.112.247
137.184.33.84
143.198.103.58
143.198.132.93
146.190.169.1
146.190.172.250
159.223.199.218
164.92.68.152
209.38.147.216
24.199.101.184
64.23.172.129 

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AWS

All the numbers: Amazon Prime Day 2026 powered by AWS

Leave a comment
This post was originally published on this site

Amazon Prime Day 2026 was exclusively for Prime members and ran June 23–26, 2026 with millions of deals across more than 35 categories.

As part of our annual tradition of sharing how AWS powered Prime Day (2016, 2017, 2019, 2020, 2021, 2022, 2023, 2024, and 2025), I want to share the services and chart-topping metrics from AWS that made your amazing shopping experience possible.

Prime Day 2026 – all the numbers

As always, Prime Day was powered by AWS. Here are some of the most interesting and/or mind-blowing metrics:

Amazon Elastic Compute Cloud (Amazon EC2) and AWS Graviton – During Amazon Prime Day 2026, AWS Graviton powered up to 49% of the Amazon EC2 compute used by Amazon.com.

Amazon Elastic Block Store (Amazon EBS) – During Prime Day 2026, Amazon EBS, our high-performance block storage service, peaked at over 24.8 trillion I/O operations, moving over an exabyte of data daily.

AWS Lambda – AWS Lambda handled over 2.3 trillion invocations per day during Prime Day 2026.

Amazon Elastic Container Service (ECS) and Fargate – During Prime Day 2026, Amazon ECS launched an average of 158.3 million tasks per day on AWS Fargate, representing a 47.7 percent increase from the previous year’s Prime Day average.

Amazon CloudFront – Amazon CloudFront delivered over 2.1 trillion HTTP requests during the global week of Prime Day 2026, a 5 percent increase in total requests compared to Prime Day 2025.

Amazon DynamoDB – Amazon DynamoDB, a serverless, fully managed, distributed NoSQL database, powers multiple high-traffic Amazon properties and systems including Alexa, the Amazon.com sites, and all Amazon fulfillment centers. Over the course of Prime Day 2026, between June 23 and June 26, 2026, DynamoDB processed over 59 trillion requests. DynamoDB maintained high availability while delivering single-digit millisecond responses and peaking at 192 million requests per second.

Amazon Aurora – On Prime Day, Amazon Aurora, a relational database management system (RDBMS) built for high performance and availability at global scale for PostgreSQL, MySQL, and DSQL, processed hundreds of billions of transactions, stored 5,491 terabytes of data, and transferred 1,194 terabytes of data.

Amazon ElastiCache – During Prime Day, Amazon ElastiCache peaked at serving over 2.3 quadrillion daily requests and 2.1 trillion requests in a minute.

Amazon Kinesis Data Streams – Amazon Kinesis Data Streams, a fully managed serverless data streaming service, processed a peak of 988 million records per second during Prime Day 2026.

Amazon Simple Notification Service (SNS) – Amazon SNS, a fully managed pub/sub messaging service for application-to-application and application-to-person communication, delivered 5 trillion messages in a single day during Prime Day 2026.

Amazon Simple Queue Service (SQS) – Amazon SQS, a fully managed message queuing service for microservices, distributed systems, and serverless applications, received a peak of 213 million messages per second during Prime Day 2026

AWS CloudTrail – AWS CloudTrail processes billions of API activity events per day for governance, compliance, and operational auditing. During Prime Day 2026, that volume surged to 3.6 trillion events in just four days, a 44% increase over Prime Day 2025.

AWS CloudWatch – Amazon CloudWatch processed over 2.15 quadrillion metric observations per day during Prime Day 2026.

Amazon GuardDuty – During Prime Day 2026, Amazon GuardDuty monitored an average of 14.08 trillion log events per hour, a 59% increase from last year’s Prime Day.

AWS Fault Injection Service (FIS) – We ran over 44,000 AWS FIS experiments – more than six times what we conducted in 2025 – to help ensure Amazon.com remains highly available on Prime Day.

Prepare to scale

If you’re preparing for similar business-critical events, product launches, and migrations, I recommend that you take advantage of AWS Countdown Premium. From retail peak seasons to major sporting events, elections, and healthcare enrollment periods, we help you deliver flawless experiences when it matters most. Our experts help you manage your infrastructure to handle massive traffic spikes while maintaining security and performance. We work alongside your team to scale infrastructure, optimize costs during demand surges, strengthen security measures, and monitor real-time demands. To learn more, visit AWS Countdown Premium for business critical events.

I look forward to seeing what other records will be broken next year!

— Channy