Who We Worked With
Our client was a healthtech company based out of Hyderabad, building an AI-driven hospital and clinic management platform used by hospitals and clinics across India for OPD/IPD workflows, pharmacy stock, lab reporting, billing, and patient communication. Like most healthtech platforms handling real patient and hospital data, uptime and trust weren't optional for them — a false alarm that led to blocking real doctors and patients would have cost just as much as missing a genuine attack would have. We're keeping their identity anonymous at their request; we'll just call them "the client" here.
The Problem: A Spike Nobody Could Explain
It started with a message from the client's engineering team. Their production traffic had jumped, and it hadn't done that in months. Nobody on their side could say with confidence what was behind it — a hospital rolling the platform out to a new location, a feature quietly catching on among clinic staff, a bot scraping patient-facing pages, or the opening moves of something worse.
They came to us with one question, and they didn't dress it up:
Is this real usage, or are we being attacked — and how do we actually know?
We could tell the question was weighing on them more than they were letting on. Healthtech platforms sit on patient records, billing data, hospital operations — the kind of data that makes you want to slam the door shut the moment something looks off. But we also knew that slamming the door on a false alarm meant real doctors couldn't pull up a patient's chart and real front-desk staff couldn't close out a bill. Whichever way this went, getting it wrong would cost them something real.
Current Infrastructure: What We Walked Into
The client ran their production backend on Amazon ECS behind an Application Load Balancer — a clean, fairly standard containerised setup, nothing unusual about it. But when we sat down to actually investigate, we found the environment had almost none of the usual traffic-forensics groundwork laid:
- No AWS WAF — nothing was inspecting requests before they reached the application.
- No VPC Flow Logs — no network-layer visibility at all.
- No ALB access logs — no request-level record of who was hitting which URL, from where, or with what.
- No baseline alarms — no automated way to know a spike was even happening, beyond someone noticing the dashboard looked different one morning.
None of this was unusual to us, and we said so. Infrastructure tends to get built for uptime and scale first; the forensic layer usually gets bolted on later, often only after something forces the question. Our job wasn't to make the client feel behind — it was to answer what they were actually asking, using what CloudWatch already gave us for free, and then be straight with them about what that answer was and wasn't worth.
What We Did: Reading the Signals Before Reaching for a New Tool
We didn't start by pitching a stack of new security tooling. That would have taken days to stand up, and it still wouldn't have answered the client's question that week. Instead, we went back to four metrics that any ALB and ECS setup already produces, and we read them together, because on their own each one only tells half a story.
1. Did the traffic arrive as a cliff, or did it climb?
We pulled RequestCount across a three-month window. A bot flood or a DDoS attempt tends to look like a wall — flat for weeks, then a five-to-tenfold jump inside a few hours. What we found instead was a slow staircase: request volume had climbed roughly three-and-a-half to four times over three months, and the specific days the client had flagged were just another 15–20% on top of a trend that was already heading upward. That shape belonged to organic growth, not an attack switching on.
2. Was the traffic finding real pages, or guessing at ones that didn't exist?
We compared 4XX errors — not-found, unauthorized, bad requests — against successful 2XX responses. Scanning and credential-stuffing traffic usually throws off a 4XX count that grows with volume, because the more requests an attacker fires, the more of them miss. Here, the 4XX count barely moved across three weeks even as total traffic nearly doubled, working out to well under 1% of requests. Whoever was sending this traffic was landing on pages that existed.
3. Was the backend actually struggling to keep up?
We checked 5XX server errors, looking for signs the backend was choking under the load. The rate we found was a small fraction of a percent — nowhere near a server in real distress. We did flag two brief, narrow 5XX spikes for the client to look into separately, not because they pointed to an attack, but because an unexplained error spike is worth understanding regardless of what's causing the traffic. We were upfront with the client here too: a flat CPU or memory graph during one of these spikes doesn't clear the backend by itself. It usually just means the bottleneck was hiding somewhere else — a database connection pool, a slow downstream call, a deployment happening at the wrong moment — and we handed them a checklist to chase that down properly.
4. Were real people doing real work, or was a script hammering one cheap page?
This was the signal that told us the most. We looked at response time against traffic volume. A bot hammering a single lightweight endpoint — a health check, a static page — tends to keep latency flat, sometimes even lower than usual, because there's no real business logic underneath it. In the client's case, latency rose right alongside the traffic peak. That's what it looks like when actual logged-in users are triggering actual database reads and writes, not a script bouncing off a cache somewhere.
The Honest Part: What This Could Prove, and What It Couldn't
This is the part of the story we think matters most, and it's the part a case study usually skips. We didn't tell the client they were completely safe, because we couldn't have honestly said that. What we told them was exactly what the data could support, and no more:
Every signal that usually points to a crude bot flood or a DDoS attempt was missing here, and the one signal that was present — latency rising with load — is the opposite of what an automated attack usually looks like. We'd put this at somewhere around 90–95% confidence that this was organic growth, not an attack. That's a decision-grade answer — enough to stop panicking and stop blocking real traffic — but it's not the same thing as being certain.
We were plain with them about where that remaining gap came from. CloudWatch metrics tell you what traffic looks like in the aggregate; they can't tell you who's actually behind it. A well-built, distributed bot using rotating IPs, realistic browser sessions, and randomized timing wouldn't necessarily have shown up as an anomaly in any of the four signals we'd just walked through. Neither would something quieter — slow credential stuffing, or scraping — which can look identical to ordinary browsing at the metric level. We laid all of this out plainly, because a team making calls about patient-data infrastructure deserved to know exactly how much weight our analysis could carry, not a false sense that the question was fully closed.
What we could tell them, with real confidence: nothing in the data pointed to an active attack, and there was no reason to throttle or block the traffic they were seeing that week.
Where We Left Things
Confidence without full visibility isn't a place to stop — it's a place to build from, and we said as much to the client. Alongside our findings, we handed them a short, prioritized list of what to close next:
- Turn on ALB access logs — a single configuration change, no downtime — so the next question like this could be answered at the request level instead of only in aggregate.
- Enable AWS WAF in count-only mode with AWS-managed rule groups, including Bot Control — giving them behavioral bot detection without blocking a single real request while they got comfortable with the rules.
- Turn on VPC Flow Logs and GuardDuty — both near-zero effort, and between them they closed the network-layer and threat-intel blind spots entirely.
- Set baseline CloudWatch alarms — so the next spike would get flagged automatically, instead of relying on someone happening to notice a dashboard looked different.
None of it called for a re-architecture. Everything on that list was something the client could do inside their existing AWS setup, in days rather than months — which mattered, because their engineers had a product to build, not a security overhaul to run.
Why This Approach Worked
Healthtech companies don't get to guess. Getting this wrong in either direction — missing a real attack, or locking out real doctors and patients over a false alarm — costs more than an engineering ticket. We didn't come in trying to sell a bigger toolchain. We came in to answer the question the client actually asked, using what they already had, and to be honest about exactly how much that answer was worth.
That's the standard we tried to hold ourselves to on this engagement, and the one we hold ourselves to on every one since: give a client a decision they can act on today, and an honest map of what's still worth building.
Sitting with a traffic spike you can't quite explain? Metasips helps engineering teams get a clear, honest read on their infrastructure — using what you already have before we ever recommend what you don't. Get in touch and let's look at what you're seeing.