In this post we’re going to modify our existing VPC CloudFormation template and add a VPC Endpoint for S3 to it. I’ll also walk you through a reasonable process to update an existing CloudFormation template.
In this post we’re going to talk about how to provision a NAT (Network Address Translation) Instance from scratch, using AWS Linux 2 and CloudFormation. We’re going to provision an auto-healing NAT, meaning an instance launched by an auto-scaling group with a desired capacity of 1, so if our instance crashes the auto-scaling group with terminate it for us and spin up a new one. This is much like the auto-healing Bastion Host I provisioned in a previous post, Provision a Bastion Host to our VPC with CloudFormation. So the CloudFormation template for this NAT Instance is very similar to the Bastion Host template, and this post will focus only on the differences.
This post is going to provide a brief description of basic Linux hardening for the Bastion Host I created using CloudFormation in my last post. Really it’s hardening 101 for any Linux host, but this kind of information is surprisingly hard to find on the Internet. For instance, I read a bunch of posts that say don’t run services you don’t need, but with no practical advice on how to implement that (like how to figure out what services are running on a typical Linux box, or which specific ones I might want to stop and why). The absolute best post I’ve seen on the subject is 40 Linux Server Hardening Security Tips [2019 edition]. I didn’t actually find this post until after I’d worked through the things I’m going to implement in this post, but it covered them all and a whole lot more, so you could just go there and skip this post, however, it’s pretty complex and hard to follow in some parts, and I’m going to provide a simple explanation for some simple hardening, so you might want to stick around.
What is a bastion host? It’s sometimes called a jump box, or in days gone by a sacrificial lamb. Technically, it’s just a machine that is directly exposed to the Internet. In general, you don’t want all of your machines directly exposed to the Internet. So you take one box and expose it through SSH to the outside world (or RDP if it’s a Windows box). If you need to administer a more private instance, you SSH into the bastion and from there you can SSH into the private instance (which doesn’t accept SSH connections from outside of your network) to do your administration task. So you two-hop into your network (jump box) and you assume the direct exposure to the Internet means you may get compromised at some point (sacrificial lamb).
So in this post, we’re going to look at a CloudFormation template for adding a Bastion Host to a VPC. We’re going to deploy our bastion host to an auto-scaling group, not so much for the purpose of high availability but rather for some measure of auto-healing. If the box goes south and stops responding, the auto-scaling group will kill it and bring up a new fresh instance.
This post is about a detailed examination of a CloudFormation template for provisioning a Virtual Private Cloud (VPC) in Amazon AWS. It is the first of what will be a series of posts that talk about Infrastructure as Code, revolving around trying to accomplish some particular thing. In particular, I’m moving my blog (this blog) to AWS from a shared hosting provider, and my experiences doing that is what this series will be about.
I have some specific goals in moving my blog, like my current service is a bit slower than I would like, and also less reliable (only 2 nines of availability), so I was looking to upgrade either way. Looking at the next step up in shared hosting, it would cost about twice as much as I’m currently spending (around $400/year), so I would ideally like to come up with something on AWS that isn’t much more than that, but with improved reliability and maybe speed. I have no idea starting out if I can actually meet any of these goals.