VPC

Requirements:

CREATE VPC
- Subnet (AZ)
-> Public
    -> Internet connection both of inbound and outbound
         -> SG(Secret Gate, whitelist)
             -> SSH(port 22) open for the office IP
    -> Linux framework
    -> ec2 instance
    -> In order to access to the private
-> Private
    -> No internet connection.
    -> Linux, ec2, web application (port 80)
    -> NAT gateway for the outbound
    -> ELB(gateway) to aceess to the private
        -> SG(Secret Gate, whitelist)
             -> SSH(port 22) open for the office IP

References:
Amazon Virtual Private Cloud: https://aws.amazon.com/vpc/
Amazon VPC Scenarios and Examples
Getting Started with Amazon VPC
NAT Instances
Route Tables

ebooks:
Amazon Virtual Private Cloud Overview
Amazon Virtual Private Cloud User Guide
Amazon Virtual Private Cloud Network Administrator Guide


Amazon Virtual Private Cloud (Amazon VPC) lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.
You can easily customize the network configuration for your Amazon VPC. For example, you can create a public-facing subnet for your web servers that has access to the Internet, and place your backend systems such as databases or application servers in a private-facing subnet with no Internet access. You can leverage multiple layers of security, including security groups and network access control lists, to help control access to Amazon EC2 instances in each subnet.
Additionally, you can create a Hardware Virtual Private Network (VPN) connection between your corporate data center and your VPC and leverage the AWS Cloud as an extension of your corporate data center.


Scenario: VPC with Public and Private Subnets (NAT)


The configuration for this scenario includes a virtual private cloud (VPC) with a public subnet and a private subnet. We recommend this scenario if you want to run a public-facing web application, while maintaining back-end servers that aren't publicly accessible. A common example is a multi-tier website, with the web servers in a public subnet and the database servers in a private subnet. You can set up security and routing so that the web servers can communicate with the database servers.
The instances in the public subnet can send outbound traffic directly to the Internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) gateway that resides in the public subnet. The database servers can connect to the Internet for software updates using the NAT gateway, but the Internet cannot establish connections to the database servers.
Note
You can also use the VPC wizard to configure a VPC with a NAT instance; however, we recommend that you use a NAT gateway. For more information, see NAT Gateways.
This scenario can also be optionally configured for IPv6—you can use the VPC wizard to create a VPC and subnets with associated IPv6 CIDR blocks. Instances launched into the subnets can receive IPv6 addresses, and communicate using IPv6. Instances in the private subnet can use an egress-only Internet gateway to connect to the Internet over IPv6, but the Internet cannot establish connections to the private instances over IPv6. For more information about IPv4 and IPv6 addressing, see IP Addressing in Your VPC.

Overview

The following diagram shows the key components of the configuration for this scenario.
Diagram for scenario 2: VPC with public and private subnets
The configuration for this scenario includes the following:
  • A VPC with a size /16 IPv4 CIDR block (example: 10.0.0.0/16). This provides 65,536 private IPv4 addresses.
  • A public subnet with a size /24 IPv4 CIDR block (example: 10.0.0.0/24). This provides 256 private IPv4 addresses. A public subnet is a subnet that's associated with a route table that has a route to an Internet gateway.
  • A private subnet with a size /24 IPv4 CIDR block (example: 10.0.1.0/24). This provides 256 private IPv4 addresses.
  • An Internet gateway. This connects the VPC to the Internet and to other AWS services.
  • Instances with private IPv4 addresses in the subnet range (examples: 10.0.0.5, 10.0.1.5). This enables them to communicate with each other and other instances in the VPC.
  • Instances in the public subnet with Elastic IPv4 addresses (example: 198.51.100.1), which are public IPv4 addresses that enable them to be reached from the Internet. The instances can have public IP addresses assigned at launch instead of Elastic IP addresses. Instances in the private subnet are back-end servers that don't need to accept incoming traffic from the Internet and therefore do not have public IP addresses; however, they can send requests to the Internet using the NAT gateway (see the next bullet).
  • A NAT gateway with its own Elastic IPv4 address. Instances in the private subnet can send requests to the Internet through the NAT gateway over IPv4 (for example, for software updates).
  • A custom route table associated with the public subnet. This route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC over IPv4, and an entry that enables instances in the subnet to communicate directly with the Internet over IPv4.
  • The main route table associated with the private subnet. The route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC over IPv4, and an entry that enables instances in the subnet to communicate with the Internet through the NAT gateway over IPv4.

Implementing Scenario

You can use the VPC wizard to create the VPC, subnets, NAT gateway, and optionally, an egress-only Internet gateway. You must specify an Elastic IP address for your NAT gateway; if you don't have one, you must first allocate one to your account. If you want to use an existing Elastic IP address, ensure that it's not currently associated with another instance or network interface. The NAT gateway is automatically created in the public subnet of your VPC.
These procedures include optional steps for enabling and configuring IPv6 communication for your VPC. You do not have to perform these steps if you do not want to use IPv6 in your VPC.
(Optional) To allocate an Elastic IP address for the NAT gateway (IPv4)
  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose Elastic IPs.
  3. Choose Allocate new address.
  4. Choose Allocate.
To create a VPC
  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. On the VPC dashboard, choose Launch VPC Wizard.
    The Amazon VPC dashboard
  3. Choose the second option, VPC with Public and Private Subnets, and then choose Select.
  4. (Optional) You can name your VPC and subnets to help you identify them later in the console. You can specify your own IPv4 CIDR block range for the VPC and subnets, or you can keep the default values.
  5. (Optional, IPv6-only) For IPv6 CIDR block, choose Amazon-provided IPv6 CIDR block. For Public subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR and specify the hexadecimal pair value for your subnet, or keep the default value. For Private subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR. Specify the hexadecimal pair value for the IPv6 subnet or keep the default value.
  6. In the Specify the details of your NAT gateway section, specify the allocation ID for an Elastic IP address in your account.
  7. You can keep the rest of the default values on the page, and choose Create VPC.

Because the WebServerSG and DBServerSG security groups reference each other, create all the security groups required for this scenario before you add rules to them.
To create the WebServerSG and DBServerSG security groups
  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose Security Groups, Create Security Group.
  3. Provide a name and description for the security group. In this topic, the name WebServerSG is used as an example. For VPC, select the ID of the VPC you created and choose Yes, Create.
  4. Choose Create Security Group again.
  5. Provide a name and description for the security group. In this topic, the name DBServerSG is used as an example. For VPC, select the ID of your VPC and choose Yes, Create
To add rules to the WebServerSG security group
  1. Select the WebServerSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
  2. On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:
    1. Choose Type, HTTP. For Source, enter 0.0.0.0/0.
    2. Choose Add another rule, Type, HTTPS. For Source, enter 0.0.0.0/0.
    3. Choose Add another rule, Type, SSH. For Source, enter your network's public IPv4 address range.
    4. Choose Add another rule, Type, RDP. For Source, enter your network's public IPv4 address range.
    5. (Optional, IPv6-only) Choose Add another rule, Type, HTTP. For Source, enter ::/0.
    6. (Optional, IPv6-only) Choose Add another rule, Type, HTTPS. For Source, enter ::/0.
    7. (Optional, IPv6-only) Choose Add another rule, Type, SSH (for Linux) or RDP (for Windows). For Source, enter your network's IPv6 address range.
    8. Choose Save

  1. On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:
    1. Locate the default rule that enables all outbound traffic and choose Remove.
    2. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.
    3. Choose Add another rule, Type, HTTP. For Destination, enter 0.0.0.0/0.
    4. (Optional, IPv6-only) Choose Add another rule, Type, HTTPS. For Destination, enter ::/0.
    5. (Optional, IPv6-only) Choose Add another rule, Type, HTTP. For Destination, enter ::/0.
    6. Choose Save.


You can now launch instances into your VPC.
To launch an instance (web server)

PRIVATE INSTANCE - WINDOWS
  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  2. From the dashboard, choose Launch Instance.
  3. Select an AMI and an instance type and choose Next: Configure Instance Details.
    Note
    If you intend to use your instance for IPv6 communication, you must choose a supported instance type; for example, T2. For more information, seeAmazon EC2 Instance Types.


2. On the Configure Instance Details page, for Network, select the VPC that you created earlier and then select a subnet. For example, launch a web server into the public subnet and the database server into the private subnet.
  1. (Optional) By default, instances launched into a nondefault VPC are not assigned a public IPv4 address. To be able to connect to your instance in the public subnet, you can assign a public IPv4 address now, or allocate an Elastic IP address and assign it to your instance after it's launched. To assign a public IPv4 address now, ensure that you choose Enable from the Auto-assign Public IP list. You do not need to assign a public IP address to an instance in the private subnet.
    Note
    You can only use the auto-assign public IPv4 feature for a single, new network interface with the device index of eth0. For more information, see Assigning a Public IPv4 Address During Instance Launch.
  2. (Optional, IPv6-only) You can auto-assign an IPv6 address to your instance from the subnet range. For Auto-assign IPv6 IP, choose Enable.
  1. On the next two pages of the wizard, you can configure storage for your instance, and add tags. On the Configure Security Group page, choose the Select an existing security group option, and select one of the security groups you created earlier (WebServerSG for a web server or DBServerSG for a database server). Choose Review and Launch.

  1. Review the settings that you've chosen. Make any changes that you need and choose Launch to choose a key pair and launch your instance.


If you did not assign a public IPv4 address to your instance in the public subnet in step 5, you will not be able to connect to it. Before you can access an instance in your public subnet, you must assign it an Elastic IP address.
To allocate an Elastic IP address and assign it to an instance (IPv4)
  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose Elastic IPs.
  3. Choose Allocate new address.
  4. Choose Allocate.
    Note
    If your account supports EC2-Classic, first choose VPC.
  5. Select the Elastic IP address from the list and choose Actions, Associate address.
  6. Select the network interface or instance. For Private IP, select the corresponding address to associate the Elastic IP address with and choose Associate.
You can now connect to your instances in the VPC. For information about how to connect to a Linux instance, see Connect to Your Linux Instance in the Amazon EC2 User Guide for Linux Instances. For information about how to connect to a Windows instance, see Connect to Your Windows Instance in the Amazon EC2 User Guide for Windows Instances.

PUBLIC INSTANCE - LINUX





Implementing Scenario 2 with a NAT Instance

You can implement scenario 2 using a NAT instance instead of a NAT gateway. For more information about NAT instances, see NAT Instances.
You can follow the same procedures as above; however, in the NAT section of the VPC wizard, choose Use a NAT instance instead and specify the details for your NAT instance. You will also require a security group for your NAT instance (NATSG), which allows the NAT instance to receive Internet-bound traffic from instances in the private subnet, as well as SSH traffic from your network. The NAT instance can also send traffic to the Internet, so that instances in the private subnet can get software updates.

To create the NATSG security group
  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose Security Groups, and the choose Create Security Group.
  3. Specify a name and description for the security group. In this topic, the name Mijoo-NATSG is used as an example. For VPC, select the ID of your VPC and choose Yes, Create.
  1. Select the NATSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
  2. On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:
    1. Choose Type, HTTP . For Source, enter the IP address range of your private subnet.
    2. Choose Add another rule, Type, HTTPS. For Source, enter the IP address range of your private subnet.
    3. Choose Add another rule, Type, SSH. For Source, enter your network's public IP address range.
    4. Choose Save.
  1. On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:
    1. Locate the default rule that enables all outbound traffic and choose Remove.
    2. Choose Type, HTTP. For Destination, enter 0.0.0.0/0.
    3. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.
    4. Choose Save.


Setting up the NAT Instance

1. Launch an instance into your public subnet from an AMI that's been configured to run as a NAT instance. Amazon provides Amazon Linux AMIs that are configured to run as NAT instances. These AMIs include the string amzn-ami-vpc-nat in their names, so you can search for them in the Amazon EC2 console.
Note
We recommend that you always use the latest version of the NAT AMI to take advantage of configuration updates.
If you add and remove secondary IPv4 CIDR blocks on your VPC, ensure that you use AMI version amzn-ami-vpc-nat-hvm-2017.03.1.20170623-x86_64-ebs or later.

After selecting the instance, configure it.

On the Configure Security Group page, select the Select an existing security group option, and select the NATSG security group that you created. Choose Review and Launch.

Disabling Source/Destination Checks
Each EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. However, a NAT instance must be able to send and receive traffic when the source or destination is not itself. Therefore, you must disable source/destination checks on the NAT instance.
You can disable the SrcDestCheck attribute for a NAT instance that's either running or stopped using the console or the command line.
To disable source/destination checking using the console
  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  2. In the navigation pane, choose Instances.
  3. Select the NAT instance, choose Actions, Networking, Change Source/Dest. Check.
  4. For the NAT instance, verify that this attribute is disabled. Otherwise, choose Yes, Disable.
  5. If the NAT instance has a secondary network interface, choose it from Network interfaces on the Description tab and choose the interface ID to go to the network interfaces page. Choose Actions, Change Source/Dest. Check, disable the setting, and choose Save.

Updating the Main Route Table

The private subnet in your VPC is not associated with a custom route table, therefore it uses the main route table. By default, the main route table enables the instances in your VPC to communicate with each other. You must add route that sends all other subnet traffic to the NAT instance.
To update the main route table
  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose Route Tables.
  3. Select the main route table for your VPC (the Main column displays Yes) . The details pane displays tabs for working with its routes, associations, and route propagation.
  1. On the Routes tab, choose Edit, specify 0.0.0.0/0 in the Destination box, select the instance ID of the NAT instance from the Target list, and then choose Save.
  2. On the Subnet Associations tab, choose Edit, and then select the Associate check box for the subnet. Choose Save.

Testing Your NAT Instance Configuration

After you have launched a NAT instance and completed the configuration steps above, you can perform a test to check if an instance in your private subnet can access the Internet through the NAT instance by using the NAT instance as a bastion server. To do this, update your NAT instance's security group rules to allow inbound and outbound ICMP traffic and allow outbound SSH traffic, launch an instance into your private subnet, configure SSH agent forwarding to access instances in your private subnet, connect to your instance, and then test the Internet connectivity.

To update your NAT instance's security group
  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  2. In the navigation pane, choose Security Groups.
  3. Find the security group associated with your NAT instance, and choose Edit in the Inbound tab.
  4. Choose Add Rule, select All ICMP - IPv4 from the Type list, and select Custom from the Source list. Enter the IP address range of your private subnet, for example, 10.0.1.0/24. Choose Save.
  1. In the Outbound tab, choose Edit.
  2. Choose Add Rule, select SSH from the Type list, and select Custom from the Destination list. Enter the IP address range of your private subnet, for example, 10.0.1.0/24. Choose Save.
  3. Choose Add Rule, select All ICMP - IPv4 from the Type list, and select Custom from the Destination list. Enter 0.0.0.0/0, and then choose Save.

Connecting to Your Windows Instance















Comments

Post a Comment

Popular posts from this blog

Essential git commands

1) git config Utility: To set your user name and email in the main configuration file. How to:  To check your name and email:  git config --global user.name and git config --global user.email .  To set your new email or name: git config --global user.name = “xxxx” and git config --global user.email = “xxxx@email.com” 2) git init Utility: To initialize a git repository for a new or existing project. How to: git init in the root of your project directory. 3) git clone Utility: To copy a git repository from remote source, also sets the remote to original source so that you can pull again. How to: git clone <:clone git url:> git clone through ssh:  git clone ssh://username@host.xz/absolute/path/to/repo.git/ git clone username@host.xz:relative/path/to/repo.git/ 4) git status Utility: To check the status of files you’ve changed in your working directory, i.e, what all has changed since your last commit. How to: git status in your working directo
Read more

Basic Concept of Docker

Image
SERVER MANAGEMENT   Server management is very complicated and difficult In general, Server management is very complicated and difficult.  Just a few years ago, one of the developers' main tasks was to install the various programs in the operating system to deploy the source codes.  The installation manual was long and complicated and I failed to install it for some unknown reason even though they worked properly on my local machine. If it did not install correctly, I would install from OS again and again. For examples, The OS and Database server versions used by the company were fixed, and updating versions was a huge risk, so it was best to leave the server untouched as much as possible after installation. The day I set up the new servers was a sleepless night, I became a master of configurations and installation. If you think you have become accustomed to it, you would have problems if the Linux distribution changed or the environment changed. It was also a proble
Read more