AWS Shield Advanced Can Now Show You the Attack. For D2C, the Win Is Telling a DDoS From a Flash Sale.

The question AWS Shield Advanced flow logs answer is not "are we under attack" — it is "is this even an attack, or is it the best sales hour of our year." For a D2C brand, those two readings demand opposite responses, and until this launch you were guessing from aggregate graphs while the clock and the AWS bill both ran.

AWS just shipped flow logs for Shield Advanced, giving you packet-level metadata during a traffic event. The security press framed it as DDoS forensics. That is real, but it buries the part that actually moves money for the brands we run AWS architecture for: the same logs are the fastest way to stop over-reacting to traffic you should have just served.

What AWS actually shipped

Shield Advanced already detects and mitigates DDoS attacks against CloudFront, Elastic Load Balancing, Route 53, Global Accelerator, and Elastic IP addresses. What it did not give you was the underlying traffic — only rolled-up metrics. Flow logs change that by capturing metadata during an event and delivering it where you can query it.

Each record carries 14 fields, including srcaddr and dstaddr, srcport and dstport, protocol, packets and bytes, tcp_flags, srccountry (a two-letter code), the AWS ingress location, the sampling_rate, and the Shield action taken on the traffic. Logs aggregate on 5-minute intervals, individual files cap at 75 MB, and you can land them in three places depending on what you need:

Setup is a short pipeline: create the destination, attach a resource policy for the CloudWatch Logs delivery service, grab your protection ARN with aws shield list-protections, then wire put-delivery-source, put-delivery-destination, and create-delivery, and confirm with describe-deliveries. The IAM principal doing this needs logs:PutDeliverySource, logs:PutDeliveryDestination, and logs:CreateDelivery.

The question that actually costs D2C money

Here is the contrarian take we give every founder. The DDoS that takes you down is rare and loud. The traffic event you misread is common and quiet, and it bleeds money either way you get it wrong. Over-react to real demand and you throttle your own customers on the best hour of the quarter. Under-react to junk traffic and you auto-scale a fleet to serve bots, then open an AWS bill that ruins the sale's margin.

A US supplements brand doing about $11M came to us after a "DDoS" that, on inspection, was a Klaviyo campaign and an influencer post landing in the same ten minutes. Their on-call engineer saw the traffic wall, assumed an attack, and scaled the application tier 6x. There was no attack. They served the demand — and a $9,400 surprise on that day's compute, most of it idle capacity that spun up after the spike had already passed. Flow logs would have shown diverse source IPs from their actual customer states and a Shield action of count, not drop. That is a sale to lean into, not a fire to fight.

We have also seen the mirror image: a brand that blamed "a DDoS" for a checkout outage that was really a database connection-pool exhaustion they triggered themselves. They spent two days chasing attackers who never existed. Packet-level truth ends both arguments in about ten minutes.

The five fields that tell a DDoS from a demand spike

You do not need all 14 fields in the heat of the moment. Read these five together and the answer is usually obvious:

The Athena query we run first

With logs landing in S3 as Parquet, this is the first query we point at an event — it ranks source IPs by traffic and shows whether Shield is counting or dropping them. Diversity at the top means demand; concentration means trouble.

SELECT srcaddr,
       srccountry,
       action,
       COUNT(*)        AS records,
       SUM(packets)    AS total_packets,
       SUM(bytes)      AS total_bytes,
       SUM(bytes) / NULLIF(SUM(packets), 0) AS avg_bytes_per_packet
FROM   shield_flow_logs
WHERE  event_timestamp BETWEEN TIMESTAMP '2026-06-04 18:00:00'
                           AND TIMESTAMP '2026-06-04 18:30:00'
GROUP  BY srcaddr, srccountry, action
ORDER  BY total_bytes DESC
LIMIT  50;

If the top 50 rows are 50 different IPs from your core countries with a healthy bytes-per-packet ratio and action = count, stand down and serve the traffic. If a few IPs dominate with tiny packets and action = drop, Shield is doing its job and you should not be scaling compute to meet it. The same data exports cleanly to a one-page board summary after the dust settles.

The caveats AWS soft-pedals

We are not knocking the feature — we are already turning it on for clients. But read the fine print before you build alerting on top of it:

What to do before your next sale

Turn flow logs on now, not during the incident. Land them in S3, define the Athena table, and save the query above so it is one click at 2 a.m. Write the two-line decision rule on the runbook: diverse IPs plus count means scale and serve; concentrated IPs plus drop means hold and let Shield work. Decide the threshold for auto-scaling in advance so nobody makes a $9,400 call on adrenaline.

If you already use Shield Advanced for sales protection — our walkthrough of Shield for DDoS protection during flash sales and the Black Friday peak-shield case study are the companion pieces — flow logs are the missing diagnostic layer that turns "we think we survived an attack" into "here is exactly what hit us and what Shield did about it."

Frequently Asked Questions