Building a Scalable Image Optimization Pipeline on AWS
Author
Mateus Alexandre
Date Published
Image optimization has become a critical pillar in ensuring modern web performance. Unoptimized assets directly impact Core Web Vitals, SEO rankings, and overall user experience, particularly on mobile networks.
For years, engineering teams have relied on third-party SaaS platforms and CDN-native optimization features to manage image delivery and transformation. These solutions provide immediate access to capabilities such as on-the-fly format conversion, dynamic resizing for different device viewports, and intelligent compression designed to reduce bandwidth consumption without compromising visual quality. As a result, developers can avoid building and maintaining complex media processing pipelines internally.
However, this convenience often introduces scaling challenges. Many platforms rely on pricing models based on transformation credits or image requests rather than actual infrastructure consumption. As traffic grows, increases, costs can grow disproportionately, leading to expenses that outpace underlying resource usage.
Amazon CloudFront and AWS serverless services make it possible to build and cost-efficient image optimization pipelines directly on AWS infrastructure. The following sections explore the architectural trade-offs, design decisions, and serverless components behind this approach.
The Dilemma: SaaS vs. AWS (Build Your Own)
When building an image optimization pipeline, engineering teams typically face a fundamental architectural decision: adopt a specialized SaaS platform or build directly on top of cloud infrastructure.
On one side are mature platforms such as Cloudinary, Imgix, and CDN-native optimization offerings from Akamai and Cloudflare. These services are feature-rich and easy to integrate, often providing capabilities such as URL-based transformations, format conversion, resizing, smart cropping, and caching with minimal operational overhead. However, convenience at the beginning does not always translate to sustainability at scale.
The SaaS Model: Convenience with a Scaling Cost Curve
Most media SaaS platforms operate on transformation- or credit-based pricing models. Organizations are not simply paying for storage and bandwidth, but also for the abstraction layer itself. While this simplifies adoption, it introduces several long-term architectural and financial considerations.
1. Financial Decoupling from Infrastructure Usage
Costs are typically tied to image requests, transformations, or derived assets rather than actual compute or bandwidth consumption. As traffic scales, pricing can grow disproportionately, particularly for high-volume e-commerce and media workloads.
2. Vendor Lock-In
Image URLs, transformation syntax, caching behavior, and sometimes even asset storage become tightly coupled to the provider’s ecosystem. Migrating away later may require significant changes across frontend applications, caching strategies, and media workflows.
3. Limited Control Over Optimization Logic
SaaS platforms define the transformation engine and processing rules. Although these platforms offer flexibility, custom workflows, advanced routing behavior, or integrations with internal systems can become difficult to implement or unsupported entirely.
For startups, these trade-offs are often acceptable in exchange for speed and simplicity. However, at enterprise scale, they become architectural and financial considerations.
The AWS Alternative: Owning the Stack
Building an image optimization pipeline on AWS using services such as Amazon CloudFront, AWS Lambda, and Amazon S3 fundamentally changes both the architectural and cost model.
Instead of paying for transformations or platform credits, costs are tied directly to underlying infrastructure consumption, including:
- Compute duration
- Outbound bandwidth
- Storage
- CDN requests
Cost Efficiency at Scale
With AWS, costs scale more predictably with actual infrastructure consumption. There are no transformation credits or opaque pricing models tied to derived assets or image requests. At high volume, this can result in substantial cost savings, particularly when combined with edge caching.
Once an asset is transformed and cached in Amazon CloudFront, subsequent requests are served directly from edge locations without invoking compute again. Processing occurs once, while cached delivery handles the majority of traffic.
Full Ownership and Portability
Building directly on AWS also provides full control over the image optimization stack, including:
- The transformation engine (e.g., Sharp or FFmpeg)
- URL structure and transformation syntax
- Caching policies
- Security controls such as signed URLs or token validation
- Storage lifecycle management
Because the solution is built on infrastructure primitives rather than proprietary abstractions, it remains portable and easier to evolve over time.
Performance Without Compromise
Amazon CloudFront delivers content through a globally distributed edge network with low-latency delivery comparable to leading CDN platforms. Combined with serverless compute, transformation logic can execute close to the user while maintaining centralized operational control.
Rather than sacrificing performance, this approach replaces managed platform abstractions with programmable infrastructure.
The TrackIt Solution: Advanced Serverless Architecture
To combine the flexibility and performance of managed image optimization platforms with the cost efficiency of AWS infrastructure, TrackIt designed a custom serverless image processing pipeline based on the AWS Dynamic Image Transformation for Amazon CloudFront guidance solution. This architecture separates lightweight request routing from heavy processing workloads, ensuring compute resources are only invoked when required.
Architecture
CloudFront Function (Viewer Request): The URL Translator
Before a request reaches the cache or origin infrastructure, a lightweight CloudFront Function intercepts and normalizes the incoming URL. Human-readable transformation presets such as /t_thumb/asset.png are translated into the parameterized transformation syntax required by the backend processing engine.
Because this logic executes directly at the edge in approximately one millisecond, requests can be normalized before cache evaluation. This improves cache hit ratios and reduces redundant image processing operations.
Amazon CloudFront: The Global Cache
Amazon CloudFront serves as the primary delivery layer, caching transformed assets at edge locations globally to reduce latency and minimize origin load.
Lambda@Edge (Origin Request): Intelligent Request Routing
Standard AWS Lambda response streaming supports payloads up to 200 MB, which can still become a constraint for large raw media assets. To avoid unnecessary processing and payload bottlenecks, a Lambda@Edge function inspects incoming requests before they reach the transformation layer.
- Requests for untransformed assets are routed directly to Amazon S3, bypassing the compute layer entirely.
- Transformed assets are forwarded to the processing engine.
This routing model minimizes unnecessary compute invocation while ensuring large source assets do not pass through the transformation pipeline unless processing is required.
AWS Lambda (Function URL): The Processing Engine
The processing engine is powered by AWS Lambda and uses tools such as Sharp for image transformations, FFmpeg for video processing, and Poppler for PDF rendering.
To overcome standard AWS service limitations and maximize performance, the architecture incorporates two key optimizations:
Function URLs over API Gateway
The Lambda function is exposed using a Lambda Function URL instead of Amazon API Gateway. This avoids API Gateway’s 10 MB response size limitation, which becomes restrictive for media processing workloads involving large transformed assets.
End-to-End Response Streaming
Standard AWS Lambda responses are limited to 6 MB payloads. By enabling response streaming, transformed content can stream directly from Amazon S3 through the processing engine and back to the client in real time.
Instead of waiting for the entire transformation to complete, the client begins receiving data immediately as processing starts. This increases the effective payload limit from 6 MB to 200 MB while significantly improving Time to First Byte (TTFB), particularly for large image, video, and document transformations.
Key Transformation Capabilities
Powered by this serverless architecture, the pipeline exposes a Cloudinary-inspired URL syntax (for example: /c_crop,w_200,h_200/f_webp/image.jpg) that allows developers to control transformations directly through request parameters.
Core capabilities include:
- Dynamic Image Processing: Real-time format conversion (WebP, AVIF, etc.), dimensional adjustments (Crop, LimitPad, scale), and intelligent quality tuning to balance visual fidelity with file size.
- Video Manipulation: On-the-fly MP4 trimming via start/end offsets, resolution scaling, and precise frame extraction for thumbnails.
- Complex Format Support: Automated rasterization of complex design files (PSDs) and documents (PDFs) into web-ready images before applying further transformations.
- Advanced Delivery Logic: Device-aware optimization (automatically adjusting quality based on device type), conditional transformations, and automated fallback assets to ensure a resilient user experience.
- Named Transformations: Reusable transformation presets defined at the CloudFront edge to simplify frontend integration and standardize optimization behavior across applications.
Operational Use Cases
Format Conversion and Quality Optimization
One of the most impactful optimizations for web performance is serving images in modern formats. WebP consistently delivers significantly smaller file sizes compared to JPEG at equivalent visual quality, directly reducing bandwidth consumption and improving page load times.
The pipeline handles format conversion at the CDN level, meaning the source asset remains a JPEG in S3 while the client receives a WebP. No re-upload or manual conversion is required.
1# Original JPEG2https://dg2lhxtqga5i0.cloudfront.net/dog.jpeg34# Converted to WebP with device-aware quality5https://dg2lhxtqga5i0.cloudfront.net/f_webp,q_auto/dog.jpeg
The original JPEG was served as-is from S3. When the same URL was requested with f_webp,q_auto, the pipeline intercepted the request, converted the image to WebP on the fly, and returned it with a significantly smaller file size. The source asset in S3 was never modified and the conversion happened entirely at the processing layer.
The q_auto parameter adjusts compression based on the requesting device type, automatically applying higher quality for desktop viewers and more aggressive compression for mobile, where bandwidth is more constrained.
Dynamic Cropping and Resizing
Different product surfaces require different image dimensions. A thumbnail grid, a detail page hero, and a social media preview all have distinct aspect ratio and size requirements. Managing separate uploads for each variant is operationally expensive and error-prone.
The pipeline supports dynamic cropping with gravity control, allowing the most relevant region of an image to be targeted based on a single URL parameter.
1# Original image2https://dg2lhxtqga5i0.cloudfront.net/city.jpeg
.png%3F2026-07-21T03%253A47%253A02.751Z&w=3840&q=85)
1# Crop to 800x800 anchored to the left2https://dg2lhxtqga5i0.cloudfront.net/c_crop,w_800,h_800,g_west/city.jpeg
1# Crop to 800x800 anchored to the center2https://dg2lhxtqga5i0.cloudfront.net/c_crop,w_800,h_800,g_center/city.jpeg
1# Fit inside 400x400 with white background padding2https://dg2lhxtqga5i0.cloudfront.net/c_lpad,w_400,h_400,b_rgb:ffffff/city.jpeg
The original city photo was served without transformation. Adding c_crop,w_800,h_800,g_west returned a square crop anchored to the left side of the image. Switching to g_center shifted the crop region to the middle. Using c_lpad instead fitted the entire image inside a 400x400 box and filled the empty space with a white background, preserving the original content without any distortion.
The c_lpad mode is particularly useful for product catalogs where images have inconsistent aspect ratios. Rather than cropping content, it fits the image within the target dimensions and fills the remaining space with a configurable background color, ensuring visual consistency across a grid without distorting the original asset.
Document Rendering
PDF documents are not natively renderable as web images. Traditionally, generating image previews from PDFs requires a separate preprocessing pipeline, dedicated storage for derived assets, and manual orchestration between services.
This pipeline handles PDF-to-image conversion on the fly using Poppler at the Lambda layer. Requesting a PDF asset with an image extension triggers automatic rasterization of the first page, returning a web-ready image without any preprocessing step.
1# Original PDF2https://dg2lhxtqga5i0.cloudfront.net/AmazonCloudFront.pdf34# First page rendered as PNG on the fly5https://dg2lhxtqga5i0.cloudfront.net/AmazonCloudFront.png
The PDF was first opened directly in the browser as a document. Requesting the same filename with a .png extension triggered the pipeline to download the PDF from S3, pass it through Poppler, and return a rasterized image of the first page all within a single HTTP request, with no preprocessing or separate image stored in S3.
The source file in S3 remains a PDF. The conversion happens at request time, and the result is cached at the CloudFront edge for subsequent requests.
Automatic Fallback Assets
In production systems, missing assets are inevitable. Products get deleted, uploads fail, or content is staged before assets are ready. The conventional approach is to handle fallbacks on the client using JavaScript onerror handlers, but this always incurs two network round trips — the browser makes the initial request, receives a failure, and only then fetches the fallback.
Defining the fallback at the CDN level resolves the asset transparently in a single request. The logic is also defined once in the URL itself, rather than implemented and maintained across every frontend codebase that consumes the image.
1# Missing asset — returns Not Found2https://dg2lhxtqga5i0.cloudfront.net/non-existent-image.jpeg34# Same URL with CDN-level fallback5https://dg2lhxtqga5i0.cloudfront.net/d_dog.jpeg/non-existent-image.jpeg
Requesting a non-existent asset returned a Not Found response. Adding d_dog.jpeg to the URL told the pipeline to fall back to that asset if the primary one was missing. The response came back as a valid image in a single request, with no failed round trip visible to the client.
Named Transformations
As transformation combinations grow more complex, embedding full parameter strings in every URL becomes difficult to maintain. A change to the standard thumbnail specification requires updating every URL across every application that references it.
Named transformations solve this by defining reusable presets at the CloudFront edge. A single short alias expands into the full transformation string before the request reaches the cache or processing layer, keeping URLs clean and transformation logic centralized.
1# Full transformation string2https://dg2lhxtqga5i0.cloudfront.net/c_lpad,cs_srgb,d_thumb_default.jpg,h_100,w_100/city.jpeg34# Equivalent named transformation5https://dg2lhxtqga5i0.cloudfront.net/t_demo_thumb/city.jpeg
The full transformation string c_lpad,cs_srgb,d_thumb_default.jpg,h_100,w_100 was applied to the image and produced a padded 100x100 thumbnail. The same request was then made using t_demo_thumb, which expanded to the exact same transformation string at the CloudFront edge before the request reached the cache or processing layer. Both returned identical results.
Video Thumbnail Extraction
Generating thumbnail images from video assets typically requires a separate transcoding job, dedicated storage for the derived image, and coordination between media processing services. For large video libraries, this creates significant operational overhead before a single thumbnail is available.
The pipeline supports on-the-fly frame extraction from MP4 assets. Requesting a video with an image format parameter triggers FFmpeg to extract a frame at the specified offset and return it as a static image, without any preprocessing or separate storage required.
1# Original video2https://dg2lhxtqga5i0.cloudfront.net/video.mp434# Frame extracted at 2 seconds, returned as PNG5https://dg2lhxtqga5i0.cloudfront.net/so_2,f_png/video.mp4
The so_2 parameter specifies the timestamp in seconds. The extracted frame is cached at the CloudFront edge, so repeated requests for the same thumbnail are served without re-invoking the processing layer.
Conclusion
The six use cases demonstrated above cover a range of real-world media delivery challenges, all handled through URL parameters with no client-side processing and no changes to the source assets in S3.
What makes this architecture compelling is not any single capability in isolation, but the combination of them running on infrastructure you own. Each transformation is executed once, cached at the CloudFront edge, and served globally on subsequent requests. The cost model scales with actual infrastructure consumption rather than transformation credits, and the processing logic remains fully under your control.
For engineering teams evaluating whether to build or buy, the trade-off is clear at scale. SaaS platforms offer a faster starting point, but as traffic grows, so does the financial and architectural cost of the abstraction. This approach replaces that abstraction with programmable infrastructure that can be extended, audited, and evolved without vendor dependency.
The pipeline demonstrated here is a proof of concept, but the foundation is production-ready. Format conversion, smart cropping, PDF rendering, and video thumbnail extraction are not experimental features, they are solving the same problems that enterprise media platforms charge for, running on AWS primitives that your team already operates.
