AWS Builder Center

Builder Center

Cloud-Native PDF ToolKit Service

Built and deployed a serverless PDF processing platform using HTML, CSS, JavaScript, Python, Docker, AWS S3, Lambda, ECR, Cognito, IAM, and CloudFormation. Implemented event-driven PDF compression and processing with Ghostscript and pypdf, supporting compression, merge, split, rotate, and page deletion. Designed CI/CD pipelines with GitHub, AWS CodePipeline, and CodeBuild for automated testing, Docker image builds, ECR publishing, Lambda deployment, and S3 frontend deployment.

Building a Cloud-Native PDF Compression Service with AWS Lambda, Docker, Amazon S3, and CI/CD

PDF files are widely used for documents, reports, applications, certificates, invoices, and other digital workflows. However, large PDF files can become difficult to upload, store, share, and process efficiently.
To solve this problem, I built a cloud-native PDF processing and compression service using AWS. The application allows users to upload PDF files through a web interface and perform operations such as compression, merging, splitting, rotating, and deleting pages.
The project uses a serverless backend packaged as a Docker container and deployed to AWS Lambda, while Amazon S3 provides cloud storage for uploaded and processed files.
The architecture also includes infrastructure automation and a CI/CD pipeline using GitHub, AWS CodePipeline, AWS CodeBuild, Amazon ECR, and AWS Lambda.
Visit the website: PDF Toolkit — Compress, Edit & Transform PDFs 

1. Project Overview

The main goal of this project was to build a PDF processing system that is:
  • Cloud-based
  • Serverless
  • Containerized
  • Scalable
  • Cost-conscious
  • Easy to deploy
  • Automated through CI/CD
  • Capable of handling multiple PDF operations
The application separates the frontend, storage layer, processing layer, and deployment infrastructure.
The high-level architecture is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
USER
|
v
+-------------------+
| Web Frontend |
| HTML / CSS / JS |
+---------+---------+
|
v
+-------------------+
| Amazon S3 |
| Input Bucket |
+---------+---------+
|
| Object Event
v
+-------------------+
| AWS Lambda |
| PDF Processing |
| Docker Container |
+---------+---------+
|
v
+-------------------+
| Amazon S3 |
| Output Bucket |
+---------+---------+
|
v
Download PDF
The deployment architecture is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Developer
|
v
 GitHub
|
v
 AWS CodePipeline
|
v
 AWS CodeBuild
|
+----------+----------+
| |
v v
 Docker Build Application Tests
|
v
 Amazon ECR
|
v
 AWS Lambda

2. Technologies Used

The project combines several AWS services and development technologies.

Application

  • HTML
  • CSS
  • JavaScript
  • Python
  • Docker
  • Ghostscript
  • pypdf

AWS Services

  • Amazon S3
  • AWS Lambda
  • Amazon ECR
  • AWS IAM
  • AWS CloudFormation
  • AWS CodePipeline
  • AWS CodeBuild

Development and Version Control

  • Git
  • GitHub
  • Docker
  • CI/CD automation
The project is divided into separate frontend and backend repositories.

3. Frontend Architecture

The frontend is a static web application built using:
  • HTML
  • CSS
  • JavaScript
The frontend provides the user interface for uploading and processing PDF files.
The static website is hosted using Amazon S3.
The user interacts with the application through the browser rather than directly interacting with the Lambda function.
The frontend is responsible for:
  1. Selecting PDF files.
  2. Uploading files.
  3. Starting PDF processing operations.
  4. Displaying processing results.
  5. Providing access to processed files.
The frontend repository is:
AWS-PDF-Compression-System
The backend repository is:
AWS-PDF-Compression-Backend
This separation makes the application easier to maintain because frontend and backend changes can be developed independently.

4. Amazon S3 as the Storage Layer

Amazon S3 is one of the most important components of the architecture.
The application uses S3 to store PDF files instead of storing them directly inside the Lambda execution environment.
The general flow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
User
|
v
Frontend
|
v
S3 Input
|
v
Lambda
|
v
PDF Processing
|
v
S3 Output
|
v
User Download
There are two logical storage areas:

Input

The original PDF uploaded by the user is stored in the input location.

Output

After processing is completed, the resulting PDF is stored in the output location.
This approach keeps file storage independent from compute.
That is important because AWS Lambda functions are designed for temporary, event-driven execution rather than permanent file storage.

5. Why AWS Lambda?

The PDF processing backend uses AWS Lambda.
Lambda provides a serverless execution environment where the application can run without maintaining a traditional server.
Instead of keeping an EC2 instance running continuously, the PDF processor is executed when processing is required.
This provides several advantages:
  • No server management
  • Automatic scaling
  • Event-driven execution
  • Pay-for-use architecture
  • Easy integration with S3
  • Suitable for short-lived PDF processing workloads
The Lambda function used in this project is:
pdf-compressor

6. Why Use Docker with Lambda?

One of the interesting parts of this project is that the Lambda function is deployed as a container image.
Instead of uploading a traditional Lambda ZIP package, the backend is packaged into a Docker image.
The architecture becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
Python Application
|
v
Dockerfile
|
v
Docker Image
|
v
Amazon ECR
|
v
AWS Lambda
This approach is particularly useful for this project because PDF processing depends on external libraries and system-level PDF utilities.
The container contains the application and its required dependencies in a consistent environment.
This makes the runtime more predictable between development, testing, and production.

7. Amazon ECR

After building the Docker image, the image is pushed to Amazon Elastic Container Registry (ECR).
The repository used by the project is:
pdf-compressor
The deployment flow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
Source Code
|
v
Docker Build
|
v
Docker Image
|
v
Amazon ECR
|
v
AWS Lambda
ECR acts as the container image registry.
Lambda then retrieves the container image from ECR when deploying or updating the function.

8. PDF Processing Engine

The backend is written in Python.
The project uses:
  • Ghostscript for PDF compression
  • pypdf for PDF manipulation
The processing system supports several PDF operations.

Compression

The application uses Ghostscript to reduce PDF size.
The compression process can reduce unnecessary data and optimize the PDF for easier storage and transmission.

Merge

Multiple PDF files can be combined into a single PDF.
1
2
3
4
5
6
PDF 1
PDF 2
PDF 3
|
v
Merged PDF

Split

A PDF can be separated into individual pages or selected page ranges.
1
2
3
4
5
6
Input PDF
|
+---- Page 1
+---- Page 2
+---- Page 3
+---- ...

Rotate

Individual pages can be rotated to the required orientation.

Delete Pages

Selected pages can be removed from a PDF.
These operations are implemented using the backend PDF processing layer rather than requiring a separate server for each operation.

9. End-to-End Processing Flow

Let's look at what happens when a user processes a PDF.

Step 1 — User selects a PDF

The user opens the web application and selects a PDF file.
1
2
3
4
Browser
|
v
Select PDF

Step 2 — File is uploaded to S3

The file is uploaded to the S3 input location.
1
2
3
4
5
6
7
8
Browser
|
v
Amazon S3
|
+-- input/
|
+-- document.pdf
S3 provides durable object storage for the uploaded document.

Step 3 — Processing is triggered

The backend processing workflow receives the PDF and invokes the Lambda-based processing layer.
The Lambda function runs the required PDF operation.
For example:
1
2
3
4
5
6
7
8
9
10
document.pdf
|
v
Lambda
|
v
Ghostscript
|
v
compressed.pdf

Step 4 — PDF is processed inside the container

The Lambda function runs inside the Docker container.
The container contains:
  • Python application
  • PDF libraries
  • Ghostscript
  • Required dependencies
The processing operation depends on the user's selected action.
For compression:
1
2
3
4
5
6
7
Original PDF
|
v
Ghostscript
|
v
Compressed PDF
For other operations, pypdf performs the required PDF manipulation.

Step 5 — Result is stored in S3

After processing is completed, the generated PDF is stored in the output location.
1
2
3
4
5
6
7
Lambda
|
v
Output PDF
|
v
S3 Output
The application can then provide the processed PDF to the user.

10. Handling File Names Correctly

One practical challenge in the project was handling PDF file names containing special characters and spaces.
For example:
1
2
3
4
my report.pdf
project #1.pdf
file+name.pdf
résumé.pdf
These file names require careful handling because S3 object keys and URL encoding can behave differently.
The backend was updated to correctly preserve and decode file names during processing.
The implementation was
# aws-codebuild# aws-codepipeline# aws-lambda# amazon-s3# amazon-cognito
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article