With a number of recent high-profile leaks of personal data on Amazon Web Services (AWS) S3 service, it seems like a good time to review the security mechanisms that govern storage and sharing of data from AWS. If your organization uses S3 for storage of PHI, PII, or other sensitive data, you should be aware that failure to properly secure and restrict access and log this information can carry hefty fines and even jail time. Leaking users’ personal data can also be detrimental to your business model. (Photo Credit: Flickr)
What we have to say, what you want us to hear.
That’s how our blog works. It’s interactive. Let’s learn together.
Serverless application architectures are still an emerging art form. One of the big challenges serverless architectures pose is traceability and debugging. Because we are dealing with many discrete entities performing as a single cohesive unit, we want to be able to see the impact of those entities on the system as a whole.
A little over two weeks ago, large sections of the internet ground to a halt. Many sites, from Netflix and Spotify to Pinterest and Buzzfeed were unresponsive, during a four-hour outage of Amazon Web Services’ (AWS) S3 – Simple Storage Service. For two of those four hours, AWS couldn’t update the service status from “Service is operating normally” because the status itself depended on the storage service’s operation. Should you trust your data with AWS? Why shouldn’t we start calling S3 the “Sometimes Storage Service?” How could this event be a good thing?
Welcome to the final installment of Reasons to Deploy in the Cloud! In this series of posts, I'm discussing some reasons for choosing a cloud platform. Previously I've talked about managing costs, the power of scaling, ease of management, interoperability, and in the last post, reliability. This is the final part of the series, discussing flexibility.