Context & Pain Points
Field workers collect testimony in regions where a leaked identity puts a source in danger, so the intake path had to protect the submitter as carefully as the record. Interviews and attachments were moving through channels the organisation did not control, with no single place to say who could read a file or how long that access lasted. The public dashboards were the second exposure: they carry the organisation's name, they are a standing target, and a volumetric flood aimed at them also takes down the intake API when both sit on the same origin. Analysts needed map views over the same records, which meant the store had to answer heavy geospatial aggregation without slowing the write path that field submissions depend on.
What We Had To Solve
- Defending high-profile public assets against targeted distributed denial of service attempts, where the same flood that degrades a dashboard also blocks the field intake path if the two share an origin. Absorbing that traffic at the edge, rather than at the application, was the only way to keep the two paths independent.
- Optimizing heavy geodatabase aggregations and analytical query times for localized dashboard mapping, since a map view fans out into far more work than a single record lookup.
- Securing static assets and submission uploads containing highly confidential field interviews, so that possession of an object key is never enough to read the file behind it.
- Keeping analyst reporting traffic and field ingestion from competing for the same capacity, so a spike in one never delays the other.
How We Built It
- Wrapped API ingress zones in Amazon CloudFront distributions with strict AWS WAF rate-limiting and geolocation rules, so filtering happens at the edge and origin tasks only see traffic that already passed.
- Built containerized Node.js processing workers on ECS Fargate that scale on SQS ingestion backlog size, which turns a submission spike into a longer queue and more workers rather than a failed upload.
- Configured private Amazon S3 buckets with KMS server-side encryption and signed, time-limited request URLs, so no bucket object is reachable without a credential the application issued for that request.
- Added custom indexing to the RDS PostgreSQL geodatabase for the aggregations the map views run, keeping the analytical read path off the same query plans as record writes. Report queries read the indexed aggregates, so a slow map render never blocks a submission write.
Outcomes That Mattered
Hardened Defense
Successfully deflected multiple high-velocity DDoS attempts without experiencing any performance degradation, with CloudFront and WAF absorbing the traffic ahead of the Fargate tasks.
Optimized Geospatial Queries
Reduced geospatial map visualization loading times by over 80% using custom indexing, so analysts work from live map views instead of pre-rendered exports.
100% Confidentiality
Secured all upload assets using signed, encrypted URLs, eliminating unauthorized access vectors and leaving every file read attributable to an application-issued grant.
Outcome
The platform runs as containerised Node.js services on ECS Fargate behind Amazon CloudFront, with AWS WAF applying rate limits and geolocation rules at the edge before a request reaches an origin task. A React front end serves both the public dashboards and the authenticated analyst views. Structured records land in Amazon RDS PostgreSQL; interview files and other uploads go to private S3 buckets encrypted with KMS keys and reachable only through signed URLs that expire. Ingestion is decoupled from submission: uploads queue on SQS and Fargate workers scale on backlog depth, so a burst of field submissions lengthens the queue instead of failing at the door. Infrastructure sits behind a single CloudFront distribution, so the public site, the analyst views and the intake API share one edge configuration and one place to tighten a rule when an attack pattern changes.