Answers: <p>I'd take that as a math problem with the SLA being the probability of being OK.</p>
  
  <p>In this case we can rely on <a href="https://en.wikipedia.org/wiki/Probability#Mathematical_treatment" rel="noreferrer">probability rules</a> to get an overall.</p>
  
  <p>For your first case the probability that App Service (A) and Sql Service (B) are down at the same time is the product of their probability:</p>
  
  <pre><code>P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025
  </code></pre>
  
  <p>The probability that one of them is down is the sum of their probability:</p>
  
  <pre><code>P(A)+P(B) = 0.001
  </code></pre>
  
  <p>When two events are independents the resulting formula to take in account the probability of both being down is:</p>
  
  <pre><code>P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975
  </code></pre>
  
  <p>So the overall SLA would be <code>1 - 0,00099975 =  0,99900025</code> wich in percent is <code>99.900025 %</code></p>
  
  <p>A simplification is the product of the first probability: <code>0.9995 * 0.9995 = 0,99900025</code>.</p>
  
  <p>Applied to your 1h/24h outage (4,166666% of a day)  this gives (decimals are abbreviated):</p>
  
  <pre><code>0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222
  </code></pre>
  
  <p>So the probability of being OK is <code>1 - 0.0816 = 0.9184</code> in percent: <code>91,84%</code></p>
  
  <pre><code>24 * 0.0816 = 1.95 h
  </code></pre>
  
  <p>This is less than the worst case of 2 hours because there's a chance both are down at the same time.</p>
  
  <p>Keeping that in mind, you may notice the availability for each is <code>95,84%</code> and <code>0,958333333 * 0,958333333 = 0,918402778</code> which is our <code>91.84%</code> from above (sorry for the full decimals here, but they are needed for the demonstration)</p>
  
  <p>Now for your second case, we'll start gain from our compound probability for each region (Sorry I dismissed the change for SQL to keep it reasonable), assuming there's no independent probability for the region itself and that each region is isolated and as such a DB failure take only its region down.</p>
  
  <p>We have the traffic manager OK probability <code>P(T) = 0.9999</code> and each app+DB couple with a OK probability <code>P(G) = 0,99900025</code> from </p>
  
  <p>How much region we have play a role as we have to apply the product of failure probability only to get the probability both region are down as the same time:<br>
  <code>0,00099975 * 0,00099975 = 0,0000009995000625</code> which means an overall availability of at least one region of <code>99,049375 %</code> </p>
  
  <p>Now we have the overall regions availability, the product with the traffic manager one give us the overall availability of the system:</p>
  
  <pre><code>0.9999 * 0,9999990004999375 = 0,99989900059988750625
  </code></pre>
  
  <p>The overall availability is <code>99.989900 %</code> </p>
  
  <p>Another source as explanation is available on <a href="https://docs.microsoft.com/en-us/azure/architecture/resiliency/#composite-slas" rel="noreferrer">Azure's docs</a> (link courtesy of <a href="https://devops.stackexchange.com/users/11333/raj-rao">Raj Rao</a>)</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-30T18:15:49.157Z
Answers: The overall availability seems very low - in fact by adding an additional region and traffic manager the SLA is an order of magnitude lower than if it was just a single region.  I'm trying to dig how I used to do this for networks out of the back of my brain.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-03-30T18:29:10.500Z
Answers: Phew! I was sure I was going mad.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-03-31T08:02:04.087Z
Answers: @RichardSlater maths corrected
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2019-06-11T15:17:10.353Z
Answers: SQL Azure is 99.99% not 99.95%
Answers: Jeffery Tang
Answers: CC BY-SA 4.0
Answers: 2020-09-25T11:28:33.880Z
Answers: composite-sla link content has been moved here : https://docs.microsoft.com/en-us/azure/architecture/framework/resiliency/business-metrics#composite-slas
Answers: callee.args
Answers: CC BY-SA 4.0
Answers: 2020-09-30T20:04:58.690Z
Answers: @callee feel free to edit to correct the link
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-12-12T22:36:56.677Z
Answers: There is also this document that demonstrates this calculation: https://docs.microsoft.com/en-us/azure/architecture/resiliency/#composite-slas
Answers: Raj Rao
Answers: CC BY-SA 4.0
Answers: 2018-12-13T08:39:51.397Z
Answers: @RajRao Thanks for the link, I've included it in my answer, it wasn't existing when I wrote this answer though ;)
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-12-13T11:36:18.883Z
Answers: not to complicate matters,but why are the probabilities assumed independent? Surely Bayesian statistics should be considered?
Answers: Bruce Becker
Answers: CC BY-SA 4.0
Answers: 2018-12-13T12:24:32.737Z
Answers: @BruceBecker probably yes, at it certainly seems that the IEEE has published research on the topic, I suspect however given the purpose of calculating these numbers it is more about having concrete "proof" that you do, or do not, need High Availability capabilities added to a system - i.e. we use these numbers to drive cost-benefit decisions based upon a companies risk appetite.  Building a Bayesian model may not represent the best use of our time.
Answers: Richard Slater
Answers: CC BY-SA 4.0
Answers: 2018-12-13T12:47:06.443Z
Answers: @BruceBecker Yes part of the prob are tied (same datacenter getting down and both service are within it, which must be low), for the rest I think we can safely assume the app services and sql services run on different systems and are unlikely to fail at the same time _for the same reason_. Getting further into the maths would require a precise documentation on how Azure architecture is done and thus can only be answered by someone from Microsoft.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2018-12-13T13:56:23.613Z
Answers: So, we leave the "real" statistics to the Azure team ;) Snarky comments aside though, I think this is solid reasoning - I just wanted something in here for future SLA economists.
Answers: Bruce Becker
Answers: CC BY-SA 4.0
Answers: 2018-12-13T14:08:25.863Z
Answers: Well, they're the only ones able to give hard numbers knowing the architecture, but mostly the blog post doesn't go further than this approach. Moreover, that's SLA and we all forget too often the A stand for Agreement, that's not a real probability. ATEOTD the only meaning of those SLA is to provide the customer a way to get a partial refund in case they are not met. So in my opinion going further down in precision is just a waste of time :)
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2017-03-29T13:23:05.933Z
Answers: 2018-12-13T08:38:42.183Z
Answers: 2018-12-13T08:38:42.183Z
Answers: Tensibai
Answers: <p>In the second diagram you multiply the two regions to calculate a full system availability.  In all cases you are calculating a probability that the system shall be down (or up).</p>
  <p>There is however, no reference to the worst case scenario where each component fails in a serial manner, and the duplicated components fail together.
  (i.e. traffic manager fails, comes back as both app services fail (or app-A and SQL-B), they are in turn restored as both SQL database fail)</p>
  <p>So a dual site solution can't provide any more guarantee than a single site solution in the worst case.  But can only reduce the probability of an issue occurring.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-04-26T14:58:11.997Z
Answers: 2021-04-26T14:58:11.997Z
Answers: Kevin
Answers: <p>After reading <a href="https://devops.stackexchange.com/a/715/397">Tensibai's excellent answer</a>, I realised I used to be able to calculate this for network analysis purposes.  I dug out my copy of <a href="https://www.amazon.co.uk/Availability-Network-Fundamentals-Chris-Oggerino-ebook/dp/B0015T6G44" rel="noreferrer">High Availability Network Fundamentals</a> by Chris Oggerino and had a crack at working this out from, not quite first principals.</p>
  <p>Taking my serial example directly out of Tensibai's answer is simply a case of multiplying the probability of each component being available by the other:</p>
  <p><a href="https://i.sstatic.net/ux8vH.png" rel="noreferrer"><img src="https://i.sstatic.net/ux8vH.png" alt="Serial Availability" /></a></p>
  <p>So</p>
  <blockquote>
  <p>99.95% * 99.95% = <strong>99.9%</strong></p>
  </blockquote>
  <p>Calculating it in parallel is a little more complicated as we do need to consider what the percentage <em>un</em>availability will be:</p>
  <p><a href="https://i.sstatic.net/dWKLI.png" rel="noreferrer"><img src="https://i.sstatic.net/dWKLI.png" alt="Serial and Parallel Availability" /></a></p>
  <p>The calculation is done as follows:</p>
  <ol>
  <li><p>Multiply the <em>un</em>availability of the two regions together.</p>
  <blockquote>
  <p>0.1% * 0.1% = <strong>0.0001%</strong></p>
  </blockquote>
  </li>
  <li><p>Convert that back to availability</p>
  <blockquote>
  <p>100% - 0.0001% = <strong>99.9999%</strong></p>
  </blockquote>
  </li>
  <li><p>Multiply the Traffic Manager availability by the availability of the two regions.</p>
  <blockquote>
  <p>99.99% * 99.9999% = <strong>99.9899%</strong></p>
  </blockquote>
  </li>
  <li><p>The result is the whole system availability.</p>
  <blockquote>
  <p>99.9899% is close to <strong>99.99%</strong></p>
  </blockquote>
  </li>
  </ol>
  <p>I ended up using Excel to perform the calculations, here is the values:</p>
  <p><a href="https://i.sstatic.net/67BzD.png" rel="noreferrer"><img src="https://i.sstatic.net/67BzD.png" alt="Excel Values" /></a></p>
  <p>... and the formulas ...</p>
  <p><a href="https://i.sstatic.net/u2POH.png" rel="noreferrer"><img src="https://i.sstatic.net/u2POH.png" alt="Excel Formulas" /></a></p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-30T21:14:43.153Z
Answers: That's it, in a more straightforward way than mine (I felt the need to demonstrate the maths behind :))
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-30T21:19:31.140Z
Answers: Agreed, your answer is really good for the maths.
Answers: Richard Slater
Answers: CC BY-SA 4.0
Answers: 2019-06-11T15:17:14.440Z
Answers: SQL Azure is 99.99% not 99.95%
Answers: Jeffery Tang
Answers: CC BY-SA 4.0
Answers: 2019-06-11T15:29:20.617Z
Answers: @JefferyTang it (probably) was at the question/answer writing time (I don't exactly remember) and the actual value doesn't change the methodology to get the answer to "How to calculate the compound SLA from individual parts SLA" which is the real question.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-30T20:56:50.260Z
Answers: 2017-03-30T20:56:50.260Z
Answers: 2020-06-18T08:28:10.803Z
Answers: Richard Slater
Body: <p>Cloud services hosted by <a href="https://aws.amazon.com/" rel="noreferrer">Amazon Web Services</a>, <a href="https://azure.microsoft.com/" rel="noreferrer">Azure</a>, <a href="https://cloud.google.com/compute/" rel="noreferrer">Google</a> and most others <a href="https://azure.microsoft.com/en-gb/support/legal/sla/traffic-manager/v1_0/" rel="noreferrer">publish the <strong>S</strong>ervice <strong>L</strong>evel <strong>A</strong>greement</a>, or SLA, for the individual services they provide.  Architects, Platform Engineers and Developers are then responsible for putting these together to create an architecture that provides the hosting for an application.</p>
  
  <p>Taken in isolation, these services usually provide something in the range of three to four nine's of availability:</p>
  
  <ul>
  <li>Azure Traffic Manager: 99.99% or 'four nines'.</li>
  <li>SQL Azure: 99.99% or 'four nines'.</li>
  <li>Azure App Service: 99.95% or 'three nine five'.</li>
  </ul>
  
  <p>However when combined together in architectures there is the possibility that any one component could suffer an outage resulting in an overall availability that is not equal to the the component services.</p>
  
  <h2>Serial Compound Availability</h2>
  
  <p><a href="https://i.sstatic.net/yHl4U.png" rel="noreferrer"><img src="https://i.sstatic.net/yHl4U.png" alt="Serial Availability"></a></p>
  
  <p>In this example there are three possible failure modes:</p>
  
  <ul>
  <li>SQL Azure is down</li>
  <li>App Service is down</li>
  <li>Both are down</li>
  </ul>
  
  <p>Therefore the overall availability of this "system" must lower than 99.95%.  My rationale for thinking this is <em>if</em> the SLA for both services was:</p>
  
  <blockquote>
    <p>The service will be available 23 hours out of 24</p>
  </blockquote>
  
  <p>Then:</p>
  
  <ul>
  <li>The App Service could be out between 0100 and 0200</li>
  <li>The Database out between 0500 and 0600</li>
  </ul>
  
  <p>Both component parts are within their SLA but the total system was unavailable for 2 hours out of 24.</p>
  
  <h2>Serial and Parallel Availability</h2>
  
  <p><a href="https://i.sstatic.net/wSLk5.png" rel="noreferrer"><img src="https://i.sstatic.net/wSLk5.png" alt="Serial and Parallel Availability"></a></p>
  
  <p>In this architecture there are a large number of failure modes however principally:</p>
  
  <ul>
  <li>SQL Server in RegionA is down</li>
  <li>SQL Server in RegionB is down</li>
  <li>App Service in RegionA is down</li>
  <li>App Service in RegionB is down</li>
  <li>Traffic Manager is down</li>
  <li>Combinations of Above</li>
  </ul>
  
  <p>Because Traffic Manager is a circuit breaker it is capable of detecting an outage in either region and routing traffic to the working region, however there is still a single point of failure in the form of Traffic Manager so the total availability of the "system" cannot be higher than 99.99%.</p>
  
  <p>How can the compound availability of the two systems above be calculated and documented for the business, potentially requiring rearchitecting if the business desires a higher service level than the architecture is capable of providing?</p>
  
  <p>If you want to annotate the diagrams, I have built them in <a href="https://www.lucidchart.com/invitations/accept/94e87d78-8f60-4277-9a86-8285cd8746ce" rel="noreferrer">Lucid Chart</a> and created a multi-use link, bear in mind that anyone can edit this so you might want to create a copy of the pages to annotate.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-29T11:11:24.880Z
Comments: Lowest SLA from SPOF, assuming your app is able to cope with the session breaking ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-29T11:15:47.283Z
Comments: @Tensibai - I don't think it can be, based upon my first example *if* the SLA for both services was it will be available 23 hours out of 24 then, the App Service could be out between 0100 and 0200 and the Database out between 0500 and 0600, both component parts are within their SLA but the total system was unavailable for 2 hours out of 24.  Make sense?
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-29T11:21:10.740Z
Comments: Yep, makes sense, but in this case the resulting should be the product of all no ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-29T11:23:40.597Z
Comments: I mean app 99.95 x sql 99.95 should be the overall availability of the group
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-12-18T07:22:10.797Z
Comments: Keep in mind also that you can build a system that's more reliable than its components, through retries or failovers or degradation instead of full failure.
Comments: Xiong Chiamiov
Tags: <architecture><cloud><sla><infrastructure>
Title: How do you calculate the compound Service Level Agreement (SLA) for cloud services?
UserDisplayName: Richard Slater
ThreadText: # How do you calculate the compound Service Level Agreement (SLA) for cloud services?
  
  (Asked by: username_0 on 2017-03-29)
  
  Cloud services hosted by [Amazon Web Services](https://aws.amazon.com/), [Azure](https://azure.microsoft.com/), [Google](https://cloud.google.com/compute/) and most others [publish the **S**ervice **L**evel **A**greement](https://azure.microsoft.com/en-gb/support/legal/sla/traffic-manager/v1_0/), or SLA, for the individual services they provide. Architects, Platform Engineers and Developers are then responsible for putting these together to create an architecture that provides the hosting for an application.
  
  Taken in isolation, these services usually provide something in the range of three to four nine's of availability:
  
  * Azure Traffic Manager: 99.99% or 'four nines'.
  * SQL Azure: 99.99% or 'four nines'.
  * Azure App Service: 99.95% or 'three nine five'.
  
  However when combined together in architectures there is the possibility that any one component could suffer an outage resulting in an overall availability that is not equal to the the component services.
  
  ## Serial Compound Availability
  
  [![Serial Availability](https://i.sstatic.net/yHl4U.png)](https://i.sstatic.net/yHl4U.png)
  
  In this example there are three possible failure modes:
  
  * SQL Azure is down
  * App Service is down
  * Both are down
  
  Therefore the overall availability of this "system" must lower than 99.95%. My rationale for thinking this is *if* the SLA for both services was:
  
  > The service will be available 23 hours out of 24
  
  Then:
  
  * The App Service could be out between 0100 and 0200
  * The Database out between 0500 and 0600
  
  Both component parts are within their SLA but the total system was unavailable for 2 hours out of 24.
  
  ## Serial and Parallel Availability
  
  [![Serial and Parallel Availability](https://i.sstatic.net/wSLk5.png)](https://i.sstatic.net/wSLk5.png)
  
  In this architecture there are a large number of failure modes however principally:
  
  * SQL Server in RegionA is down
  * SQL Server in RegionB is down
  * App Service in RegionA is down
  * App Service in RegionB is down
  * Traffic Manager is down
  * Combinations of Above
  
  Because Traffic Manager is a circuit breaker it is capable of detecting an outage in either region and routing traffic to the working region, however there is still a single point of failure in the form of Traffic Manager so the total availability of the "system" cannot be higher than 99.99%.
  
  How can the compound availability of the two systems above be calculated and documented for the business, potentially requiring rearchitecting if the business desires a higher service level than the architecture is capable of providing?
  
  If you want to annotate the diagrams, I have built them in [Lucid Chart](https://www.lucidchart.com/invitations/accept/94e87d78-8f60-4277-9a86-8285cd8746ce) and created a multi-use link, bear in mind that anyone can edit this so you might want to create a copy of the pages to annotate.
  
  **Tags:** architecture, cloud, sla, infrastructure
  
  > **Comments:**
  > **username_1**: Lowest SLA from SPOF, assuming your app is able to cope with the session breaking ?  
  > **username_0**: @username_1 - I don't think it can be, based upon my first example *if* the SLA for both services was it will be available 23 hours out of 24 then, the App Service could be out between 0100 and 0200 and the Database out between 0500 and 0600, both component parts are within their SLA but the total system was unavailable for 2 hours out of 24.  Make sense?  
  > **username_1**: Yep, makes sense, but in this case the resulting should be the product of all no ?  
  > **username_1**: I mean app 99.95 x sql 99.95 should be the overall availability of the group  
  > **username_2**: Keep in mind also that you can build a system that's more reliable than its components, through retries or failovers or degradation instead of full failure.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_0 on 2017-03-30. Score: 37 | Accepted answer
  
  After reading [username_1's excellent answer](https://devops.stackexchange.com/a/715/397), I realised I used to be able to calculate this for network analysis purposes. I dug out my copy of [High Availability Network Fundamentals](https://www.amazon.co.uk/Availability-Network-Fundamentals-Chris-Oggerino-ebook/dp/B0015T6G44) by Chris Oggerino and had a crack at working this out from, not quite first principals.
  
  Taking my serial example directly out of username_1's answer is simply a case of multiplying the probability of each component being available by the other:
  
  [![Serial Availability](https://i.sstatic.net/ux8vH.png)](https://i.sstatic.net/ux8vH.png)
  
  So
  
  > 99.95% \* 99.95% = **99.9%**
  
  Calculating it in parallel is a little more complicated as we do need to consider what the percentage *un*availability will be:
  
  [![Serial and Parallel Availability](https://i.sstatic.net/dWKLI.png)](https://i.sstatic.net/dWKLI.png)
  
  The calculation is done as follows:
  
  1. Multiply the *un*availability of the two regions together.
  
     > 0.1% \* 0.1% = **0.0001%**
  2. Convert that back to availability
  
     > 100% - 0.0001% = **99.9999%**
  3. Multiply the Traffic Manager availability by the availability of the two regions.
  
     > 99.99% \* 99.9999% = **99.9899%**
  4. The result is the whole system availability.
  
     > 99.9899% is close to **99.99%**
  
  I ended up using Excel to perform the calculations, here is the values:
  
  [![Excel Values](https://i.sstatic.net/67BzD.png)](https://i.sstatic.net/67BzD.png)
  
  ... and the formulas ...
  
  [![Excel Formulas](https://i.sstatic.net/u2POH.png)](https://i.sstatic.net/u2POH.png)
  
  > **Comments:**
  > **username_1**: That's it, in a more straightforward way than mine (I felt the need to demonstrate the maths behind :))  
  > **username_0**: Agreed, your answer is really good for the maths.  
  > **username_3**: SQL Azure is 99.99% not 99.95%  
  > **username_1**: @username_3 it (probably) was at the question/answer writing time (I don't exactly remember) and the actual value doesn't change the methodology to get the answer to "How to calculate the compound SLA from individual parts SLA" which is the real question.  
  
  ---
  
  ### Answer by username_1 on 2017-03-29. Score: 24
  
  I'd take that as a math problem with the SLA being the probability of being OK.
  
  In this case we can rely on [probability rules](https://en.wikipedia.org/wiki/Probability#Mathematical_treatment) to get an overall.
  
  For your first case the probability that App Service (A) and Sql Service (B) are down at the same time is the product of their probability:
  
  ```
  P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025
  
  ```
  
  The probability that one of them is down is the sum of their probability:
  
  ```
  P(A)+P(B) = 0.001
  
  ```
  
  When two events are independents the resulting formula to take in account the probability of both being down is:
  
  ```
  P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975
  
  ```
  
  So the overall SLA would be `1 - 0,00099975 = 0,99900025` wich in percent is `99.900025 %`
  
  A simplification is the product of the first probability: `0.9995 * 0.9995 = 0,99900025`.
  
  Applied to your 1h/24h outage (4,166666% of a day) this gives (decimals are abbreviated):
  
  ```
  0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222
  
  ```
  
  So the probability of being OK is `1 - 0.0816 = 0.9184` in percent: `91,84%`
  
  ```
  24 * 0.0816 = 1.95 h
  
  ```
  
  This is less than the worst case of 2 hours because there's a chance both are down at the same time.
  
  Keeping that in mind, you may notice the availability for each is `95,84%` and `0,958333333 * 0,958333333 = 0,918402778` which is our `91.84%` from above (sorry for the full decimals here, but they are needed for the demonstration)
  
  Now for your second case, we'll start gain from our compound probability for each region (Sorry I dismissed the change for SQL to keep it reasonable), assuming there's no independent probability for the region itself and that each region is isolated and as such a DB failure take only its region down.
  
  We have the traffic manager OK probability `P(T) = 0.9999` and each app+DB couple with a OK probability `P(G) = 0,99900025` from
  
  How much region we have play a role as we have to apply the product of failure probability only to get the probability both region are down as the same time:  
  `0,00099975 * 0,00099975 = 0,0000009995000625` which means an overall availability of at least one region of `99,049375 %`
  
  Now we have the overall regions availability, the product with the traffic manager one give us the overall availability of the system:
  
  ```
  0.9999 * 0,9999990004999375 = 0,99989900059988750625
  
  ```
  
  The overall availability is `99.989900 %`
  
  Another source as explanation is available on [Azure's docs](https://docs.microsoft.com/en-us/azure/architecture/resiliency/#composite-slas) (link courtesy of [username_5](https://devops.stackexchange.com/users/11333/username_5))
  
  > **Comments:**
  > **username_0**: The overall availability seems very low - in fact by adding an additional region and traffic manager the SLA is an order of magnitude lower than if it was just a single region.  I'm trying to dig how I used to do this for networks out of the back of my brain.  
  > **username_0**: Phew! I was sure I was going mad.  
  > **username_1**: @username_0 maths corrected  
  > **username_5**: There is also this document that demonstrates this calculation: https://docs.microsoft.com/en-us/azure/architecture/resiliency/#composite-slas  
  > **username_1**: @username_5 Thanks for the link, I've included it in my answer, it wasn't existing when I wrote this answer though ;)  
  > **username_6**: not to complicate matters,but why are the probabilities assumed independent? Surely Bayesian statistics should be considered?  
  > **username_0**: @username_6 probably yes, at it certainly seems that the IEEE has published research on the topic, I suspect however given the purpose of calculating these numbers it is more about having concrete "proof" that you do, or do not, need High Availability capabilities added to a system - i.e. we use these numbers to drive cost-benefit decisions based upon a companies risk appetite.  Building a Bayesian model may not represent the best use of our time.  
  > **username_1**: @username_6 Yes part of the prob are tied (same datacenter getting down and both service are within it, which must be low), for the rest I think we can safely assume the app services and sql services run on different systems and are unlikely to fail at the same time _for the same reason_. Getting further into the maths would require a precise documentation on how Azure architecture is done and thus can only be answered by someone from Microsoft.  
  > **username_6**: So, we leave the "real" statistics to the Azure team ;) Snarky comments aside though, I think this is solid reasoning - I just wanted something in here for future SLA economists.  
  > **username_1**: Well, they're the only ones able to give hard numbers knowing the architecture, but mostly the blog post doesn't go further than this approach. Moreover, that's SLA and we all forget too often the A stand for Agreement, that's not a real probability. ATEOTD the only meaning of those SLA is to provide the customer a way to get a partial refund in case they are not met. So in my opinion going further down in precision is just a waste of time :)  
  > **username_3**: SQL Azure is 99.99% not 99.95%  
  > **username_4**: composite-sla link content has been moved here : https://docs.microsoft.com/en-us/azure/architecture/framework/resiliency/business-metrics#composite-slas  
  > **username_1**: @callee feel free to edit to correct the link  
  
  ---
  
  ### Answer by username_7 on 2021-04-26. Score: 0
  
  In the second diagram you multiply the two regions to calculate a full system availability. In all cases you are calculating a probability that the system shall be down (or up).
  
  There is however, no reference to the worst case scenario where each component fails in a serial manner, and the duplicated components fail together.
  (i.e. traffic manager fails, comes back as both app services fail (or app-A and SQL-B), they are in turn restored as both SQL database fail)
  
  So a dual site solution can't provide any more guarantee than a single site solution in the worst case. But can only reduce the probability of an issue occurring.
  
  
  ---
  
  