<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Well Architected on My AWS Rocks!</title><link>https://myaws.name/tags/well-architected/</link><description>Recent content in Well Architected on My AWS Rocks!</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 19 Jul 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://myaws.name/tags/well-architected/index.xml" rel="self" type="application/rss+xml"/><item><title>Network Security at all levels</title><link>https://myaws.name/network-security-at-all-levels/</link><pubDate>Sat, 19 Jul 2025 00:00:00 +0000</pubDate><guid>https://myaws.name/network-security-at-all-levels/</guid><description>&lt;p&gt;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 &lt;a href="__GHOST_URL__/security-at-all-levels/" rel="noreferrer"&gt;Security at all levels&lt;/a&gt; gives an overview of what I believe security in depth means and why we should all follow the principles.
&lt;p&gt;So I&amp;rsquo;ve previously talked about NACLs and Security Groups (&lt;a href="https://myaws.name/nacl-vs-security-group/"&gt;Here&lt;/a&gt;) and (&lt;a href="https://myaws.name/how-to-use-nacls-and-security-groups"&gt;Here&lt;/a&gt;) and their role in securing your workload. This post will go in to further details of controls that should be considered when deploying AWS services to ensure security of solutions. There is a fine line between network and application security. I will not talk about what I deem application security such as IAM Roles for services of application level restrictions such as rate limiting on a service. However I doe believe services such as WAF and Load Balancers are a network level control so will touch on them.&lt;/p&gt;</description></item><item><title>Cost Savings and Sustainability</title><link>https://myaws.name/why-cost-optimisation-and-sustainability/</link><pubDate>Sun, 13 Oct 2024 00:00:00 +0000</pubDate><guid>https://myaws.name/why-cost-optimisation-and-sustainability/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;I am not implying these two items are not relevant, I am also not saying they shouldn&amp;rsquo;t be in the Well-Architected Framework.&lt;/p&gt;
&lt;p&gt;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 &amp;ldquo;Cost Optimizations&amp;rdquo; or &amp;ldquo;Sustainability Audits&amp;rdquo; of your AWS estate. There might be some tweaks and improvements but the base level of &amp;ldquo;Well-Architected&amp;rdquo; for those pillars should have been achieved.&lt;/p&gt;</description></item><item><title>Wait! IP4 has a cost?</title><link>https://myaws.name/wait-ip4-has-a-cost/</link><pubDate>Sun, 11 Aug 2024 00:00:00 +0000</pubDate><guid>https://myaws.name/wait-ip4-has-a-cost/</guid><description>&lt;p&gt;&lt;strong&gt;Caveat:&lt;/strong&gt; I started this post in April because lots of people were shocked at the cost appearing on their bill. I got half way and though it wasn&amp;rsquo;t worth publishing as the chatter would die down. However 4 months later I am still  seeing people ask what can they do about IPv4 costs so thought I&amp;rsquo;d finish it off.&lt;/p&gt;
&lt;p&gt;So you will know, or should know, that the 1st February 2024 saw AWS introduce charges for all public IPv4 addresses in use within an AWS account.&lt;/p&gt;</description></item><item><title>Don't get trapped by the elephant in the room!</title><link>https://myaws.name/decision-making-for-technology/</link><pubDate>Sat, 27 Jul 2024 00:00:00 +0000</pubDate><guid>https://myaws.name/decision-making-for-technology/</guid><description>&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>My bill is how much‽</title><link>https://myaws.name/my-bill-is-how-much/</link><pubDate>Thu, 21 Dec 2023 00:00:00 +0000</pubDate><guid>https://myaws.name/my-bill-is-how-much/</guid><description>&lt;p&gt;One of the most common post by newcomers to AWS seems to be bill shock or unexpected charges.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Some however is where accounts have been compromised and resources used by someone else.&lt;/p&gt;
&lt;p&gt;So what can you do to prevent this?&lt;/p&gt;
&lt;p&gt;This article will look at ways of securing your account and managing your costs. It is a high level article and doesn&amp;rsquo;t go into every service mentioned in detail, however it should give you enough to protect yourself and point you to further resources.&lt;/p&gt;</description></item><item><title>AWS Well-Architected - Why so many get it wrong</title><link>https://myaws.name/aws-well-architected-why-so-many-get-it-wrong/</link><pubDate>Fri, 07 Jul 2023 00:00:00 +0000</pubDate><guid>https://myaws.name/aws-well-architected-why-so-many-get-it-wrong/</guid><description>&lt;p&gt;This blog follows on from my speaking session as a Community Builder at the AWS Summit in London (June 7th 2024).&lt;/p&gt;
&lt;p&gt;I looked at why so many people miss-understand the &lt;a href="https://docs.aws.amazon.com/wellarchitected/latest/framework/"&gt;Well Architected Framework&lt;/a&gt;, and as a result perform poorly in Well-Architected Reviews.&lt;/p&gt;
&lt;p&gt;
 &lt;img src="https://myaws.name/img/post-25/20230607_113230-1.jpg" alt=""&gt;

&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>How to use NACLs and Security Groups</title><link>https://myaws.name/how-to-use-nacls-and-security-groups/</link><pubDate>Tue, 06 Dec 2022 00:00:00 +0000</pubDate><guid>https://myaws.name/how-to-use-nacls-and-security-groups/</guid><description>&lt;p&gt;Following up from my last post &lt;a href="https://myaws.name/nacl-vs-security-group/"&gt;here&lt;/a&gt; on what Network Access Control Lists (NACLs) and Security Groups (SGs) are, I will now take a look at where and how I think you should use them to ensure you have a secure network.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ll use a basic scenario of a VPC (10.0.0.0/16) split into two public subnets, with access to the internet (10.0.0.0/24 and 10.0.1.0/24), and two private subnets, with no route the the internet (10.0.10.0/24 and 10.0.1.0/24). The application is running on 2 EC2 behind an application load balancer to discuss the options.&lt;/p&gt;</description></item><item><title>Why use a Transit Gateway</title><link>https://myaws.name/why-use-a-transit-gateway/</link><pubDate>Tue, 05 Jul 2022 00:00:00 +0000</pubDate><guid>https://myaws.name/why-use-a-transit-gateway/</guid><description>&lt;p&gt;You may see in my designs and discussions that I always use an AWS Transit Gateway for connections outside of the VPC.&lt;/p&gt;
&lt;p&gt;While there are use cases where this does not make sense, which I&amp;rsquo;ll describe, for the majority of organisations&amp;rsquo; use cases I believe that using Transit Gateways is the preferable solution.&lt;/p&gt;
&lt;p&gt;
 &lt;img src="https://myaws.name/img/post-18/tgw-after-1.png" alt="TGW"&gt;

&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="cost-"&gt;Cost 💰&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>Creating a Well-Architected VPC</title><link>https://myaws.name/aws-vpc-101/</link><pubDate>Wed, 20 Apr 2022 00:00:00 +0000</pubDate><guid>https://myaws.name/aws-vpc-101/</guid><description>&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>How to Well-Architect network connectivity to AWS services.</title><link>https://myaws.name/well-architecting-connectivity-to-aws-services/</link><pubDate>Sun, 05 Dec 2021 00:00:00 +0000</pubDate><guid>https://myaws.name/well-architecting-connectivity-to-aws-services/</guid><description>&lt;p&gt;&lt;strong&gt;With so many possible paths which do you take?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;My first point of reference for them was the great map by &lt;a href="https://twitter.com/QuinnyPig"&gt;Corey Quinn&lt;/a&gt;, Chief Cloud Economist at&lt;a href="https://www.duckbillgroup.com/"&gt;The Duckbill Group&lt;/a&gt; which looks at the costs for moving data around AWS.&lt;/p&gt;</description></item><item><title>How to use the AWS Well-Architected Framework</title><link>https://myaws.name/well-architected-part3/</link><pubDate>Mon, 01 Mar 2021 00:00:00 +0000</pubDate><guid>https://myaws.name/well-architected-part3/</guid><description>&lt;p&gt;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 &amp;ldquo;&lt;strong&gt;How to design well when there is no rule book&lt;/strong&gt;&amp;rdquo;. 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.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="how-not-to-use-it"&gt;How not to use it&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>Why use the AWS Well-Architected Framework</title><link>https://myaws.name/well-architected-part2/</link><pubDate>Mon, 15 Feb 2021 00:00:00 +0000</pubDate><guid>https://myaws.name/well-architected-part2/</guid><description>&lt;p&gt;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 &lt;strong&gt;&amp;ldquo;How to design well when there is no rule book&amp;rdquo;&lt;/strong&gt; . 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.&lt;/p&gt;
&lt;p&gt;I split the &lt;strong&gt;what&lt;/strong&gt; of the framework into 3 categories; Cloud Roadmap, Design Principle; Cloud Assessment.&lt;/p&gt;</description></item><item><title>What is the AWS Well-Architected Framework</title><link>https://myaws.name/well-architected-part1/</link><pubDate>Mon, 01 Feb 2021 00:00:00 +0000</pubDate><guid>https://myaws.name/well-architected-part1/</guid><description>&lt;p&gt;
 &lt;figure&gt;
 &lt;img src="https://myaws.name/img/post-4/Well-Architected.jpg" alt="The AWS Well Architected elements shown pictorally"&gt;
 &lt;center&gt;&lt;figcaption&gt;AWS Well Architected elements&lt;/figcaption&gt;&lt;/center&gt;
 &lt;/figure&gt;

&lt;/p&gt;
&lt;p&gt;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 &lt;strong&gt;&amp;ldquo;How to design well when there is no rule book&amp;rdquo;&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;This first part looks at what the Well-Architected Framework is.&lt;/p&gt;
&lt;p&gt;On the &lt;a href="https://aws.amazon.com/architecture/well-architected"&gt;AWS website&lt;/a&gt;they describe the framework as:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item></channel></rss>