Last week I wrote a post on enabling KMS encryption for a running Amazon RDS instance for the Open Source Database Community Blog of Percona . Glad to share with the amazing Percona community how at Funambol we encrypted dozens of Amazon RDS instances without significant downtime. You can read the post here.
I would like to take advantage of Server-Side Encryption with Amazon S3-Managed Encryption Keys for some existing buckets where I have some legacies applications storing data without S3 encryption. Encryption of data at rest is of course important and with the chance of doing it on AWS with a simple flag (or one line of code) there is not much of an excuse not using it while working with S3. But how does it work for old legacy applications where you might not able to change the client code soon? Unfortunately there is not a simple way to achieve it using S3 configuration only.
Ideally I would love to simply find a simple bucket property in the console but unfortunately there is not one. With a bucket policy I can of course lock PUT requests without server-side encryption but my goal is to convert them to PUT with server side encryption, not simply reject the requests. A bucket policy can only check for permissions on the object that is uploaded to S3 and compare to the rules set, it cannot transform data on the fly.
Any other option?
You can implement a Lamdba function that performs a new PUT for the same objects on every PUT of requests without the server-side encryption attribute: it has some implications on the costs but it’s an easy short term workaround while you adapt the legacy application and it’s entirely transparent to the existing clients, whatever they are using SDKs or directly performing HTTP requests (check the doc to get a general idea about S3 integration with Lambda)
Of course the long-term solution should be to implement Server Side Encryption with the SDK changing client code but a Lambda function can be your short-term hack.