We will deploy our networking resources in eu-central-1, also known as the Frankfurt region. Once all the components have been deployed, we will have a final design that looks similar to what’s shown in Figure 4.3:

Figure 4.3: Networking resources deployed on the eu-central-1 region

Let’s go through the relevant code snippets from the CloudFormation template to make deploying all these resources a reality.

Virtual Private Cloud

These are region-scoped network entities that give you an IP address space that can be used to host your resources in the cloud. It is your private version of the data center, running in AWS. You can use a VPC to deploy application workloads that are internet-facing or completely private:

Parameters:

VpcCIDR:

Description: Please enter the IP range (CIDR notation) for this VPC

Type: String

Default: 10.192.0.0/16

Resources:

VPC:

Type: AWS::EC2::VPC

Properties:

CidrBlock: !Ref VpcCIDR

EnableDnsSupport: true

EnableDnsHostnames: true

You might notice that we haven’t hardcoded any configuration values here, but instead used parameters to receive inputs at runtime. To ensure a good user experience, it’s a good practice to additionally provide sensible defaults so that it becomes easy for anyone to try out these templates in their account with minimal effort.

Internet gateway

We can use an internet gateway to allow internet traffic to flow into and out of the VPC. Internet gateways are VPC-scoped resources, which means you create them per region. It’s important to note that in the absence of an internet gateway, your applications cannot receive traffic originating from the internet, even if they have public IPs attached to them. This behavior might be different from some other cloud providers. Within AWS, it helps you avoid any unplanned internet exposure, unless you set up all the required components and routing mechanisms around it:

Resources:

InternetGateway:

Type: AWS::EC2::InternetGateway

Properties:

Tags:

– Key: Name

Value: !Ref EnvironmentName

InternetGatewayAttachment:

Type: AWS::EC2::VPCGatewayAttachment Properties:

InternetGatewayId: !Ref InternetGateway

VpcId: !Ref VPC

In these resource definitions, we created an internet gateway and then attached it to the VPC that will host the application workloads.

Public subnets

A VPC CIDR range is further divided into subnets that are availability zone (AZ) scoped. Since this is a multi- AZ architecture, we will deploy two public subnets. AWS does not natively support the concept of a public or private subnet. The routes that are added to these subnets define their behavior. By definition, public subnets are the ones that forward outgoing internet-bound traffic to the internet gateway. Resources hosted in a public subnet have publicly resolvable IP addresses and the subnet typically has a route for 0.0.0.0/0 pointing to the internet gateway. Let’s have a look at the subnet’s definition and the corresponding route table:

Resources:

PublicSubnet1:

Type: AWS::EC2::Subnet

Properties:

VpcId: !Ref VPC

AvailabilityZone: !Select [ 0, !GetAZs ” ]

CidrBlock: !Ref PublicSubnet1CIDR

MapPublicIpOnLaunch: true

Tags:

– Key: Name

Value: !Sub ${EnvironmentName} Public Subnet (AZ1)

PublicRouteTable:

Type: AWS::EC2::RouteTable

Properties:

VpcId: !Ref VPC

Tags:

– Key: Name

Value: !Sub ${EnvironmentName} Public Routes DefaultPublicRoute:

Type: AWS::EC2::Route

DependsOn: InternetGatewayAttachment

Properties:

RouteTableId: !Ref PublicRouteTable

DestinationCidrBlock: 0.0.0.0/0

GatewayId: !Ref InternetGateway

PublicSubnet1RouteTableAssociation:

Type: AWS::EC2::SubnetRouteTableAssociation Properties:

RouteTableId: !Ref PublicRouteTable SubnetId: !Ref PublicSubnet1 …

CloudFormation offers built-in functions that help you assign values that are not available until runtime. You can use these programming capabilities within your templates to construct, extract, and define different types of values. !Select (short form for Fn::Select) is one such function that can help you extract an item from a list, for a given index. Here, we get the ID of the first AZ so that we can deploy the public subnet. We also use !Sub to substitute the contents of the EnvironmentName parameter into the Tag value. This is an efficient approach to dynamically changing the resource tag names by modifying a single parameter in the template. You can explore other intrinsic functions supported by the service athttps://docs.aws.amazon.com/AWSCloudFormation/ latest/UserGuide/intrinsic-function-reference.html.

Please note that we also define similar resource blocks for the other public subnet, hosted in the second AZ, but they haven’t been mentioned in this example to avoid redundancy.

We will use the public subnets to host an internet-facing load balancer that can receive requests from the end user and balance the load across multiple compute instances in the background.

Leave a Reply

Your email address will not be published. Required fields are marked *