What a DDoS Attack Taught Me About Reading Clouds

Lessons from Cloudflare Network Analytics, VPC Flow Logs, and one very loud afternoon

Most days in a SOC have a rhythm. You triage, you document, you tune, you hand over. Then there are days when the dashboard stops being polite and starts shouting.

I remember one afternoon when the alert queue filled faster than I could scroll. Cloudflare Network Analytics was showing a spike that did not look like normal traffic growth. It looked like someone had opened a firehose and pointed it at a client. That was my first real front row seat to a DDoS event, and it changed how I think about cloud visibility.

The first lesson: volume is not the same as impact

When a DDoS alert fires, the instinct is to look at the number. Packets per second. Requests per second. Bandwidth. Big numbers feel urgent, and they are designed to.

But the more useful question is not "how big is this" but "what is this actually doing to the service." A massive flood against a well protected edge can be absorbed with almost no customer impact. A smaller, smarter attack against a weak path can take something down.

Cloudflare Network Analytics gave us the shape of the attack. We could see the traffic profile, the source distribution, and the target patterns. That context let us separate "loud but handled" from "quiet but dangerous." In an incident, the loudest signal is not always the most important one.

The second lesson: your logs tell different stories at different layers

One thing I appreciate now is how many layers of truth exist during an attack.

Cloudflare showed us what hit the edge. VPC Flow Logs showed us what reached the network. Grafana and Dynatrace showed us how the application was breathing under the load. Each source told a different part of the same story, and none of them was complete on its own.

VPC Flow Logs were especially useful because they showed rejected and accepted traffic patterns that the edge view could not. When you correlate edge analytics with flow logs, you start to see where the attack was stopped and where it leaked through. That gap is where the real investigation lives.

A simplified way to think about the flow log side:

AWSVPCFlow
| where Action == "REJECT"
| summarize RejectedCount = count() by SrcAddr, DstAddr, DstPort
| order by RejectedCount desc
| take 20

AWSVPCFlow
| where Action == "REJECT"
| summarize RejectedCount = count() by SrcAddr, DstAddr, DstPort
| order by RejectedCount desc
| take 20

That is not a full detection. It is a lens. It helps you ask better questions about where traffic is being blocked and whether anything is slipping past.

The third lesson: dashboards are only as good as the questions you bring

I used to think of Grafana and Dynatrace as monitoring tools. Now I think of them as conversation partners. They do not tell you what is happening. They tell you what you asked them to show you.

During that event, the useful dashboards were not the pretty ones. They were the ones that answered specific questions:

Is latency rising for real users or only for the attack traffic? Are error rates climbing at the application layer or staying flat? Is the service degraded, or is it just noisy? Which backend is absorbing the most pressure?

Those questions turned a wall of graphs into a decision. Without them, you stare at spikes. With them, you can brief the client, coordinate with the team, and actually do something useful.

The fourth lesson: communication is part of incident response

This is the part nobody puts in the tool documentation.

During a DDoS event, the technical work is only half the job. The other half is telling people what is happening in plain language. Clients do not want a lecture on packet rates. They want to know: is the service up, what are we doing, and when will we know more.

I learned to keep updates short and honest. Here is what we see. Here is what we are doing. Here is what we do not know yet. That last part matters. Pretending you have full clarity when you do not erodes trust faster than the attack itself.

This is also where the NIST and ISO aligned playbooks earn their keep. They give you a spine when your brain is busy. Investigation, containment, communication, documentation. The order matters less than the discipline of not skipping steps.

The fifth lesson: the quiet aftermath is where you learn the most

The attack ends. The graphs flatten. The queue empties. And then the real work begins.

What did we miss? What fired too late? What fired too often? What would have helped us see this sooner? Did our thresholds make sense for this client? Were the right people notified quickly enough?

That review is where detection engineering actually happens. The incident is the exam. The aftermath is the classroom.

After that event, we tightened a few things. We improved how we correlated edge analytics with flow logs. We refined what we surfaced in Grafana so the next on call analyst would not have to rebuild context from scratch. We wrote notes so the next person would not start from zero.

None of that is glamorous. All of it is what makes a SOC better.

What I would tell someone starting out

If you are new to cloud security or SOC work, here is my honest advice about DDoS and cloud visibility.

Do not chase the biggest number on the dashboard. Chase the question behind it. Learn to read more than one log source at the same time. The edge, the network, and the application each know something the others do not. Practice explaining an incident in three sentences. If you cannot, you do not understand it yet. Write down what you learned after every event. Future you is a different person and will need the notes.

DDoS events are loud, but they are also generous teachers. They show you where your visibility is thin, where your playbooks are vague, and where your communication needs work. If you treat them as more than a fire to put out, they will make you a better engineer.

The clouds are not just where our workloads live now. They are where our evidence lives too. Learning to read them is the whole job.