While this will work, and can be secured, in my view its not the best way to do things. So many designs and documents will say just put ALB in public subnet. If you have to have a box to run tools within the environment, or bridge connectivity to AWS services, then migrate the box to a private subnet and use session manager to access via SSH or tunnel through to access items such as RDS. It can also be logged in terms of connections and, if needed, commands performed. This gives you control at a user level of what systems they can connect to and removes the need for extra infrastructure. If you need to access a EC2 instance I'd recommend migrating from bastions to SSM Sessions. This puts a lot of risk of data exposure.
They are also often configured with tools, and credentials to access data such as storage and databases. The issue here is that if someone breaches these boxes they generally then have a direct route to lots of other systems. These systems are often open to everywhere or have poor control to remove IP permissions. I'll look at the common ones I see and address both why I think its not a good idea and what you should be doing instead. So you will now probably have a "what about" component in mind that you think you should put in a public subnet. While many will argue an ALB can also do this, by segregating the role of NLB and ALB, the ALB performance is increased, and internal traffic is not as impacted from the effect of external traffic load. Placing these in front of Application Load Balancers (ALB) allows you to direct traffic to different load balancers and have an outer perimeter of security such as enforcing TLS1.3. Use them to be the broker directing traffic to internal services. Whether that is a Gateway Load Balancers (GWLB), or Network Load Balancers (NLB) these act as the inbound gateway for traffic to your VPC. Ideally though I would be looking at building solutions that don't need internet access from application/solution VPCs reducing the need for gateways as a whole. Whether these are NAT Gateways, IPv6 Egress Only Gateways, or Internet Gateways, these have to be in the public subnet if you want outbound internet access. There are only two services I would deploy in to a public subnet. This also means you can then bypass layers such as external egress for internal services or those over trusted connections such as a direct connect. I believe layering services gives the optimum solution with out trying to make one layer do all the hard work.
While you could secure you external facing devices, you risk increasing latency for internal services or under conditions of extra load by doing this for all traffic. This is a big risk for your services and data and if you don't have to put something in the public subnet I wouldn't. In general new resources are detected and scanned in less than 5 minutes of being available on the internet. If you put something in a public subnet it poses a significantly increased security risk. There are two reasons I think this is not the best thing to do. Resources in a public subnet can access the public internet."Ĭonversely, this also means that a resource in a public subnet is also accessible from the public internet. The AWS VPC docs, a public subnet is defined as " a direct route to an internet gateway. So first lets look at what a public subnet is. In this article I'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't need to. But why do so many people put things in public subnets that don't need to be?
0 kommentar(er)
