In this post I will try to give information about Amazon VPC concept. First I will explain different scenarios like public vpn,private vpn and then setup a Site-to-site Vpn with a juniper firewall ( optional 🙂 ). I will also explain and give an example of new VPC feature, VPC peering. VPC is a seperated network for your infrastructure in aws cloud. It gives you the flexibility to configure your own network in a secure manner. In my current company we use VPC to connect aws network with our private clouds so we can easily communicate with our servers. Also VPC gives us the flexibility of security and access control ( by using security groups, NACL ).
Before we start I can say that it can be confusing to explain the public and private subnet. The public VPC is basically a VPC , isolated your own network that can be reached from internet. And the private subnet is a isolated your own network that can’t be reached from internet. When we start to configure VPC, it will be easier to understand. So let’s get started.
In our dashboard we can see our VPC connection status, peering status, and also vpn connections status. Also we can start our vpn creation wizard on dashboard page. We can use wizard to create VPC and also we can do it manually. Here I will use the wizard option.
When we click the “start VPC wizard” , it asks me which scenario we want to use. There are four options here.
– VPC with a single public subnet: It is an isolated network that is reachable from internet.
– VPC with public and private subnets: It is an isolated network that the public subnet is reachable from internet but the private subnet is not. Private subnet can create outbound connections via NAT server.
– VPC with public and private subnets and hardware VPN access: This is like “VPC with public and private subnets” option but it also configures an IPSEC site-to-site VPN with your own corporate network
– VPC with a private subnet only and hardware vpn access: It is an isolated network from internet and can only be accessed with your own corporate network via IPSEC VPN connection.
In this post we will configure the first one, VPC with a Single Public Subnet.
In “IP CIDR block” section we will enter the range of IPs that we will use in our VPC. It must be between /16 and /28 netmasks. By default it gives us 10.0.0.0/16 that 65531 ip addresses are available for us to use. Then we give a name to our VPC in “VPC name” section. In “Public subnet” section we will configure the range of our network. It is important to plan which availability zone/zones to be used. Because after we create our VPC and want to create new instances it will be created in that subnet created in that specific AZ ( if only we have one ) . For high availability we can create two subnets in different AZs and create our instances in that different subnets separately. After that we give a name to our subnet ( After creation VPC it allows us to create additional subnets ) . In “Enable DNS hostnames” section it allows us to enable or disable that created instances in that VPC are provided with hostnames or not. Finally we can choose if our instances created in that VPC are dedicated tenancy instances ( by default they are not ) .
Now let’s create a new instance in our demo_vpc. In our configuration we selected our VPC and it automatically selected our subnet ( subnet_for_webservers , 126.96.36.199/24 ).
And our instance is ready.
If we want to connect our instance unfortunately it will fail. The reason is it has no public ip address. If we want our instance in public subnet vpc to be reachable, there are some important rules we have to take care.
– First we have to give a public ip address to our instance either by assigning public ip ( temporary ) or elastic ip ( static )
– The security group rules for that instance should allow necessary inbound and outbound ports opened. ( for outbound connections by default all traffic is enabled. destination –> 0.0.0.0/0 ). Remember that security group rules are instance based and stateful. That means, you don’t have to open any outbound ports. For example if we opened inbound ssh port and deleted default outbound rule in our security group, we are still able to connect our instance over ssh. I will give detailed information about Security groups and NACLs in a different post.
– An internet gateway (if we don’t use wizard we have to configure it manually)
– A route table (if we don’t use wizard we have to configure it manually)
Now let’s assign an elastic ip address to our instance and check it’s connectivity.
In my next post we will configure VPC with public and private subnets. If you have any questions please feel free to ask/comment.