Introduction

In August 2025, Ghana’s government email infrastructure experienced a disruption that left ministries and agencies unable to access official .gov.gh email services for nearly three days.

The incident highlighted an uncomfortable reality: as governments digitize public services, their digital infrastructure becomes a critical national asset — and a growing target for cyber threats.

At the same time, the Cyber Security Authority reported over 2,000 cyber incidents in the first half of 2025 alone, underscoring the accelerating pace of cyber threats across the country’s digital ecosystem.

As healthcare, insurance, and government services move online, protecting these platforms is no longer optional. It is essential for maintaining trust, availability, and operational resilience.

The healthcare sector in Ghana has increasingly become part of this cybersecurity conversation. In late 2025 and early 2026, both Komfo Anokye Teaching Hospital and the National Health Insurance Authority were highlighted in discussions around strengthening cybersecurity awareness and resilience in healthcare systems.

During a cybersecurity awareness event organized by KATH in collaboration with the Cyber Security Authority, the Director-General of the CSA revealed a concerning insight: the cybersecurity maturity level of healthcare institutions in Ghana is significantly lower than that of banks and telecommunications companies.

In an assessment covering fifteen health entities — including public hospitals, private hospitals, and medical laboratories — several critical vulnerabilities were discovered. These included:

• Lack of password encryption

• Outdated software systems

• Web server misconfigurations

• Susceptibility to Distributed Denial-of-Service (DDoS) attacks

• Lack of HTTPS enforcement

• Exposure through verbose error messages

These vulnerabilities represent exactly the type of weaknesses that attackers exploit to disrupt healthcare services.

The threat is not theoretical. In January 2024, a Ghanaian hospital reportedly experienced a ransomware incident that took its patient management system offline, with attackers demanding GHS 3.5 million for system restoration. More recently, in early 2026, the National Health Insurance Authority reportedly engaged private cybersecurity firms to help patch vulnerabilities within its digital infrastructure.

These events highlight an important reality: as healthcare systems become digital, web applications become critical infrastructure.

Protecting them requires strong architectural defenses.

This article explores a practical security architecture that uses AWS Web Application Firewall (WAF) and Amazon CloudFront to protect healthcare web applications from malicious traffic, unauthorized access attempts, and application-layer attacks.

The project demonstrates how modern cloud architectures can help healthcare institutions reduce risk while maintaining reliable digital services.

Architecture Overview

To address these challenges, the architecture designed in this project introduces a protective security layer in front of a web application using AWS-native services.

Architecture showing how AWS WAF and CloudFront filter malicious internet traffic before it reaches a healthcare web application hosted on Amazon EC2, ensuring secure and resilient access.

The goal of the architecture is simple:

Ensure that only legitimate traffic reaches the healthcare application while malicious or suspicious traffic is blocked at the edge.

The key components of the architecture include:

• AWS CloudFront Distribution

At the edge of the architecture sits Amazon CloudFront, a global content delivery network that distributes incoming user requests across AWS edge locations.

CloudFront serves two important purposes:

1. Improves performance by caching content closer to users.

2. Acts as a front-line traffic gateway where security controls can be enforced.

All user requests from the internet are routed through CloudFront before reaching the application backend.

• AWS WAF Web ACL

Attached to the CloudFront distribution is AWS Web Application Firewall.

AWS WAF allows administrators to create Web Access Control Lists (Web ACLs) that define rules for inspecting and filtering incoming traffic.

These rules can:

• Block malicious IP addresses

• Prevent automated bot traffic

• Detect suspicious request patterns

• Mitigate common web exploits

• Protect applications from DDoS-style traffic floods

In the healthcare context, this helps prevent attackers from overwhelming or probing patient service portals.

• EC2 Instance (Web Application Server)

Behind the CloudFront distribution sits an Amazon EC2 instance hosting the web application. This instance represents a simplified version of a healthcare portal or patient management interface.

Because traffic must pass through CloudFront and AWS WAF first, the backend application receives filtered and legitimate requests only. This reduces exposure to common web-based attacks.

• AWS Systems Manager Session Manager

Administrative access to the EC2 instance is handled using AWS Systems Manager Session Manager. Unlike traditional SSH access, Session Manager allows administrators to securely connect to the instance without opening inbound ports to the internet.

This greatly reduces the attack surface and aligns with security best practices for managing cloud infrastructure.

• AWS CloudFormation

To deploy the architecture quickly and consistently, the environment is created using AWS CloudFormation. CloudFormation enables infrastructure to be defined as code, ensuring the entire setup can be deployed, modified, or rebuilt in a controlled and repeatable way.

This is particularly valuable for organizations managing critical infrastructure.

Together, these services form a layered defense architecture where:

Internet Traffic → CloudFront → AWS WAF → EC2 Web Application

Only traffic that passes WAF inspection reaches the backend system.

Project Walkthrough: Building the Architecture from Scratch

To better understand how this security architecture works in practice, I implemented the entire environment from scratch using core AWS services. The goal was to simulate how a healthcare web application could be protected from malicious traffic using AWS WAF and CloudFront.

The following steps outline the process used to build and test the system.

Step 1: Sign in to the AWS Management Console

The process begins by logging into the AWS Management Console. From here, all resources required for the architecture are created and managed.

Before provisioning resources, it is good practice to select the AWS region where the infrastructure will be deployed and ensure that appropriate permissions are available for creating networking, compute, and security resources.

Step 2: Launch an EC2 Instance to Host the Web Application

Next, an Amazon EC2 instance is launched to act as the backend web server.

During this step:

• An Amazon Machine Image (AMI) such as Amazon Linux is selected.

• An instance type suitable for testing (for example, t2.micro) is chosen.

• A security group is configured to allow HTTP traffic so that the web application can be accessed.

• An IAM role with permissions for AWS Systems Manager is attached to enable Session Manager access.

Once the instance is running, it represents the backend application server that CloudFront will later distribute traffic to.

Step 3: Configure the Web Application on the EC2 Instance

After launching the instance, the next step is to deploy a simple web application.

Instead of opening SSH ports, the instance is accessed securely using AWS Systems Manager Session Manager.

From the Session Manager terminal:

• The Apache web server is installed.

• The service is started and enabled.

• A simple HTML page is created to simulate a healthcare web portal.

This application will later serve as the origin for the CloudFront distribution.

Step 4: Create a CloudFront Distribution

With the backend server ready, the next step is to create a CloudFront distribution.

During this process:

• The EC2 instance's public DNS or Elastic IP is configured as the origin server.

• The default cache behavior is configured to allow HTTP and HTTPS traffic.

• Security policies are left at recommended defaults for testing.

Once deployed, CloudFront provides a globally distributed entry point for users accessing the web application.

At this stage, traffic flows as follows:

User → CloudFront → EC2 Web Server

However, the application is not yet protected by AWS WAF.

Step 5: Create an AWS WAF Web ACL

Next, a Web Access Control List (Web ACL) is created using AWS WAF.

This Web ACL acts as a rule engine that inspects incoming requests before they reach the application.

Several rules can be defined, such as:

• blocking traffic from specific IP addresses

• rate limiting excessive requests

• filtering suspicious request patterns

For demonstration purposes, an IP blocking rule is created to block requests originating from a specific IP address.

Step 6: Associate the Web ACL with CloudFront

Once the Web ACL is configured, it is associated with the CloudFront distribution.

This step is critical because it ensures that all incoming requests are inspected by AWS WAF before reaching the origin server.

After the association is complete, the traffic flow becomes:

User → CloudFront → AWS WAF → EC2 Web Server

Only requests that pass the WAF inspection are forwarded to the backend application.

Step 7: Test the WAF Rules

With the architecture in place, the next step is to verify that the WAF rules are functioning correctly.

First, the CloudFront distribution domain name is accessed from a browser to confirm that the application loads successfully.

Next, the current public IP address is added to the blocked IP rule within the Web ACL.

When attempting to access the CloudFront URL again, the request is blocked, confirming that AWS WAF is actively filtering traffic.

To restore access, the IP address is removed from the rule, allowing traffic to pass through once again.

This simple test demonstrates how security teams can dynamically respond to suspicious activity by blocking malicious traffic in real time.

Step 8: Validate the Architecture

After testing, the architecture is validated by confirming the following:

• the web application is accessible through CloudFront

• AWS WAF successfully blocks requests from specified IP addresses

• administrative access to the EC2 instance is securely managed using Session Manager

• the backend server remains protected behind the CloudFront and WAF security layers

This confirms that the architecture is functioning as intended.

Step 9: Clean Up AWS Resources

To avoid unnecessary costs, all resources created during the project are deleted after testing.

This includes:

• terminating the EC2 instance

• deleting the CloudFront distribution

• removing the AWS WAF Web ACL

• deleting associated security groups and configurations

Cleaning up resources ensures the environment remains cost-efficient and well managed.

Threat Model: What Attacks This Architecture Helps Prevent

When designing security architectures, it is important to understand what types of threats the system is expected to defend against. In the context of healthcare web applications, attackers often target systems that store or process sensitive patient information.

The architecture implemented in this project introduces protective layers that help mitigate several common web-based threats.

Distributed Denial-of-Service (DDoS) Attacks

Healthcare platforms such as patient portals and insurance verification systems must remain available at all times. A Distributed Denial-of-Service attack attempts to overwhelm these services with massive volumes of traffic, making them inaccessible to legitimate users.

By routing traffic through Amazon CloudFront, requests are distributed across a global network of edge locations. This helps absorb and manage high traffic volumes before they reach the backend application.

Additionally, AWS Web Application Firewall rules can enforce rate limiting and traffic filtering to block suspicious patterns commonly associated with DDoS attacks.

Malicious IP Traffic

Attackers often launch repeated probing attempts from specific IP addresses to discover vulnerabilities within web applications.

Using AWS WAF, administrators can create IP-based blocking rules to immediately deny requests originating from known malicious sources.

This allows security teams to quickly respond to suspicious behavior without modifying application code or backend infrastructure.

Automated Bot Attacks

Many attackers use automated tools to scan websites for weaknesses such as exposed directories, outdated frameworks, or misconfigured endpoints.

AWS WAF can detect abnormal request patterns, such as:

• unusually high request frequency

• suspicious user-agent strings

• repeated access attempts to restricted endpoints

By filtering these automated requests, the architecture prevents bots from reaching the application server.

Web Application Exploits

Many healthcare systems rely on web applications that may contain vulnerabilities if they are poorly configured or outdated.

Some common attack vectors include:

• SQL injection attempts

• cross-site scripting (XSS)

• malicious query parameters

• exploitation of server misconfigurations

AWS WAF helps mitigate these risks by inspecting incoming HTTP requests and blocking patterns that match known exploit signatures.

This is particularly important in environments where legacy healthcare systems may not always receive immediate security updates.

Direct Infrastructure Exposure

A common security weakness occurs when backend servers are directly exposed to the internet.

In this architecture, the EC2 web server sits behind CloudFront, meaning users interact with the edge distribution rather than the server itself.

Administrative access is also handled using AWS Systems Manager Session Manager, which eliminates the need to expose SSH ports publicly.

This significantly reduces the system's attack surface.

Why Threat Modeling Matters

Threat modeling allows architects to design systems with security built in from the start, rather than attempting to add protections after vulnerabilities are discovered.

In the case of healthcare systems, this approach is especially important because:

• patient information is highly sensitive

• healthcare services must remain available at all times

• system outages can disrupt medical operations

By combining CloudFront, AWS WAF, and secure instance management practices, the architecture implemented in this project provides a strong defensive foundation for protecting healthcare web applications.

Recommended AWS WAF Rules for Healthcare Applications

While the demonstration in this project used a simple IP blocking rule, real-world healthcare systems require a more comprehensive set of protections. Fortunately, AWS Web Application Firewall provides several managed rule groups and security features that can significantly strengthen the protection of healthcare web applications.

Below are some recommended WAF protections that healthcare organizations can implement when deploying applications on AWS.

AWS Managed Core Rule Set

One of the most effective ways to protect web applications is by enabling the AWS Managed Core Rule Set.

This rule group provides protection against many common application-layer attacks, including:

• SQL injection attempts

• cross-site scripting (XSS)

• malicious file uploads

• HTTP protocol violations

These rules are continuously maintained by AWS security teams, ensuring that new attack patterns are regularly addressed.

For healthcare portals handling patient data, this baseline protection is essential.

Rate-Based Rules

Healthcare systems are often targeted by automated traffic spikes designed to overwhelm servers or disrupt services.

Using rate-based rules in AWS WAF allows administrators to automatically block IP addresses that exceed a defined request threshold.

For example, a rule might block any IP address making more than 1,000 requests within five minutes.

This approach helps mitigate:

• denial-of-service attempts

• automated scraping bots

• brute-force login attempts

Bot Control Protection

Many attackers use automated bots to scan web applications for vulnerabilities.

AWS WAF provides Bot Control features that detect and block suspicious automated traffic while allowing legitimate search engine crawlers.

This helps prevent:

• credential stuffing attacks

• automated vulnerability scanning

• excessive scraping of sensitive healthcare data

IP Reputation Lists

AWS WAF can also use managed IP reputation lists that contain addresses known to be associated with malicious activity.

These lists help block traffic originating from:

• known botnets

• compromised devices

• suspicious network sources

Blocking these sources early reduces the chances of attackers interacting with healthcare applications.

Geographic Traffic Controls

Healthcare portals often serve users from specific geographic regions.

Using geographic match rules, administrators can restrict access to countries where legitimate traffic is expected.

This approach reduces exposure to attack traffic originating from regions unrelated to the organization’s services.

Custom Security Rules

In addition to managed protections, organizations can create custom rules tailored to their applications.

Examples include:

• blocking repeated login attempts

• restricting access to administrative endpoints

• preventing requests with suspicious query parameters

Custom rules allow security teams to adapt defenses based on real usage patterns and observed threats.

Strengthening Healthcare Cybersecurity in the Cloud

When combined with services like Amazon CloudFront and secure infrastructure management practices, AWS WAF provides a powerful first line of defense for healthcare applications.

Implementing these rules ensures that:

• malicious traffic is filtered early

• backend infrastructure remains protected

• sensitive healthcare systems remain available and secure

For healthcare institutions handling critical patient information, these protections are not just best practices — they are essential safeguards for maintaining operational resilience and trust.

Key Lessons from This Project

Several important lessons emerged from this exercise.

1. Security should be implemented at the architecture level, not only within applications.

2. Edge security services like CloudFront and AWS WAF can dramatically reduce the exposure of backend systems.

3. Removing unnecessary public access points is one of the most effective ways to improve cloud security.

4. Infrastructure as Code improves reliability and reduces configuration mistakes.

5. Healthcare digital systems must be designed with cybersecurity as a core requirement, not an afterthought.

Final Thoughts

As Ghana continues to digitize healthcare services, systems such as hospital portals and insurance platforms will become increasingly central to patient care and administrative operations.

But digital transformation must be accompanied by strong cybersecurity architecture.

The vulnerabilities identified in several healthcare institutions show that many systems remain exposed to preventable risks.

Architectures like the one demonstrated in this project provide a practical blueprint for building safer healthcare applications in the cloud.

By placing AWS WAF and CloudFront at the edge of the system, organizations can block malicious traffic before it reaches critical infrastructure — improving both resilience and trust.

This approach represents a key principle in modern cloud security:

protect systems before attackers reach them.

In the next article in this series, we will shift our focus to another critical layer of cloud architecture:

Databases in AWS.

We will explore how data storage systems such as relational and managed databases are designed, secured, and integrated into resilient cloud applications.

Because in modern systems, protecting the infrastructure is only the beginning — safeguarding the data itself is equally important.

See you next week.