My AWS Rocks!

Home - AWS Skill BuilderAWS Skill Builder is an online learning center where you can learn from AWS experts and build cloud skills online. With access to 600+ free courses, certification exam prep, and training that allows you to build practical skills there’s something for everyone.AWS Skill Builder - Security Compliance and Governance for AI Solutions

In most organisations data is the primary source of value. Wether that data is the source code to the next big breakthrough, a list of opportunities and sales tactics, or a more traditional data set such as a back catalogue of music, how it is managed is critical to modern businesses and losing that data brings major consequences. This post in a series on security at all layers focuses on the security of data. I'll look at how data can be protect in three states; At Rest (Store), In Transit (Move), and In Use (Access), and in three ways; Encryption, Permissions, Resiliency.

In this, the second of a multi-part series on securing your workloads, I'll look more broadly and why, where, and how, you should be securing your network. I'll look at both the principles and AWS services that help you reduce the risk of network based breaches. The introduction to the Security at all levels gives an overview of what I believe security in depth means and why we should all follow the principles.

Security in depth, defence in depth, layered security, zero trust; all terms that get spoken but often not fully understood. Mainly because much of these security principles have evolved over time and depending on the lens applied a different term has emerged. In this, the first of a series focused on security, I'll try and unpack what security in depth means (at least for me) and why you should be considering a layered security approach. I will try and keep these posts a mix of technical and non-technical details, and where possible utilise real world examples to highlight my thoughts. Future post will focus on the implementation of security from different perspectives such as application, data, and infrastructure.

In this post I will look at why I find it hard to understand why people have to focus specifically on cost-optimisation and sustainability initiatives rather than them being part of everyday design and build activities. I am not implying these two items are not relevant, I am also not saying they shouldn't be in the Well-Architected Framework. What I am saying is that, if you do the first 4 pillars (Operational Excellence, Security, Reliability, Performance Efficiency) well, then most of the benefits should have already been achieved and there should not be a need to perform "Cost Optimizations" or "Sustainability Audits" of your AWS estate. There might be some tweaks and improvements but the base level of "Well-Architected" for those pillars should have been achieved.