Wednesday 29 September 2021
Wednesday 22 September 2021
AWS Networking - Part VI: Subnet to Route Table Association
At this phase, we have attached subnets to their respective Availability Zones. Next, we will create subnet-specific route tables for both Public and Private subnets.
Figure 1-25: VPC Subnets: Select VPC.
Tuesday 21 September 2021
AWS Networking - Part V: Create Subnet Using AWS Console
When we have created a new VPC, we can start adding subnets to it. We are going to create two subnets. Subnet 10.10.0.0/24 is a Public Subnet in Availability Zone eu-west2c, where we later add an Internet GW. Subnet 10.10.0.0/24 is a Private Subnet in Availability Zone eu-west2a that will use a NAT GW for uni-directional Internet access.
Figure 1-18: VPC Route Table: Routes.
AWS Networking - Part IV: Create VPC Using the AWS CloudFormation
The focus of this section is to show how we can create a VPC using AWS CloudFormation service. Figure 1-12 shows our example AWS CloudFormation Templates. Its first section, AWSTemplateFormatVersion, specifies the template language format. At the time of writing, 2010-09-09 is the latest and only valid version. We can use the Description section to describe our template. Note that it must follow the AWSTemplateFormatVersion Section. AWSTemplateFormation-Version and Description are optional sections. The Resources section specifies the actual AWS resources and their properties. Each AWS resource is identified with a logical name. I have given the logical name NwktVPC for our example VPC. We can use resource-specific logical names for defining dependencies between resources. For example, when adding the AWS::EC2::Subnet resource to our template, we assign the VpcId value by calling it from the AWS::EC2::VPC resource using !REF intrinsinc function. I will explain the process in the Subnet section later. The resources and their properties are defined under logical names. The Resources section is the only required section in AWS CloudFormation-Template. AWS CloudFormation Templates are identified by using Stack Names in AWS Cloud Formation. Our example Stack Name is MyNetworkStack.
Figure 1-12: AWS CloudFormation: VPC.
Monday 20 September 2021
AWS Networking - Part III: VPC Verification Using AWS CLI
VPC Verification Using AWS CLI
We can verify our VPC configuration by using AWS CLI. Example 1-1 shows the output for command aws ec2 describe-vpc in JSON format. This command lists all our VPC resources with their properties. The first one is the newest VPC NVKT-VPC-01, and the second one is the default VPC which I have named DFLT-VPC. The first VPC gets ordinal zero [0], and the second VPC gets number one [1]. Note that ordinal numbers are not shown in the output. VPC properties describe the VPC-specific CIDR Block, DHCP Options, VPC Identifier, Owner Id, CIDR Block Association, and Tags.
aws ec2 describe-vpcs
{
"Vpcs": [
{
"CidrBlock": "10.10.0.0/16",
"DhcpOptionsId": "dopt-09217361",
"State": "available",
"VpcId": "vpc-04ef72cc79a73f82e",
"OwnerId": "123456654321",
"InstanceTenancy": "default",
"CidrBlockAssociationSet": [
{
"AssociationId": "vpc-cidr-assoc-0379c0e3e854f43ff",
"CidrBlock": "10.10.0.0/16",
"CidrBlockState": {
"State": "associated"
}
}
],
"IsDefault": false,
"Tags":
[
{
"Key": "Name",
"Value": "NVKT-VPC-01"
}
]
},
{
"CidrBlock": "172.31.0.0/16",
"DhcpOptionsId": "dopt-09217361",
"State": "available",
"VpcId": "vpc-cfbac1a7",
"OwnerId": "123456654321",
"InstanceTenancy": "default",
"CidrBlockAssociationSet": [
{
"AssociationId": "vpc-cidr-assoc-89d487e1",
"CidrBlock": "172.31.0.0/16",
"CidrBlockState": {
"State": "associated"
}
}
],
"IsDefault": true,
"Tags":
[
{
"Key": "Name",
"Value":
"DFLT-VPC"
}
]
}
]
Example 1-1: AWS CLI: Retrieve VPC Information.
We can use filters for retrieving information only from some specific resources. The command aws ec2 describe-vpcs --filters Name=tag:Name,Values=NVKT-VPC-01 shows VPCs where we have attached the Key/Value pair Name/NVKT-VPC-01.
aws ec2 describe-vpcs --filters
Name=tag:Name,Values=NVKT-VPC-01
{
"Vpcs": [
{
"CidrBlock":
"10.10.0.0/16",
"DhcpOptionsId":
"dopt-09217361",
"State":
"available",
"VpcId":
"vpc-04ef72cc79a73f82e",
"OwnerId":
"123456654321",
"InstanceTenancy":
"default",
"CidrBlockAssociationSet": [
{
"AssociationId":
"vpc-cidr-assoc-0379c0e3e854f43ff",
"CidrBlock":
"10.10.0.0/16",
"CidrBlockState":
{
"State":
"associated"
}
}
],
"IsDefault": false,
"Tags": [
{
"Key":
"Name",
"Value":
"NVKT-VPC-01"
}
]
}
]
}
Example 1-2: AWS CLI: Retrieve VPC Information.
We can also query resource-specific information using the command aws ec2 describe-vpcs --query "Vpcs[0]". The zero within square brackets after the resource Vpcs identifies the ordinal number of a resource. In our example, VPC NVKT-VPC-01 is the first one, and it has an ordinal number zero.
aws ec2 describe-vpcs --query
"Vpcs[0]"
{
"CidrBlock":
"10.10.0.0/16",
"DhcpOptionsId":
"dopt-09217361",
"State": "available",
"VpcId":
"vpc-04ef72cc79a73f82e",
"OwnerId": "123456654321",
"InstanceTenancy":
"default",
"CidrBlockAssociationSet": [
{
"AssociationId":
"vpc-cidr-assoc-0379c0e3e854f43ff",
"CidrBlock":
"10.10.0.0/16",
"CidrBlockState": {
"State":
"associated"
}
}
],
"IsDefault": false,
"Tags": [
{
"Key": "Name",
"Value":
"NVKT-VPC-01"
}
]
}
Example 1-3: AWS CLI: Retrieve VPC Information.
If we want to see only some specific resource properties, we can add the properties after the resource, separated by a dot. Example 1-4 shows how we can see the CIDR Block Association for VPC NVKT-VPC-01 (ordinal zero).
aws ec2 describe-vpcs --query
"Vpcs[0].CidrBlockAssociationSet"
[
{
"AssociationId":
"vpc-cidr-assoc-0379c0e3e854f43ff",
"CidrBlock":
"10.10.0.0/16",
"CidrBlockState": {
"State":
"associated"
}
}
]
Example 1-4: AWS CLI: Retrieve CIDR (Properties) Association
to VPC (Resource).
We can change the output representation from the JSON to table by using the option --output table. The table output is a good choice when we create documentation about VPCs. Note that you can use this option with all other commands too.
aws ec2 describe-vpcs --query
"Vpcs[0].CidrBlockAssociationSet" --output table
------------------------------------------------------
| DescribeVpcs |
+-----------------------------------+----------------+
| AssociationId |
CidrBlock |
+-----------------------------------+----------------+
| vpc-cidr-assoc-0379c0e3e854f43ff | 10.10.0.0/16
|
+-----------------------------------+----------------+
|| CidrBlockState ||
|+------------------+-------------------------------+|
|| State
| associated ||
|+------------------+-------------------------------+|
Example 1-5: AWS CLI: Retrieve CIDR Association to VPC – Table
Output.
AWS Networking - Part II: Create VPC - AWS Console
The first thing to do when we create a VPC is to log in to the AWS console. Then we select the AWS Region where we want to launch our VPC. We are going to use VPC Region Europe (London) eu-west-2. As the last step, we give the name to VPC and associate a CIDR block 10.10.0.0/16 to it.
Figure 1-3: Virtual Private Cloud (VPC) – Example VPC.
Wednesday 15 September 2021
AWS Networking - Part I: Virtual Private Cloud (VPC) Introduction
AWS Virtual Private Cloud (VPC) is a virtual network for Amazon Elastic Cloud Compute instances (EC2) within AWS Region. AWS Regions, in turn, belongs to the global AWS Cloud environment. Each AWS Region consists of three or more physical data centers, Availability Zones (AZ). At the time of writing, Seoul and Tokyo have four, and Northern Virginia has six AZs. All other regions have three AZs. VPC spans over regional AZs but not between AWS Regions. In other words, VPCs are region-specific virtual networks.
A VPC has to have a CIDR (Classless Interdomain Routing) IP block attached to it. The VPC CIDR defines the IP range that we can use when creating subnets to VPC. CIDR range is VPC specific and can overlap with other VPC’s CIRD range. If there should be VPC-to-VPC inter-connection, VPC CIDR IP ranges have to be unique per VPC.
We can allocate subnets for EC2 instances from the VPC’s CIDR range. Subnets are AZ-specific, and they can’t be span from one AZ to another. Subnets are classified either as Public Subnets or Private Subnets. Public Subnet has a route to Internet GW (Internet Gateway) in its Routing Table (RT). EC2 instances launched in a Public Subnet have to have a public IPv4 address in order to have an Internet connection. Note that IPv6 addresses are always assigned from the public address space. EC2 launched in a Private Subnet doesn’t need a public IPv4 address, they can have an Internet connection through the NAT GW. To allow Internet connection to EC2 instances in Private Subnet, we need to add a route to NAT GW into the Private Subnet Routing Table. We can allow a stateful egress-only Internet connection for EC2 instances with IPv6 addresses in Private Subnet by using Egress-Only Internet GW. This way EC2 instance has an Internet connection but hosts on the internet can’t initiate a connection to EC2. IP connectivity between EC2 instances within VPC is established between private IP address even if one of the EC2s is attached to Public Subnet and has a Public IP address. VPC has a main Routing Table that is used with subnets which we don’t define subnet-specific RT.
Each VPC also has a default Network Access Control List (NACL). The default NACL is bind to all subnets in VPC by default. NACL is stateless by nature, traffic to and from the subnet has to be allowed in both inbound and outbound directions. The default NACL allows all ingress/egress traffic.
Figure 1-1 illustrates our example VPC and its relationship to AWS Availability Zones, AWS Regions, and AWS Account. When we create VPC, we first have to log on to our AWS account. Next, we select an AWS Region, in our case Europe (London) eu-west-2. Then we choose Availability Zones for subnets. In our case, network 10.10.0.0/24 is a Public Subnet in the AZ eu-west-2c, and network 10.10.1.0/24 is a Private Subnet in the AZ eu-west-2a. As the last step, we create subnet-specific Routing Tables where we can later add subnet-specific routes.
Figure 1-1: Virtual Private Cloud (VPC) Basic Building
Blocks.
Subscribe to:
Posts (Atom)