Cloud Worry or Risk?

I have the privilege of speaking to hundreds of customers a year to talk about how AWS can help their businesses deliver more value to their customers, become more agile, and create innovations that delight in this digital age. However, occasionally I’ll hear statements like, “What if AWS goes away?” “What if AWS decides to yank service such and such?” or “I worry if I use your cloud native services, I’ll be locked in.” All of these questions, left unmanaged, temper or inhibit their adoption of the cloud and its associated advantages.

My response is not to wave away or discredit these concerns. Capturing the “What if?” is the first step in risk management. When I delivered large and complex systems in my consulting days, one of the ways we assured that these types of projects were delivered with a high degree of success was to have a trusted and seasoned consulting partner assigned as an independent quality assurance auditor. Everyone would take these reviews extremely seriously, as the audit findings would go straight to the top of the organization. A sure way to be put in the hot seat was not to have an active and well-managed issues and risk register. From my perspective, risk management is a table stakes activity for any delivery of capability (no matter the delivery methodology: agile, XP, waterfall, etc), including developing, managing, operating, and securing applications and data in the cloud.

However, just asking and being concerned around the “What ifs?” does not constitute risk management. More worrisome is when business decisions and investments are made solely off the questions, concerns, and fears. Risks are defined as negatively impactful events (loss, injury, damage, etc., and typically represented as a monetary value) that have a probability of occurring. Calling out the event without capturing the specific impact and probability of occurrence is just a worry or fear.

I did a quick web search on managing cloud risks and found that most of the guidance focused more on categorizing and describing the types of things that could go wrong in the cloud rather than on their probability of occurring, their impact, and how best to mitigate them if they do occur. The issue is that all of these “risks” appear equal in stature. Is the risk of a data breach due to unencrypted data equal to vendor lock-in? Given the limited resources and management attention of any organization, the danger is focusing and investing in mitigating the wrong types of risks.

So how do you create a prioritized list of your cloud risks? Calculate the expected loss value of each risk by multiplying the probability of the event and the monetary impact. Even if you don’t have the actual probability of the event or monetary impact, simply assigning a value of low, medium, and high is better than not doing it at all. What should bubble to the top are high probability and high impact risks.

The next step in risk management after you’ve prioritized your risks is to have a mitigation for each risk. But one thing I see organizations getting wrong is they put in place a risk mitigation that exceeds the expected monetary value of the risk. There’s a sometimes a concern that AWS will behave as some legacy providers have by raising prices once they have your business. At the time of writing this blog, AWS has lowered prices over 70 times, so I think one can make a rather strong argument that the risk of price increases is a low probability event. But if AWS did raise prices on a service like EC2 to the point of causing a desire to migrate, the impact would be the cost to move workloads and data out of the AWS cloud. Whatever assumptions or metrics you use, a very low probability multiplied by even a large migration cost will end up with a relatively low expected risk value. There are a number of mitigations which I’ve heard from companies, ranging from developing a plan for exit to investing in platforms and architectures, to allow for moving workloads quickly between clouds. Each of these approaches should be measured against the expected value of the risk.

Whatever mitigation approach is decided, I would be thrilled if organizations followed standard risk management processes to assess their cloud risks versus making emotional decisions because they have been burned by the behavior of legacy vendors. But perhaps more importantly, the expected value of the opportunity that comes from moving to AWS (innovation, agility, increasing resiliency, etc.) needs to be weighed against the expected value of the risk. My bet is that when the risk is documented and assessed correctly the opportunity to use cloud services will trump the risks every time.

Never stop innovating,

Joe