DEV Community: Swarali Chine

Deploying a Static Website on Amazon EC2 with Apache HTTP Server

Swarali Chine — Wed, 29 Jul 2026 04:03:57 +0000

Introduction
Amazon EC2 (Elastic Compute Cloud) is one of the core compute services in AWS, providing scalable virtual servers that can host websites, applications, and enterprise workloads. While AWS offers several managed hosting options, understanding how to manually configure a web server on EC2 provides a strong foundation in Linux administration, networking, and cloud infrastructure.

In this project, I launched an Amazon EC2 instance running Amazon Linux 2023, installed the Apache HTTP Server, and deployed a custom static website. Along the way, I learned how Security Groups control network access, how Apache serves web content, and how AWS services work together to host a web application.

Why Build This Project?
Understanding how web applications are hosted on a virtual server is a fundamental cloud engineering skill. Although managed services simplify deployments, manually configuring a web server helps build a deeper understanding of compute, networking, operating systems, and web server administration.
This project demonstrates how to:

Launch and configure an Amazon EC2 instance
Secure access using AWS Security Groups
Install and manage Apache HTTP Server
Deploy a static HTML website
Understand how HTTP requests are processed
Practice responsible AWS resource management

Architecture

AWS Services Used in This Project
Amazon EC2
Amazon EC2 (Elastic Compute Cloud) provides resizable virtual servers in the cloud. I used EC2 to host the Apache web server and deploy the static website. It gives complete control over the operating system, networking, storage, and server configuration, making it an excellent service for learning cloud infrastructure.
Amazon Linux 2023
Amazon Linux 2023 is an AWS-optimized Linux distribution designed for running applications on Amazon EC2. I selected it because it is lightweight, secure, regularly updated, and integrates seamlessly with AWS services. It also uses the dnf package manager, making software installation and maintenance straightforward.
Amazon EBS
Amazon Elastic Block Store (EBS) provides persistent block storage for Amazon EC2 instances. In this project, the root EBS volume stored the operating system, Apache installation, configuration files, and website content. The website files remained available throughout the lifetime of the EC2 instance.
Security Groups
Security Groups act as virtual firewalls that control inbound and outbound traffic for EC2 instances. I configured inbound rules to allow SSH access only from my IP address for secure administration and HTTP access on port 80 so users could access the hosted website through a browser.
Apache HTTP Server
Apache HTTP Server is one of the world's most widely used open-source web servers. I installed Apache on the EC2 instance to process incoming HTTP requests and serve the custom HTML webpage stored in the server's document root.

Step 1: Launch an EC2 Instance
I launched an EC2 instance using the Amazon Linux 2023 Amazon Machine Image (AMI) and selected a micro instance type suitable for a learning environment.

To securely access the server while making the website publicly available, I configured the following Security Group rules:
SSH (Port 22) → My IP
HTTP (Port 80) → Anywhere (0.0.0.0/0)

Step 2: Connect to the Instance
I connected to the instance using EC2 Instance Connect and verified the environment before installing Apache.
Some of the first commands I executed were:
whoami
cat /etc/os-release
pwd
These commands confirmed the current user, operating system version, and working directory.

Step 3: Install Apache HTTP Server
After updating the operating system packages, I installed Apache using the Amazon Linux package manager.
sudo dnf update -y
sudo dnf install httpd -y
Once the installation completed, I started the Apache service and configured it to start automatically whenever the EC2 instance boots.
sudo systemctl start httpd
sudo systemctl enable httpd
I also verified that the service was running successfully.

Step 4: Deploy the Website
Apache serves website files from its default document root:
/var/www/html
I replaced the default Apache welcome page with a custom index.html file and restarted the Apache service.
sudo systemctl restart httpd
After opening the EC2 instance's public IPv4 address in a web browser, my custom website was successfully displayed.

Step 5: Verify Apache Configuration
To better understand how Apache works, I explored its configuration and log files.
To locate the configured document root:
grep -n "DocumentRoot" /etc/httpd/conf/httpd.conf
To review recent HTTP requests:
sudo tail -10 /var/log/httpd/access_log
These commands helped me understand where Apache stores website content and how incoming requests are recorded for monitoring and troubleshooting.

Key Takeaways
This project provided practical experience with:

Launching and managing Amazon EC2 instances
Understanding Amazon Linux 2023
Installing and configuring Apache HTTP Server
Configuring AWS Security Groups
Managing Linux services using systemctl
Understanding the Apache document root
Reading Apache access logs
Deploying a static website on AWS More importantly, it strengthened my understanding of how compute, networking, storage, and web server software work together to deliver a web application.

Cost Optimization
To keep the project cost-effective, I followed several AWS cost optimization practices:

Used a micro EC2 instance suitable for learning
Used the default root EBS volume
Avoided provisioning unnecessary AWS resources
Terminated the EC2 instance immediately after completing the project
Verified that associated resources were cleaned up to prevent ongoing charges Managing cloud costs is an important aspect of building production-ready AWS solutions, even for small learning projects.

GitHub Repository
The complete project, including source code, documentation, architecture diagrams, and screenshots, is available on GitHub.
Repository:
https://github.com/swaralichine/aws-projects/tree/main/01-web-hosting-and-deployment/03-ec2-apache-web-server

Final Thoughts
Building and deploying a website on Amazon EC2 provided a hands-on introduction to the core building blocks of AWS infrastructure. While the application itself is simple, the project demonstrates several fundamental cloud concepts, including virtual machines, networking, Linux administration, persistent storage, and web server configuration.

For anyone beginning their AWS learning journey, this project offers an excellent opportunity to understand what happens behind the scenes when hosting a website in the cloud. These foundational skills serve as the basis for more advanced architectures involving load balancing, auto scaling, containers, and highly available applications.

Deploying a WordPress Blog on AWS Lightsail: A Beginner-Friendly Approach to Hosting Dynamic Websites

Swarali Chine — Mon, 27 Jul 2026 01:25:26 +0000

Introduction
After building my first AWS project—hosting a static website with Amazon S3 and Amazon CloudFront—I wanted to understand what happens when a website needs to generate content dynamically.

Static websites are great for portfolios and documentation, but applications like WordPress require much more than file storage. They need a server to process requests, an application runtime to execute code, and a database to store content.

Rather than configuring all of these components manually, I chose Amazon Lightsail, AWS's simplified virtual private server (VPS) service, to understand the fundamentals of hosting a dynamic web application.

By the end of this project, I had:

Deployed a WordPress website
Logged into the WordPress administration dashboard
Published my first blog post
Configured a Static IP
Created a server snapshot for backup and recovery

Static vs. Dynamic Websites
Before starting this project, I wanted to clearly understand why my previous S3 project couldn't host WordPress.

A static website simply serves files that already exist. Every visitor receives the same HTML, CSS, JavaScript, and images without any server-side processing.

A dynamic website is different. Every request is processed by the server, which executes application logic, retrieves information from a database, and generates the webpage before sending it to the user's browser.

WordPress is one of the most common examples of a dynamic web application because every page depends on PHP and a database.

Diagram 1 – Static vs. Dynamic Website
Static Website

Browser
│
▼
Amazon S3
│
▼
HTML • CSS • JavaScript

           Dynamic Website

Browser
│
▼
Apache Web Server
│
▼
PHP Runtime
│
▼
MariaDB Database
│
▼
Generated HTML

Because WordPress relies on server-side processing, it cannot simply be hosted in an S3 bucket.

Why Amazon Lightsail?
AWS offers several compute services, including Amazon EC2 and Amazon Lightsail.

For beginners and small projects, Lightsail removes much of the operational complexity while still exposing the key concepts behind cloud infrastructure.

With a few clicks, Lightsail provides:

A virtual Linux server
Networking
Storage
Static IP support
Built-in application blueprints
Predictable monthly pricing

Instead of installing Ubuntu, Apache, PHP, MariaDB, and WordPress individually, I selected the WordPress blueprint and AWS provisioned everything automatically.

This allowed me to focus on understanding the architecture rather than spending time configuring the operating system.

Solution Architecture
The deployed architecture is straightforward but introduces several important AWS concepts.

Diagram 2 – Architecture
Internet
│
▼
Static Public IP
│
▼
Amazon Lightsail Instance
┌─────────────────────────────┐
│ Ubuntu Linux │
│ Apache Web Server │
│ PHP Runtime │
│ MariaDB Database │
│ WordPress Application │
└─────────────────────────────┘
│
▼
Lightsail Snapshot

Each component plays an important role.

Ubuntu hosts the application.
Apache receives incoming HTTP requests.
PHP executes the WordPress application.
MariaDB stores posts, pages, users, and settings.
Static IP provides a consistent public endpoint.
Snapshot enables backup and disaster recovery.

Deployment Walkthrough

Launching the WordPress Instance Using the WordPress blueprint, AWS automatically created a fully configured environment with Ubuntu, Apache, PHP, MariaDB, and WordPress. This eliminated the need to manually install and configure each component.

Accessing the WordPress Dashboard After retrieving the administrator password from the instance, I logged into the WordPress admin dashboard. From there, I could manage the website, configure settings, install plugins, and publish content.

Publishing My First Blog Post To verify that everything was working correctly, I created and published my first blog post. This confirmed that the web server, PHP runtime, and database were communicating correctly.

Configuring a Static IP Initially, the instance was assigned a temporary public IP address. Since public IP addresses can change if an instance is recreated or restarted, I attached a Static IP. Using a permanent IP address makes it easier to associate the server with a domain name in the future.

Creating a Snapshot Before deleting the environment, I created a Lightsail snapshot. Snapshots capture the complete state of the server, including:

Operating system
WordPress installation
Configuration
Database
Uploaded content This makes it possible to restore the environment if needed.

How a Request Reaches WordPress
Understanding the request flow helped me connect the different components of the architecture.
Diagram 3 – Request Flow
Browser
│
▼
Static IP
│
▼
Apache
│
▼
PHP
│
▼
WordPress
│
▼
MariaDB
│
▼
HTML Response
│
▼
Browser

Every page request follows this sequence before the generated HTML is returned to the user.

Cost Optimization
One of my goals was to complete this project while keeping costs as low as possible.
To achieve this, I:

Selected the smallest available Lightsail instance
Did not purchase a custom domain
Deferred HTTPS configuration because it typically requires a registered domain
Deleted the instance, Static IP, and snapshot immediately after completing the project Since the environment was only active during development and testing, the actual cost was only a small fraction of the monthly Lightsail plan.

Key Takeaways
This project helped reinforce several cloud concepts that are useful beyond WordPress hosting.

Dynamic applications require compute resources.
A web server processes incoming requests before generating a response.
Databases are essential for storing application data.
Static IPs provide stable network endpoints.
Snapshots are a simple but effective disaster recovery mechanism.
Managed services like Amazon Lightsail simplify infrastructure while still teaching the core principles of cloud computing.

Conclusion
Amazon Lightsail provides an excellent balance between simplicity and functionality, making it an ideal service for learning how dynamic web applications are deployed in AWS.

While the deployment process is straightforward, the project introduces several foundational cloud concepts—including compute, networking, storage, application hosting, and backup strategies—that are applicable across many AWS services.

For anyone beginning their cloud journey or looking for a simple way to host a WordPress application, Amazon Lightsail offers an approachable starting point without requiring extensive infrastructure management.

GitHub Repository
You can find the complete project, documentation, architecture, and screenshots here:
https://github.com/swaralichine/aws-projects/tree/main/01-web-hosting-and-deployment/02-wordpress-aws-lightsail

Building a Secure Static Website on AWS with Amazon S3 and CloudFront.

Swarali Chine — Sun, 26 Jul 2026 16:54:51 +0000

Introduction
Hosting a static website is one of the simplest ways to deploy content on the web. Whether it's a personal portfolio, documentation site, product landing page, or blog, static websites consist of files such as HTML, CSS, JavaScript, and images that don't require a backend server or database.
While Amazon S3 makes it easy to host static content, simply enabling S3 Static Website Hosting requires making the bucket publicly accessible. Although suitable for demonstrations, exposing the storage layer directly isn't the most secure approach.
A more robust architecture is to keep the Amazon S3 bucket private and use Amazon CloudFront as the public entry point. CloudFront securely retrieves content from the bucket using Origin Access Control (OAC), delivers it over HTTPS, caches content closer to users, and improves both security and performance.
In this article, we'll build a secure static website using Amazon S3 and Amazon CloudFront while following AWS best practices.

Prerequisites

Before getting started, you'll need:
An active AWS account
Basic familiarity with the AWS Management Console
A static website (HTML, CSS, JavaScript, and supporting assets)
Basic understanding of Amazon S3

What You'll Build
By the end of this project, you'll have:

A private Amazon S3 bucket storing your website files
An Amazon CloudFront distribution serving the website globally
Origin Access Control (OAC) securing access between CloudFront and Amazon S3
HTTPS-enabled website delivery
A scalable, low-maintenance static website architecture

Architecture

Why These AWS Services?
Amazon S3
Amazon S3 is AWS's object storage service designed to provide highly durable, available, and scalable storage. Since static websites are simply collections of files, S3 provides an ideal location to store website assets without managing web servers or application infrastructure.
For this project, Amazon S3 acts as the origin that stores the website files.
Amazon CloudFront
Although Amazon S3 stores the website content, it isn't optimized to deliver that content efficiently to users across different geographic locations.
Amazon CloudFront is AWS's Content Delivery Network (CDN). Instead of every request reaching the origin bucket, CloudFront caches content at AWS edge locations around the world, allowing users to retrieve content from the nearest location.
Using CloudFront provides several benefits:

Lower latency
Faster page load times
HTTPS support
Reduced requests to the origin
Improved scalability during traffic spikes
Origin Access Control (OAC)
One of the most important design decisions in this architecture is preventing direct public access to the Amazon S3 bucket.
Origin Access Control allows CloudFront to securely access objects stored in Amazon S3 while ensuring that users cannot access the bucket directly.
This approach provides:
A private Amazon S3 bucket
Controlled access through CloudFront
Reduced attack surface
Better alignment with AWS security best practices

Implementation
The solution was implemented in four simple steps.
Step 1 – Create an Amazon S3 Bucket
A new Amazon S3 bucket was created to store the website files.
To improve security, Block Public Access remained enabled so that objects could not be accessed directly from the internet.
The following website assets were uploaded:

index.html
styles.css
script.js
error.html

Step 2 – Configure Amazon CloudFront
An Amazon CloudFront distribution was created using the Amazon S3 bucket as the origin.
The following configuration was applied:
Origin Access Control (OAC) enabled
Default root object configured as index.html
HTTPS enabled
Default CloudFront domain used for testing
CloudFront automatically updated the bucket policy, allowing secure access to the private S3 bucket.

Step 3 – Deploy the Website
After the CloudFront distribution finished deploying, the generated CloudFront domain successfully served the website over HTTPS.
CloudFront caches content at edge locations, allowing future requests to be served faster while reducing requests to the origin bucket.

Security Considerations
The following AWS best practices were implemented:

Amazon S3 Block Public Access enabled
Private Amazon S3 bucket
Origin Access Control (OAC) configured
CloudFront acting as the only public entry point
HTTPS used for all client communication Keeping the storage layer private while exposing only CloudFront significantly improves the security posture of the application.

Cost Estimate
The architecture is inexpensive to operate and is well suited for personal portfolios, documentation websites, and small business websites.

Amazon S3 – Stores the static website files (HTML, CSS, JavaScript, images, and other assets). Estimated cost: Less than $0.50/month for a small personal website.
Amazon CloudFront – Delivers website content globally with low latency through edge locations and HTTPS support. Estimated cost: Approximately $0–$2/month for light traffic.
Origin Access Control (OAC) – Securely allows CloudFront to access the private Amazon S3 bucket while preventing direct public access. Estimated cost: No additional cost.

Estimated monthly cost: $0–$2 for a personal portfolio or low-traffic website.

Challenges and Lessons Learned
One of the biggest lessons from this project was understanding the difference between Amazon S3 Static Website Hosting and serving content through Amazon CloudFront.
While enabling static website hosting on Amazon S3 is straightforward, using CloudFront with Origin Access Control provides a more secure architecture by keeping the storage bucket private and allowing access only through CloudFront.
Another key takeaway was learning how CloudFront deployments work. Configuration changes require time to propagate across AWS edge locations, so it's important to wait for the distribution to finish deploying before validating the website.
Finally, this project demonstrated how combining multiple AWS managed services results in a solution that is secure, scalable, and easy to maintain without managing any servers.

Key Takeaways
This project demonstrates how AWS managed services can be combined to build a secure and scalable static website.
By completing this implementation, we achieved:

Secure object storage using Amazon S3
Global content delivery with Amazon CloudFront
Private origin access using Origin Access Control (OAC)
HTTPS-enabled website delivery
Improved performance through edge caching
A low-cost, highly scalable hosting solution

Resources
GitHub Repository
Project Repository
https://github.com/swaralichine/aws-projects/tree/main/01-web-hosting-and-deployment/01-static-website-s3-cloudfront

AWS Documentation
Amazon S3 User Guide-https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
Amazon CloudFront Developer Guide-
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
Restrict access to an Amazon S3 origin using Origin Access Control (OAC)-https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html