Architecture on My AWS Rocks!

Network Security at all levels

Sat, 19 Jul 2025 00:00:00 +0000

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 at all Layers

Fri, 16 May 2025 00:00:00 +0000

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.

Cost Savings and Sustainability

Sun, 13 Oct 2024 00:00:00 +0000

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.

Don't get trapped by the elephant in the room!

Sat, 27 Jul 2024 00:00:00 +0000

I was part of a webinar with Jeff Barr where he was discussing creating your own luck. One of the elements he talked about was doing something quickly and more frequently can often be better than waiting to ensure you are doing the right thing. He talked about the OODA model which I discuss later, but it got me thinking about how often in technology we so often get caught up in the detail, or even worse, the wrong detail and we end up not doing anything.

My bill is how much‽

Thu, 21 Dec 2023 00:00:00 +0000

One of the most common post by newcomers to AWS seems to be bill shock or unexpected charges.

Some of this is from using a service with out knowing the costs or forgetting to shut something down and incurring costs for longer than planned.

Some however is where accounts have been compromised and resources used by someone else.

So what can you do to prevent this?

This article will look at ways of securing your account and managing your costs. It is a high level article and doesn’t go into every service mentioned in detail, however it should give you enough to protect yourself and point you to further resources.

AWS Well-Architected - Why so many get it wrong

Fri, 07 Jul 2023 00:00:00 +0000

This blog follows on from my speaking session as a Community Builder at the AWS Summit in London (June 7th 2024).

I looked at why so many people miss-understand the Well Architected Framework, and as a result perform poorly in Well-Architected Reviews.

While this post will not cover everything I talked about it should give you an idea of the content and act as a reminder if you were at the event.

Why use a Transit Gateway

Tue, 05 Jul 2022 00:00:00 +0000

You may see in my designs and discussions that I always use an AWS Transit Gateway for connections outside of the VPC.

While there are use cases where this does not make sense, which I’ll describe, for the majority of organisations’ use cases I believe that using Transit Gateways is the preferable solution.

Cost 💰

Firstly lets address the cost implications of using an AWS Transit Gateway over VPC Peering, as many will use this to justify using peering because they see it directly on their bill.

Creating a Well-Architected VPC

Wed, 20 Apr 2022 00:00:00 +0000

So this is the first in my posts walking through how to deploy a solution in AWS. Hopefully you find it useful as VPCs are the foundation for private and secure networking in AWS and an area many struggle. This guide is designed to ensure that your VPC deployments can be Well-Architected and provide a base level of network security but is only one option for VPC layout. While it will meet a vast majority of workloads you might want to review the structure and reduce, or increase, the number of subnets as well as other components.

How to Well-Architect network connectivity to AWS services.

Sun, 05 Dec 2021 00:00:00 +0000

With so many possible paths which do you take?

So a few weeks ago I was asked what my strategy was for accessing internal AWS resources such as S3, DynamoDB etc. where it is possible to access over VPC endpoints as well as the internet.

My first point of reference for them was the great map by Corey Quinn, Chief Cloud Economist atThe Duckbill Group which looks at the costs for moving data around AWS.

How to use the AWS Well-Architected Framework

Mon, 01 Mar 2021 00:00:00 +0000

This is the final part in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group “How to design well when there is no rule book”. In this part we will look at how to use the Well-Architected Framework and also some resources to help you further understand the framework and review process.

How not to use it

Firstly I think we should look at how not to use the framework and review as often I see people getting dishearten or resenting the review because it is used in the wrong way.

Why use the AWS Well-Architected Framework

Mon, 15 Feb 2021 00:00:00 +0000

This is the second in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group “How to design well when there is no rule book” . In the first part of this series I looked at what the Well-Architected Framework is. In this part we will look at why you should use the Well-Architected Framework.

I split the what of the framework into 3 categories; Cloud Roadmap, Design Principle; Cloud Assessment.

What is the AWS Well-Architected Framework

Mon, 01 Feb 2021 00:00:00 +0000

AWS Well Architected elements

This is the first in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group “How to design well when there is no rule book”.

This first part looks at what the Well-Architected Framework is.

On the AWS websitethey describe the framework as:

The AWS Well-Architected Framework describes the key concepts, design principles, and architectural best practices for designing and running workloads in the cloud. By answering a set of foundational questions, you learn how well your architecture aligns with cloud best practices and are provided guidance for making improvements.

AWS Foundational Architecture

Mon, 18 Jan 2021 00:00:00 +0000

When building a house, the most important thing to get right is the foundations. With out a good foundation everything that is built on top will have issues and, worse case, completely fail. Building IT solutions is no different. We have to ensure the basic foundations are in place in order to build good solutions for the business we are working for.

Often I see organizations trying to implement the foundations once they have built the first few systems or they realize that “this cloud craze is real”. Many times it is after a proof of concept has suddenly become a production system. What ever the reason for the delay it always causes rework, at a cost to the business, and can cause friction or resentment from engineers who implemented the first solutions.