In this guide, we compare Cloudinary vs S3. While the services seem different at first, there's a few important factors to consider, including AWS S3 Object Lambda...

AWS S3 and Cloudinary are huge names when it comes to file hosting – particularly media files (images, video, and audio) with respect to Cloudinary.

There are many websites using these services for asset hosting: you only need to open the network tab in your browser, and eventually, you'll see a website serving files from S3:

https://my-website.s3.us-west-2.amazonaws.com/puppy.png

Or from Cloudinary:

https://res.cloudinary.com/my-website/image/upload/puppy.jpg

So it's only natural to ask:

When it comes to media storage and hosting, which is right for me?

In this article, we'll answer this question by giving you a side-by-side comparison of Amazon S3 vs. Cloudinary, with a clear summary of when to use each. We'll also present a 3rd option: Bytescale's Image CDN, which works well as a cost-effective option for fast image hosting.

Cloudinary vs S3: Overview

Both Cloudinary and AWS S3 share the same core set of features:

Where they diverge is in functionality and cost: Cloudinary offers more functionality, whereas S3 is much cheaper.

To summarise the above diagram, both Cloudinary and S3 provide:

• File uploads (with support for direct uploads from your website's forms)
• File storage
• File hosting
• File versioning
• Command-line interface (CLI)

In addition, both services also provide (not included in the diagram):

• File management dashboard
• Application programming interface (API)
• Software development kits (SDKs)

Cloudinary also offers the following additional features, which S3 does not:

• Image processing
• Video processing
• Reverse proxy
• Built-in CDN
• HTML file upload widget

Whereas only S3 provides:

• Large file support (up to 5TB for S3, compared to Cloudinary's variable limit that ranges from 10MB to 3GB, depending on the file type).
• Cheap storage.
• Cheap bandwidth.

Let's take a further look at the functional differences between the services:

Cloudinary vs S3: Features

When it comes to features, Cloudinary wins hands down. Even if you're a developer requiring the more advanced API feature from S3, you can always drop down into S3's API when using Cloudinary, since Cloudinary supports custom S3 buckets as a file storage backend.

So the question becomes: is Cloudinary worth the extra features it brings on top of S3? Let's see:

Cloudinary vs S3: User Interface

Cloudinary's user interface contains thumbnails, image previews, and an advanced search:

Compared to S3's user interface, which displays much less information:

Cloudinary's dashboard offers the following additional benefits over S3's dashboard:

• Advanced search (i.e. search by aspect ratio, media type, etc.)
• Recursive search (i.e. enter a file name, and search all folders recursively)
• Image previews (annotated with pixel dimensions)

S3's dashboard doesn't appear to offer anything that Cloudinary's doesn't. (Aside from displaying the storage class for each object, which is an S3-specific feature that allows you to store objects/files in differently-priced storage tiers.)

Winner for User Interface (UI): Cloudinary

Cloudinary vs S3: Command Line Interface (CLI)

Both Cloudinary and AWS offer a command line interface (CLI): a tool for developers to use when working with the service.

CLIs aren't essential, but they definitely make certain development tasks easier: for example, automatically uploading files when publishing the new version of a website.

Cloudinary's CLI is largely inspired by AWS's CLI, so the two are similar:

Both CLIs use a hierarchical command structure. Cloudinary's CLI allows you to pass --help to any command to learn more about it, whereas AWS's CLI allows you to pass help:

AWS's CLI is marginally better: it provides manpages with improved formatting, more output options (JSON, plain text, etc.), and paging. However, we doubt these features would ever be important enough to influence a purchasing decision, so for that reason, we're calling it a draw.

Winner for Command Line Interface (CLI): Draw

Cloudinary vs S3: Uploading Files From The Browser

Both Cloudinary and S3 support file uploads from the browser (i.e. from your website's forms).

Cloudinary supports "signed uploads" and "unsigned uploads".

AWS S3 only supports "signed uploads".

Here's what the two terms mean:

• Unsigned uploads: only require frontend code, so are simpler for developers to implement, but also means hackers can upload any type of file to your AWS/Cloudinary account.
• Signed uploads: requires backend code (in addition to frontend code), so takes more time to implement, but provides greater security.

While S3 supports browser-based file uploads, only Cloudinary provides a file upload widget, which will save you time if you require progress bars, image previews, etc.:

Cloudinary's file upload widget handles:

• File upload progress
• File upload cancellation
• File type filtering
• Image previews
• Image cropping

Cloudinary's widget is very large, however, at 974KB.

By contrast Bytescale's Upload Widget is only 33KB (shameless plug!):

However, when it comes to Cloudinary vs. S3 for file uploads, Cloudinary's larger array of browser-based options make it the winner when compared to S3.

Winner for Browser File Upload Support: Cloudinary

Cloudinary vs S3: File Storage

It's worth noting that Cloudinary uses S3 internally, and on Cloudinary's Enterprise plans (i.e. it's custom plans) you can pay extra for a custom S3 bucket. This means you can use Cloudinary, while still benefiting from all of S3's features (assuming your business can afford a Cloudinary Enterprise plan).

S3 storage offers the following features:

• Storage classes (i.e. "standard", "intelligent tiering", "infrequent access" and "archival" – each offer different performance and price profiles.)
• Storage class analysis (an automated AWS tool that suggests the best storage class to use based on your bucket's usage patterns).
• Encryption at rest (using either SSE-S3 or SSE-KMS – i.e. with or without KMS – both settings are bucket-level and won't interfere with Cloudinary).
• Replication (i.e. backing up your files across multiple S3 buckets).
• Kinesis streams integration (i.e. for fast processing of file upload events).
• Max file size: 5TB

Cloudinary's built-in storage offers the following:

• Automatic regional backup.
• Max file size: 4GB for video. 40MB for everything else.

Winner for File Storage: S3 (or Cloudinary, if you're an Enterprise customer and are using a custom S3 bucket)

Cloudinary vs S3: File Hosting

An S3 bucket always resides in one AWS region. This means your files are hosted from a single city. If you host your files in a "US East" S3 bucket, then file downloads from Australia will likely be slow due to latency. (Fibre optic cables, while fast, are still limited by the speed of light: the further away the data center is, the slower your downloads will be.)

Cloudinary, by contrast, comes pre-integrated with a content delivery network (CDN) to ensure files are hosted close to your users.

CDNs work by serving copies of your file all around the world, reducing the distance – and therefore latency – between your files and your users.

There are many CDNs on the market, with Akamai, Fastly and AWS CloudFront being among the most popular.

Which CDN does Cloudinary use?

Cloudinary currently uses Fastly for its free and off-the-shelf plans. Cloudinary Enterprise customers can elect to use multiple CDNs, in which case Cloudinary will dynamically switch between Akamai, Fastly and AWS CloudFront.

With regards to S3's support for CDNs, it goes without saying that AWS CloudFront can very easily be configured to sit "in front" of an S3 bucket. However, since we're measuring out-the-box performance of Cloudinary vs. S3, we have to give the point to Cloudinary (since it comes pre-integrated with a CDN).

Winner for File Hosting Performance: Cloudinary

Cloudinary vs S3: File Processing

Both Cloudinary and AWS S3 support file processing.

Cloudinary's file processing is "ready to go", with out-the-box file transformations such as image resizing, image cropping, and video transcoding.

AWS S3's file processing – which it provides through a feature introduced in 2021 called Amazon S3 Object Lambda – is more like a basic building block for developing your own file transformations through code. For example, to resize an image with S3, you'll need to use ImageMagick on AWS Lambda to perform the image processing – something that requires a non-trivial amount of code.

If you require ready-made transformations: use Cloudinary.

If you require custom code transformations: use S3.

If you require both: use Bytescale.

When evaluating Cloudinary vs. S3, most prospective users will likely be interested in common operations such as image processing and video processing – which Cloudinary provides out of the box. Therefore, when considering S3 vs. Cloudinary for file processing, we have to give the point to Cloudinary.

Winner for File Processing: Cloudinary

Cloudinary vs S3 Pricing

Is S3 cheaper than Cloudinary?

If we compare storage costs alone, Cloudinary stands at around 16x more expensive than S3. (Cloudinary's most economical tier is around $0.37 per GB, whereas S3 starts at $0.023 per GB.)

However, this isn't a fair comparison.

We need to look at the total cost of ownership (TCO) of AWS S3 vs. Cloudinary, and to do that, we need to make some assumptions.

Let's say we're building Flickr.

Requirements:

• We need a CDN (to provide fast downloads to our users).
• We need to accept image uploads from our users.
• We need a file upload UI in our website's forms, with an image cropper, and file upload progress bars.
• We need to display these uploaded images, resized, on other parts of the website.
• We estimate 1000 unique visitors per day (immediately after launching the website). Each visitor on average will upload 1 raw photo, and download 100 photo thumbnails. (We've chosen 1 raw upload per visitor to account for the fact that most visitors will only be downloading.)
• We assume the average raw photo size is 10MB and the average thumbnail size is 0.1MB.

Our capacity plan:

• +297GB storage / month. Calculation = 365/12 * 1000 unique visitors * 1 raw uploads * 10MB raw photo size
• 297GB upload bandwidth / month. Calculation = same as above
• 297GB download bandwidth / month. Calculation = 365/12 * 1000 unique visitors * 100 photo thumbnails * 0.1MB thumbnail size

Now for the hidden cost: our development team's time!

• Build your own file upload UI for your website's forms: 160 man-hours.
• Build the backend code for signed S3 file uploads: 20 man-hours.
• Build an Amazon S3 Object Lambda function to perform the image thumbnail generation using ImageMagick: 40 man-hours.
• Add AWS CloudFront in front of AWS S3: 2 man-hours.
• Maintenance for all the above: 4 man-hours per month.

Now we know our initial and ongoing resource requirements.

Next, we need to assign a cost to these resources...

For our manual labor costs:

• Assume $70 per man-hour.

For our AWS costs:

• S3 upload bandwidth is free.
• S3 download bandwidth is free (as it's going via CloudFront in our solution)
• S3 storage is $0.023 per GB.
• CloudFront download bandwidth is $0.085 per GB.

For our Cloudinary costs:

• Cloudinary uses a credit-based system.
• One Cloudinary credit is roughly $0.37.
• One Cloudinary credit buys you 1GB of storage or 1GB of download bandwidth.

Breakeven Point (BEP) for Cloudinary vs. S3 Pricing:

As you can see, while Cloudinary is cheaper for the first 18 months, a custom-built S3 solution would prove cheaper after month 19.

The questions you need to ask yourself are:

• How certain is your project's success?
• Do you have the time to invest in a custom solution now?
• Are there better things you could be building instead, that would improve the functionality of your product? (Generally speaking, you should focus on building features first, and then aim to reduce costs later.)

If you answered "Yes, yes, no" to the above three questions: S3 is most likely your best option. Otherwise, go with Cloudinary!

Winner for Pricing: Draw (S3 has lower ongoing costs, but larger upfront costs. To determine which is most economical for you, you'll need to plot your own breakeven point – like in the example above – and then answer the above 3 questions.)

Conclusion

Our conclusion on the S3 vs. Cloudinary comparison:

AWS S3 is the winner on pricing. Of course, this is only assuming you require basic file hosting, without image or video processing. If you do require processing and have the resources to build your own processing pipelines, then in the long-run AWS S3 will be cheaper, although upfront development costs will be more.

Cloudinary is the winner on functionality. Cloudinary, which is built on top of S3, was built to solve the end-to-end process of file uploading, processing, storage, and hosting. As such, it's better to view Cloudinary as an extension of S3, rather than a competing product. Most notably, Cloudinary supports image and video processing, comes with a built-in CDN (which S3 does not), and also provides a file upload widget to use in your website's forms.

Cloudinary's biggest drawback is cost. At around $0.37 per GB of storage, compared to $0.023 per GB for AWS S3, Cloudinary works out almost 16x more expensive. This cost is largely justified, of course, if you're using all of Cloudinary's file processing features, and not just using it as file storage.

A cheaper alternative to Cloudinary is Bytescale. Bytescale is newer and offers a modern developer experience compared to Cloudinary.

Summary:

• Only need file storage? Choose AWS S3.
• Need image/video/audio processing too? Choose a service like Cloudinary or Bytescale.

Whatever decision you make, we hope you enjoyed reading this article and found it useful! 😊