What about Transparency?
If you need to seek for transparency, your provider failed.
Around September 25, AWS notified their valued customers of ongoing reboots of their EC2 infrastructure during the course of the upcoming weekend. The notifications always also stated: “You will not be able to stop/start or re-launch instances in order to avoid this maintenance update.” Hence, we – and many others, obviously – were forced to undergo this maintenance and prepare for any potential subsequent maintenance of their own following any possible failure during the reboot (which admittedly we were lucky not to have).
In an attempt to understand the root cause of this “scheduled” maintenance, we were able to discover some forum conversations such as this one: https://forums.aws.amazon.com/thread.jspa?threadID=161544&tstart=0
On Wednesday, Oct 1st, customers received an eMail notification subjected “Follow-up Note on Bash Security Issues from Last Week” which claimed that AWS “reviewed the security issues, known as CVE-2014-6271 and CVE-2014-7169, and determined that our APIs and backends were not affected“. More detailed explanations were linked into the eMail referring to an AWS Security Bulletin.
When digging a little further into the issue, I was able to discover this article (also dating September 25th).
At this very moment it is still unclear what really caused the host reboots affecting many EC2 customers, and while AWS did a very good job in sending target oriented information to those customers who are really affected by the reboot (rather than spamming everyone with the info), they failed completely in making it transparent to users why the reboots need to happen.
Security – ladies and gentlemen at AWS – is about transparency. First and foremost.
