I am setting up a VPC on AWS. It has a public subnet and two private subnets. The public subnet is for web servers. The private subnets are for high availability databases. I am securing the resources using Security Groups, not Network ACL's.
The default security group which was created when I created the VPC allows all outbound traffic, and only allows inbound traffic from other subnets in the VPC. I'm not sure exactly what kind of servers I'll be deploying in the future - more web servers, more RDS instance, something else? In light of this, I think my default security group should allow no traffic inbound or outbound. Does that make sense?
In this way, if I forget to explicitly choose the security group when I launch an instance, the server is isolated from all other resources.
Given your design, a recommended security configuration is:
Put your load balancer in the public subnet: It is public-facing
Put your web servers in a private subnet: This keeps them secure by removing direct access from the Internet
This way, if you launch a future instance in the private subnet, it is more secure than launching in a public subnet. Security groups are then an extra layer of security.
Given that you are aiming for High Availability, also spread your web servers across multiple Availability Zones. An easy way to do this is to use Auto Scaling, which distributes instances evenly across Availability Zones and has the benefit of scaling in/out to meet demand while minimizing costs.
For an example architecture, see the Web Application Hosting reference architecture in the AWS Architecture Center.
Related
can anyone explain difference between Azure Application Gateway, Virtual Network Gateway, Virtual WAN, ExpressRoute, Arc and Private Link, please?
It seems to me all services are pretty similar helping with connecting either on-prem to Azure, in-Azure to in-Azure or public to Azure.
They're similar in that they all involve network traffic, but that's pretty much where the similarities end.
Application Gateway is a Layer 7 load balancing service with advanced features like SSL termination. It's used to route client requests to your applications.
Virtual Network Gateway is a VPN gateway for point-to-site (user) and site-to-site (office/datacenter) VPN connections to your own Azure VNETs. This would, for example, allow you to RDP into Azure VMs from your on-prem office using their private IPs.
ExpressRoute is similar to site-to-site, however it doesn't use IpSec tunnels, it's a dedicated, unencrypted connection from your location directly into Microsoft's backbone. (i.e. you don't traverse the public internet). There's no encryption and the connection is faster. This is a service you need to work with a 3rd party internet provider to implement.
Virtual WAN is more like a networking hub where there would be many site-to-site, point-to-site, ExpressRoute, etc... connections spanning a wide area (as the name implies). This would be for large enterpise organizations with many on-prem locations.
Arc is a means of adding your on-prem resources into Azure for management. e.g. you have a physical server somewhere and you want to manage it though ARM/portal.
Azure Private Link is a feature of many Azure services (storage, SQL PaaS, etc..) which allows you to create a private DNS record and assign a private IP address on your internal VNETs. This is used when you want to disable all public network access to a resource and only allow access from within your own VNET.
I have barely scratched the surface of the differences here, but suffice it to say, there are many differences. From this page, you can type the service name into the search and get more specific details on the offering. Hope this helps.
https://learn.microsoft.com/en-us/search/?terms=networking%20in%20azure
We manage big environments inside Azure with multiple customers, we are redesigning it and in it we wanted to manage traffic within multiple common subnets like app, web and db subnets.
So essentially no two different application inside any common subnet like db cannot communicate with each other.
By default, resources in the different subnets from the same VNet could communicate with each other. So you need to use an Azure network security group to filter network traffic to and from Azure resources in an Azure virtual network or subnet.
Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. To learn more, see Application security groups.
For PaaS like Azure app service or Azure SQL database, you could use VNet Integration to access VNet resources in a private network or use virtual network service endpoints and rules for servers in Azure SQL Database.
For more information, you may know:
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/secure-vnet-dmz
https://learn.microsoft.com/en-us/azure/networking/networking-overview
Please forgive my ignorance.
Question:
How can I control network traffic to a publicIP resource and send it to multiple different resources based on destination port?
Background:
I have setup some VMs that are configured with only private IPs in different subnets. All belong to the same Virtual Network. All these VMs have different services and I do not want HA as I do not need it and it costs money.
I just want all the services on these VMs to communicate out using the same single publicIP and I want to split incoming traffic to that same publicIP between my resources based on destination port.
Seems like a straight forward requirement right?
At first I though "this must be a task for the Load Balancer service" as it's operating at L4 and tried to set it up but I was not able to split inbound traffic on different ports to more than a single VM or a single availability set. I do not understand why you can only use Load Balancers NAT rules with a single VM or Availability Set.
I can probably delete/re-create all VMs (thank you Microsoft..) into a single availability set that only has 1 fault and 1 error domain but does this make any sense?
It just seems to me like a dirty workaround using availability sets in a way they are not meant to in order to solve a very basic thing.
Thanks!
Basically, you could create a public-facing Azure Load balancer then target the VMs or Availability Sets to the backend pools of this load balancer. What you need to do is to configure the load balancing rules and some health probes or inbound NAT rules for the backend services with ports forwarding.
Refer to the SO answer.
You would use NAT rule when you have 1 backend server or you know
which backend server to get to and load balancing rules when you want
to load-balance to multiple backend servers.
NAT rule must be explicitly attached to a VM (or network interface) to
complete the path to the target; whereas Load Balancing rule need not
be. In the latter case, a VM is selected (from the back-end address
pool or VMs) to complete the path to the target.
Additionally, Azure Load balancer supports two SKUs: basic and standard. Different SKUs support different backend pool endpoints. Read more details about Load Balancer SKU comparison.
Can we have a single Application Gateway for all VMSS created in different regions?
If yes please share the possible options.
As the comment mentioned, we could not have a single Application gateway for all VMSS created in a different region since Application Gateway is always deployed in a virtual network subnet and it directly supports to deploy the VMSS as the backends in the same region and virtual network as the Application gateway.
As a workaround, you could use a public IP address as the backend for communicating with instances outside of the virtual network as long as there is IP connectivity. Read more details about backend pools. So you may use a public-facing load balancer associated with the VMSS.
Furthermore, you also could use Traffic Manager to distribute traffic across multiple Application Gateways in different datacenters. Or use Azure Front Door Service provides a scalable and secure entry point for fast delivery of your global web applications.
Even when I create EC2 instances in a private subnet, they must be able to send traffic to the Internet if I want to register them to a ECS cluster.
I am using a NAT gateway to do this, but I still feel insecure that the instances can send private information to anywhere in case of takeover.
What would be the most compact CIDR range that I can use for the instances' security group, instead of 0.0.0.0/0?
For the moment, you may have to rely on the list of public IP address ranges for AWS, allowing traffic bound for all the CIDR blocks associated with your region.
Part of design for resiliency of much of what AWS does relies on the ability of their service endpoints not to depend on static address assigments and instead to use DNS... but their service endpoints should always be on addresses associated with your region, since very few services violate their practice strict regional separation of service infrastructure.
(CloudFront, Route 53, and IAM do, maybe others, but these are provisioning endpoints, not operational ones. These provisioning-only endpoints do not need to be accessible for most applications to function normally.)
A super common pattern here is to create a proxy in a narrow CIDR and only allow outbound traffic to flow through the proxy. White-list AWS endpoints and log all traffic flowing through the proxy for monitoring/auditing.
AWS Endpoints = https://docs.aws.amazon.com/general/latest/gr/rande.html