Welcome to 'Back to Basics'.
I am Gerardo Estaba
and today we're going to talk about the basics
of handling public and private files
with your cloud application.
Your cloud application is likely using a combination of both.
So let's say... a public website.
And just those static files to serve your website.
What do you store?
Your HTML, CSS, JavaScript, and other media files,
so that your users can access your website.
A common anti-pattern I've seen is to bundle those files
together with your back end application code.
For example, if you already had application code
running on EC2, I can see why installing a web server
on the instances and bundling your static website
with the rest of your app might be tempting.
It sounds simple and sure,
it can work..
But coupling software components
is rarely a good idea.
For instance, having multiple developers working on
the same code base can bring challenges.
Merging everyone's changes can become
a stressful experience.
But also think about a software release.
Imagine having to release software and going
through the whole process every time you need to make a change
in something trivial from the website, like an image.
It sounds like a waste of time.
In modern software architectures you want your components
to be loosely coupled.
This will make applications not only faster to scale,
but easier to manage and troubleshoot.
The best place to store and serve static websites
on AWS is Amazon S3.
Among other things because it's designed for four nines
of availability and eleven nines of durability.
And for static website files, S3 offers
built-for-purpose website hosting functionality,
removing the need to use web servers completely.
You also enable website hosting on the S3 bucket
where your static website files are.
And to deliver your website securely
over HTTPS, and at the same time speed up
website delivery to your users, you can use
a CloudFront distribution in front of it,
which then becomes the entry point to your website.
Your website is then automatically updated
by simply uploading new files, deleting files
or replacing individual files on that S3 bucket.
So your static website files are best on S3.
But what about user files such as documents or user photos?
Can we store those on the EC2 instances' file systems?
Well, I would not recommend that.
On one side, your files will have less availability
and durability than on S3, but on the other,
it would also be costlier from the storage, network,
and EC2 processing capacity, as opposed to S3.
And for auto scaling apps, it'll be hard to keep a copy
of all the files in sync on each instance,
or unnecessarily complex to introduce
a network file share.
It is hard to beat S3 at this game.
On S3, you don't get any of these issues.
S3 is a great place to store private files, such as user files.
By default, all S3 buckets and objects are private.
So how do we let our application access these
private objects on S3?
Well, two things need to happen.
First, the application needs to have permission
to access the bucket.
You do this by having the EC2 instances
assume an IAM role with an IAM policy
that allows access in the S3 bucket.
This is similar if your application is on ECS,
on EKS, Fargate, or Lambda.
All these can assume IAM roles.
Second, your bucket needs to allow to be accessed.
This is done by configuring a bucket policy,
which is simply a resource-based IAM policy
with permissions to access that bucket.
Now you have two S3 buckets, one with your
public website files and one that is private
but only your applications can access.
What if you want to share a private file with a single user?
You certainly don't want to make a private file public
because that would risk unintended access
by every other user as well.
Instead, you can use a pre-signed URL
to grant temporary access to a specific S3 object.
A pre-signed URL can be constructed using
the AWS SDK or the AWS CLI
and it uses the creator's own security credentials
to sign the URL to add a layer of security to it.
Then, you give the URL to your user
and the user will be able to access the object
for a limited time that you configured.
When this time lapses, the pre-signed URL
will no longer access the object.
So there you have it.
Amazon S3 is a great addition to manage files
with your cloud application.
Use it to decouple the application,
to serve public websites, to keep private files private,
and to share files, as needed, securely.
Keep on building and I'll see you next time.