Cons of Self Service Cloud

Today’s model and mindset is that it seems that you can assemble anything using services provided by different companies and it will be solid. Those services are like parts of LEGO.

AWS could be like a LEGO. Kids are playing with it. You can make functional things. You can build a house out of LEGO. Is this the best tooling for building a house? Maybe, it is simple. A kids can do it. If you have enough LEGO a kid can build a house. Would it survive many summers and winters, hurricanes, maybe yes, maybe not. Depends how much engineering experience the builder has. A bad engineer may build a bad house out of good old time bricks and a good engineer can make a great house of LEGO. However if you want to build a rocket, you need an “enterprise” class LEGO. You can use one from ToysRs but at least you have to engineer your solution.

Today’s simplicity is a good thing, a bad thing and a scary thing.

Updated November 2026: the original post is kept above; the sections below add context for readers today.

Where self-service cloud goes wrong

The point of the LEGO comparison is that easy building blocks do not replace engineering. Most cloud incidents are not failures of AWS or Microsoft Azure; they come from how customers configure them: storage left public, too many administrator accounts, no logging, no tested backups, and costs nobody watches.

• Design the account structure, network and identity before the first workload.
• Turn on logging and security monitoring from day one.
• Use infrastructure as code so changes are reviewed and repeatable.
• Back up outside the production account and test the restore.
• Review costs every month; idle resources add up quickly.

Under the shared responsibility model, the provider secures the cloud and you secure what you put in it. Digital Edge CloudOps and cloud security bring the engineering to AWS and Azure environments.