Secure Serverless Platform for a Human Rights NGO

Context & Pain Points

The organisation works on labour rights and human trafficking, so the people in its records are often the ones most at risk if those records leak. The platform had to hold personal details, sign-in identities and case information, and every one of those is worth protecting more carefully than an ordinary web app would. The team running it was small and the budget was a nonprofit's. That ruled out a fleet of always-on servers that someone would have to patch, size and watch. Usage also came in bursts, around field reporting rounds and campaigns, with long quiet stretches between them. Paying for peak capacity all year would have spent money the organisation needed for its actual work. Because the data was sensitive, it had to stay off the public internet wherever the architecture allowed. Someone also had to hear quickly if anything in the account started to look wrong.

What We Had To Solve

• Keeping sensitive records off the public internet while running serverless. Lambda is easiest to run outside a VPC, but then every call to a database or bucket leaves the private network. The functions needed private paths to RDS, DynamoDB and S3 without giving up the serverless model.
• Paying for real use, not for peak. Traffic arrived in bursts around field reporting rounds, and an always-on fleet sized for those bursts would have sat idle most of the year on a nonprofit budget.
• Running a Django application without managing servers. The existing code was a Django app, and rewriting it as separate microservices was not a good use of a small team's time.
• Handling sign-up and identity safely. Passwords, verification and account recovery are easy to get wrong in custom code, and a mistake there exposes exactly the people the organisation protects.
• Knowing quickly when something goes wrong. A small team cannot watch logs all day, so findings had to reach them instead of waiting to be found.

How We Built It

• Attached the Lambda functions to private application subnets in two Availability Zones. RDS sits in an isolated subnet with no internet route, and DynamoDB and S3 are reached through gateway VPC endpoints. Only outbound calls that genuinely need the internet leave through a NAT gateway.
• Put AWS WAF in front of an API Gateway REST API, so requests are filtered before any function runs. The public entry point is a managed service rather than a server.
• Ran the Django application as a Lambda function behind API Gateway, alongside small single-purpose functions for user management, user profiles and email.
• Handed sign-up, sign-in and account recovery to an Amazon Cognito user pool, so password storage and verification never live in application code.
• Moved email off the request path. A sign-up publishes to an SQS queue, an email function consumes it and sends through SES, and a slow mail provider no longer slows a sign-up. EventBridge triggers scheduled work and SNS sends notifications out.
• Turned on AWS Config, GuardDuty, Security Hub and Macie across the account, with Macie looking for personal data in S3. Function logs go to CloudWatch.

Outcomes That Mattered