Amazon Virtual Private Cloud

The net­work infra­struc­ture of Ama­zon Web Ser­vices (AWS) can be com­pli­cat­ed. Struc­tur­ing VPCs and instances requires tac­ti­cal plan­ning whether it’s using a con­tent deliv­ery net­work (CDN), a net­work opti­miz­er, or dynam­ic con­tent accel­er­a­tors. Using Elas­tic IPs in AWS can help you opti­mize your infra­struc­ture and imple­ment mod­i­fi­ca­tions more eas­i­ly. With Elas­tic IPs, you’ll need a quick and easy way to mod­i­fy your set­up as your envi­ron­ment and busi­ness need change. Rec­og­niz­ing what an Elas­tic IP is, as well as the dif­fer­ences between sta­t­ic and pub­lic IPs, can add tremen­dous val­ue when design­ing your AWS configuration.

Pri­vate IP address­es #

Pri­vate IP address­es are those that can’t be reached over the inter­net. Pri­vate IPs allow instances in the iden­ti­cal net­work to com­mu­ni­cate with one anoth­er. When you cre­ate a new instance, you get a pri­vate IP address and an inter­nal DNS host­name that resolves to the instance’s pri­vate IP address. It will not work if you try to con­nect to it via the inter­net. For that, you’d require a pub­lic IP address. A pri­vate IP address is reserved for a pri­vate net­work and is not wide­ly used.

Pub­lic IP address­es #

For inter­ac­tion between many inter­net instances and your pub­lic IP address­es are employed An exter­nal DNS host­name is allo­cat­ed to each instance with a pub­lic IP address. The pub­lic IP address­es asso­ci­at­ed with your instances come from Amazon’s pub­lic IP list. Once you end or ter­mi­nate your instance, the pub­lic IP address is dis­charged, and when it restarts, a new one is assigned. An elas­tic IP address must be used to keep this pub­lic IP address after it has been stopped or ter­mi­nat­ed. The inter­net rec­og­nizes you by your pub­lic IP address. The IP address that your inter­net-con­nect­ed device uses to inter­act with the pub­lic inter­net is known as a pub­lic IP address.

Elas­tic IP Address­es #

Sta­t­ic or per­sis­tent pub­lic IP address­es are includ­ed with your account as elas­tic IP address­es. With the elas­tic IP address, if any of your soft­ware or instances fails, they can be eas­i­ly remapped to anoth­er instance. You can keep an elas­tic IP address in your account until you decide to dis­charge it. If an Elas­tic IP address is in your account but not assigned to an instance, a charge is attrib­uted to it. AWS man­ages its dynam­ic cloud com­put­ing ser­vices with elas­tic IP address­es. Cus­tomers have vir­tu­al pri­vate clouds inside the AWS infra­struc­ture (VPCs). Users have instances with­in VPCs. 

The Elas­tic IP address is used to broad­cast the data inside the instance to the rest of the inter­net. Elas­tic IP is uti­lized for dynam­ic cloud com­put­ing in the AWS cloud envi­ron­ment, accord­ing to AWS. It’s cru­cial to make this dis­tinc­tion. If your AWS instance breaks down, you’ll want to keep your IP address and inter­act effec­tive­ly with your account. As a result, an Elas­tic IP is a hybrid of a pub­lic and a sta­t­ic IP address. It enables you to keep pro­mot­ing AWS instances inside of your AWS net­work infrastructure.

Sub­net #

A sub­net in your VPC is defined by AWS as a set of IP address­es. AWS resources can be launched into a spe­cif­ic sub­net. A pub­lic sub­net is for inter­net-con­nect­ed resources, while a pri­vate sub­net is for non-inter­net-con­nect­ed resources. In VPC, a sub­net is an essen­tial ele­ment. All pub­lic sub­nets (or a mix of pub­lic and pri­vate sub­nets) can be con­tained with­in a VPC. A sub­net with­out a route to the inter­net gate­way is known as a pri­vate sub­net. A VPN-only sub­net can be cre­at­ed by rout­ing traf­fic through a vir­tu­al pri­vate gateway.

A default sub­net in your VPC has a net­mask of 20, which allows for up to 4,096 address­es per sub­net, with a hand­ful restrict­ed for AWS use. Although the VPC can stretch var­i­ous avail­abil­i­ty zones, the sub­net is gen­er­al­ly mapped to just one. Avail­abil­i­ty zones make up a vir­tu­al pri­vate cloud. Each avail­abil­i­ty zone has its sub­net, and users won’t be able to launch any instances only if their VPC has subnets.

Pub­lic and Pri­vate Sub­nets #

Sub­nets are divid­ed into two cat­e­gories: pub­lic and pri­vate. Web servers, for exam­ple, use a pub­lic sub­net to con­nect to the inter­net. The main route table sends sub­net traf­fic bound for the inter­net to the inter­net gate­way, mak­ing a pub­lic sub­net pub­lic. Pri­vate sub­nets are used for resources that don’t require an inter­net con­nec­tion or that users want to keep safe from the inter­net, such as data­base instances.

Inter­net Gate­way #

An inter­net gate­way is a VPC ele­ment that is robust, hor­i­zon­tal­ly scaled, and high­ly avail­able. It allows instances in your VPC to com­mu­ni­cate with each oth­er and with the inter­net. As a result, your net­work traf­fic is not sub­ject to any avail­abil­i­ty threats or band­width restric­tions You must link an inter­net gate­way to your VPC for it to be able to con­nect to the inter­net. Each VPC can only have one inter­net gate­way con­nect­ed. The very first step in grant­i­ng inter­net access to instances in your VPC is to con­nect an inter­net gateway.

To con­nect an EC2 instance to the inter­net, you must imple­ment the fol­low­ing rules:

• Link an Inter­net gate­way to your VPC. 
• Ascer­tain that your instances either have pub­lic or an elas­tic IP address. 
• Set your subnet’s route table to point to the inter­net gateway. 
• Check that your secu­ri­ty group and net­work access con­trol rules per­mit use­ful traf­fic to move into and out of your instance.

Route Table #

A rout­ing table, accord­ing to Ama­zon, is a set of rules known as routes that estab­lish where net­work traf­fic is guid­ed. Each sub­net must be asso­ci­at­ed with a rout­ing table, and each sub­net can only be asso­ci­at­ed with one route table. 

A rout­ing table, on the oth­er hand, can be asso­ci­at­ed with mul­ti­ple sub­nets. Every VPC has a default route table, which you should leave alone and estab­lish a new route table to cus­tomize the net­work traf­fic routes linked with your VPC. We’ve includ­ed two route tables in this illus­tra­tion: the main route table and the cus­tom route table. The new route table or cus­tom route table instructs the inter­net gate­way where to route inter­net traf­fic to the pub­lic subnet. 

The pri­vate sub­net, on the oth­er hand, is still linked with the default route table, which is the main route table that does not per­mit inter­net traf­fic. With­in the pri­vate sub­net, all traf­fic con­tin­ues to remain local.

NAT Devices #

A Net­work Address Trans­la­tion (NAT) device can be employed to con­nect instances in a pri­vate sub­net to the inter­net or AWS ser­vices, but this blocks the inter­net from estab­lish­ing con­nec­tions with the instances in the pri­vate sub­net. As pre­vi­ous­ly stat­ed, pub­lic and pri­vate sub­nets secure your assets from being direct­ly con­nect­ed to the internet.

For instance, your web serv­er would be in the pub­lic sub­net, while your data­base would be in the pri­vate sub­net, which does not have inter­net access. How­ev­er, your pri­vate sub­net data­base instance may still require inter­net access or the abil­i­ty to inter­act with oth­er AWS resources. You can accom­plish this by using a NAT device. The NAT device routes traf­fic from your pri­vate net­work to the inter­net or oth­er AWS ser­vices. The response is then sent back to your instances. When traf­fic is direct­ed to the inter­net, your instance’s source IP address is sub­sti­tut­ed with the NAT device address, and when traf­fic returns, the NAT device inter­prets the address to your instance’s pri­vate IP address.

The net­work­ing foun­da­tion for EC2 and oth­er AWS ser­vices is pro­vid­ed by the Vir­tu­al Pri­vate Cloud ser­vice. AWS aggre­gates some net­work­ing com­po­nents so that con­fig­ur­ing them is eas­i­er than in a tra­di­tion­al net­work, but archi­tect­ing VPCs still requires a sol­id under­stand­ing of net­work­ing fundamentals.