diff --git a/opsec/cloud_provider_adversary/index.html b/opsec/cloud_provider_adversary/index.html
index d4da2d0..03eae2b 100644
--- a/opsec/cloud_provider_adversary/index.html
+++ b/opsec/cloud_provider_adversary/index.html
@@ -264,7 +264,18 @@ in this post we are going to do a threat modelling exercise:
Following her analysis, Alice understands that having a VPS gives her no privacy from her cloud provider. That all of her traffic and data can easily be seen, copied or moved.
- A bare-metal server would give her more privacy and better protection from a malicious cloud provider. She can still put in place mitigations measures through her SOPS (standard operating procedures).
+ Thus, if she needs to run a sensitive service on a VPS it will only ever be a short-lived one. Such a VPS will live on borrowed time from the moment it is started because as soon as the service provider will decide to look into it it will be easily identified and shut down.
+
+ One way to avoid such issues and the availability implications is to run a fleet of VPSes with load balancers and redirectors. That way, any instance being shutdown by the cloud provider becomes a non-event that does not impact overall availability. This requires the following:
+
+