I am trying out AWS free tier and choose to set up a VPC with Public and Private Subnets.
The IP CIDR Block is defaulted to: 10.0.0.0/16 which is 65531 ip addresses. Both public and private subnets are set to 10.0.0.0/24.
Isn't the less the number of ip addresses that will fit my need the better for security? So for example, if I intend to run 2 EC2 then all I need is just 2 ip addresses?
I need to deploy a Meteor web application to be used by the public. Could some one please explain if I need to have the most number of ip address to server the hieghtest number of connection to my app? I am confused.
In VPC number of IP address does not matter as per the security goes. For better security it depends how you are exposing the application and the resources in your VPC to open world.
65531 IP address means your VPC can have 65531 EC2 instances into it. So if your application is going to have more than 65531 EC2 instances then you need to create a new VPC. And if you need less IP address for your VPC you can any time create another VPC with less IP address by tweaking the CIDR block as per your requirement.
As per the security goes you need to follow the AWS best practices when you are creating the infrastructure in a AWS VPC.
This is a good read
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html
http://harish11g.blogspot.com/2014/01/Amazon-Virtual-Private-Cloud-VPC-best-practices-tips-for-architecture-migration.html
Related
The IP address 10.20.1.1 came up during our security scan and I was wondering which resource this IP belongs to. I searched through the EC2 instances and wasn't able to find this IP, it looks like a network interface IP or something like this so was wondering if someone could please point me to the right direction so I can find the resource and match it to that IP.
From Subnets for your VPC - Amazon Virtual Private Cloud:
The first four IP addresses and the last IP address in each subnet CIDR block are not available for your use, and they cannot be assigned to a resource, such as an EC2 instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:
10.0.0.0: Network address.
10.0.0.1: Reserved by AWS for the VPC router.
10.0.0.2: Reserved by AWS. The IP address of the DNS server is the base of the VPC network range plus two. For VPCs with multiple CIDR blocks, the IP address of the DNS server is located in the primary CIDR. We also reserve the base of each subnet range plus two for all CIDR blocks in the VPC. For more information, see Amazon DNS server.
10.0.0.3: Reserved by AWS for future use.
10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.
Since you have a subnet of 10.20.1.0/24, the address of 10.20.1.1 is Reserved by AWS for the VPC router.
AWS is responsible for routing traffic within a VPC according to the DHCP option sets in Amazon VPC. When a new instance launches and uses DHCP to obtain an IP address in the subnet, it is provided with the address of the router. Some network settings (such as DNS server) can be set, but AWS retains control of the router.
Your network scan detected the IP address associated with this router.
When we create a VPC, we generally allocate it a private IPv4 address range as specified in RFC 1918.
I am making an assumption that Internet Gateway, NAT Gateway etc. are hosted on AWS managed VPCs as they are highly available and scalable same like how a customer would design a service on AWS.
Are there private IPv4 ranges AWS reserves for its use to solve overlaps between Customer's VPC and their own VPCs that hosts Internet Gateway / NAT Gateway? How is the CIDR overlaps managed?
It appears that you are asking about overlaps between customer VPCs and the actual networks used to 'run' AWS. However, there is no such overlap.
All networking in VPCs is virtual. Infrastructure deployed within VPCs are given IP addresses from the VPC's CIDR range. For example, a NAT Gateway connects to a VPC via an Elastic Network Interface (ENI), which consumes a private IP address from within the VPC. This allows it to communicate with other resources in the VPC, such as EC2 instances, RDS databases and Load Balancers.
The Internet Gateway does not consume any private IP addresses. It is simply a routing concept between a VPC and the Internet.
The actual equipment that AWS uses to operate services runs on separate networks that exist 'outside of' VPCs.
Yes there are some ways AWS reserves ip addresses in your VPC :).
Firstly, the internet gateway actually does not use up an address in your VPC. The vpc router basically takes care of routes to the internet gateway (more on the vpc router below). I guess that they use all kinds of fancy network overlays and tricks to handle this traffic. Unfortunately I'm not enough of a network specialist to know the exact tech they use for this.
When creating a NAT gateway, AWS actually creates an elastic network interface inside your subnet with a a private ip address attached to it. You can see these when going to the 'elastic network interface' view in the EC2 console. Obviously, you can't reuse these addresses.
Thirdly, aws actually reserves several addresses per subnet. From the aws docs:
The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:
10.0.0.0: Network address.
10.0.0.1: Reserved by AWS for the VPC router.
10.0.0.2: Reserved by AWS. The IP address of the DNS server is the base of the VPC network range plus two. For VPCs with multiple CIDR blocks, the IP address of the DNS server is located in the primary CIDR. We also reserve the base of each subnet range plus two for all CIDR blocks in the VPC. For more information, see Amazon DNS server.
10.0.0.3: Reserved by AWS for future use.
10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.
If you create a VPC or subnet using a command line tool or the Amazon EC2 API, the CIDR block is automatically modified to its canonical form. For example, if you specify 100.68.0.18/18 for the CIDR block, we create a CIDR block of 100.68.0.0/18.
So in short, the vpc router takes care of routing requests to AWS internet gateway, NAT gateways get their own elastic network interface and there are some other addresses reserved as well.
Private IP address can reuse in different network and can not be use in public, that's why it is called private.
If you use AWS services and if it is in a VPC, it will get an IP address in your CIDR range. Otherwise, it will allocate in AWS network.
I have a scenario where I want to setup an haproxy cluster with keepalived. I saw this blog post https://www.peternijssen.nl/high-availability-haproxy-keepalived-aws/ and its pretty detailed and easy to follow, but for my scenario I need the elastic IP's to be private. Is this doable ? As from AWS documentation Elastic IP's are only public IPs.
I need a floating IP which will act as a floating cluster IP. What can I use if Elastic IP is not an option.
An elastic IP within AWS is actually a static public IP address. This functionality is required as by default a public IP address is not reserved by an account, and when enabled limits the total IPv4 addresses you can keep.
For private address ranges however, your instances can be assigned any private IP address that is within any of your VPCs CIDR range(s).
In fact for this reason you can select almost any IP address found within your VPC when launching a new instance, in addition the IP addresses that are attached to an EC2 instance are static and will be attached to that instance until it is terminated.
Therefore as long as you don't terminate the instances the private IP(s) will be maintained. However, in the event the instance fails and is not recoverable you would still need to launch a new instance and use that IP.
It might be more beneficial using a DNS record to resolve the IP just in case of an emergency, or failing that use a load balancer to distribute traffic.
For this case you can provision an Elastic Network Interface (ENI) with a static private IP address which you can attach/re-attach to EC2 instances. As long as you don’t delete the ENI, it will retain the I as p address. Find out more here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html
Just starting to move our first application to AWS. We have one public subnet (web servers) and two private subnets (for our app instances and databases). My query is where should we put our log management (greylog) and monitoring instances. Should we put them into our app instances subnet or create another private subnet?
Yes you can use the same app subnet, but it is good to have separate subnet for separate services since it will helpful for scenarios like while debugging we can easily classify that requests coming from a particular CIDR range belongs to app subnet or monitoring subnet and we can also have the flexibility of blocking traffic through ACL which applies at subnet level.
You can very well place the logging/monitoring servers in the one the existing private subnets as long as you have rightly sized the subnet CIDR block with enough IP addresses.
Refer this documentation for VPC/Subnet sizing
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4
I started to mess around with aws a couple days ago and I have a question about VPCs.
I'm considering two options to make "private" a subnet and I want to know your opinion:
OPTION 1:
A subnet with an ig attached (a public subnet really) with an ACL to only allow traffic from the VPC.
Pros: cheaper!
Cons: public ip for each instance (is this a real problem?), different public Ip for each instance (a kind of messy stuff for ip's whitelists)
OPTION 2:
A subnet without an ig attached using a Nat gateway.
Pros: more secure?, same public Ip for each instance.
Cons: more expensive.
I consider the Option 2 the best technical solution, only a bit more expensive. But, do you consider the option 1 a bad practice? Has more pitfalls that I'm not seeing?
It appears that your requirements are:
Run some Amazon EC2 instances
Keep them "private" from the Internet (no direct access from the Internet to the instances)
Allow the instances to access the Internet (eg to download updates, or to communicate with AWS API endpoints)
Your Option 1 is a public subnet, made private by modifying the Network ACLs to allow traffic only within the subnet. You are giving public IP addresses to the instances, presumably so they can access the Internet. This will not work. The Network ACLs that limit access to the VPC will also block traffic from the instances to the Internet.
Your Option 2 is a private subnet, with instances accessing the Internet via a NAT gateway. There is no need to assign public IP addresses to these instances, since they are in a private subnet. Yes, this will work but, as you note, there is the extra expense of the NAT Gateway (or a NAT instance).
An alternative is to use a Public Subnet with Security Groups:
Use a public subnet and give instances auto-assigned public IP addresses. This will allow them to access the Internet. (Note: This is different to an Elastic IP Address, which is limited to 5 per region per AWS account.)
Use a Security Group on each instance to block Inbound access. The instances will still be able to initiate outbound access to the Internet (and responses will come back because Security Groups are stateful)
See documentation: Amazon EC2 Security Groups for Linux Instances
Of course, since the instances now block inbound traffic, you will need a way to connect to them. This is typically done by launching a Bastion Server (Jump Box) in your public subnet. You can connect to the Bastion Server via public IP address, then connect to the private servers via their private IP address. To allow this, configure the Security Group on the private instances to permit inbound traffic from the IP range of the VPC, or from the Security Group associated with the Bastion Server.