![]() So updates and patching often occurs at specific times, when things are released. ![]() And you can end up with a number of instances within that private subnet, using your NAT instance to download patches, get updates, or to just synchronize files or time. Now as you can imagine, this is a really useful service. So a bastion host allows inbound access to known IP addresses and authenticated users, a NAT instance allows instances within your VPC to go out to the internet. Now, a NAT instance, on the other hand, generally enables hosts in a private subnet within your VPC, outbound access to the internet. This ensures that the same trusted Elastic IP addresses are used at all times, and it makes it easier to allow these IP addresses from on-premise firewalls. You can and should associate an Elastic IP address with the bastion instance, that way, the existing Elastic IP addresses are reassociated with the new instances if an instance is terminated, and the Auto Scaling group launches a new instance in its place. And you can do this by creating a security group, and associating the bastion instances with that security group. So you can create limited access to only your IP address, for example. So for Linux bastion hosts, that's going to be TCP port 22, for SSH connections, and that will typically be the only port allowed. Now the bastion host ports need to be limited to allow only the necessary access to that host. And you can set that to be a maximum of one, and a minimum of one, if you just want to ensure a host is available for high availability. You can deploy an Auto Scaling group to ensure that the number of bastion host instances always matches the desired capacity you specify during the launch. Now Linux bastion hosts are generally deployed in two availability zones, so it supports immediate access across the VPC, and you can configure a number of bastion host instances when you launch them. ![]() So a bastion host allows secure connections into your VPC. This means we can connect to the bastion host using one of these secure protocols, and then if we're authenticated correctly, and assuming the bastion host has the correct routes enabled, we will then be able to connect to other resources within the VPC from that bastion host. An bastion host generally resides within a public subnet, and has ingress rules for SSH or RDP protocols. Which is why a bastion host is so useful. But what if we want an authenticated user, or someone known to us, to be able to access resources within a private subnet? Now remember, a public subnet is a subnet that has an internet gateway, and a route to that internet gateway. So private subnets and security groups block public access to resources, they do that very well. Now keep in mind and remember that a subnet that doesn't have an internet gateway, or a route to that internet gateway, is a private subnet. So why would you want to do this? Well, we don't want to have all our resources in the VPC accessible from the internet, right? So it's generally a best practice to restrict access to resources, by placing them in private subnets, or by limiting access via security group rules. And once authenticated on that bastion host, you can then connect, or jump, to other instances in your VPC. A bastion does this by acting as a jump host, so you connect to the bastion host via a secure protocol, such as SSH or RDP. A bastion host generally enables you to connect into instances in your VPC. We get a lot of questions about bastion hosts, and NAT instances, what's the difference, and how do you maintain high availability, et cetera? So I thought I'd do a quick chalk talk on these two. ![]()
0 Comments
Leave a Reply. |