Thread by @paulmeighan

Why Object Lock is Cool: A Twitter Thread

With all this talk about Veeam 10, I thought it would be good to take a step back and send out a note on why I am absurdly into S3 Object Lock. /1

What is Object Lock you ask? GREAT QUESTION. Object Lock gives customers a write once read many (WORM) capability in S3. This allows you to render S3 objects immutable, so that they cannot be deleted by any means, before a date that you specify. /2

WORM storage is useful in compliance scenarios that explicitly require it; and also as a general layer of data protection against ‘oh crap moments.’ By definition, the best way to protect against accidental deletes is to just throw away the delete key. /3

In fact, there is literally no way to delete an object in S3 with a compliance-grade lock on it, short of deleting your AWS Account. This is a feature, not a bug. Our regulated customers need this as tablestakes, and many others have a strong preference for it. /4

Our good friends at @CohassetAssoc did the Object Lock compliance assessment. The assessment is a good read, not just for compliance people. It’s a tech paper, and provides a good third-party view on how to not accidentally delete your stuff. /5

d1.awsstatic.com/r2018/b/S3-Obj…

Object Lock is extra cool for two reasons. First, you get the granularity of object-level controls, while still being able to set a bucket-level default for any object coming in. Second, it comes in 3 flavors, which gives you options based on what you want to do. /6

Why in tarnation do I care about object-level controls you ask? Well, we’re talking about potentially long retention periods. You’ll want to have the option to act with precision, especially when you need to extend a retention period. OL lets you do that on a single object. /7

Here’s a view of object-level meta-data in a head request made from the CLI. I’m waaaay to amused by this I know. IMMUTABILITY IS DEFINED IN OBJECT META-DATA YOU GUYS HOLY MOLEY. /8

BUT – Acting precisely all the time can be not so hot. Sometimes we want to just apply defaults and let it ride. OL lets you do that too. A bucket-level default may seem contradictory to the object-level thing that I was just fawning over, BUT IT’S NOT. /9

What that bucket-level default does, is it stamps each object with a Retain Until Date on the PUT, based on a retention period that you specify. This happens on the fly as each object is created in the bucket. /9

This allows you to apply a rolling retention period with just a simple bucket-level config /10

The second reason that OL is cool is that it comes in three flavors: COMPLIANCE, GOVERNANCE, and LEGAL HOLD. This gives you a bit of flexibility on the type of lock that you want to apply, based on what you’re trying to do. /11

Compliance Mode is a hard lock. Please be careful with Compliance Mode. You can’t unlock it. We can’t unlock it. Seriously. When you’re talking about compliance with the law though, or if you have data that there’s no way you would ever delete – Compliance Mode rocks. /12

Governance Mode is a soft lock. We have dedicated permissions in IAM for Governance Mode, that you can vend out to a small number of users in your environment that can be used to break locks. This gives you a break glass mechanism if compliance is not your gig. /13

Finally we have Legal Hold, which is similar to Governance Mode in that it provides a lock that can be broken. It has dedicated IAM permissions, so that you can isolate these operations to specific users, and there’s never an end date; you have to explicitly remove holds. /14

So that’s it – WORM in the cloud with all the trappings. Object-level locks with bucket-level defaults that can be applied in three flavors. And that’s why I love S3 Object Lock. And if you made it this far you're a storage nerd and we should be friends. Or you're my mother. /15