- The S3 service has a very broad feature set.
And part of that is because it's been around for so long,
since 2006,
but also because it has a really broad acceptance
as far as customers realizing
that there are so many different ways to use it
that they keep asking for new features
to go along with that.
So let's start with some security features.
S3 is one of the services
that supports resource based access control.
So you can provide a bucket policy
that looks a lot like an IAM policy
to grant or restrict access to your bucket.
There is a feature called S3 Block Public Access
which acts as a sort of an override switch
on top of public access
so that you can disable the capabilities
for making buckets or objects public.
In addition to bucket policies,
S3 also supports bucket and object ACLs
or access control lists.
These are primitive permission mechanisms
that have been around since the service was released
and are still in use by a couple of different features
and integration points across the rest of AWS,
including if you create a pre-signed URL
for an object in an S3 bucket,
it uses an ACL to provide that permission.
You can also enable object level encryption.
And you can make it a default at the bucket level
but you can still override on a per object basis.
And this is going to be at rest encryption
with a number of different key options.
Let's take a look at some of the object management features.
We can create lifecycle rules
which give you the ability to move data
through the different storage classes as they age
or even delete them.
You have versioning,
which we're actually gonna talk about in just a moment,
which turns your bucket
into sort of a version control system.
And you have the ability
to replicate the contents of your bucket
or prefixes within the bucket
to other buckets in the same region,
across region, same account, cross account,
and even doing multi-way replication across several buckets.
So let's take a look at lifecycle rules
in a little bit more detail.
As far as the options go,
you can choose to transition current versions of a resource
into other storage classes,
recognizing that you can only move left to right
through standard S3 IA, Z-IA,
and then through the glacier classes.
You cannot move backwards.
You can transition previous versions of an object
in the same way.
You can choose to expire current or previous versions.
And when we say expire, we mean delete.
But if you have versioning enabled,
it simply adds a delete marker
and we'll talk about that shortly.
You can also choose to delete incomplete multipart uploads.
This is something that is a cost saver,
that if a client had attempted to upload a large object
and failed somewhere in the middle,
you still pay for the partial data that was uploaded.
So now let's take a look at versioning.
When you create a bucket,
the default behavior is for it to be unversioned.
And that means it doesn't create any versions of new objects
and it's simply unconfigured.
But if you enable versioning, from that point forward,
you can suspend the versioning,
which stops new versions from being created,
but you cannot return it to the unversioned state.
Now a version enabled bucket is going to attach a version ID
to every version of an object.
If you delete an object, it simply attaches a delete marker.
It doesn't actually delete the data.
And if you ever have a requirement
to avoid accidental deletion,
providing a sort of recycle bin,
this is one way to go about it.
There are only a couple of ways in all of AWS
where you can guarantee data will not be deleted
under any circumstances.
The glacier vault lock is one of them.
So there are S3 buckets and there are glacier vaults.
When you transition data into glacier,
it's going to be placed into a vault.
And while the glacier vaults provide a policy
similar to bucket policies,
they have a second policy called a vault log.
And this is also a permission policy.
You use it for very specific purposes,
such as denying deletes on your data.
You can use it to enforce lifecycle rules
but what really makes this unique
as a resource based policy, is when you create it,
you have 24 hours to verify.
And once you do that verification,
that policy is locked forever.
There is no way for you to change or delete the policy.
And there's no support request that you can put into AWS
to ask them to do the same.
Now, another feature of S3 is that as an object store,
every single object has its own URL
that you can use to access it.
However, the data is private by default
and it does require authentication
and permissions to reach them.
But when you enable public access to an object,
you use that URL to access the object.
An entire bucket can be turned into a static website.
And if you do that, you have access
to be able to create redirect engines
around different prefixes and URLs.
And finally, and I mentioned these a little bit earlier,
you can create pre-signed URLs
against an individual object in a bucket
to allow a client to access it
without providing explicit authentication
and permissions to do so.
Now, when you enable S3 static website hosting,
there are a couple of things
that you can do from that point.
First off, the bucket name has to match
the DNS you're gonna use to reach the bucket
if you want to use custom DNS.
Next, you can configure an index document.
So like index.html, or something like that.
You can configure error pages for different error codes.
You can even configure redirects
and turn your bucket into a redirect engine.
And you can enable access logs,
which are then delivered to a different S3 bucket.
However, there is a trade off.
If you enable static website hosting,
you cannot use HTTPS to access those objects.
You can only use unencrypted transports.