<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Security on My AWS Rocks!</title><link>https://myaws.name/tags/security/</link><description>Recent content in Security 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/security/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>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>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>You put what in a public subnet‽</title><link>https://myaws.name/you-put-what-in-a-public-subnet/</link><pubDate>Tue, 04 Apr 2023 00:00:00 +0000</pubDate><guid>https://myaws.name/you-put-what-in-a-public-subnet/</guid><description>&lt;p&gt;Its great seeing peoples designs for modern solutions and especially serverless. What is more impressive is, where VPC services are in use, they are splitting them out into separate tiers and subnets.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;😕 &lt;strong&gt;But why do so many people put things in public subnets that don&amp;rsquo;t need to be?&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;In this article I&amp;rsquo;ll look at what I think should be in public subnets and why you try not to put anything in a public subnet you don&amp;rsquo;t need to.&lt;/p&gt;</description></item><item><title>Troubleshooting with VPC Flow Logs</title><link>https://myaws.name/troubleshooting-with-vpc-flowlogs/</link><pubDate>Thu, 05 Jan 2023 00:00:00 +0000</pubDate><guid>https://myaws.name/troubleshooting-with-vpc-flowlogs/</guid><description>&lt;p&gt;So you built your secure VPC, but things are not working as expected.&lt;br&gt;Or maybe something changed on the infrastructure and now things are not working.&lt;/p&gt;
&lt;p&gt;And as any network engineer knows, every application fault is always due to the network! So how do we prove traffic is getting to our systems and it&amp;rsquo;s not the network?&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;The answer is VPC Flow Logs.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;There is great guidance on Flow Logs in the &lt;a href="https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html"&gt;AWS VPC documentation&lt;/a&gt; so I will try not to cover that. What I will try and do is clarify some areas and explain how we can then use them to understand what is going on in our network. Specifically how we can use the AWS CloudWatch Logs console to find out what is happening in our VPC and give us some pointers on what might be wrong.&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>Network Access Control Lists vs Security Groups</title><link>https://myaws.name/nacl-vs-security-group/</link><pubDate>Sat, 22 Oct 2022 00:00:00 +0000</pubDate><guid>https://myaws.name/nacl-vs-security-group/</guid><description>&lt;p&gt;Both are used to protect networks and resources, but there is often confusion about the difference between Network Access Control Lists (NACLs) and Security Groups, and when each should be used.
&lt;p&gt;This post, aims to demystify the two concepts.&lt;/p&gt;
&lt;p&gt;The differences that we will cover are:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Stateful vs Stateless&lt;/li&gt;
&lt;li&gt;Inbound vs Outbound&lt;/li&gt;
&lt;li&gt;Allow vs Deny&lt;/li&gt;
&lt;li&gt;Rule Order&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Future post will then look at how to use this knowledge to apply both NACLs and Security Groups, and how to troubleshoot connectivity issues when NACLs and Security Groups are in place.&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>Security 101</title><link>https://myaws.name/security-101/</link><pubDate>Mon, 15 Mar 2021 00:00:00 +0000</pubDate><guid>https://myaws.name/security-101/</guid><description>&lt;p&gt;Following on from the &lt;a href="https://myaws.name/foundational-architecture/"&gt;foundational architecture&lt;/a&gt; post I thought I&amp;rsquo;d give a dive into security of the AWS cloud. For me this is the most important element to understand before even creating an AWS account as if you get this wrong it can be costly in more ways than one. There are a few items that need to be looked at when considering security. These include, but are not limited to:&lt;/p&gt;</description></item></channel></rss>