19CSE08 AWS ACADEMY CLOUD ARCHITECTING LAB

LIST OF PROGRAMS

1.Making Environment Highly Available

2.Using Auto Scaling with AWS Lambda

3.Automating Infrastructure Deployment with AWS Cloud Formation

4.Decoupling Infrastructure

5.Implementing a Serverless Architecture with AWS Managed Services

6.Introduction to Amazon CloudFront

7.Multi-Region Failover With Amazon Route 53

8.Sandbox

Ex. No : 1 Hosting a Static Website

Objectives:
Static websites have fixed content with no backend processing. They can contain
HTML pages, images, style sheets, and all files that are needed to render a
website. However, static websites do not use server-side scripting or a database.
If you want your static webpages to provide interactivity and run programming
logic, you can use JavaScript that runs in the user's web browser.

You can easily host a static website on Amazon Simple Storage Service (Amazon
S3) by uploading the content and making it publicly accessible. No servers are
needed, and you can use Amazon S3 to store and retrieve any amount of data at
any time, from anywhere on the web.

After completing this lab, you should be able to:

● Create a bucket in Amazon S3

● Upload content to your bucket
● Enable access to the bucket objects
● Update the website

##Duration

This lab will require approximately 20 minutes to complete.

AWS service restrictions
In this lab environment, access to AWS services and service actions might be
restricted to the ones that are needed to complete the lab instructions. You
might encounter errors if you attempt to access other services or perform
actions beyond the ones that are described in this lab.

Accessing the AWS Management Console

1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.

2. Wait until the Start Lab panel displays the message Lab status: ready, then
close the panel by choosing the X.
3. At the top of these instructions, choose AWS.

This action opens the AWS Management Console in a new browser tab.
The system automatically logs you in.

Tip: If a new browser tab does not open, a banner or icon is usually at the
top of your browser with the message that your browser is preventing the
site from opening pop-up windows. Choose the banner or icon, and then
choose Allow pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside

these instructions. Ideally, you will have both browser tabs open at the
same time so that you can follow the lab steps more easily.

Do not change the Region unless specifically instructed to do so.

Task 1: Creating a bucket in Amazon S3

In this task, you will create an S3 bucket and configure it for static website
hosting.

1. In the AWS Management Console, on the Services menu, choose S3.

2. Choose Create bucket

An S3 bucket name is globally unique, and the namespace is shared by all

AWS accounts. After you create a bucket, the name of that bucket cannot
be used by another AWS account in any AWS Region unless you delete the
bucket.

Thus, for this lab, you will use a bucket name that includes a random
number, such as: website-123

3. For Bucket name, enter: website-<123> (replace <123> with a random

number)

Public access to buckets is blocked by default. Because the files in your

static website will need to be accessible through the internet, you must
permit public access.

o Verify the AWS Region is set to us-east-1 (if it is not, choose the us-
east-1 Region)
4. In the Object Ownership section, select ACLs enabled, then verify
Bucket owner preferred is selected.
5. Clear Block all public access, then select the box that states I
acknowledge that the current settings may result in this bucket and
the objects within becoming public.
6. Choose Create bucket.

You can use tags to add additional information to a bucket, such as a

project code, cost center, or owner.

7. Choose the name of your new bucket.

8. Choose the Properties tab.
9. Scroll to the Tags panel.
10.Choose Edit then Add tag and enter:

● Key: Department
● Value: Marketing

1. Choose Save changes to save the tag.

Next, you will configure the bucket for static website hosting.
 2. Stay in the Properties console.
3. Scroll to the Static website hosting panel.
4. Choose Edit
5. Configure the following settings:
o Static web hosting: Enable
o Hosting type: Host a static website
o Index document: index.html
▪ Note: You must enter this value, even though it is already
displayed.
o Error document: error.html
6. Choose Save changes
7. In the Static website hosting panel, choose the link under Bucket
website endpoint.

You will receive a 403 Forbidden message because the bucket permissions
have not been configured yet. Keep this tab open in your web browser so
that you can return to it later.

Your bucket has now been configured to host a static website.

Task 2: Uploading content to your bucket

In this task, you will upload the files that will serve as your static website to the
bucket.

1. Right-click each of these links and download the files to your computer:

Ensure that each file keeps the same file name, including the extension.

o index.html
o script.js
o style.css
2. Return to the Amazon S3 console and in the website-<123> bucket you
created earlier, choose the Objects tab.
3. Choose Upload
4. Choose Add files
5. Locate and select the three files that you downloaded.
6. If prompted, choose I acknowledge that existing objects with the same
name will be overwritten.
7. Choose Upload

Your files are uploaded to the bucket.

 o Choose Close

Task 3: Enabling access to the objects

Objects that are stored in Amazon S3 are private by default. This ensures that
your organization's data remains secure.

In this task, you will make the uploaded objects publicly accessible.

First, confirm that the objects are currently private.

1. Return to the browser tab that showed the 403 Forbidden message.
2. Refresh the webpage.

If you accidentally closed this tab, go to the Properties tab, and in the
Static website hosting panel choose the Endpoint link again.

You should still see a 403 Forbidden message.

Analysis: This response is expected! This message indicates that your static
website is being hosted by Amazon S3, but that the content is private.

You can make Amazon S3 objects public through two different ways:

o To make either a whole bucket public, or a specific directory in a

bucket public, use a bucket policy.
o To make individual objects in a bucket public, use an access control
list (ACL).

It is normally safer to make individual objects public because this avoids

accidentally making other objects public. However, if you know that the
entire bucket contains no sensitive information, you can use a bucket
policy.

You will now configure the individual objects to be publicly accessible.

3. Return to the web browser tab with the Amazon S3 console (but do not
close the website tab).
4. Select all three objects.
5. In the Actions menu, choose Make public via ACL.

A list of the three objects is displayed.

 6. Choose Make public

Your static website is now publicly accessible.

7. Return to the web browser tab that has the 403 Forbidden message.
8. Refresh the webpage.

You should now see the static website that is being hosted by Amazon S3.

Task 4: Updating the website

You can change the website by editing the HTML file and uploading it again to
the S3 bucket.

Amazon S3 is an object storage service, so you must upload the whole file. This
action replaces the existing object in your bucket. You cannot edit the contents
of an object—instead, the whole object must be replaced.

1. On your computer, load the index.html file into a text editor (for
example, Notepad or TextEdit).
2. Find the text Served from Amazon S3 and replace it with Created by
<YOUR-NAME>, substituting your name for <YOUR-NAME> (for example,
Created by Jane).
3. Save the file.
4. Return to the Amazon S3 console and upload the index.html file that you
just edited.
5. Select index.html and use the Actions menu to choose the Make public
via ACL option again.
6. Return to the web browser tab with the static website and refresh the
page.

Your name should now be on the page.

 Your static website is now accessible on the internet. Because it is hosted on

Amazon S3, the website has high availability and can serve high volumes of
traffic without using any servers.

Submitting your work

1. At the top of these instructions, choose Submit to record your progress
and when prompted, choose Yes.
2. If the results don't display after a couple of minutes, return to the top of
these instructions and choose Grades
Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.

1. To find detailed feedback on your work, choose Details followed by View

Submission Report.

Lab complete 
Congratulations! You have completed the lab.

1. Choose End Lab at the top of this page, and then select Yes to confirm that
you want to end the lab.

A panel indicates that DELETE has been initiated... You may close this
message box now.

2. Select the X in the top right corner to close the panel.

Ex. No: 2 Introducing Amazon Elastic File System (Amazon

EFS)

objectives
This lab introduces you to Amazon Elastic File System (Amazon EFS) by using the
AWS Management Console.

After completing this lab, you should be able to:

● Log in to the AWS Management Console

● Create an Amazon EFS file system
● Log in to an Amazon Elastic Compute Cloud (Amazon EC2) instance that runs
Amazon Linux
● Mount your file system to your EC2 instance
● Examine and monitor the performance of your file system

This lab requires approximately 20 minutes to complete.

Accessing the AWS Management Console

1. At the top of these instructions, choose Start Lab to launch your lab.
 A Start Lab panel opens, and it displays the lab status.

 Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.

2. Wait until the Start Lab panel displays the message Lab status: ready, then
close the panel by choosing the X.

3. At the top of these instructions, choose AWS.

This action opens the AWS Management Console in a new browser tab.
The system automatically logs you in.

4. Arrange the AWS Management Console tab so that it displays alongside these

instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

Task 1: Creating a security group to access

your EFS file system

The security group that you associate with a mount target must allow inbound
access for TCP on port 2049 for Network File System (NFS). This is the security group
that you will now create, configure, and attach to your EFS mount targets.

5. In the AWS Management Console, on the Services menu, choose EC2.

6. In the navigation pane on the left, choose Security Groups.

7. Copy the Security group ID of the EFSClient security group to your text editor.

The Group ID should look similar to sg-03727965651b6659b.

8.Choose Create security group then configure:

o Security group name: EFS Mount Target

o Description: Inbound NFS access from EFS clients
o VPC: Lab VPC

9.Under the Inbound rules section, choose Add rule then configure:

● Type: NFS
● Source:
o Custom
o In the Custom box, paste the security group's Security group ID that you copied
to your text editor
● Choose Create security group.

Task 2: Creating an EFS file system

EFS file systems can be mounted to multiple EC2 instances that run in different
Availability Zones in the same Region. These instances use mount targets that are
created in each Availability Zone to mount the file system by using standard NFSv4.1
semantics. You can mount the file system on instances in only one virtual private cloud
(VPC) at a time. Both the file system and the VPC must be in the same Region.

10.On the Services menu, choose EFS.

11.Choose Create file system

12.In the Create file system window, choose Customize

10.On Step 1:
o Uncheck  Enable automatic backups.
o Lifecycle management: Select None
o In the Tags section, configure:
▪ Key: Name
▪ Value: My First EFS File System

10.Choose Next

11.For VPC, select Lab VPC.

12.Detach the default security group from each Availability Zone mount target by

choosing the  check box on each default security group.

13.Attach the EFS Mount Target security group to each Availability Zone mount

target by:

● Selecting each Security groups check box.

● Choosing EFS Mount Target.

A mount target is created for each subnet.

Your mount targets should look like the following example. The diagram shows
two mount targets in the Lab VPC that use the EFS Mount Target security
group. In this lab, you should be using the Lab VPC.
18.Choose Next
19.On Step 3, choose Next
20.On Step 4:
● Review your configuration.
● Choose Create

Task 3: Connecting to your EC2 instance via

SSH
In this task, you will connect to your EC2 instance by using Secure Shell (SSH).

21.Above these instructions that you are currently reading, choose

the Details dropdown menu, and then select Show

A Credentials window opens.

22.Choose the Download PPK button and save the labsuser.ppk file.

23. Note the EC2PublicIP address, if it is displayed.
24. Exit the Details panel by choosing the X.
25. To use SSH to access the EC2 instance, you must use *PuTTY*. If you do not have PuTTY
installed on your computer 
26. Open putty.exe.
27. To keep the PuTTY session open for a longer period of time, configure the PuTTY
timeout:
● Choose Connection
● Seconds between keepalives: 30
28.Configure your PuTTY session by using the following settings.

● Choose Session
● Host Name (or IP address): Paste the EC2PublicIP for the instance you noted
earlier
o Alternatively, return to the Amazon EC2 console and choose Instances
o Select the instance you want to connect to
o In the Description tab, copy the IPv4 Public IP
● Back in PuTTY, in the Connection list, expand  SSH
● Choose Auth (but don't expand it)

● Choose Browse

● Browse to the labsuser.ppk file that you downloaded, select it, and choose Open

● Choose Open again

29.To trust and connect to the host, choose Accept.

30.When you are prompted with login as, enter: ec2-user

31.Microsoft Windows users: 

32.Above these instructions that you are currently reading, choose

the Details dropdown menu, and then select Show

A Credentials window opens.

33.Choose the Download PEM button and save the labsuser.pem file.

34.Note the EC2PublicIP address, if it is displayed.

35.Exit the Details panel by choosing the X.

36.Open a terminal window, and change directory to the directory where

the labsuser.pem file was downloaded by using the cd command.

For example, if the labsuser.pem file was saved to your Downloads directory, run

this command:cd ~/Downloads

37.Change the permissions on the key to be read-only, by running this command:

38. chmod 400 labsuser.pem

Run the following command (replace <public-ip> with the EC2PublicIP address that you copied
earlier).

o Alternatively, to find the IP address of the on-premises instance, return to the

Amazon EC2 console and select Instances
o Select the instance that you want to connect to
o In the Description tab, copy the IPv4
ssh -i labsuser.pem ec2-user@<public-ip>
39..When you are prompted to allow the first connection to this remote SSH
server, enter yes.

Because you are using a key pair for authentication, you are not prompted for a
password.
 Task 4: Creating a new directory and
mounting the EFS file system
Amazon EFS supports the NFSv4.1 and NFSv4.0 protocols when it mounts your
file systems on EC2 instances. Though NFSv4.0 is supported, we recommend
that you use NFSv4.1. When you mount your EFS file system on your EC2
instance, you must also use an NFS client that supports your chosen NFSv4
protocol. The EC2 instance that was launched as a part of this lab includes an
NFSv4.1 client, which is already installed on it.

40.Back in the AWS Management Console, on the Services menu, choose EFS.

41.Choose My First EFS File System.
42.In the Amazon EFS Console, on the top right corner of the page,
choose Attach to open the Amazon EC2 mount instructions.
43.In your SSH session, follow the instructions in the To set up your EC2
instance section. Copy and paste (or manually type) the command to install the
required utilities.

The command should look similar to this example:

sudo yum install -y amazon-efs-utils

44.Scroll down to the Mounting your file system section.

45.In your SSH session, make a new directory by entering sudo mkdir efs
46.Copy the entire command in the Using the NFS client section.

The mount command should look similar to this example:

sudo mount -t nfs4 -o

nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-
bce57914.efs.us-west-2.amazonaws.com:/ efs

 The provided sudo mount... command uses the default Linux mount options.

47.In your Linux SSH session, mount your Amazon EFS file system by:
o Pasting the command
o Pressing ENTER

48.Get a full summary of the available and used disk space usage by entering:

sudo df -hT

This following screenshot is an example of the output from the following disk

filesystem command:

df -hT

Notice the Type and Size of your mounted EFS file system.

Task 5: Examining the performance behavior of

your new EFS file system
Examining the performance by using Flexible IO
 Flexible IO (fio) is a synthetic I/O benchmarking utility for Linux. It is used to benchmark
and test Linux I/O subsystems. During boot, fio was automatically installed on your EC2
instance.

49. Examine the write performance characteristics of your file system by

entering:
sudo fio --name=fio-efs --filesize=10G --filename=./efs/fio-efs-test.img --bs=1M --nrfiles=1 --direct=1 --sync=0
--rw=write --iodepth=200 --ioengine=libaio
 The fio command will take 5–10 minutes to complete. The output should look
like the example in the following screenshot. Make sure that you examine the
output of your fio command, specifically the summary status information for this
WRITE test.
 Monitoring performance by using Amazon
CloudWatch
50.In the AWS Management Console, on the Services menu, choose CloudWatch.

51.In the navigation pane on the left, choose Metrics.

52.In the All metrics tab, choose EFS.

53.Choose File System Metrics.

54.Select the row that has the PermittedThroughput Metric Name.

 You might need to wait 2–3 minutes and refresh the screen several times before
all available metrics, including PermittedThroughput, calculate and populate.

55.On the graph, choose and drag around the data line. If you do not see the line
graph, adjust the time range of the graph to display the period during which you
ran the fio command.
 56.Pause your pointer on the data line in the graph. The value should be 105M.

56.The throughput of Amazon EFS scales as the file system grows. File-based
workloads are typically spiky. They drive high levels of throughput for short
periods of time, and low levels of throughput the rest of the time. Because of
this behavior, Amazon EFS is designed to burst to high throughput levels for
 periods of time. All file systems, regardless of size, can burst to 100 MiB/s of
throughput. For more information about performance characteristics of your
EFS file system, see the official Amazon Elastic File System documentation.

57.In the All metrics tab, uncheck the box for PermittedThroughput.

58.Select the check box for DataWriteIOBytes.

 If you do not see DataWriteIOBytes in the list of metrics, use the File System
Metrics search to find it.

59.Choose the Graphed metrics tab.

60.On the Statistics column, select Sum.

61.On the Period column, select 1 Minute.

62.Pause your pointer on the peak of the line graph. Take this number (in bytes)
and divide it by the duration in seconds (60 seconds). The result gives you the
write throughput (B/s) of your file system during your test.

The throughput that is available to a file system scales as a file system grows. All file
systems deliver a consistent baseline performance of 50 MiB/s per TiB of storage. Also,
all file systems (regardless of size) can burst to 100 MiB/s. File systems that are larger
than 1T B can burst to 100 MiB/s per TiB of storage. As you add data to your file system,
the maximum throughput that is available to the file system scales linearly and
automatically with your storage.
 EX:3

Creating an Amazon RDS Database

Traditionally, creating a database can be a complex process that requires either

a database administrator or a systems administrator. In the cloud, you can
simplify this process by using Amazon Relational Database Service (Amazon
RDS).

After completing this lab, you should be able to:

● Launch a database using Amazon RDS

● Configure a web application to connect to the database instance

At the end of this lab, your architecture will look like the following example:

Accessing the AWS Management Console

1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.
  

2. Wait until the Start Lab panel displays the message Lab status: ready, then
close the panel by choosing the X.

3. At the top of these instructions, choose AWS

This action opens the AWS Management Console in a new browser tab. The
system automatically logs you in.

Tip: If a new browser tab does not open, a banner or icon is usually at the top of
your browser with the message that your browser is preventing the site from
opening pop-up windows. Choose the banner or icon, and then choose Allow
pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside these
instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

Do not change the Region unless specifically instructed to do so.

Task 1: Creating an Amazon RDS database

In this task, you will create a MySQL database in your virtual private cloud (VPC).
MySQL is a popular open source relational database management system
(RDBMS), so there are no software licensing fees.

Windows Users: Use Chrome or Firefox as your web browser for this lab. The
lab instructions are not compatible with Internet Explorer because of a
difference in the Amazon RDS console.

5. In the search box to the right of Services, search for and choose RDS to open
the RDS console.

6. Choose Create database

  

7. Under Engine options, select MySQL.

The options include several use cases, ranging from enterprise-class databases
to Dev/Test systems. In the options, you might notice Amazon Aurora. Aurora is
a MySQL-compatible system that was re-architected for the cloud. If your
company uses large-scale MySQL or PostgreSQL databases, Aurora can provide
enhanced performance.

8. Set the templates and availability and durability options:

o Under the Templates section, select Dev/Test.
o Under the Availability and durability section, select Single DB instance

Note: the default Multi-AZ deployment option automatically creates a replica of

the database in a second Availability Zone for High Availability, however in this
lab that is not needed.

9.  
10.Under the Settings section, configure these options:
o DB instance identifier: inventory-db
o Username: admin
o Password: lab-password
o Confirm password: lab-password

11.Under the DB instance class section, configure these options:

o Select Burstable classes (includes t classes).
o Select db.t3.micro

12.Under the Connectivity section, configure these options:

o Virtual Private Cloud (VPC): Lab VPC
o Existing VPC security groups:
▪ Choose DB-SG. It will be highlighted.
▪ Remove the default security group.

13.Expand the Additional configuration panel, then configure these settings:

o Initial database name: inventory

Note: This is the logical name of the database that will be used by the
application.

o Clear (turn off) the Enable Enhanced monitoring option

Feel free to review the many other options displayed on the page, but leave
them set to their default values. Options include automatic backups, the ability
to export log files, and automatic version upgrades. The ability to activate these
features through check boxes demonstrates the power of using a fully managed
database solution instead of installing, backing up, and maintaining the database
yourself.

14.Choose Create database (at the bottom of the page).

You should receive a message indicating that your database is being created.

If you receive an error message that mentions rds-monitoring-role, confirm that

you have cleared (turned off) the Enhanced Monitoring option in the previous
step, then try again.

Before you continue to the next task, the database instance status must be
Available. This process might take several minutes.

Task 2: Configuring web application

communication with a database instance
This lab automatically deployed an Amazon Elastic Compute Cloud (Amazon EC2)
instance with a running web application. You must use the IP address of the
instance to connect to the application.

14.In the search box to the right of Services, search for and choose EC2 to open the
EC2 console.
  

15.In the left navigation pane, choose Instances.

In the center pane, there should be a running instance that is named App
Server.

16.Select the App Server instance.

17.In the Details tab, copy the Public IPv4 address to your clipboard.

Tip: If you hover over the IP address, a copy icon appears. To copy the displayed
value, choose the icon.

18.Open a new web browser tab, paste the IP address into the address bar, and
then press ENTER.

The web application should appear. It does not display much information
because the application is not yet connected to the database.

19.Choose Settings.

You can now configure the application to use the RDS DB instance you created
earlier. You will first retrieve the Database Endpoint so that the application
knows how to connect to a database.

20.Return to the AWS Management Console, but do not close the application tab.
(You will return to it soon.

21.In the Services search box, search for and choose RDS to open the RDS console.

 
22.In the left navigation pane, choose Databases.

23.Choose inventory-db.

24.Scroll to the Connectivity & Security section and copy the Endpoint to your
clipboard.

It should look similar to this example: inventory-

db.crwxbgqad61a.rds.amazonaws.com

25.Return to the browser tab with the Inventory application, and enter these values:
o Endpoint: Paste the endpoint you copied earlier
o Database: inventory
o Username: admin
o Password: lab-password
o Choose Save

The application will now connect to the database, load some initial data, and
display information.

26.Add inventory, edit, and delete inventory information by using the web
application.

The inventory information is stored in the Amazon RDS MySQL database that
you created earlier in the lab. This means that any failure in the application
server will not lose any data. It also means that multiple application servers can
access the same data.

27.Insert new records into the table. Ensure that the table has 5 or more inventory
records before submitting your work.

You have now successfully launched the application and connected it to the
database!
 Optional: You can access the saved parameters in the Systems Manager
console, under Parameter Store.

Submitting your work

28.At the top of these instructions, choose Submit to record your progress and
when prompted, choose Yes.

29.If the results don't display after a couple of minutes, return to the top of these
instructions and choose Grades

Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.

30.To find detailed feedback on your work, choose Details followed by View
Submission Report.

Lab complete 
Congratulations! You have completed the lab.

31.Choose End Lab at the top of this page, and then select Yes to confirm that you
want to end the lab.

A panel should appear with this message: DELETE has been initiated... You may
close this message box now.
 Ex 4 : Creating a Virtual Private
 

Cloud
Lab overview and objectives
Traditional networking is difficult. It involves equipment, cabling, complex
configurations, and specialist skills. Amazon Virtual Private Cloud (Amazon VPC)
hides the complexity, and simplifies the deployment of secure private networks.

This lab shows you how to build your own virtual private cloud (VPC), deploy
resources, and create private peering connections between VPCs.

After completing this lab, you should be able to:

● Deploy a VPC

● Create an internet gateway and attach it to the VPC

● Create a public subnet

● Create private subnet

● Create an application server to test the VPC

Duration
This lab will require approximately 30 minutes to complete.

AWS service restrictions

In this lab environment, access to AWS services and service actions might be
restricted to the ones that are needed to complete the lab instructions. You
might encounter errors if you attempt to access other services or perform
actions beyond the ones that are described in this lab.

At the end of this lab, your architecture will look like the following example:
 Accessing the AWS Management Console
 

1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.
  

2. Wait until the Start Lab panel displays the message Lab status: ready, then close
the panel by choosing the X.

3. At the top of these instructions, choose AWS.

This action opens the AWS Management Console in a new browser tab. The
system automatically logs you in.

Tip: If a new browser tab does not open, a banner or icon is usually at the top of
your browser with the message that your browser is preventing the site from
opening pop-up windows. Choose the banner or icon, and then choose Allow
pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside these
instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

Do not change the Region unless specifically instructed to do so.

Task 1: Creating a VPC

You will begin by using Amazon VPC to create a new virtual private cloud, or
VPC.

A VPC is a virtual network that is dedicated to your Amazon Web Services (AWS)
account. It is logically isolated from other virtual networks in the AWS Cloud. You
can launch AWS resources, such as Amazon Elastic Compute Cloud (Amazon
EC2) instances, into the VPC. You can configure the VPC by modifying its IP
address range, and create subnets. You can also configure route tables, network
gateways, and security settings.

5. In the search box to the right of Services, search for and choose VPC to open
the VPC console.
 The VPC console provides a wizard that can automatically create several VPC
architectures. However, in this lab, you will create the VPC components
manually.

6. In the left navigation pane, choose Your VPCs.

A default VPC is provided so that you can launch resources as soon as you start
using AWS. There is also a Shared VPC that you will use later in the lab.
However, you will now create your own Lab VPC.

The VPC will have a Classless Inter-Domain Routing (CIDR) range of 10.0.0.0/16,
which includes all IP address that start with 10.0.x.x. It contains over 65,000
addresses. You will later divide the addresses into separate subnets.

7. Choose Create VPC and configure these settings:

o Name tag: Lab VPC
o IPv4 CIDR block: 10.0.0.0/16
o Choose Create VPC

A message that you successfully created the VPC appears.

8. In the lower half of the page, choose the Tags tab.

Tags are useful for identifying resources. For example, you can use a tag to
identify cost centers or different environments (such as development, test, or
production).

9. Choose Actions and select Edit DNS hostnames.

This option assigns a friendly Domain Name System (DNS) name to EC2 instances
in the VPC, such as:

ec2-52-42-133-255.us-west-2.compute.amazonaws.com

10.Select enable and then choose Save changes

Any EC2 instances that are launched into the VPC will now automatically receive
a DNS hostname. You can also add a more meaningful DNS name (such as
app.example.com) later by using Amazon Route 53.

Task 2: Creating subnets

A subnet is a subrange of IP addresses in the VPC. AWS resources can be
launched into a specified subnet. Use a public subnet for resources that must be
connected to the internet, and use a private subnet for resources that must
remain isolated from the internet.

In this task, you will create a public subnet and a private subnet:
 Creating a public subnet
The public subnet will be used for internet-facing resources.

11.In the left navigation pane, choose Subnets.

12.Choose Create subnet and configure these settings:

o VPC ID: Lab VPC

o Subnet name: Public Subnet

o Availability Zone: Select the first Availability Zone in the list (do not keep the No
Preference default)

o IPv4 CIDR block: 10.0.0.0/24

o Choose Create subnet

The VPC has a CIDR block of 10.0.0.0/16, which includes all 10.0.x.x IP addresses.
The subnet you just created has a CIDR block of 10.0.0.0/24, which includes all
10.0.0.x IP addresses. They might look similar, but the subnet is smaller than the
VPC because of the /24 in the CIDR range.

You will now configure the subnet to automatically assign a public IP address for
all instances that are launched in it.

13. 

14.Select Public Subnet.

15.Choose Actions and select Edit subnet settings, then:

o Select Enable auto-assign public IPv4 address

o Choose Save

Though this subnet is named Public Subnet, it is not yet public. A public subnet
must have an internet gateway, which you attach in the next task.

 
 Creating a private subnet
The private subnet will be used for resources that must remain isolated from the
internet.

15.Use what you just learned to create another subnet with these settings:

o VPC ID: Lab VPC

o Subnet name: Private Subnet

o Availability Zone: Select the first Availability Zone in the list (do not keep the No
Preference default)

o IPv4 CIDR block: 10.0.2.0/23

The CIDR block of 10.0.2.0/23 includes all IP addresses that start with 10.0.2.x and
10.0.3.x. This is twice as large as the public subnet because most resources
should be kept private, unless they specifically must be accessible from the
internet.

Your VPC now has two subnets. However, the public subnet is totally isolated
and cannot communicate with resources outside the VPC. You will next
configure the public subnet to connect to the internet via an internet gateway.

Task 3: Creating an internet gateway

An internet gateway is a horizontally scaled, redundant, and highly available VPC
component. It allows communication between the instances in a VPC and the
internet. It imposes no availability risks or bandwidth constraints on network
traffic.

An internet gateway serves two purposes:

● To provide a target in route tables that connects to the internet

● To perform network address translation (NAT) for instances that were assigned public
IPv4 addresses

In this task, you will create an internet gateway so that internet traffic can access
the public subnet.

16.In the left navigation pane, choose Internet Gateways.

  

17.Choose Create internet gateway and configure these settings:

o Name tag: Lab IGW
o Choose Create internet gateway
You can now attach the internet gateway to your Lab VPC.

18.Choose Actions then Attach to VPC, and configure these settings:

o Available VPCs: Place you cursor in the search box, then select Lab VPC

o Choose Attach internet gateway

This action will attach the internet gateway to your Lab VPC. Though you created
an internet gateway and attached it to your VPC, you must also configure the
public subnet route table so it uses the internet gateway.

Task 4: Configuring route tables

A route table contains a set of rules, called routes, that are used to determine
where network traffic is directed. Each subnet in a VPC must be associated with
a route table because the table controls the routing for the subnet. A subnet can
only be associated with one route table at a time, but you can associate multiple
subnets with the same route table.

To use an internet gateway, a subnet's route table must contain a route that
directs internet-bound traffic to the internet gateway. If a subnet is associated
with a route table that has a route to an internet gateway, it is known as a public
subnet.

In this task, you will:

● Create a public route table for internet-bound traffic

● Add a route to the route table to direct internet-bound traffic to the internet
gateway

● Associate the public subnet with the new route table

19.In the left navigation pane, choose Route Tables.

 Several route tables are displayed, but there is only one route table associated
with Lab VPC. This route table routes traffic locally, so it is called a private route
table.

20.Scroll to the right so that you can see the VPC column, then expand the width of
the column so that you can see which one is used by Lab VPC.

21.Scroll back to the left and select the route table that shows Lab VPC.

22.In the Name column, choose then enter the name Private Route Table and choose
.

23.In the lower half of the page, choose the Routes tab.

There is only one route. It shows that all traffic that is destined for 10.0.0.0/16
(which is the range of the Lab VPC) will be routed locally. This route allows all
subnets in a VPC to communicate with each other.

You will now create a new public route table to send public traffic to the internet
gateway.

24.Choose Create route table and configure these settings:

o Name: Public Route Table
o VPC: Lab VPC
o Choose Create route table
25.In the Routes tab, choose Edit routes

You will now add a route to direct internet-bound traffic (0.0.0.0/0) to the
internet gateway.

26.Choose Add route then configure these settings:

o Destination: 0.0.0.0/0
o Target: Select Internet Gateway and then, from the list, select Lab IGW
o Choose Save changes
The last step is to associate this new route table with the public subnet.

 
27.Choose the Subnet associations tab.

28.Choose Edit subnet associations

29.Select the row with Public Subnet.

30.Choose Save associations

The public subnet is now public because it has a route table entry that sends
traffic to the internet via the internet gateway.

To summarize, you can create a public subnet by following these steps:

o Create an internet gateway
o Create a route table
o Add a route to the route table that directs 0.0.0.0/0 traffic to the internet gateway
o Associate the route table with a subnet, which thus becomes a public subnet

Task 5: Creating a security group for the

application server
A security group acts as a virtual firewall for instances to control inbound and
outbound traffic. Security groups operate at the level of the elastic network
interface for the instance. Security groups do not operate at the subnet level. Thus,
each instance can have its own firewall that controls traffic. If you do not specify
a particular security group at launch time, the instance is automatically assigned
to the default security group for the VPC.

In this task, you will create a security group that allows users to access your
application server via HTTP.

31.In the left navigation pane, choose Security Groups.

32.Choose Create security group and configure these settings:

o Security group name: App-SG
o Description: Allow HTTP traffic
o VPC: select the X to clear the default selection, then choose Lab VPC
o Scroll to the bottom and choose Create security group
33.Verify the Inbound rules tab is selected below.

The settings for Inbound Rules determine what traffic is permitted to reach the
instance. You will configure it to permit HTTP (port 80) traffic that comes from
anywhere on the internet (0.0.0.0/0).

34.Choose Edit inbound rules

35.Choose Add rule and then configure these settings:

o Type: HTTP
o Source type: Anywhere-IPv4
o Description: Allow web access
o Choose Save rules
You use this App-SG in the next task.

Task 6: Launching an application server in

the public subnet
To test that your VPC is correctly configured, you will now launch an EC2
instance into the public subnet. You will also confirm that you can access the EC2
instance from the internet.

36.In the search box to the right of Services, search for and choose EC2 to open the
EC2 console.

37.From the Launch instance menu, choose Launch Instance. Configure these
options:

o Name: App Server

o In the list of available Quick Start AMIs, keep the default Amazon Linux selected.
Also keep the specific default Amazon Linux 2 AMI (HVM) selected.

o In the Instance type panel, keep the default t2.micro selected.

o From the Key pair name menu, select vockey.

o Next to Network settings, choose Edit, then configure:

▪ Network: Lab VPC
▪ Subnet: Public Subnet
o Under Firewall (security groups), choose Select an existing security group.
▪ For Common security groups, select App-SG.
o In the Configure storage section, keep the default settings.

o Expand the Advanced details panel.

o IAM instance profile: Inventory-App-Role

o Scroll to the bottom of the page and then copy and paste the code shown below
into the User data box:
#!/bin/bash
# Install Apache Web Server and PHP
yum install -y httpd mysql
amazon-linux-extras install -y php7.2
# Download Lab files
wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-ACACAD-20-EN/mod6-guided/
scripts/inventory-app.zip
unzip inventory-app.zip -d /var/www/html/
# Download and install the AWS SDK for PHP
wget https://github.com/aws/aws-sdk-php/releases/download/3.62.3/aws.zip
unzip aws -d /var/www/html
# Turn on web server
chkconfig httpd on
service httpd start
o At the bottom of the Summary panel on the right side of the screen choose
Launch instance

You will see a Success message.

38.Choose View all instances

39.Wait until the App Server instance shows 2/2 checks passed in the Status check
column.

This may take a few minutes. Choose the refresh icon at the top of the page
every 30 seconds or so to more quickly become aware of the latest status of the
instance.

40.Select App Server.

41.Copy the Public IPv4 DNS value shown in the Details tab at the bottom of the
page.
  

42.Open a new web browser tab with that IP address.

If you configured the VPC correctly, the Inventory application and this message
should appear: Please configure Settings to connect to database. You have not
configured any database settings yet, but the appearance of the Inventory
application demonstrates that the public subnet was correctly configured.

If the Inventory application does not appear, wait 60 seconds and refresh the
page to try again. It can take a couple of minutes for the EC2 instance to boot
and run the script that installs the software.

Submitting your work

43.At the top of these instructions, choose Submit to record your progress and
when prompted, choose Yes.

44.If the results don't display after a minute, return to the top of these instructions
and choose Grades

Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.

45.To find detailed feedback on your work, choose Details followed by View
Submission Report.

Lab complete 
Congratulations! You have completed the lab.

46.Choose End Lab at the top of this page, and then select Yes to confirm that you
want to end the lab.

A panel indicates that DELETE has been initiated... You may close this message box
now.

47.Select the X in the top right corner to close the panel.

 Ex 5 :Creating a VPC Peering
Connection
Lab overview and objectives
You might want to connect your virtual private clouds (VPCs) when you must
transfer data between them. This lab shows you how to create a private VPC
peering connection between two VPCs.

After completing this lab, you should be able to:

● Create a VPC peering connection

● Configure route tables to use the VPC peering connection

Duration
 

This lab will require approximately 20 minutes to complete.

AWS service restrictions

In this lab environment, access to AWS services and service actions might be
restricted to the ones that are needed to complete the lab instructions. You
might encounter errors if you attempt to access other services or perform
actions beyond the ones that are described in this lab.

Accessing the AWS Management Console

1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

 Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.
2. Wait until the Start Lab panel displays the message Lab status: ready, then close
the panel by choosing the X.
3. At the top of these instructions, choose AWS.

This action opens the AWS Management Console in a new browser tab. The
system automatically logs you in.

 Tip: If a new browser tab does not open, a banner or icon is usually at the top of
your browser with the message that your browser is preventing the site from
opening pop-up windows. Choose the banner or icon, and then choose Allow
pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside these

instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

 Do not change the Region unless specifically instructed to do so.

Task 1: Creating a VPC peering connection

Your task is to create a VPC peering connection between two VPCs.

A VPC peering connection is a one-to-one networking connection between two

VPCs that enables you to route traffic between them privately. Instances in
either VPC can communicate with each other like they are in the same network.
You can create a VPC peering connection between your own VPCs, in a VPC in
another AWS account, or with a VPC in a different AWS Region.

Two VPCs are provided as part of this lab: Lab VPC and Shared VPC. Lab VPC has
an Inventory application that runs on an Amazon Elastic Compute Cloud
(Amazon EC2) instance in a public subnet. Shared VPC has a database instance
that runs in a private subnet.
5. In the AWS Management Console, on the Services menu, choose VPC.
6. In the left navigation pane, choose Peering Connections.
7. Choose Create Peering Connection and configure:
o Peering connection name tag: Lab-Peer
o VPC (Requester): Lab VPC
o VPC (Accepter): Shared VPC
o Choose Create Peering Connection then choose OK

When a VPC peering connection is created, the target VPC must accept the
connection request. The target VPC must accept the request because it might be
owned by a different account. Alternatively, the user that creates the peering
connection might not have permission to accept the connection request for the
target VPC. However, in this lab, you will accept the connection yourself.

8. Select  Lab-Peer.
9. Choose Actions then select Accept Request, and choose Yes, Accept to accept
the request.
10.In the pop-up box, choose Close.

Task 2: Configuring route tables

You will now update the route tables in both VPCs to send traffic from Lab VPC to
the peering connection for Shared VPC.
11.In the left navigation pane, choose Route Tables.
12.Select  Lab Public Route Table (for Lab VPC).

You will configure the Public Route Table associated with Lab VPC. If the

destination IP address falls in the range of Shared VPC, the Public Route Table will
send traffic to the peering connection.

13.In the Routes tab, choose Edit routes then configure these settings:

o Choose Add route
o Destination: 10.5.0.0/16 (The setting is the Classless Inter-Domain Route, or
CIDR, block range of Shared VPC.)
o Target: Select Peering Connection, and then from the list, select Lab-Peer.
o Choose Save routes then choose Close.

You will now configure the reverse flow for traffic that comes from Shared
VPC and goes to Lab VPC.

14.Select  Shared-VPC Route Table. If the check boxes for any other route tables
are selected, clear them.

This route table is for Shared VPC. You will now configure it to send traffic to the
peering connection if the destination IP address falls in the range of Lab VPC.

15.In the Routes tab, choose Edit routes then configure these settings:

o Choose Add route
o Destination: 10.0.0.0/16 (This setting is the CIDR block range of Lab VPC.)
o Target: Select Peering Connection, and then from the list, select Lab-Peer.
o ChooseSave routes then choose Close.
 The route tables are now configured to send traffic via the peering connection
when the traffic is destined for the other VPC.

Task 3: Testing the VPC peering connection

Now that you configured VPC peering, you will test the VPC peering connection.
You will perform the test by configuring the Inventory application to access the
database across the peering connection.

16.On the Services menu, choose EC2.

17.In the left navigation pane, choose Instances.
18.Copy the IPv4 Public IP address that is shown in the Description tab.
19.Open a new web browser tab with that IP address.

You should see the Inventory application and the following message: "Please
configure settings to connect to database"

20.Choose  Settings and configure:
o Endpoint: Paste the database endpoint. To find this endpoint, select Details.
Next to AWS, choose Show. Then, copy the Endpoint.
o Database: inventory
o Username: admin
o Password: lab-password
o Choose Save

The application should now show data from the database.

This step confirms that the VPC peering connection was established
because Shared VPC does not have an internet gateway. The only way to access
the database is through the VPC peering connection.

Submitting your work

21.At the top of these instructions, choose Submit to record your progress and
when prompted, choose Yes.
22.If the results don't display after a couple of minutes, return to the top of these
instructions and choose Grades
 Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.

23.To find detailed feedback on your work, choose Details followed by  View

Submission Report.

Lab complete 
 Congratulations! You have completed the lab.

24.Choose End Lab at the top of this page, and then select Yes to confirm that you
want to end the lab.

A panel indicates that DELETE has been initiated... You may close this message box
now.

25.Select the X in the top right corner to close the panel.

Ex 6 :Controlling AWS Account

Access by Using IAM

IAM AWS service

IAM Group Reason
User access

AppDevelopers Nikhil AWS Nikhil often works as an

Cloud9 access application developer.
to Amazon EC2 He should be able to
development access the AWS Cloud9
environment. environment for the
Also, read-only development
access environment of the café
to Amazon web application.
EC2. However, he shouldn't
have access to the
production
 IAM AWS service
IAM Group Reason
User access

environment. He should
also be able to see all
Amazon EC2 resources
and configuration
details, but he shouldn't
be able to modify them.

Olivia was hired as a

contract database
administrator to help
manage the database
that the café web
application uses. She
Full access should thus have full
to Amazon Amazon RDS access
RDS. rights. She will also need
DBAdministrator
Olivia Also, full access access to AWS Systems
s
to AWS Manager, where the
Systems database connection
Manager. information is stored.
However, beyond access
to these two services,
Sofía can't think of any
reason why Olivia would
need more access to
AWS resources.

Lab overview and objectives

In this lab, you will use AWS Identity and Access Management (IAM) to define
different access rights for different users. You will test access and adjust access.
You will also observe how the access rights that you grant affect what actions
the IAM users can perform on AWS account resources.

After completing this lab, you should be able to:

● Create IAM users and IAM groups, and associate IAM policies with IAM groups
● Indicate how limited access rights affect what resources IAM users can access and what
actions they can take
● Use AWS managed IAM policies to modify user access rights and observe the results
● Use the IAM Policy Simulator to observe the scope of the access that is granted by
different policies
● Access the IAM Access Advisor to observe what access rights different users are taking
advantage of
● Create custom IAM policies by using the visual editor

AWS service restrictions

In this lab environment, access to AWS services and service actions might be
restricted to the ones that are needed to complete the lab instructions. You
might encounter errors if you attempt to access other services or perform
actions beyond the ones that are described in this lab.

Accessing the AWS Management Console

1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

Tip: If you ever need more time to complete the lab that is displayed on the
timer, choose the Start Lab button again to restart the timer for the environment.
Doing so will not delete resources you have created.

2. Wait until you see the message Lab status: ready, then close the Start Lab panel
by choosing the X.
3. At the top of these instructions, choose AWS.

This opens the AWS Management Console in a new browser tab. The system will
automatically log you in.

Tip: If a new browser tab does not open, a banner or icon is usually at the top of
your browser with the message that your browser is preventing the site from
opening pop-up windows. Choose the banner or icon, and then choose Allow
pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside these
instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

Note: You can also uncheck the box next to Terminal at the top of the screen, to
hide it from view.

A business request: Configuring AWS

account access for application developers
(Challenge #1)
The cafe wants to configure access permissions that are appropriate for
application developers. You will take on the role of Sofía to configure the access.
You will then take on the role of Nikhil and test the access for application
developers.

Task 1: Configuring an IAM group with policies and an

IAM user
In this first task in the lab, you will work as Sofía, the AWS account administrator.

As Sofía, you will create an IAM group and assign AWS managed policies to the
group. You will then create a new IAM user, and add that user as a member of
the group. Next, you will create an AWS Cloud9 environment on the existing EC2
instance where the development version of the café web application runs.
Finally, you will share the development environment with the new user.

Note: The user you are logged in as displays in the upper-right area of the webpage.
It should currently indicate that you are logged in as a voclabs user. In this lab,
imagine that the voclabs user is Sofía.
  

5. In the console, open the IAM service page.

6. Create an IAM group named AppDevelopers, and attach the following IAM policies
to it:

o AmazonEC2ReadOnlyAccess

o AWSCloud9EnvironmentMember

7. Create an IAM user and add the user to the AppDevelopers group.

o User name: Nikhil

o Access type: AWS Management Console access

o Custom password: @ppD3veloper2020!

o Require password reset: Clear this check box

o Add Nikhil to the AppDevelopers group

o Note: You don't need to add any tags

o In the Success screen, you can optionally choose Download .csv and save the
file to your computer

o Choose Close

8. While still logged in as the voclabs user (Sofía), connect to the AWS Cloud9 IDE
and set up the café web application.

o Open the AWS Cloud9 service page and under DEVCafeServer, choose Open
IDE.

The AWS Cloud9 IDE that run on an EC2 instance should now display.

o In the Bash terminal window at the bottom of the screen, paste and run these
three commands:
 wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-ACACAD-20-EN/mod8-challenge/
install-cafe-app.sh
chmod +x install-cafe-app.sh
./install-cafe-app.sh
Note: You do not need to wait for the script to finish running. Instead, go to the
next step.

9. Share the AWS Cloud9 environment with the Nikhil user.

o In the top-right corner of the AWS Cloud9 IDE, choose Share.

o In the Share this environment panel, under Invite Members, enterNikhil and
choose Invite.

o Choose OK, choose OK again, and then choose Done.

Important: Close the AWS Cloud9 IDE browser tab, but leave open at least one
other browser tab where you are logged into the AWS Management Console as
the voclabs user (Sofía).

Task 2: Logging in as Nikhil and testing access

In this task, you will work as Nikhil to test the access permissions that Sofía
configured.

Tip: We recommend opening an incognito or private browser tab to log in as

Nikhil.

● For example, if you are using Chrome, choose File > New Incognito Window. If you are
using Firefox, choose File > New Private Window.
● Alternatively, use a different browser (for example, if you used Chrome to complete
Task 1, use Firefox, Edge, or Safari for Task 2).

Note: Using an incognito session, a private session, or a different browser is

convenient. You can remain logged in as both the voclabs user and as another
user (such as Nikhil) simultaneously. You can thus switch between these two
user-access levels without needing to log out or log in repeatedly. The
authenticated session information in the different browser tabs will be isolated
from one another.

10.As Nikhil, log in to the AWS Management Console.

o In the browser tab where you are logged in as the voclabs user (Sofía), open the
IAM console, choose Users, and then choose Nikhil.
o Choose the Security credentials tab, and in the Sign-in credentials section,
copy the Console sign-in link.

o Paste the link into an incognito or private browser tab (or other browser as
explained in the previous tip).

o In the Sign in as IAM user screen, enter Nikhil's credentials and choose Sign in.

▪ IAM user name: Nikhil

▪ Password: @ppD3veloper2020!

11.Open the Amazon EC2 console and in a browser tab, load the café web
application.

o Verify that you are in the correct Region (for example, N. Virginia) and switch to
it, if necessary.

o You should be able to view all the details of the EC2 instances.

o Locate and copy the IPv4 Public IP address of the aws-cloud9-DEVCafeServer

instance.

o In a new browser tab, load http://<dev-public-ip-address>/cafe, where <dev-public-ip-

address> is the IP address that you copied.

The café website should display. Keep this browser tab open for later in the lab.

12.Test your Amazon EC2 access further by attempting to restart the web server.

o Try to reboot the aws-cloud9-DEVCafeServer instance

Tip: To find the Reboot option, select the instance and look in the Actions
menu.

Answering questions about Nikhil's Amazon EC2 access

Answers will be checked when you choose the blue Submit button at the end of
the lab.

13.Access the questions in this lab.

o Above these instructions, choose the Details  menu, and then choose Show.

o At the bottom of the page, choose the Access the multiple choice questions
link.
 The questions should load in a new browser tab.

14.In the webpage that you just opened, answer the first two questions:

o Question 1: What happened when Nikhil tried to reboot the EC2 instance?

o Question 2: Which IAM policy allowed Nikhil to access the AWS Cloud9
environment?

Note: Leave the questions webpage open in your browser tab. You will return to
it later in this lab.

Accessing the Development server as Nikhil

15.Return to the browser tab where you are logged into the AWS Management
Console as Nikhil.

Tip: Remember that you can see which user you are using in the top-right area
of the browser interface.

16.Browse to the AWS Cloud9 console, and connect to the AWS Cloud9 IDE on the
DEVCafeServer EC2 instance.

o From the Services menu, choose AWS Cloud9.

o On the left, expand the menu by choosing the (menu icon), choose Shared with
you, and verify that the DEVCafeServer environment is available.

o Choose Open IDE.

Note: You have just connected to the guest OS of the aws-cloud9-DEVCafeServer

EC2 instance. You observed this instance in the Amazon EC2 console a moment
ago. You can use the IDE to browse and edit files on the web server. It also
provides a Bash terminal that runs on the instance.

17.On the development instance of the café website, modify the main heading for
the webpage.

o Open the main webpage in the editor by going to the file browser, navigating to
the DEVCafeServer/www/html/cafe directory, and double-clicking index.php.

o Modify line 13 So that it reads:

 <div class="center">Caf&eacute; DEV Site</div>
o To save the change, choose File > Save and in the browser, refresh the http://dev-
public-ip-address/cafe/ webpage.

Notice that, while acting as Nikhil, you changed the main heading of the
webpage in the development environment.

18.Test the connectivity of the web application database.

o In the café website, choose Menu.

o What message displays?

19.Return to the browser tab with the multiple-choice questions for this lab, and
answer the following question.

o Question 3: Which message was displayed on the Menu page of the café
website's development instance?

Nikhil recalls that the database connection parameters are stored in the AWS
Systems Manager Parameter Store.

20.As Nikhil, open the Systems Manager Parameter Store.

o In the console, open the Systems Manager service.

o From the menu on the left, choose Application Management > Parameter
Store.

o What message displays?

21.Return to the browser tab with the multiple-choice questions for this lab, and
answer the following question.
o Question 4: Which message was displayed when Nikhil opened the Systems Manager
Parameter Store page in the console?
 Nikhil alerts Sofía about the issue on the development server that's preventing
him from improving the café web application. Sofía is concerned. She asks Nikhil
to check if the production version of the website is experiencing the same issue.

22.As Nikhil, verify that the production café web application is working correctly.
o Open the Amazon EC2 console and copy the IPv4 Public IP address of the
PRODCafeServer instance.
o In a new browser window, load http://prod-public-ip-address/cafe/menu.php.
o Does the webpage display correctly, and can you place orders?

New business requirement: Configuring

AWS account access for database
administrators (Challenge #2)
Nikhil reports the results of his test to Sofía. She's glad to know that the
production site is still functioning well. However, Sofía wants to correct the
problem on the development site.

Sofía decides that she will ask Olivia to fix the issue. However, Sofía must first
define the AWS account access rights for database administrators. She must
then create an IAM user resource so that Olivia can log in to the account.

Task 3: Configuring IAM for database administrator

user access
In this task, you will work as Sofía to enable AWS access for Olivia.

23.Back in the browser where you are logged in as the voclabs user (Sofía), create
an IAM group named DBAdministrators, with the following permissions:
o AmazonRDSReadOnlyAccess
o AmazonSSMFullAccess
Note: In a real-world situation, Sofia would need to grant more than simply read
only access to RDS to her database administrators. However, the permissions in
this lab environment, do not allow you to attach the AmazonRDSFullAccess
policy. Instead, for this lab, you should use the AmazonRDSReadOnlyAccess
policy as a substitute.
  

24.Create an IAM user that's named Olivia with access to the AWS Management
Console.

o Set a custom password: Db@dministrat0r2020!

o Clear the requirement to reset the password

 
25. Add Olivia to the DBAdministrators group.

Task 4: Logging in as the database administrator and

resolving the database connectivity issue
In this task, you will work as Olivia to resolve the database issue that Nikhil
identified. You will also work as Sofía to help Olivia resolve some issues.

26.As Olivia, log in to the AWS Management Console.

Tip: Use the incognito session, private session, or other browser type that you
used to log in as Nikhil. To do this:

o Choose Nikhil @ <account-number> in the top-right area of the console and

choose Sign Out.

o Then, choose Log back in.

The Sign in as IAM user screen should display, with the Account ID pre-
populated.

Note: If the login screen doesn't display the account ID, return to the browser
tab where you are still logged in as the voclabs (Sofía) user. In the IAM console,
choose Users and choose Olivia. Choose the Security credentials tab. In the
Sign-in credentials section, copy the Console sign-in link.

o Sign in with Olivia's credentials:

▪ IAM user name: Olivia

▪ Password: Db@dministrat0r2020!

27.Verify that the RDS database is running.

o Open the Amazon RDS service page and choose Databases.
o Verify that the Status of the database instance is Available.
 Olivia observes that the database is running.

She recalls that the development environment connects to the database by

using parameters that are stored in the Systems Manager Parameter Store.
Olivia wonders if the DEVCafeServer EC2 instance has permissions to read the
parameters out of the Parameter Store.

28.Open the Amazon EC2 console and choose Running Instances.

29.Return to the browser tab with the multiple-choice questions for this lab, and
answer the following question.
o Question 5: Why can't Olivia access the EC2 instance details?
Olivia tells Sofía that she can't access the EC2 instances, and Sofía goes back to
the console to troubleshoot this issue.
You will now work as Sofia to review and update Olivia's access to AWS
resources.

30.Return to the browser tab where you are logged in as the voclabs user (Sofía).

31.Open the DBAdministrators group, and attach these policies:

o AmazonEC2ReadOnlyAccess
o IAMReadOnlyAccess
Note: Sofía realizes that Olivia needs some IAM permissions if she must access
the details of the IAM role that's attached to the EC2 instance.

32.Still as the voclabs user (Sofía), check which services and features Olivia used.

o In the IAM console, open the Olivia user, and choose the Access Advisor tab

o Notice that you can see which service areas that Olivia visited. Recent service
activity usually appears within 4 hours (as stated in the Access Advisor details).
You might not see any Last accessed data for Olivia yet.

You can use this view to gain insight into how a user's permissions might be
more open than they should be. This information enables you to more closely
align access rights with the principle of least privilege.

Sofía asks Olivia to check her Amazon EC2 access.

33. 
34.As Olivia, return to the browser tab where the Olivia user is logged in and refresh
the instances page of the Amazon EC2 console.

o Olivia should now be able to access both running EC2 instances.

o Select the aws-cloud9-DEVCafeServer instance.

o In the Description tab, find IAM role and choose CafeRole.

o In the Permissions tab, expand the AmazonSSMManagedInstanceCore policy

and choose the JSON view option.

o Review the policy permissions.

34.Return to the browser tab with the multiple-choice questions for this lab and
answer the following question.
o Question 6: Name two specific actions in the policy that allow the café web application
on this instance to access the database credentials in the Parameter Store.
Olivia is now convinced that the web application on the development EC2
instance can access the Parameter Store. Maybe the problem is something else.
Olivia discusses the issue with Sofía.
After some conversation, Sofía remembers that the development environment
previously used a local database, but that it now uses Amazon RDS. The local
database had a different user name that allowed the web application to connect
to the database. Connecting to the database on Amazon RDS requires a different
database user name. That must be the issue!
Sofía asks Olivia to check whether the database user name is the source of the
problem and to update it.

35.As Olivia, update the dbUser value in the Systems Manager Parameter Store.

36.In the web application on the development café server, refresh the Menu page.
o If this webpage isn't already open, load http://<dev-public-ip-address>/cafe/menu.php in a
browser (where <dev-public-ip-address> is the actual IPv4 public IP address of the aws-
cloud9-DEVCafeServer instance).
o Does the full page of content display correctly now? Can you successfully submit an
order?
Congratulations! You acted as a member of the DBAdministrators group, and you
fixed the website. Nikhil thanks Olivia for resolving the issue, and Olivia also
informs Sofía that the issue is resolved.

 
 New business requirement: Refining IAM
user access (Challenge #3)
Frank and Martha are happy that Sofía and the team improved the security of
the AWS account. Meanwhile, Sofía is happy that she was able to configure
different permissions for her application developers and database
administrators. She likes that assigning separate permissions to each role
results in team members working together—each within their area of core
competency and assigned responsibility—to do development and to
troubleshoot issues.

Sofía takes a minute to relax with her friends. However, she's already thinking
about further customizing the security settings that she assigned to the different
users. Some of the permissions are still too open and don't fully follow the
principle of least privilege. In this final challenge in the lab, you will take on the
role of Sofía. You will work to define a custom IAM policy that reduces the
number of allowed IAM actions that are granted to members of the database
administrators group. However, you must also grant them enough IAM access to
accomplish their job responsibilities.

Task 5: Using the IAM Policy Simulator and creating a

custom IAM policy with the visual editor
37.Return to the browser window where you are logged in as the voclabs user
(Sofía), and load this URL in a new browser tab

The IAM Policy Simulator page should open.

  

38.Choose the Olivia user.

39.In the IAM Policies list, make sure that the IAMReadOnlyAccess policy is
selected. However, clear the check boxes of the other policies.

40.In the Policy Simulator section, choose Select service. In the Filter search box,
enter Ident and select Identity and Access Management.

41.Choose the Select All option (to the right of the Select actions menu), and then
choose Run Simulation.
o In the Action Settings and Results panel, a list of actions should display.
o The Permission column displays Olivia's permissions for each action. The
IAMReadOnlyAccess policy denies Olivia the permissions to perform Add or Create
actions. However, scroll to find the actions that she can take.
o The summary (at the top of the list) shows that Olivia is currently allowed to take 57 IAM
actions.

42.Return to the browser tab where you are logged in as the voclabs user (Sofía).

43.In the IAM console, choose Policies and then choose Create policy.

 
44.In the Visual editor tab, configure the following settings.
o Click Choose a service. Search for and choose EC2.
▪ In the Actions search box, search for IAM and select
DescribeIamInstanceProfileAssociations.

44.
o At the bottom of the screen, choose Add additional permissions.
o Click Choose a service. Search for and choose IAM.
▪ In the Actions search box, search for Get and select the following actions –
▪ GetPolicyVersion
▪ GetRole
▪ GetRolePolicy
▪ Back in the search box, search for List and select the following actions –
▪ ListAttachedRolePolicies
▪ ListInstanceProfiles
▪ ListInstanceProfilesForRole
▪ ListPolicies
▪ ListRolePolicies
▪ ListRoles
o Expand the Resources section and for all three resource types (instance-profile,
policy, and role) select Any in this account.
o Back at the top of the screen, choose the JSON tab

This view shows the JSON document that you just composed by using the visual
editor.

o Verify that the policy document details match what is shown in the following
example:
45.Exit the Create policy wizard by choosing Cancel.

46.In the Policies search box, search for LimitedIamPolicy.

Observe that the policy details match the one you worked to build, as shown in
the previous screen capture.

Note: The Sid elements in a policy are optional. Also, the order in which Effect,
Action, and Resource appear in a policy document doesn't affect how the policy
works.

47.Edit the DBAdministrators IAM group.

o Attach the LimitedIamPolicy policy
o Detach the IAMReadOnlyAccess policy

Sofía asks Olivia to confirm that she can still access the details of the CafeRole
IAM role, even with the more limited IAM access rights now granted to her.

48.Return to the browser tab where you are logged in as Olivia, and verify that you
can still access the details of CafeRole.
o In the Amazon EC2 console, select the aws-cloud9-DEVCafeServer instance.
o In the Description tab, choose the IAM role > CafeRole.
o Expand the AmazonSSMManagedInstanceCore policy and verify that you can
still see the JSON document details.

49.(Optional) Return to the IAM Policy Simulator browser tab where you are
logged in as the voclabs user (Sofía). Run the simulation again (for what IAM
actions Olivia can take).
o Tip: To display the new IAM policies that apply to Olivia, refresh the browser
page.
o Before the change to the DBAdministrators IAM group, Olivia was allowed to
perform 57 actions that are related to the IAM service. However, after the
change, her access to the IAM service is now much more limited.
o The new policy grants fewer IAM permissions. However, Olivia still has the
access that she needs to perform her job functions.
 Update from the café
Sofía believes that she's becoming good at managing user access to the AWS
account!

She knows how to use AWS managed IAM policies to control access, and she also
knows how to use the IAM Policy Simulator to observe the scope of the
permissions that different policies grant. She knows how to access the IAM
Access Analyzer to observe what access rights different users are taking
advantage of. And finally, she also practiced using the IAM policy Visual Editor to
create custom IAM policies.

Submitting your work

50.At the top of these instructions, choose Submit to record your progress and
when prompted, choose Yes.

51.If the results don't display after a couple of minutes, return to the top of these
instructions and choose Grades

Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.

52.To find detailed feedback on your work, choose Details followed by View
Submission Report.

Lab complete
Congratulations! You have completed the lab.

53.To confirm that you want to end the lab, at the top of this page, choose End Lab,
and then choose Yes.
 A panel should appear with this message: DELETE has been initiated... You may
close this message box now.

54.To close the panel, choose the X in the top-right corner.

EX 7: Creating a Highly Available

Environment
Lab overview and objectives
Critical business systems should be deployed as highly available applications—
that is, applications remain operational even when some components fail. To
achieve high availability in Amazon Web Services (AWS), we recommend that you
run services across multiple Availability Zones.

Many AWS services are inherently highly available, such as load balancers. Many
AWS services can also be configured for high availability, such as deploying
Amazon Elastic Compute Cloud (Amazon EC2) instances in multiple Availability
Zones.

In this lab, you will start with an application that runs on a single EC2 instance.
You will then make the application highly available.

After completing this lab, you should be able to:

● Inspect a provided virtual private cloud (VPC)

● Create an Application Load Balancer
● Create an Auto Scaling group
 AWS service restrictions
In this lab environment, access to AWS services and service actions might be
restricted to the ones that are needed to complete the lab instructions. You
might encounter errors if you attempt to access other services or perform
actions beyond the ones that are described in this lab.

Accessing the AWS Management Console

1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.

2. Wait until the Start Lab panel displays the message Lab status: ready, then close
the panel by choosing the X.
  

3. At the top of these instructions, choose AWS.

This action opens the AWS Management Console in a new browser tab. The
system automatically logs you in.

Tip: If a new browser tab does not open, a banner or icon is usually at the top of
your browser with the message that your browser is preventing the site from
opening pop-up windows. Choose the banner or icon, and then choose Allow
pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside these
instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

Do not change the Region unless specifically instructed to do so.

Task 1: Inspecting your VPC

This lab begins with an environment that is already deployed via AWS
CloudFormation. It includes:

● A VPC
● Public and private subnets in two Availability Zones
● An internet gateway (not shown) that is associated with the public subnets
● A Network Address Translation (NAT) gateway in one of the public subnets
● An Amazon Relational Database Service (Amazon RDS) instance in one of the
private subnets
5. On the AWS Management Console, on the Services menu, choose VPC.

6. In the left navigation pane, under Filter by VPC, choose the Select a VPC box
and select Lab VPC.

This setting will limit the console to only show resources that are associated with
the Lab VPC.

7. In the left navigation pane, choose Your VPCs.

Here, you can access information about the Lab VPC that was created for you.

The IPv4 CIDR column has a value of 10.0.0.0/16, which means that this VPC
includes all IP addresses that start with 10.0.x.x.
  

8. In the left navigation pane, choose Subnets.

Here, you can access information about Public Subnet 1:

o The VPC column shows that this subnet exists inside of Lab VPC.
o The IPv4 CIDR column has a value of 10.0.0.0/24, which means that this subnet
includes the 256 IP addresses between 10.0.0.0 and 10.0.0.255. Five of these
addresses are reserved and unusable.
o The Availability Zone column lists the Availability Zone where this subnet
resides.

9. To reveal more details at the bottom of the page, select Public Subnet 1.

Tip: To adjust the size of the lower window pane, you can drag the divider.

10.In the lower half of the page, choose the Route table tab.

This tab includes details about the routing for this subnet:

o The first entry specifies that traffic destined within the Classless Inter-Domain
Routing (CIDR) range for the VPC (10.0.0.0/16) will be routed within the VPC
(local).
o The second entry specifies that any traffic destined for the internet (0.0.0.0/0) is
routed to the internet gateway (igw-). This setting makes the subnet a public
subnet.

11.Choose the Network ACL tab.

This tab has information about the network access control list (network ACL) that
is associated with the subnet. The rules currently permit all traffic to flow in and
out of the subnet, but the rules can be further restricted by using security
groups.

12.In the left navigation pane, choose Internet Gateways.

 Notice that an internet gateway is already associated with Lab VPC.

13.In the left navigation pane, choose Security Groups.

14.Select Inventory-DB.

This security group controls incoming traffic to the database.

15.In the lower half of the page, choose the Inbound rules tab.

These rules permit inbound MySQL or Aurora traffic (port 3306) from anywhere
in the VPC (10.0.0.0/16). You will later modify this setting so it only accepts traffic
from the application servers.

16.Choose the Outbound rules tab.

By default, security groups allow all outbound traffic. However, this setting can
be modified as needed.

Task 2: Creating an Application Load

Balancer
To build a highly available application, it is a best practice to launch resources in
multiple Availability Zones. Availability Zones are physically separate data centers
(or groups of data centers) in the same Region. If you run your applications
across multiple Availability Zones, you can provide greater availability if a data
center experiences a failure.

Because the application runs on multiple application servers, you will need a
way to distribute traffic amongst those servers. You can accomplish this goal by
 using a load balancer. This load balancer will also perform health checks on
instances and only send requests to healthy instances.

17.On the Services menu, choose EC2.

18.In the left navigation pane, choose Load Balancers (you might need to scroll
down to find it).

19.Choose Create Load Balancer

Several types of load balancers are displayed. Read the descriptions of each type
to understand their capabilities.

20.Under Application Load Balancer, choose Create.

 
21.For Load balancer name, enter: Inventory-LB

22.Scroll down to the Network mapping section, then for VPC, select Lab VPC.

Important: Be sure to choose Lab VPC. It is likely not the default selection.

You will now specify which subnets the load balancer should use. It will be a
public load balancer, so you will select both public subnets.

23.Under Mappings, choose the first Availability Zone, then choose the Public
Subnet that displays.

24.Choose the second Availability Zone, then choose the Public Subnet that
displays.

You should now have selected two subnets: Public Subnet 1 and Public Subnet
2. (If not, go back and try the configuration again.)

25.In the Security groups section, select Create new security group, then
configure:
o Security group name: Inventory-LB
o Description: Enable web access to load balancer
o VPC: Remove the default VPC by choosing the X to the right of it. Then select Lab
VPC.

26.Under Inbound rules, choose Add rule and configure as described:

o Type: HTTP
o Source: Anywhere-IPv4

27.Still under Inbound rules, choose Add rule again and configure:
o Type: HTTPS
o Source: Anywhere-IPv4

 
28.Choose Create security group.

29.Assign the security group to the load balancer:

o Return to the browser tab where you are still configuring the load balancer.
o Scroll down to the Security groups area and choose the refresh icon.
o For Security groups, select the Inventory-LB security group.
o Next, below the Security groups dropdown menu, select the X next to the
default security group so that the Inventory-LB is now the only security group
chosen.

30.In the Listeners and routing section, choose Create target group.

Analysis: Target groups define where to send traffic that comes into the load
balancer. The Application Load Balancer can send traffic to multiple target
groups based upon the URL of the incoming request, such as having requests
from mobile apps going to a different set of servers. Your web application will
use only one target group.

31.A new browser tab will open. Configure the target group as described here:
o Choose a target type: Instances
o Target group name: Inventory-App
o VPC: Ensure that Lab VPC is chosen.
o Scroll down and expand Advanced health check settings.

Note: The Application Load Balancer automatically performs health checks on all
instances to ensure that they are responding to requests. The default settings
are recommended, but you will make them slightly faster for use in this lab.

o Healthy threshold: 2
o Interval: 10 (seconds)

This means that the health check will be performed every 10 seconds, and if the
instance responds correctly twice in a row, it will be considered healthy.

o Choose Next. The Register targets screen appears.

 Note: Targets are the individual instances that will respond to requests from the
load balancer.

You do not have any web application instances yet, so you can skip this step.

o Review the settings and choose Create target group.

32.Return to the browser tab where you already started defining the load balancer.

33.In the Listeners and routing section, choose the refresh icon.

34.For the Listener HTTP:80 row, set the Default action to forward to Inventory-
app.

35.Scroll to the bottom of the page, and choose Create load balancer.
o The load balancer is successfully created.
o Choose View load balancer.

Task 3: Creating an Auto Scaling group

Amazon EC2 Auto Scaling is a service designed to launch or terminate Amazon EC2
instances automatically based on user-defined policies, schedules, and health
checks. It also automatically distributes instances across multiple Availability Zones
to make applications highly available.

In this task, you will create an Auto Scaling group that deploys EC2 instances
across your private subnets, which is a security best practice for application
deployment. Instances in a private subnet cannot be accessed from the internet.
Instead, users send requests to the load balancer, which forwards the requests
to EC2 instances in the private subnets.
 Create an AMI for Auto Scaling
You will create an Amazon Machine Image (AMI) from the existing Web Server 1.
This will save the contents of the boot disk so that new instances can be
launched with identical content.

36. In the AWS Management Console, on the Services menu, choose EC2.

37.In the left navigation pane, choose Instances.

First, you will confirm that the instance created for you in this lab is running.

38.Wait until the Status check for Web Server 1 displays 2/2 checks passed. Choose
refresh to update.

39. Select Web Server 1.

  

40.In the Actions  menu, choose Image and templates > Create image, then
configure:
o Image name: Web Server AMI
o Image description: Lab AMI for Web Server

41.Choose Create image

A banner at the top of the screen displays the AMI ID for your new AMI.

You will use this AMI when launching the Auto Scaling group later in the lab.

Create a launch configuration and an Auto Scaling

group
You will first create a launch configuration, which defines the type of instances
that Amazon EC2 Auto Scaling should launch. The interface looks similar to when
you launch an EC2 instance. However, instead of launching an instance, it stores
the configuration for later use.

42. In the left navigation pane, choose Launch Configurations.

43. Choose Create launch configuration

44.Configure these settings:

o Launch configuration name: Inventory-LC

o Amazon machine image (AMI): Web Server AMI

o Instance type:
▪ Select Choose instance type
▪ Select t3.micro
▪ Select Choose
Note: If you have launched the lab in the us-east-1 Region, select the t2.micro
instance type. To find the Region, look in the upper-right corner of the Amazon
EC2 console.
 Note: If you receive the error message Something went wrong. Please refresh and
try again, you may ignore it and continue with the exercise.

o Additional configuration:
▪ IAM instance profile: Inventory-App-Role
o Monitoring: Select Enable EC2 instance detailed monitoring within CloudWatch

This allows Auto Scaling to react quickly to changing utilization.

45. Expand Advanced details. Under User data, copy and paste this script:

#!/bin/bash
# Install Apache Web Server and PHP
yum install -y httpd mysql
amazon-linux-extras install -y php7.2
# Download Lab files
wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-ACACAD-20-EN/mod9-guided/
scripts/inventory-app.zip
unzip inventory-app.zip -d /var/www/html/
# Download and install the AWS SDK for PHP
wget https://github.com/aws/aws-sdk-php/releases/download/3.62.3/aws.zip
unzip aws -d /var/www/html
# Turn on web server
chkconfig httpd on
service httpd start
46. Under Security groups, for Select an existing security group, choose Inventory-App.

You will receive a warning that You will not able to connect to the instance. You can
ignore this warning because you will not need connect to the instance. All
configuration is done via the user data script.

47.Under Key pair (login):

o Key pair options: Proceed without a key pair
o Select I acknowledge that...

48.Choose Create launch configuration

 The launch configuration defined what to launch, but the Auto Scaling group
defines where to launch the resources.

49. In the Launch configurations table, select Inventory-LC.

50. From the Actions menu, choose Create Auto Scaling group.

51. For Auto Scaling group name, enter: Inventory-ASG (ASG stands for Auto Scaling group)

52. Choose Next

53.On the Network page, configure as described below:

o VPC: Lab VPC

o Subnet: Select Private Subnet 1 and Private Subnet 2

This will launch EC2 instances in private subnets across both Availability Zones.

54. Choose Next

55.Under Load balancing, configure:

o Select Attach to an existing load balancing

o Existing load balancer target groups: Select Inventory-App

These settings tell the Auto Scaling group to register new EC2 instances as part
of the Inventory-App target group that you created earlier. The load balancer will
send traffic to instances that are in this target group.

56.Under Health checks, configure:

o Health check type: Select ELB
o Health check grace period: 90

 
57. Under Additional settings, select Enable group metrics collection within
CloudWatch.

58. Choose Next

59.Under Group size, configure:

o Desired capacity: 2
o Minimum capacity: 2
o Maximum capacity: 2

60.Under Scaling policies, choose None.

For this lab, you will maintain two instances at all times to ensure high availability.
If the application is expected to receive varying loads of traffic, you can also
create scaling policies that define when to launch or terminate instances.
However, you do not need to create scaling policies for the Inventory application
in this lab.

61. Choose Next

62. On the Add notifications page, choose Next. You do not need to configure any of
these settings.

63.On the Add tags page, choose Add tag and configure:
o Key: Name
o Value: Inventory-App
o Select Next
These settings will tag the Auto Scaling group with a Name, which will also
appear on the EC2 instances that are launched by the Auto Scaling group. You
can use tags to identify which Amazon EC2 instances are associated with which
application. You could also add tags such as Cost Center to assign application
costs in the billing files.

64.On the Review page, choose Create Auto Scaling group

 The Inventory-ASG will appear in the console:

64.The review shows that:

o The group currently has no instances, but the Status column indicates Updating
capacity.
o The Desired quantity is 2 instances. Amazon EC2 Auto Scaling will attempt to
launch two instances to reach the desired quantity.
o The Min and Max are also set to 2 instances. Amazon EC2 Auto Scaling will try to
always provide two instances, even if failure occurs.

Your application will soon run across two Availability Zones. Amazon EC2 Auto
Scaling will maintain that configuration even if an instance or Availability Zone
fails.

After a minute, choose the refresh icon to update the display. It should show
that 2 instances are running.

Task 4: Updating security groups

The application you deployed is a three-tier architecture. You will now configure
the security groups to enforce these tiers:

Load balancer security group

You already configured the load balancer security group when you created the
load balancer. It accepts all incoming HTTP and HTTPS traffic.

The load balancer has been configured to forward incoming requests to a target
group. When Auto Scaling launches new instances, it will automatically add those
instances to the target group.
 Application security group
The application security group was provided as part of the lab setup. You will now
configure it to only accept incoming traffic from the load balancer.

67. In the left navigation pane, choose Security Groups.

68. Select Inventory-App.

69. In the lower half of the page, choose the Inbound rules tab.

The security group is currently empty. You will now add a rule to accept
incoming HTTP traffic from the load balancer. You do not need to configure
HTTPS traffic because the load balancer was configured to forward HTTPS
requests via HTTP. This practice offloads security to the load balancer, reducing
the amount of work that is required by the individual application servers.

70. Choose Edit inbound rules.

71. On the Edit inbound rules page, choose Add rule and configure these settings:
● Type: HTTP

● Source:
o Choose the search box to the right of Custom
o Delete the current contents
o Enter sg
o From the list that appears, select Inventory-LB
● Description: Traffic from load balancer

● Choose Save rules

The application servers can now receive traffic from the load balancer. This
includes health checks that the load balancer performs automatically.
 Database security group
You will now configure the database security group to only accept incoming traffic
from the application servers.

72.In the Security groups list, choose Inventory-DB (and make sure that no other
security groups are selected).

The existing rule permits traffic on port 3306 (used by MySQL) from any IP
address within the VPC. This is a good rule, but security can be restricted further.

73.In the Inbound rules tab, choose Edit inbound rules and configure these
settings:
o Delete the existing rule.
o Choose Add rule.
o For Type, choose MYSQL/Aurora
o Choose the search box to the right of Custom
o Enter sg
o From the list that appears, select Inventory-App
o Description: Traffic from application servers
o Choose Save rules
You have now configured three-tier security. Each element in the tier only accepts
traffic from the tier above.

In addition, the use of private subnets means that you have two security barriers
between the internet and your application resources. This architecture follows
the best practice of applying multiple layers of security.

Task 5: Testing the application

Your application is now ready for testing.

In this task, you will confirm that your web application is running. You will also
test that it is highly available.

74.In the left navigation pane, choose Target Groups.

The Inventory-App group of instances will be displayed.

75.Select Inventory-app.

75.In the lower half of the page, choose the Targets tab.

This tab should show two registered targets. The Status column shows the results
of the load balancer health check that is performed against the instances.

76.In the Registered targets area, occasionally choose the refresh icon until the
Status for both instances appears as healthy.

If the status does not eventually change to healthy, ask your educator for help
with diagnosing the configuration.

You will test the application by connecting to the load balancer, which will then
send your request to one of the EC2 instances. You will first need to retrieve the
Domain Name System (DNS) name of the load balancer.

77. In the left navigation pane, choose Load Balancers.

78.In the Description tab in the lower half of the window, copy the DNS name to
your clipboard.

It should be similar to: inventory-LB-xxxx.elb.amazonaws.com

79.Open a new web browser tab, paste the DNS name from your clipboard and
press ENTER.

The load balancer forwarded your request to one of the EC2 instances. The
instance ID and Availability Zone are shown at the bottom of the webpage.

80.Reload the page in your web browser. You should notice that the instance ID
and Availability Zone sometimes change between the two instances.

When this web application displays, the flow of information is:

●

You sent the request to the load balancer, which resides in the public subnets that
are connected to the internet.
● The load balancer chose one of the EC2 instances that reside in the private
subnets and forwarded the request to it.
● The EC2 instance then returned the webpage to the load balancer, which
returned it to your web browser.

Task 6: Testing high availability

Your application was configured to be highly available. You can prove the
application's high availability by terminating one of the EC2 instances.

81.Return to the Amazon EC2 console tab in your web browser (but do not close
the web application tab—you will return to it soon).

82.In the left navigation pane, choose Instances.

You will now terminate one of the web application instances to simulate a
failure.

83.Select one of the Inventory-App instances (it does not matter which one you
select).

84.Choose Instance State > Terminate instance.

 
85.Choose Terminate.

In a short time, the load balancer health checks will notice that the instance is
not responding. The load balancer will automatically route all requests to the
remaining instance.

86.Return to the web application tab in your web browser and reload the page
several times.

You should notice that the Availability Zone that is shown at the bottom of the
page stays the same. Though an instance failed, your application remains
available.

After a few minutes, Amazon EC2 Auto Scaling will also notice the instance
failure. It was configured to keep two instances running, so Amazon EC2 Auto
Scaling will automatically launch a replacement instance.

87.Return to the Amazon EC2 console tab where you have the instances list
displayed. In the top-right area, choose the refresh icon every 30 seconds or so
until a new EC2 instance appears.

After a few minutes, the health check for the new instance should become
healthy. The load balancer will resume sending traffic between the two
Availability Zones. You can reload your web application tab to see this happen.

This task demonstrates that your application is now highly available.

Optional task 1: Making the database

highly available
This task is optional. You can work on this task if you have remaining lab time.

The application architecture is now highly available. However, the Amazon RDS
database operates from only one database instance.
 In this optional task, you will make the database highly available by configuring it

to ru n across multiple Availability Zones (that is, in a Multi-AZ deployment).

88.

On the Services menu, choose RDS.

89.In the left navigation pane, choose Databases.

90.Choose the link for the name of the inventory-db instance.

Feel free to explore the information about the database.

91.Choose Modify

 
92.Scroll down to the Availability & durability section. For Multi-AZ deployment,
select Create a standby instance.

Analysis: You only need to reconfigure this one setting to convert the database to
run across multiple data centers (Availability Zones).

This option does not mean that the database is distributed across multiple
instances. Instead, one instance is the primary instance, which handles all
requests. Another instance will be launched as the standby instance, which takes
over if the primary instance fails. Your application continues to use the same
DNS name for the database. However, the connections will automatically
redirect to the currently active database server.

You can scale an EC2 instance by changing attributes, and you can also scale an
RDS database this way. You will now scale up the database.

93.Scroll back up and for DB instance class, select db.t3.small.

This action doubles the size of the instance.

94.For Allocated storage, enter: 10

This action doubles the amount of space that is allocated to the database.

Feel free to explore the other options on the page, but do not change any other
settings.

95.At the bottom of the page, choose Continue

Database performance will be impacted by these changes. Therefore, these

changes can be scheduled during a defined maintenance window, or they can be
run immediately.

96.Under Scheduling of Modifications, select Apply immediately.

 
97.Choose Modify DB instance

The database enters a modifying state while it applies the changes. You do not
need to wait for it to complete.

Optional task 2: Configuring a highly

available NAT gateway
This task is optional. You can work on this task if you have remaining lab time.

The application servers run in a private subnet. If the servers must access the
internet (for example, to download data), the requests must be redirected
through a Network Address Translation (NAT) gateway. (The NAT gateway must be
located in a public subnet).

The current architecture has only one NAT gateway in Public Subnet 1. Thus, if
Availability Zone 1 fails, the application servers will not be able to communicate
with the internet.

In this optional task, you will make the NAT gateway highly available by
launching another NAT gateway in the other Availability Zone. The resulting
architecture will be highly available:
98.

On the Services menu, choose VPC.

99.In the left navigation pane, choose NAT Gateways.

The existing NAT gateway displays. You will now create a NAT gateway for the
other Availability Zone.

100. Choose Create NAT gateway and configure these settings:

o Subnet: Public Subnet 2
o Choose Allocate Elastic IP
o Choose Create NAT gateway

You will now create a new route table for Private Subnet 2. This route table will
redirect traffic to the new NAT gateway.

101. In the left navigation pane, choose Route Tables.

  

102. Choose Create route table and configure these settings:

o Name: Private Route Table 2
o VPC: Lab VPC
o Choose Create route table.

103. Observe the settings in the Routes tab.

Currently, one route directs all traffic locally. You will now add a route to send
internet-bound traffic through the new NAT gateway.

104. Choose Edit routes and then configure these settings:

o Choose Add route
o Destination: 0.0.0.0/0
o Target: Select NAT Gateway, then select the nat- entry that is not the entry for
NATGateway1 (which is under the Details button above these instructions)
o Choose Save changes

The NAT gateway that is listed under the Details button (which is above these
instructions) is for Public Subnet 1. You are configuring this route table to use the
other NAT gateway.

105. Choose the Subnet Associations tab.

106. Choose Edit subnet associations

107. Select Private Subnet 2.

108. Choose Save associations

This action now sends internet-bound traffic from Private Subnet 2 to the NAT
gateway that is in the same Availability Zone.
 Your NAT gateways are now highly available. A failure in one Availability Zone
will not impact traffic in the other Availability Zone.

Submitting your work

109. At the top of these instructions, choose Submit to record your progress
and when prompted, choose Yes.

110. If the results don't display after a couple of minutes, return to the top of
these instructions and choose Grades

Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.

111. To find detailed feedback on your work, choose Details followed by View
Submission Report.

Lab complete 
Congratulations! You have completed the lab.

112. Choose End Lab at the top of this page, and then select Yes to confirm that
you want to end the lab.

A panel indicates that DELETE has been initiated... You may close this message box
now.

113. Select the X in the top right corner to close the panel.
 EX 8: Automating Infrastructure
Deployment with AWS
CloudFormation
Lab overview and objectives
Deploying infrastructure in a consistent, reliable manner is difficult. It requires
people to follow documented procedures without taking any undocumented
shortcuts. It can also be difficult to deploy infrastructure out-of-hours when
fewer staff are available. AWS CloudFormation changes this situation by defining
infrastructure in a template that can be automatically deployed—even on an
automated schedule.

In this lab, you will learn how to deploy multiple layers of infrastructure with
AWS CloudFormation, update a CloudFormation stack, and delete a stack (while
retaining some resources).

After completing this lab, you should be able to:

● Use AWS CloudFormation to deploy a virtual private cloud (VPC) networking layer
● Use AWS CloudFormation to deploy an application layer that references the networking
layer
● Explore templates with AWS CloudFormation Designer
● Delete a stack that has a deletion policy

Duration
This lab will require approximately 20 minutes to complete.

AWS service restrictions

In this lab environment, access to AWS services and service actions might be
restricted to the ones that are needed to complete the lab instructions. You
might encounter errors if you attempt to access other services or perform
actions beyond the ones that are described in this lab.
 Accessing the AWS Management Console
1. At the top of these instructions, choose Start Lab to launch your lab.

A Start Lab panel opens, and it displays the lab status.

 Tip: If you need more time to complete the lab, restart the timer for the
environment by choosing the Start Lab button again.

2. Wait until the Start Lab panel displays the message Lab status: ready, then close
the panel by choosing the X.

3. At the top of these instructions, choose AWS.

This action opens the AWS Management Console in a new browser tab. The
system automatically logs you in.

 Tip: If a new browser tab does not open, a banner or icon is usually at the top of
your browser with the message that your browser is preventing the site from
opening pop-up windows. Choose the banner or icon, and then choose Allow
pop-ups.

4. Arrange the AWS Management Console tab so that it displays alongside these

instructions. Ideally, you will have both browser tabs open at the same time so
that you can follow the lab steps more easily.

 Do not change the Region unless specifically instructed to do so.

Task 1: Deploying a networking layer

It is a best practice to deploy infrastructure in layers. Common layers are:

● Network (Amazon VPC)

● Database
● Application

This way, templates can be reused between systems. For example, you can
deploy a common network topology between development, test, and production
environments, or deploy a standard database for multiple applications.

In this task, you will deploy an AWS CloudFormation template that creates
a networking layer by using Amazon VPC.
5. Right-click the following link and download the template to your computer: lab-
network.yaml

 If you want, you can open the template in a text editor to see how the AWS
resources are defined.

Templates can be written in JavaScript Object Notation (JSON) or YAML Ain't

Markup Language (YAML). YAML is a markup language that is similar to JSON,
but it is easier to read and edit.

6. In the AWS Management Console, from the Services menu,

choose CloudFormation.

7. If you see this message, click Try it out now and provide us feedback:

8. Choose Create stack and configure these settings.

Step 1: Specify template

o Template source:  Upload a template file
o Upload a template file: Click Choose file then select the lab-network.yaml file that
you downloaded.
o Choose Next
Step 2: Create Stack
o Stack name: lab-network
o Choose Next
Step 3: Configure stack options

o In the Tags section, enter these values.

▪ Key: application
▪ Value: inventory
o Choose Next

Step 4: Review lab-network

o Choose Create stack
The template will now be used by AWS CloudFormation to generate a stack of
resources in the AWS account.

The specified tags are automatically propagated to the resources that are

created, which makes it easier to identify resources that are used by particular
applications.

9. Choose the Stack info tab.

10.Wait for the Status to change to CREATE_COMPLETE.

  Choose Refresh  every 15 seconds to update the display, if necessary.

You can now examine the resources that were created.

11.Choose the Resources tab.

You will see a list of the resources that were created by the template.

 If the list is empty, update the list by choosing Refresh .

12.Choose the Events tab and scroll through the events log.

The events log shows (from more recent to less recent) the activities that were
performed by AWS CloudFormation. Example events include starting to create a
resource and then completing the resource creation. Any errors that were
encountered during the creation of the stack will be listed in this tab.

13.Choose the Outputs tab.

A CloudFormation stack can provide output information, such as the ID of specific

resources and links to resources.

Two outputs are listed.

o PublicSubnet: The ID of the public subnet that was created (for example: _subnet-
08aafd57f745035f1__
o VPC: The ID of the VPC that was created (for example: vpc-08e2b7d1272ee9fb4)
Outputs can also be used to provide values to other stacks. This is shown in
the Export name column. In this case, the VPC and subnet IDs are given export
names so that other stacks can retrieve the values. These other stacks can then
build resources inside the VPC and subnet that were just created. You will use
these values in the next task.

14.Choose the Template tab.

This tab shows the template that was used to create the stack—that is, the
template that you uploaded while you created the stack. Feel free to examine
the template and see the resources that were created. Also feel free to explore
the Outputs section at the end (this section defined which values to export).

Task 2: Deploying an application layer

Now that you deployed the network layer, you will deploy an application layer that
contains an Amazon Elastic Compute Cloud (Amazon EC2) instance and a
security group.
 The AWS CloudFormation template will import the VPC and subnet IDs from
the Outputs of the existing CloudFormation stack. It will then use this
information to create the security group in the VPC and the EC2 instance in the
subnet.

15.Right-click the following link and download the template to your computer: lab-
application.yaml

 If you want, you can open the template in a text editor to see how resources are
defined.

16.In the left navigation pane, choose Stacks.

17.Select Create stack > With new resources (standard), and then configure
these settings.

Step 1: Specify template

o Template source:  Upload a template file
o Upload a template file: Click Choose file then select the lab-application.yaml file that
you downloaded.
o Choose Next
Step 2: Create Stack
o Stack name: lab-application
o NetworkStackName: lab-network
o Choose Next
 The Network Stack Name parameter tells the template the name of the first stack
that you created (lab-network), so it can retrieve values from the Outputs.

Step 3: Configure stack options

o In the Tags section, enter these values.

▪ Key: application
▪ Value: inventory
o Choose Next

Step 4: Review lab-application

o Choose Create stack
While the stack is being created, examine the details in the Events tab and
the Resources tab. You can monitor the progress of the resource-creation
process and the resource status.

18.In the Stack info tab, wait for the Status to change to CREATE_COMPLETE.

Your application is now ready!

19.Choose the Outputs tab.
20.Copy the URL that is displayed, open a new web browser tab, paste the URL, and
press ENTER.

The browser tab will open the application, which is running on the web server
that this new CloudFormation stack created.

A CloudFormation stack can use reference values from another CloudFormation

stack. For example, this portion of the lab-application template references
the lab-network template:

  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Enable HTTP ingress
      VpcId:
        Fn::ImportValue:
          !Sub ${NetworkStackName}-VPCID
The last line uses the network stack name that you provided (lab-network) when
the stack was created. It imports the value of lab-network-VPCID from
the Outputs of the first stack. It then inserts the value into the VPC ID field of the
security group definition. The result is that the security group is created in the
VPC that was created by the first stack.

Here is another example, which is in the CloudFormation template that you just
used to create the application stack. This template code places the EC2 instance
into the subnet that was created by the network stack:

  SubnetId:
    Fn::ImportValue:
    !Sub ${NetworkStackName}-SubnetID
It takes the subnet ID from the lab-network stack and uses it in the lab-
application stack to launch the instance into the public subnet, which was
created by the first stack.
 Task 3: Updating a Stack
AWS CloudFormation can also update a stack that has been deployed. When you
update a stack, AWS CloudFormation will only modify or replace the resources
that are being changed. Any resources that are not being changed will be left as-
is.

In this task, you will update the lab-application stack to modify a setting in the

security group.

First, you will examine the current settings for the security group.

21.In the AWS Management Console, from the Services  menu, choose EC2.

22.In the left navigation pane, choose Security Groups.

23.Select the check box for  lab-application-WebServerSecurityGroup....

24.Choose the Inbound rules tab.

Currently, only one rule is in the security group. The rule permits HTTP traffic.

You will now return to AWS CloudFormation to update the stack.

25.From the Services  menu, choose CloudFormation.

26.Right-click the following link and download the updated template to your
computer: lab-application2.yaml

This template has an additional configuration to permit inbound Secure Shell

(SSH) traffic on port 22:

  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: 0.0.0.0/0
27.In the Stacks list of the AWS CloudFormation console, select lab-application.

28.Choose Update and configure these settings.

o Select  Replace current template
o Template source:  Upload a template file
o Upload a template file: Click Choose file then select the lab-application2.yaml file
that you downloaded.
29.Choose Next in each of the next three screens to advance to the Review lab-
application page.

In the Change set preview section at the bottom of the page, AWS

CloudFormation displays the resources that will be updated:

21.Choose Update stack
22.In the Stack info tab, wait for the Status to change to UPDATE_COMPLETE.

 Update the status by choosing Refresh  every 15 seconds, if necessary.

You can now verify the change.

23.Return to the Amazon EC2 console and from the left navigation pane,

choose Security Groups.
24.In the Security Groups list, select lab-application-WebServerSecurityGroup.

The Inbound rules tab should display an additional rule that allows SSH traffic

over TCP port 22.

This subtask demonstrates how changes can be deployed in a repeatable,

documented process. The AWS CloudFormation templates can be stored in a
source code repository (such as AWS CodeCommit). This way, you can maintain
versions and a history of the templates and the infrastructure that was
deployed.

Task 4: Exploring templates with AWS

CloudFormation Designer
 AWS CloudFormation Designer is a graphic tool for creating, viewing, and
modifying AWS CloudFormation templates. With Designer, you can diagram your
template resources by using a drag-and-drop interface, and then edit their
details through the integrated JSON and YAML editor.

Whether you are a new to AWS CloudFormation or an experienced AWS

CloudFormation user, Designer can help you quickly see the interrelationship
between a template's resources. It also enables you to easily modify templates.

In this task, you will gain some hands-on experience with Designer.

34.From the Services  menu, choose CloudFormation.

35.In the left navigation pane, choose Designer.

Tip: You might need to expand the left navigation pane by choosing the menu
icon.

36.Choose the File  menu, select Open > Local file, and select the lab-

application2.yaml template that you downloaded previously.

Designer will display a graphical representation of the template:

34.Experiment with the features of the Designer. Some things to try are:
o Click the displayed resources. The lower pane will then display the portion of the
template that defines the resources.
o Try dragging a new resource—from the Resource types pane on the left—into
the design area. The definition of the resource will be automatically inserted into
the template.
o Try dragging the resource connector circles to create relationships between
resources.
o Open the lab-network.yaml template that you downloaded earlier in the lab
and also explore its resources in Designer.

Task 5: Deleting the stack

When resources are no longer required, AWS CloudFormation can delete the
resources built for the stack.

A deletion policy can also be specified against resources. It can preserve or (in

some cases) back up a resource when its stack is deleted. This feature is useful
for retaining databases, disk volumes, or any resource that might be needed
after the stack is deleted.

The lab-application stack was configured to take a snapshot of an Amazon Elastic

Block Store (Amazon EBS) disk volume before it is deleted. The code in the
template that accomplishes that configuration is:

DiskVolume:
  Type: AWS::EC2::Volume
  Properties:
    Size: 100
    AvailabilityZone: !GetAtt WebServerInstance.AvailabilityZone
    Tags:
      - Key: Name
        Value: Web Data
  DeletionPolicy: Snapshot

The DeletionPolicy in the final line directs AWS CloudFormation to create a

snapshot of the disk volume before it is deleted.
 You will now delete the lab-application stack and see the results of this deletion
policy.

38.Return to the main AWS CloudFormation console by choosing the Close link at

the top of the Designer page (choose Leave page if prompted).
39.In the list of stacks, choose the lab-application link.
40.Choose Delete
41.Choose Delete stack

You can monitor the deletion process in the Events tab and update the screen
by choosing Refresh  occasionally. You might also see an events log entry that
indicates that the EBS snapshot is being created.

42.Wait for the stack to be deleted. It will disappear from the stacks list.

The application stack __ removed, but the network stack remained untouched.
This scenario reinforces the idea that different teams (for example, the network
team or the application team) could manage their own stacks.

You will now verify that a snapshot of the EBS volume was created before the
EBS volume was deleted.

43.From the Services  menu, choose EC2.

44.In the left navigation pane, choose Snapshots.

You should see a snapshot with a Started time in the last few minutes.

Submitting your work

45.At the top of these instructions, choose Submit to record your progress and
when prompted, choose Yes.
46.If the results don't display after a couple of minutes, return to the top of these
instructions and choose Grades

Tip: You can submit your work multiple times. After you change your work,
choose Submit again. Your last submission is what will be recorded for this lab.
47.To find detailed feedback on your work, choose Details followed by  View
Submission Report.

Lab complete 
 Congratulations! You have completed the lab.

48.Choose End Lab at the top of this page, and then select Yes to confirm that you
want to end the lab.

A panel indicates that DELETE has been initiated... You may close this message box
now.

49.Select the X in the top right corner to close the panel.