The S3 Standard class is designed for general purpose object delivery. With its low latency response and highly scalable throughput capacity, it delivers the lowest price for any content that is frequently accessed. It offers the ability to encrypt data at rest with Server Side Encryption (SSE) and encryption of data in transit with SSL. The objects stored in the S3 standard class deliver 99.999999999% durability and 99.99% availability within a 24/7/365 regimen. The objects are replicated across three availability zones within one region or three facilities in two regions if the region only has 2 zones. The service is designed to self-correct disk errors, and can withstand a complete loss of data within one region.

The ability to self-correct errors is derived from having three pieces of data that can be compared. S3 maintains MD5 checksums of all objects stored on the S3 backend, which can be compared. If there is an error in one of the objects, then the MD5 checksum will be different than the other two. Now have a quorum with a majority of 2:1 that will define what the correct piece of data is and that can push a replication request for the object that is corrupted. Even though unrecoverable errors in data storage happen at a very small statistical scale - the ratio is about    bits read successfully to reach one bit error - when you're working with billions of files stored across hundreds of thousands of disks, even a small statistical failure rate is not so insignificant at all.

S3 also supports the ability to replicate data to buckets in other regions, giving us the ability to protect the data even further, but there are of course cost implications for such replication as the data is transiting the internet and we will have to consider the cost of the traffic generated for replication.

S3 standard is our entry point when building a life cycle for our data, as it integrates seamlessly with the other storage classes in a policy that we can customize to our needs. For instance, we can keep the most recent, most frequently accessed or so-called hot data needed in our application in S3 for a certain time - perhaps 30 days - and after that time, we can set a life cycle policy that will move that data to S3 Infrequent Access as it becomes cold, meaning less frequently accessed.