AWS infrastructure for a healthcare SaaS platform

We built the AWS infrastructure of a US healthcare platform (SaaS) from scratch. The app runs on Elastic Beanstalk with Nginx. A 23-rule traffic filter and an automatic script that blocks scanners protect it, and ready-made log queries show what is happening.

Real project, unnamed

Industry	Healthcare & clinics · SaaS & technology
Challenge	Trust and credibility
Decision environment	Supervised
Complexity	High
Service	Cloud setup

When an app handles sensitive data, such as health data, the infrastructure is what protects that data every day. This case study shows the order in which the protection was built, why each piece was chosen, and how someone who is not an engineer can still read what is going on.

AWS infrastructure for a healthcare SaaS platform What was the starting situation?

A healthcare platform delivered as software (SaaS) in the US needed cloud infrastructure, built from scratch. There was no environment, no filter and no ready-made log query. A healthcare product is about people and their health, so the infrastructure had to be right from day one.

We took the cloud side. We set up the environment where the app runs, protected it, and gave the platform team a simple way to watch it.

Starting from zero has one advantage: nothing old has to be changed. It also needs care, because every choice is made on purpose and written down.

AWS infrastructure for a healthcare SaaS platform What did the infrastructure have to solve?

Any app that is open to the internet gets automatic probes within hours of going live. Programs request thousands of addresses to find a forgotten settings file, an admin panel or an old script. OWASP describes this automated abuse as constant background noise around web apps (see Sources).

In a healthcare product, each probe weighs more than on a simple brochure page. So the infrastructure had to do two things. First, stop harmful traffic before it reaches the app. Second, show clearly what is happening, so a person can spot what the rules did not foresee.

AWS infrastructure for a healthcare SaaS platform What constraints applied?

Four constraints decided most of the choices. The solution had to run on AWS. It had to be built from scratch, in a way that is easy to understand for whoever maintains it later. The filter had to leave real users free, even at the complex sign-up points, where requests easily look like an attack.

The fourth constraint is about what we publish. This page describes only what was set up. It claims no certifications and shares no client details.

AWS infrastructure for a healthcare SaaS platform What makes a setup like this work?

A setup like this works when three things run together. The filter is tuned for this specific platform, so customers get through while attacks are stopped. The team can read the logs easily. The protection works automatically, without waiting for someone to remember to react.

It also helps when every rule has a known purpose. A long list copied from a template makes life hard for the team: when a real user is blocked, nobody can tell which rule is responsible. With rules that are explained, the cause is found fast and the filter stays on.

Finally, a block has a duration. An address that is blocked forever may later belong to innocent users, because many addresses are shared or reused. A block with a time limit protects the platform without locking real people out.

AWS infrastructure for a healthcare SaaS platform What was the approach?

We worked in layers, from the outside in, so that each layer catches what the previous one lets through. First the hosting of the app, then a filter in front of it, then an automatic script that reads the logs. Last, ready-made queries for the person who watches the platform.

Hosting of the app on AWS Elastic Beanstalk, with Nginx in front of the app server.
A web application firewall (AWS WAF), which is a filter that stops harmful traffic, with 23 rules.
A small automatic script (AWS Lambda in Python) that reads the logs every 3 minutes, finds scanners and blocks them.
Ready-made queries in Amazon CloudWatch Logs Insights, so the team can read the logs without writing queries from scratch.

The 23 rules cover a request limit per IP, a geographic restriction, and ready-made rule groups that AWS maintains: common threats, known bad inputs, Amazon IP reputation, anonymous IPs, WordPress, PHP. Other rules block searches for files such as .env, .git, node_modules or phpMyAdmin. They also block PHP files or parameters that the platform does not use, and automated clients. There are also lists of allowed and blocked IPs, together with exceptions for the complex sign-up points.

AWS infrastructure for a healthcare SaaS platform What were the key decisions?

The decisions matter more than the list of tools. Four stand out: narrow exceptions for sign-up, blocks that grow step by step, rules with a clear purpose, and ready-made log queries before they are needed. Each one makes the platform safer without making life harder for real users.

Exceptions for sign-up. The complex sign-up points send requests that a strict filter sees as suspicious. We excluded only those points from specific rules, while all the other rules stayed active for the whole platform.
Blocks that grow step by step. The Lambda does not block an address forever on the first sign. The length of the block grows as the behavior repeats: a one-off mistake expires quickly, while a persistent scanner stays out longer.
Rules with a clear purpose. Each rule says what it stops. If a user gets blocked, the cause is found in a few minutes.
Queries ready in advance. The Logs Insights queries cover 4xx and 5xx errors, redirects, suspicious IPs and blocks. In an incident, the first questions are almost always the same. When the answer is ready, the team saves time at the moment it counts.
We used only the AWS services the platform needed, with no extra tools. The technology follows the requirements.

AWS infrastructure for a healthcare SaaS platform What outcome is expected?

The outcome is a set of mechanisms that work together. The platform runs in a stable, defined environment. Harmful traffic meets a filter before it reaches the app. Any scanners that get past the first rules are found by the script within a few minutes. The team sees what is happening through the ready-made queries.

We do not publish numbers, such as attacks stopped or response times, because we have no approved figures to publish. A setup like this supports the platform's reliability for years, because it makes problems visible early. Security is ongoing work: it is maintained and improved over time.

If you are planning something similar, the page on AWS cloud setup explains how we work. The article how an application is protected from automated scans explains the idea in plain words.

AWS infrastructure for a healthcare SaaS platform Sources

OWASP, Automated Threats to Web Applications

AWS infrastructure for a healthcare SaaS platform Frequently asked questions

Which AWS services were used?

Four services were used: AWS Elastic Beanstalk to host the app with Nginx in front, AWS WAF for the traffic filter, AWS Lambda in Python for the automatic blocking, and Amazon CloudWatch Logs Insights to read the logs. Only what the platform needed was added.

Who is the client of the project?

It is a real project. The client's identity stays private, and so do their details. Here we describe, in general terms, what we set up, so you can judge the approach.

How much does this setup protect against attacks?

The filter and the automatic blocking reduce the noise, stop the easy attacks and make what remains visible. No app is completely safe from attack, which is why the logs with ready-made queries were part of the work from the start.

Do you set up AWS infrastructure for other platforms too?

Yes. The same method applies to any web platform, in any sector. See how we work in SaaS platforms and business applications or start a project by describing your needs.

Next step: AWS infrastructure for a healthcare SaaS platform

Start your project

Send a project request, or check your current website for free. We read every message ourselves.

Start a project Check your website