Please read this disclaimer before

proceeding:
This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document through
email in error, please notify the system manager. This document contains
proprietary information and is intended only to the respective group / learning
community as intended. If you are not the addressee you should not disseminate,
distribute or copy through e-mail. Please notify the sender immediately by e-mail
if you have received this document by mistake and delete this document from your
system. If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this
information is strictly prohibited.
 22CS908

CLOUD ARCHITECTING

Department : CSE

Batch/Year : 2022-2026 / III Year

Created by:

Ms. A. Jasmine Gilda, Assistant Professor / CSE

Date : 15.08.2024
 1. CONTENTS

S. No. Contents

1 Contents

2 Course Objectives

3 Pre-Requisites

4 Syllabus

5 Course outcomes

6 CO- PO/PSO Mapping

7 Lecture Plan

8 Activity based learning

9 Lecture Notes

10 Assignments

11 Part A Questions & Answers

12 Part B Questions

13 Online Certifications

14 Real Time Applications

15 Assessment Schedule

16 Text Books & Reference Books

17 Mini Project suggestions

 2. COURSE OBJECTIVES
▪ To make architectural decisions based on AWS architectural principles
and best practices.
▪ To describe the features and benefits of Amazon EC2 instances, and
compare and contrast managed and unmanaged database services.
▪ To create a secure and scalable AWS network environment with VPC,
and configure IAM for improved security and efficiency.
▪ To use AWS services to make infrastructure scalable, reliable, and
highly available.
▪ To use AWS managed services to enable greater flexibility and
resiliency in an infrastructure.
 3. PRE REQUISITES

• Pre-requisite Chart

20CS908 – CLOUD ARCHITECTING

20CS907 – CLOUD FOUNDATIONS

 4. SYLLABUS
CLOUD ARCHITECTING L T P C
22CS908
2 0 2 3
UNIT I INTRODUCING CLOUD ARCHITECTING AND STORAGE LAYER 6 + 6
Cloud architecting - The AWS Well-Architected Framework - AWS global infrastructure -
Amazon S3 - Amazon S3 Versioning - Storing data in Amazon S3 - Moving data to and from
Amazon S3 - Amazon S3 Transfer Acceleration - Choosing Regions for your architecture.
List of Exercise/Experiments:
1. Creating a Static Website for the Café.
2. Configure an S3 bucket to automatically encrypt all uploaded objects.
3. Set up a cross-region replication configuration for an S3 bucket.
UNIT II COMPUTE LAYER AND DATABASE LAYER 6+6
Adding compute with Amazon EC2 - Choosing an Amazon Machine Image (AMI) to launch
an Amazon EC2 instance - Selecting an Amazon EC2 instance type - Using user data to
configure an EC2 instance - Adding storage to an Amazon EC2 instance - Amazon EC2 pricing
options - Amazon EC2 considerations - Database layer considerations - Amazon Relational
Database Service (Amazon RDS) - Amazon DynamoDB - Database security controls -
Migrating data into AWS databases.
List of Exercise/Experiments:
1. Creating a Dynamic Website for the Café.
2. Creating an Amazon RDS database.
3. Migrating a Database to Amazon RDS.
4. Create a web application that stores data in a managed database using EC2 instances
and Amazon RDS.
UNIT III CREATING AND CONNECTING NETWORKS 6+6
Creating an AWS networking environment - Connecting your AWS networking environment
to the internet - Securing your AWS networking environment - Connecting your remote
network with AWS Site-to-Site VPN - Connecting your remote network with AWS Direct
Connect - Connecting virtual private clouds (VPCs) in AWS with VPC peering - Scaling your
VPC network with AWS Transit Gateway - AWS Transit Gateway - Connecting your VPC to
supported AWS services. Securing User and Application Access: Account users and AWS
Identity and Access Management (IAM) - Organizing users - Federating users - Multiple
accounts.
List of Exercise/Experiments:
1. Creating a Virtual Private Cloud.
2. Creating a VPC Networking Environment for the Café.
3. Creating a VPC Peering Connection.
4. Configure a VPC with subnets, an internet gateway, route tables, and a
security group, and connect an on-premises network to the VPC.
UNIT IV RESILIENT CLOUD ARCHITECTURE 6+6
Scaling your compute resources - Scaling your databases - Designing an environment that’s
highly available – Monitoring - Reasons to automate - Automating your infrastructure -
Automating deployments - AWS Elastic Beanstalk - Overview of caching - Edge caching -
Caching web sessions - Caching databases.

List of Exercise/Experiments:
1. Controlling Account Access by Using IAM.
2. Creating Scaling Policies for Amazon EC2 Auto Scaling.
3. Creating a Highly Available Web Application.
4. Creating a Scalable and Highly Available Environment for the Café.
5. Streaming Dynamic Content Using Amazon CloudFront.

UNIT V BUILDING DECOUPLED ARCHITECTURES, MICROSERVICES 6 + 6

AND SERVERLESS ARCHITECTURE
Decoupling your architecture - Decoupling with Amazon Simple Queue Service (Amazon SQS)
- Decoupling with Amazon Simple Notification Service (Amazon SNS) - Sending messages
between cloud applications and on-premises with Amazon MQ. Introducing microservices -
Building microservice applications with AWS container services - Introducing serverless
architectures - Building serverless architectures with AWS Lambda - Extending serverless
architectures with Amazon API Gateway - Orchestrating microservices with AWS Step
Functions - Disaster planning strategies - Disaster recover patterns.

List of Exercise/Experiments:
1. Breaking a Monolithic Node.js Application into Microservices.
2. Implementing a Serverless Architecture on AWS.
3. Implementing a Serverless Architecture for the Café.
4. Creating an AWS Lambda Function and explore using AWS Lambda with Amazon S3.

TOTAL: 60 PERIODS
 5. COURSE OUTCOME

At the end of this course, the students will be able to:

CO1: Explain cloud architecture principles and AWS storage solutions.

CO2: Deploy and manage AWS compute and database resources

securely.
CO3: Design and configure secure AWS networks using VPC and IAM.

CO4: Implement scalable and resilient AWS architectures with high

availability.
CO5: Build decoupled and serverless applications using AWS services

like Lambda.
CO6: Develop disaster recovery strategies for AWS environments.
 6. CO - PO / PSO MAPPING

PROGRAM OUTCOMES PSO

PSO-1

PSO-2

PSO-3
PO-10

PO-11

PO-12
PO-2

PO-4
PO-1

PO-3

PO-5

PO-6

PO-7

PO-8

PO-9
CO HKL

CO1 K3 2 1 - - 2 - - 3 - 2 - 2 3 2 2

CO2 K3 2 2 - - 2 - - 2 2 2 - 2 3 2 2

CO3 K3 2 2 - - 2 - - 2 2 2 - 2 3 2 2

CO4 K3 2 2 3 - 2 - - 2 2 2 - 2 3 3 2

CO5 K3 2 2 3 - 2 - - - 2 2 - 2 3 3 3

C06 K3 2 2 3 - 2 - - - 2 2 - 2 3 3 3

Correlation Level:
1. Slight (Low)
2. Moderate (Medium)
3. Substantial (High)
If there is no correlation, put “-“.
 7. LECTURE PLAN

Number Actual
S. Proposed Taxonomy Mode of
Topic of Lecture CO
No. Date Level Delivery
Periods Date

Creating an AWS
networking
environment -
1 Connecting your 1 CO3 K3 PPT/
AWS networking Demo
environment to the
internet -
Securing your AWS
networking
environment - PPT/
2 1 CO3 K3
Connecting your Demo
remote network with
AWS Site-to-Site VPN
Connecting your
remote network with
AWS Direct Connect -
PPT/
3 Connecting virtual 1 CO3 K3
private clouds (VPCs)
Demo
in AWS with VPC
peering
Scaling your VPC
network with AWS
Transit Gateway -
AWS Transit PPT/
4 1 CO3 K2
Gateway - Demo
Connecting your VPC
to supported AWS
services.
Securing User and
Application Access:
Account users and
5 AWS Identity and
1 CO3 K2 PPT/
Access Management Demo
(IAM)
Organizing users -
6 Federating users - 1 CO3 K2 PPT/
Multiple accounts. Demo
 8. ACTIVITY BASED LEARNING

You are designing a scalable and secure AWS networking environment for a company. The setup must
include multiple VPCs, internet connectivity, and secure connections with on-premises resources.
Additionally, the environment should support resource sharing and integrate with AWS services.

Requirements:

1. Design the VPC Network:

o Create a VPC with public and private subnets.
o Define CIDR ranges, subnets, and security groups.
o Explain how you will implement and secure the subnet setup.
2. Internet Connectivity:
o Outline steps to create a public subnet and enable internet access.
o Describe how to manage traffic and remap IP addresses.
3. Site-to-Site VPN and Direct Connect:
o Explain the configuration for AWS Site-to-Site VPN and AWS Direct Connect.
o Include steps for static and dynamic routing.
4. VPC Peering and Transit Gateway:
o Describe how to set up VPC peering and AWS Transit Gateway.
o Discuss scalability and VPC isolation considerations.
5. VPC Endpoints:
o Detail the setup of VPC endpoints for AWS services.
o Provide an example of the benefits.
6. IAM and Security:
o Explain how to use IAM for secure access and permissions management.
o Include examples of roles, policies, and best practices such as tagging and ABAC.
Deliverable:

Submit a network architecture diagram and a step-by-step configuration guide. Be ready to discuss your
design choices and how they meet the requirements for scalability, security, and efficient management.
 9. UNIT III - LECTURE NOTES

CREATING AN AWS NETWORKING ENVIRONMENT:

Amazon VPC:
Amazon Virtual Private Cloud (Amazon VPC) allows you to create a logically isolated virtual network
on AWS, similar to your own data center, but with the scalability and flexibility of AWS infrastructure.
Key Features:
• Virtual Private Clouds (VPCs): These are isolated networks where you can launch AWS
resources.
• Subnets: Subdivide your VPC into smaller ranges of IP addresses, with each subnet limited to a
single Availability Zone.
• IP Addressing: Assign IPv4 and IPv6 addresses to your resources. You can also bring your own
public IPs to AWS.
• Routing: Manage network traffic with route tables to direct traffic within your VPC and beyond.
• Gateways & Endpoints: Use an internet gateway to connect to the internet, or VPC endpoints
for private connections to AWS services.
• Peering Connections: Enable communication between two VPCs.
• Traffic Mirroring: Copy and send network traffic for security analysis and monitoring.
• Transit Gateways: Act as a central hub to route traffic between multiple VPCs, VPNs, and AWS
Direct Connect.
• VPC Flow Logs: Record IP traffic data to monitor and analyze network activity.
• VPN Connections: Connect your VPC to your on-premises network securely through AWS VPN.
This setup provides flexible connectivity options for your applications while maintaining a high level of
control over your network.
Pricing for Amazon VPC:
Using a VPC is free, but some components incur charges, such as NAT gateways, IP Address Manager,
traffic mirroring, Reachability Analyzer, and Network Access Analyzer.
Public IPv4 Address Pricing:
• Resources that need internet access use public IPv4 addresses, which are chargeable.
• Private IPv4 addresses (used for internal communication) are free.
Types of Public IPv4 Addresses:
1. Elastic IP (EIP): Static public IPs you can assign to AWS resources.
2. EC2 Public IPv4: Automatically assigned to EC2 instances in certain subnets.
3. BYOIPv4: Public IP addresses you bring to AWS from your own range.
4. Service-managed IPv4: Automatically assigned to resources by AWS services (e.g., RDS, ECS).
How Amazon VPC Works:
Amazon Virtual Private Cloud (VPC) lets you create a virtual network on AWS, similar to a traditional
network in your own data center, but with the scalability of AWS infrastructure.
In a VPC, you can define an IP address range, add subnets (smaller IP ranges in specific Availability
Zones), set up route tables, and connect to the internet or other networks through gateways.
Key Concepts:
• VPC: A virtual network isolated from others in the AWS Cloud.
• Subnets: IP address ranges in your VPC, where you can launch AWS resources (like EC2
instances).
• Route Tables: Direct network traffic within and outside the VPC.
• Internet Gateway: Connects instances with public IPs to the internet.
• Private IPs: Instances with private IPs can communicate within the VPC but not with the internet
unless a NAT gateway or an Elastic IP is used.
Default vs. Nondefault VPC:
• Default VPC: Comes pre-configured with subnets and an internet gateway. EC2 instances
launched here automatically have internet access.
• Nondefault VPC: Custom VPCs where you configure subnets, IPs, and gateways manually.
Internet Access:
• Public IP addresses allow internet access through an internet gateway.
• Private IPs can access the internet using a NAT device, which handles outbound traffic while
blocking inbound traffic.
Connecting to Other Networks:
• Site-to-Site VPN: Connects your VPC to your on-premises data center.
• VPC Peering: Privately connects two VPCs.
• Transit Gateway: Acts as a hub to connect multiple VPCs and on-premises networks.
AWS Private Global Network:
• AWS uses a secure, low-latency global network backbone to handle traffic within and across
Regions for optimal performance.
VPC deployment:
A VPC (Virtual Private Cloud) is limited to a single AWS Region, meaning all of its resources are contained
within that Region. However, the VPC spans across all Availability Zones (AZs) within that Region.
This allows you to deploy AWS resources, such as EC2 instances, in any AZ within the same Region under
a single VPC. Each AZ is an isolated data center within a Region, and spanning a VPC across multiple AZs
provides high availability and fault tolerance. For instance, you can deploy instances in different AZs
within the same VPC, ensuring that if one AZ faces issues, resources in other AZs remain unaffected.

Classless Inter-Domain Routing (CIDR):

VPC CIDR Blocks:
In an Amazon VPC (Virtual Private Cloud), the IP address range is specified using Classless Inter-
Domain Routing (CIDR) notation. Each VPC must be associated with an IPv4 CIDR block, and
additional IPv4 or IPv6 CIDR blocks can be optionally added as needed.
IPv4 CIDR Blocks
• Initial Block: When a VPC is created, an IPv4 CIDR block must be specified. The block size must
fall between a /16 netmask (allowing for 65,536 IP addresses) and a /28 netmask (allowing for 16
IP addresses).
• Private IP Address Range: It is recommended to choose from private IP address ranges defined
by RFC 1918.
 • Adding Additional CIDR Blocks: After a VPC is created, it is possible to associate more IPv4
CIDR blocks. The following rules apply:
o The block size must be within the /16 to /28 range.
o The new CIDR block must not overlap with any existing CIDR blocks within the VPC.
o It is not possible to increase or decrease the size of an existing CIDR block once it is
assigned.
o There is a limit to how many CIDR blocks can be associated with a VPC, depending on AWS
quotas.
When new CIDR blocks are added, routes are automatically created in the VPC route tables to enable
routing between the different address ranges. For example, if a VPC has both a primary and secondary
CIDR block, subnets can use addresses from either, and routing between them is handled internally.

IPv6 CIDR Blocks

• Adding IPv6 CIDR Blocks: For IPv6, it is possible to associate up to five CIDR blocks, ranging
from /44 to /60, with a VPC. IPv6 CIDR blocks are allocated from Amazon’s pool of addresses, and
the specific range cannot be chosen manually.
 • Once associated, the IPv6 CIDR block can be used for creating subnets, and it can later be
disassociated from the VPC if no longer required. However, if the CIDR block is removed and an
IPv6 block is re-associated in the future, the same IP range cannot be guaranteed.
Subnets: Dividing your VPC:
A subnet is a segment of a VPC's IP address range where resources can be allocated. While subnets
divide the VPC, they are not used as isolation boundaries. Subnets are subsets of the VPC’s CIDR block,
and their CIDR blocks must not overlap.
Key points about subnets:
• Each subnet is limited to one Availability Zone and cannot span across zones.
• Multiple subnets can be created in the same Availability Zone or in a Local Zone.
• AWS automatically reserves five IP addresses in each subnet. These include:
o The network address (e.g., 10.0.0.0).
o The VPC router (e.g., 10.0.0.1).
o The DNS server (e.g., 10.0.0.2).
o One address for future use (e.g., 10.0.0.3).
o The broadcast address (e.g., 10.0.0.255), though broadcasts are not supported in a VPC.
Subnet CIDR Blocks
The subnet’s IP addresses are specified using Classless Inter-Domain Routing (CIDR) notation, and
each subnet's CIDR block must be a subset of the VPC’s CIDR block. For example, a VPC with a
10.0.0.0/24 CIDR block can be divided into two subnets:
• Subnet 1: 10.0.0.0/25 (128 IP addresses, 10.0.0.0 to 10.0.0.127).
• Subnet 2: 10.0.0.128/25 (128 IP addresses, 10.0.0.128 to 10.0.0.255).
The IPv4 CIDR block size for a subnet can range between /28 (16 IP addresses) and /16 (65,536 IP
addresses).
Subnet Sizing for IPv6
If an IPv6 CIDR block is associated with the VPC, IPv6 subnets can also be created. The allowed netmask
size ranges from /44 to /64. Just like IPv4 subnets, AWS reserves five IP addresses in each IPv6 subnet
for networking purposes.
Tools such as subnet calculators can assist in determining appropriate subnet sizes based on the
desired IP range.

Example: A VPC with CIDR /22 includes 1,024 total IP addresses.

VPC design best practices:
When designing a VPC, the following guidelines should be considered:
• Create one subnet per Availability Zone for groups of hosts with unique routing needs.
• Divide the VPC network range evenly across all Availability Zones within the region.
• Avoid allocating the entire network address space immediately; reserve some addresses for future
growth.
• Size the VPC CIDR block and subnets to accommodate expected growth in workloads.
• Ensure that the VPC's CIDR block does not overlap with any other private network ranges within
the organization.
Single VPC deployment:
A single VPC may be suitable for specific cases, such as:
• Small, single applications managed by a small team.
• High-performance computing (HPC) environments, where lower latency is crucial (e.g., physics
simulations).
• Identity management environments, where a single VPC enhances security.
Multiple VPCs:
A multiple VPC setup is ideal for:
• Single teams or organizations (e.g., managed service providers) that need full control over
resources in each environment.
• Small teams, making it easier to enforce standards and manage access across Development, Test,
and Production environments.
Exception: When strict governance or compliance standards demand greater workload isolation, even in
simpler organizational structures, more isolated environments may be required.

Multiple accounts:
A multiple account setup is best for:
 • Large organizations or those with multiple IT teams.
• Medium-sized organizations expecting rapid growth.
Why?
Managing access and maintaining standards becomes more complex as organizations grow.
This pattern works well when applications are managed by different teams. For example, developers may
have full access to Development resources but restricted or no access to Production resources.
Multiple accounts provide better isolation and easier management in larger, more complex environments.

Amazon VPC quotas:

AWS limits each account to 5 VPCs per Region by default. This means you can have up to 5 separate
VPCs in any single AWS Region.
• Each AWS account starts with a limit of 5 VPCs per Region.
• If more than 5 VPCs are needed in a Region, a request for a quota increase can be made through
the AWS Management Console.
• Go to the AWS Service Quotas dashboard in the AWS Management Console and submit a request
for the number of VPCs you need.
• Efficient management and planning can help ensure that the VPC quota meets your needs and
that requests for more VPCs are justified.

CONNECTING YOUR AWS NETWORKING ENVIRONMENT TO THE INTERNET:

Creating a Public Subnet:
• Allows resources in your VPC to communicate with the internet.
• Public subnets are designed to be horizontally scaled, redundant, and highly available.
• They use an internet gateway to route traffic to and from the internet.
Steps to Create a Public Subnet:
1. Create an Internet Gateway (IGW): This component lets your VPC resources connect to the
internet.
 2. Attach the IGW to Your VPC: Connect the gateway to your VPC.
3. Update Route Tables: Configure the route tables for your public subnet to use the IGW, so traffic
can flow to and from the internet.
Key Points:
• Internet Gateway: It handles IPv4 and IPv6 traffic and provides network address translation (NAT)
for public IP addresses in your VPC.
• Public Subnet Setup: Ensure your subnet is associated with a route table that directs internet-
bound traffic to the IGW.

Directing traffic between VPC resources:

Route Tables:
• Direct traffic within your VPC and to external destinations.
• Types:
o Main Route Table: Automatically created with your VPC. Initially, it has only a local route
that allows communication within the VPC.
o Custom Route Tables: Can be created for more control over traffic routing.
How It Works:
1. Create Route Tables: Each VPC comes with a main route table. You can also create custom
route tables for specific routing needs.
 2. Associate Subnets: Every subnet must be associated with a route table. By default, subnets use
the main route table unless a different one is specified.
3. Configure Routes: To enable internet access, update the route table with a rule directing traffic
to the internet gateway. Use the destination 0.0.0.0/0 and set the target to your internet gateway
(IGW) ID.
Best Practice:
• Custom Route Tables: Create and use custom route tables for each subnet to manage traffic
routing more precisely.
Example:
• To connect a public subnet to the internet, add a route to the route table of that subnet:
o Destination: 0.0.0.0/0
o Target: <igw-id> (your internet gateway ID)

Remapping an IP address from one instance to another:

Elastic IP Addresses:
• Static, public IPv4 addresses linked to your AWS account.
 • Can be assigned to either an instance or an elastic network interface.
• You can easily move an Elastic IP from one instance to another within your account.
• Provides redundancy when load balancers are not available.
How It Works: Elastic IP addresses allow you to keep a constant public IP, even if your instance changes.
For instance, if an instance fails, you can quickly remap the Elastic IP to another instance, ensuring
continuous service.
Benefits:
• Direct Association: Attach the Elastic IP directly to an instance for public access.
• Through Network Interface: It's more flexible to associate the Elastic IP with a network
interface. This allows you to easily transfer all the interface attributes (such as IP settings) from
one instance to another with minimal steps.
This approach helps maintain uptime and ensures that your resources are always reachable.

Connecting private subnets to the internet:

To allow your private network computers to access the internet, a special device called a NAT gateway
is needed. This device acts as a bridge between your private network and the public internet. It lets your
computers send information out to the internet but prevents the internet from sending information
directly to them.
To set up a NAT gateway, the following steps must be taken:
1. A public network must be chosen: Decide which public network (subnet) will be used for the
NAT gateway.
2. A public IP address must be obtained: Assign a public IP address to the NAT gateway.
3. The NAT gateway must be created: Set up the NAT gateway in the chosen public network.
4. Your private network must be updated: Change the settings of your private network's route
table so that it directs internet traffic to the NAT gateway.

Subnet Use Cases:

Private Subnets:
• Data Storage: Use private subnets for servers that store data, like databases.
• Batch Processing: Place servers that handle large tasks, like data processing, in private subnets.
• Backend Services: Servers that work behind the scenes, like application servers, should be in
private subnets.
Public Subnets:
 • Web Applications: While it's generally recommended to keep web servers (like those running
websites) in private subnets behind a load balancer, sometimes they need to be directly connected
to the internet. In these cases, they must be in a public subnet.
Load Balancers:
• Protecting Web Servers: Load balancers, which distribute traffic across multiple servers, should
be placed in public subnets to act as a shield for your web servers in private subnets.
Bastion hosts:
A bastion host is like a guarded gate to your private network. It's a special server that sits between your
private network and the public internet. Think of it as a secure checkpoint.
When you want to access your private network from outside, you connect to the bastion host first. This
is safer because it's designed to be more resistant to attacks. Once connected to the bastion host, you
can then access the servers within your private network.
Key Points:
• Security: Bastion hosts are designed to be more secure than regular servers.
• Gateway: It acts as a gateway between your private network and the public internet.
• Controlled Access: It helps manage and control who can access your private network.

SECURING YOUR AWS NETWORKING ENVIRONMENT:

Security groups:
Security groups in AWS act as stateful firewalls that control both incoming and outgoing traffic to your
resources. They work at the instance or network interface level, helping you isolate applications and
workloads.
To achieve isolation, you can place your EC2 instances inside a security group attached to your Virtual
Private Cloud (VPC). These security groups track connection details, allowing return traffic automatically.
For example, if you send a ping (ICMP request) to an instance and the security group allows it, the
response is also allowed—even if outbound rules block ICMP traffic—because it’s considered part of an
ongoing connection.
Security group rules are crucial for controlling traffic. You can restrict access based on IP address, service
port, and protocol to ensure only necessary traffic gets through.
However, not all traffic is tracked. For instance, if a rule allows all traffic via TCP or UDP from any IP
(0.0.0.0/0), the return traffic is allowed based on the rule itself, not by tracking connection details.
Default security groups:
When a security group is created, it has no inbound rules, so inbound traffic from other hosts to the
instance must be allowed by adding rules. By default, the security group includes an outbound rule that
allows all outgoing traffic, but this can be removed, and specific outbound rules can be added. If no
outbound rules are present, the instance cannot send any outgoing traffic.
Custom security groups:
• In a custom security group, only allow rules can be set, and deny rules are not allowed.
• For example, when creating a public subnet for web servers, a security group can be configured
to allow HTTP traffic to the instances.
• All rules in the security group are checked before allowing traffic to ensure only the allowed traffic
passes through.
Chaining security groups:
Chaining security groups is a common practice in cloud organizations, where each functional tier in an
application has its own security group with specific inbound rules. In a typical three-tier setup, the rules
are designed so traffic flows only between the appropriate tiers, ensuring that a security breach in one
tier doesn't compromise the entire subnet.
For example, in a three-tier web application:
• The web server group allows HTTP (port 80) or HTTPS (port 443) traffic from the internet.
• The application server group allows traffic on port 8000 (specific to the application) only from the
web server group.
• The database server group allows MySQL traffic (port 3306) only from the application server group.
• All groups allow administrative access via SSH (port 22), but only from the organization's corporate
network.
Network access control lists (network ACLs):
Network access control lists (network ACLs) provide an extra layer of security at the subnet level in a
VPC. Key points include:
• They act as stateless firewalls, meaning rules must be set for both inbound and outbound traffic.
• By default, network ACLs allow all inbound and outbound traffic, but rules can be added to allow
or deny specific traffic.
• Every subnet must be linked to a network ACL, and if not manually associated, it defaults to the
VPC’s default ACL. Multiple subnets can use the same network ACL, but each subnet can only have
one network ACL at a time.
• Unlike security groups, network ACLs don’t track connections, so return traffic must be explicitly
allowed with a rule.
Custom network ACLs:
Custom network ACLs are recommended only for specific network security needs. When a custom
network ACL is created and associated with a subnet, it initially denies all inbound and outbound traffic.
Traffic rules must be added to allow any communication.
Structure your infrastructure with multiple layers of defense:
To enhance security, it's best to implement multiple layers of defense in your infrastructure. Running
your infrastructure in a VPC allows control over which instances are exposed to the internet. Security
groups and network ACLs can be used together to protect your infrastructure at both the instance and
subnet levels. Additionally, instances should be secured with firewalls at the operating system level, along
with other security best practices.
By using both network ACLs and security groups, you create a defense-in-depth strategy. This ensures
that even if one control is misconfigured, the host remains protected from unauthorized traffic.

CONNECTING YOUR REMOTE NETWORK WITH AWS SITE-TO-SITE VPN:

AWS Site-to-Site VPN:
AWS Site-to-Site VPN is a reliable solution used to securely connect an on-premises network or branch
office to an AWS VPC. Internet Protocol Security (IPSec) is used to create encrypted VPN tunnels, with
two tunnels provided per connection for high availability. If one tunnel fails, the second ensures continued
data flow.
By default, instances in a VPC cannot communicate with on-premises networks. AWS Site-to-Site VPN
enables secure communication by creating encrypted links (VPN tunnels) between the networks. The
AWS side is configured with a virtual private gateway (or a transit gateway), while the on-premises side
uses a customer gateway.
Charges are applied per VPN connection-hour when the connection is active.
Static and dynamic routing:
AWS Site-to-Site VPN supports both static and dynamic routing, with the choice based on the customer
gateway device:
Static Routing:
• Used if the customer gateway device does not support Border Gateway Protocol (BGP).
• Routes (IP prefixes) must be manually specified for communication with the virtual private
gateway.
• Static routing supports up to 50 non-propagated routes by default, expandable to 1,000.
Dynamic Routing:
• Used when the customer gateway device supports BGP.
• BGP automatically advertises routes to the virtual private gateway, with a limit of 100 propagated
routes per route table.
• BGP also provides robust failover capabilities, ensuring traffic flows through the second VPN tunnel
if the primary tunnel fails.
Route Tables and VPN Priority:
• Route tables control the direction of network traffic in the VPC. Routes must be added for remote
networks, with the virtual private gateway as the target.
• For overlapping routes, AWS prioritizes static routes over propagated routes. For example, if both
static and propagated routes point to the same CIDR, traffic is directed to the static route first.
• BGP routes from AWS Direct Connect are prioritized over Site-to-Site VPN static or dynamic routes.
Routing Path Selection:
• Path health is prioritized, ensuring the most reliable route is chosen.
• For VPN tunnels using BGP, AWS recommends avoiding AS PATH prepending unless the device
doesn’t support asymmetric routing.
• Multi-exit discriminators (MED) are used to compare paths with the same AS PATH length, favoring
the path with the lowest MED.
High Availability:
• AWS recommends configuring both tunnels for high availability.
• Equal Cost Multipath (ECMP) is suggested for Transit Gateway VPN connections to use more
than one tunnel. ECMP is not supported for VPNs on a virtual private gateway.
IPv4 and IPv6 Traffic:
• By default, AWS Site-to-Site VPN supports IPv4 traffic inside VPN tunnels.
• Support for IPv6 traffic is available for new Site-to-Site VPN connections on a Transit Gateway,
where both IPv4 and IPv6 CIDR blocks are used within tunnels. However, IPv6 is only supported
for internal VPN addresses.
• Site-to-Site VPN on a virtual private gateway does not support IPv6, and IPv6 cannot be enabled
for existing VPN connections.
AWS recommends using BGP-capable devices for robust routing and failover mechanisms. Proper
configuration of both tunnels and route tables is essential for secure, efficient traffic management.
Connecting multiple VPNs:
• Redundant customer gateway devices can be set up to ensure high availability. Both devices
advertise the same prefix (e.g., 0.0.0.0/0) to the virtual private gateway.
• AWS uses BGP routing to choose the traffic path, automatically switching to the working gateway
if one device fails.
• Multiple VPN connections from different customer gateways to a single virtual private gateway can
be established using AWS VPN CloudHub.
• This setup provides redundancy and failover on the customer side of the VPN connection.
• AWS VPN CloudHub operates on a hub-and-spoke model, allowing multiple sites to securely access
the VPC or communicate with each other.
• Each customer gateway device advertises a site-specific prefix (e.g., 10.0.0.0/24, 10.0.1.0/24) to
the virtual private gateway.
• The virtual private gateway directs traffic to the right site and makes each site reachable to others.
• If a transit gateway is attached to the VPC, multiple Site-to-Site VPN connections to various on-
premises locations can be established.
• Traffic is routed through the transit gateway for connectivity between the VPC and on-premises
networks.
CONNECTING YOUR REMOTE NETWORK WITH AWS DIRECT CONNECT:
AWS Direct Connect (DX):
AWS Direct Connect (DX) provides a dedicated, private connection between your on-premises network
and AWS, bypassing the public internet for improved performance. It uses 802.1q VLANs to establish a
reliable and secure link. Key benefits include:
• Higher Performance: Offers more consistent network performance compared to internet-based
connections.
• Reduced Costs: Can lower data transfer costs by avoiding public internet routes.
• Increased Bandwidth: Supports high-speed connections with options for 1 Gbps and 10 Gbps
capacity.
• Secure and Private: Provides a private connection that enhances security and minimizes latency.
• Scalable: Ideal for workloads requiring high bandwidth or low-latency communication with AWS
services.
This solution is well-suited for enterprises seeking greater network stability and security for their cloud
operations.
DX use cases:
AWS Direct Connect (DX) is highly beneficial in the following scenarios:
• Hybrid Environments: DX enables seamless integration between on-premises infrastructure and
AWS, allowing applications to access both AWS services and on-premises resources, such as
databases, while leveraging AWS’s elasticity and cost-efficiency.
• Transferring Large Datasets: DX is ideal for applications that need to transfer large datasets,
such as high-performance computing (HPC). It offers a high-bandwidth, low-latency connection
that avoids internet congestion and reduces costs by using DX's lower data transfer rates.
• Network Performance Predictability: DX provides more consistent network performance,
making it suitable for real-time applications such as audio and video streaming, where predictable,
low-latency communication is crucial.
• Security and Compliance: DX supports stringent security and regulatory requirements by
providing a private, dedicated connection that bypasses the public internet, ensuring data flows
securely between on-premises data centers and AWS.
Extending on-premises network to AWS using DX:
AWS Direct Connect (DX) links your internal network to a DX location through a standard Ethernet fiber-
optic cable. One end connects to your router, while the other connects to a DX router. This setup allows
the creation of virtual interfaces for direct access to AWS services. A public virtual interface provides
access to public AWS services like Amazon S3, while a private virtual interface enables access to your
VPC.
DX allows access to any VPC or public AWS service across all Regions (except China) from supported DX
locations. If you don’t have equipment at a DX location, you can connect via an AWS Partner Network
(APN) Partner.

Enabling high availability: DX with backup VPN connection:

To achieve highly available connectivity between your data centers and AWS, combine one or more AWS
Direct Connect (DX) connections with a backup VPN connection. Here's how to set it up:
1. Primary and Backup Connections: Use a DX connection for primary connectivity and a VPN
connection as a backup. Both connections should be dynamically routed and come from different
customer devices.
2. Traffic Routing: AWS prefers traffic over the DX connection by default, so no additional AWS-
specific configuration is needed for routing. However, configure internal-route propagation for
both DX and VPN connections to ensure proper path selection by your internal systems.
3. Provider and Location Choices: Select network providers and DX locations based on your
organization's risk tolerance, budget, and connectivity needs. Multiple DX circuits and VPN tunnels
can be used for additional redundancy.
 4. High Availability: Utilize multiple DX locations and circuits for greater reliability. If you use
multiple AWS Regions, ensure DX locations are set up in at least two regions. Consider AWS
Marketplace appliances for VPN termination if needed.

Enabling high resiliency for critical workloads with DX:

To ensure a resilient and fault-tolerant network, AWS recommends connecting from multiple data centers
for physical redundancy. When designing remote connections, use redundant hardware and
telecommunications providers.
Key best practices include:
• Dynamically Routed Connections: Use active/active connections to automatically balance the
load and failover if one connection fails.
• Network Capacity: Ensure enough capacity to prevent one connection’s failure from affecting
the performance of the others.
• Multiple Locations: For critical production workloads, have connections at multiple locations to
guard against hardware or location failures.
To access any AWS Region (except China) from any Direct Connect location, use Direct Connect Gateway.
CONNECTING VIRTUAL PRIVATE CLOUDS (VPCS) IN AWS WITH VPC PEERING:
Connecting VPCs:
Isolating workloads in separate VPCs is a good practice for security and organization. However, when
data needs to be shared between VPCs, connectivity options are available.

Connectivity Options:

• Internet Access: VPCs can connect to the internet using internet gateways or NAT gateways.
For example, a VPC can use an internet gateway for direct access or a NAT gateway for private
subnet instances to reach the internet.

• VPC Peering: VPC peering connects two VPCs directly, allowing instances in different VPCs to
communicate as if they are within the same network.

• Transit Gateway: A transit gateway can connect multiple VPCs and on-premises networks,
simplifying management and scaling. It can also have VPN attachments for hybrid cloud
environments.

• AWS Direct Connect: Provides a dedicated, private connection to AWS from on-premises data
centers. It can be used in combination with a transit gateway to connect to VPCs.
These connectivity options allow you to build a flexible and integrated cloud infrastructure, facilitating
secure and efficient data transfer across your network, whether it's in the cloud or on-premises.

In the above diagram, VPC A is connected to the internet through an internet gateway, and the EC2
instance in the private subnet can connect to the internet using a NAT gateway in the public subnet. VPC
B is also connected to the internet, but through a direct internet gateway, allowing the EC2 instance in
the public subnet to access the internet.

Moreover, VPC A and VPC B are connected to each other through a VPC peering connection and a transit
gateway. The transit gateway has a VPN attachment to a data center, and VPC B has an AWS Direct
Connect connection to the same data center. This interconnectivity enables organizations to integrate
their cloud resources with on-premises infrastructure, creating a hybrid cloud environment.
VPC peering:
• Private and Direct Connection: VPC peering creates a direct, private network connection
between two VPCs. This allows resources in each VPC to communicate as if they are in the same
network.
• No Extra Infrastructure Needed: Unlike VPNs or additional network appliances, VPC peering
does not require gateways or extra hardware. This simplifies setup and reduces potential points
of failure.
• Highly Available: VPC peering provides a highly available connection without a single point of
failure or bandwidth bottleneck. Traffic remains on the AWS global network and does not traverse
the public internet, reducing security risks like DDoS attacks.
• Inter-Region Peering: You can connect VPCs across different AWS Regions, enabling resource
sharing and data replication between regions. This inter-region peering is straightforward and
cost-effective, with data transfer charged at standard rates.
• Use Cases: Ideal for secure communication between different parts of an application, sharing
resources between teams or accounts, or integrating on-premises networks with AWS.
Overall, VPC peering offers a secure, efficient way to connect VPCs, leveraging the AWS backbone for
reliable and private communication.

Establishing VPC peering:

1. Initiate the Request: The owner of the requester VPC (the local VPC) sends a peering
connection request to the owner of the target VPC (the peer VPC).
2. Accept the Request: The owner of the peer VPC must accept the peering connection request to
activate the connection.
3. Update Route Tables:
 o In the requester VPC, add a route to the route table that directs traffic destined for the peer
VPC's IP address range.
o Similarly, in the peer VPC, add a route that directs traffic destined for the requester VPC's
IP address range.
4. Configure Security Groups: Adjust the security group rules associated with your instances to
allow traffic to and from the peer VPC, ensuring the communication is not blocked.
By following these steps, you enable secure and private traffic flow between the peered VPCs.

VPC peering connection restrictions:

• Private IP Addresses: VPC peering connections use private IP addresses for communication.
• Different AWS Accounts: Peering connections can be established between VPCs in different
AWS accounts.
• No Overlapping CIDR Blocks: The CIDR blocks of the peered VPCs must not overlap.
• Single Peering Connection: You can have only one peering connection between any two VPCs.
• No Transitive Peering: Transitive peering is not supported. This means if VPC A is peered with
VPC B, and VPC B is peered with VPC C, VPC A cannot automatically connect to VPC C. Each
peering connection must be explicitly established.
These restrictions ensure secure and controlled connectivity between VPCs while preventing complex
network topologies that could lead to unexpected traffic paths.
Considerations for peering multiple VPCs:
When connecting multiple VPCs within a single AWS Region, keep these design principles in mind:
• Connect Only Essential VPCs: Peer only those VPCs that need to communicate with each other
to avoid unnecessary complexity.
 • Ensure Scalability: Choose a solution that can scale with your current and future VPC
connectivity requirements.

Example: VPC peering for shared resources:

In this example, each department VPC in a company peers with a shared Services VPC. This VPC contains
connections to Microsoft Active Directory, security scanning tools, monitoring and logging tools, and
various other capabilities. It also provides a proxy through which the department VPCs can access some
on-premises resources. VPC peering enables company applications that are in different VPCs to access
the shared Services VPC but remain isolated from each other. In this example, also notice that a VPC
peering connection was established between VPCs in different Regions.

SCALING YOUR VPC NETWORK WITH AWS TRANSIT GATEWAY:

Need to scale networks across multiple VPCs:
As your AWS environment grows, connecting and managing multiple VPCs and accounts becomes more
complex. While VPC peering allows you to link pairs of VPCs, managing numerous point-to-point
connections can become cumbersome and costly. Similarly, connecting each VPC to on-premises
networks individually can be time-consuming and challenging as the number of VPCs increases.
To address these scalability and management challenges, consider using AWS Transit Gateway. It
simplifies your network architecture by allowing you to manage connectivity centrally, making it easier
to scale and organize your VPCs as your environment expands.
AWS TRANSIT GATEWAY:
• AWS Transit Gateway connects your VPCs and on-premises networks through a single gateway.
• Fully managed, highly available, and flexible routing service.
• Functions as a central hub for network traffic between your VPCs and other networks.
• Supports connections to up to 5,000 VPCs and on-premises environments.
• Uses a hub-and-spoke model, simplifying network management and reducing operational costs.
• With a single connection to the transit gateway, networks can communicate with each other
automatically, making scaling easier.
Connecting multiple VPCs:
To connect multiple VPCs through AWS Transit Gateway, consider a scenario where you want to fully
connect three VPCs with non-overlapping IP addresses in a single AWS Region.
Step 1: Create a transit gateway
Start by creating a transit gateway through the Amazon VPC dashboard. This gateway acts as a hub,
enabling traffic flow between your VPCs and any VPN connections. Transit gateways automatically scale
based on traffic volume. Ensure your architecture and budget can support the associated costs.

Step 2: Deploy elastic network interfaces

Transit Gateway connects to VPCs using ENIs, which must be deployed in subnets. To ensure availability,
assign at least one ENI per Availability Zone for each VPC. For example, VPC 3 has a local route using
the 10.3.0.0/16 CIDR block.
Step 3: Update the VPC route table
Add a route in each VPC's route table to direct traffic destined for other VPCs to the transit gateway. In
this example, VPC 3 has a route for the 10.0.0.0/8 network that sends traffic to the transit gateway,
allowing it to reach either VPC 1 or VPC 2.

Step 4: Update the transit gateway route table

Configure the transit gateway's route table to direct traffic between the VPCs. Each route points to a
specific VPC attachment (ENI). For instance, traffic destined for the 10.1.0.0/16 network is sent to VPC
1’s attachment.
Using AWS Transit Gateway to achieve VPC isolation:
Though you can use AWS Transit Gateway to connect multiple VPCs, you can also use it to achieve
isolation in your VPC environment. In this scenario, you want to connect your VPN source to your VPC
environment. You also want to prevent your VPCs from directly connecting to each other, leaving the
VPN to decide if traffic from one VPC has to be forwarded to another.
By setting up the route table appropriately for the transit gateway, you can prevent information sharing
between the VPCs.
To implement this solution, update the route in the transit gateway route table to send all known traffic
to the VPN connection.
In this example, when traffic for any of the VPCs in the 10.0.0.0/8 network is sent from VPC 3 to the
transit gateway, the transit gateway will forward the traffic to the VPN as shown on the slide. The transit
gateway will not send the traffic to any of the other VPCs because there are no routes pointing to any of
the VPC attachments.
You now have isolated and secured VPN access to your VPC environment with no cross communication
between the VPCs.
You can create multiple transit gateway route tables for specific interactions to direct traffic, as you see
fit.
In this example, the second route table will direct inbound traffic from the VPN to one of the
corresponding VPCs attached to the transit gateway.

CONNECTING YOUR VPC TO SUPPORTED AWS SERVICES:

VPC endpoints:
VPC endpoints provide a way to connect your VPC to AWS services and other endpoint services privately,
without needing internet access or additional networking infrastructure. They offer:
• Private Connectivity: VPC endpoints allow your VPC to privately connect to AWS services and other
endpoint services using AWS PrivateLink.
• No External Internet Needed: Traffic between your VPC and the service stays within the AWS
network, removing the need for an internet gateway, NAT device, VPN, or Direct Connect.
• Secure and Scalable: VPC endpoints are horizontally scaled, redundant, and highly available,
ensuring reliable communication between your VPC and the connected service.
• No Public IP Required: Instances in your VPC don’t need public IP addresses to access services.
Two types of VPC endpoints:
There are two types of VPC endpoints that enable private connectivity between your VPC and supported
AWS services:
1. Interface Endpoint:
o It's an elastic network interface (ENI) with a private IP address.
o Acts as an entry point for traffic to services supported by AWS PrivateLink.
 o Commonly used for services like Amazon CloudWatch, Amazon EC2 API, and Elastic Load
Balancing.
2. Gateway Endpoint:
o Functions as a gateway in your route table for traffic headed to certain AWS services.
o Supported by services like Amazon S3 and Amazon DynamoDB.
o No data processing charges for gateway endpoints, but hourly charges apply as long as the
endpoint is provisioned.

How to set up an interface endpoint:

To set up an interface endpoint in Amazon VPC, follow these steps:
1. Select the Service: Choose the AWS service, endpoint service, or AWS Marketplace service you
want to connect with.
2. Choose the VPC: Select the VPC where you want to create the interface endpoint. You can
specify multiple subnets in different Availability Zones for high availability. A network interface is
created in each subnet.
3. Select a Subnet: Pick the subnet where the interface endpoint will be created. The network
interface will have a private IP address, serving as the entry point for traffic going to the selected
service.
4. Enable Private DNS (Optional): Enable private DNS for the endpoint if you want to use the
service's default DNS hostname for requests. This is useful for AWS services and Marketplace
services.
5. Assign Security Groups: Specify the security groups that will control the traffic to the interface
endpoint. If no security group is selected, the VPC’s default security group is used.
Note: Services cannot initiate requests to your VPC through the endpoint; they only respond to requests
from resources within your VPC.
Example of using VPC endpoints:
When you create an interface endpoint, it generates endpoint-specific DNS hostnames that can be used
to communicate with the service. For AWS services and AWS Marketplace Partner services, the private
DNS option (enabled by default) associates a private hosted zone with your VPC. This hosted zone
contains a record for the default DNS name of the service (e.g., kinesis.us-east-1.amazonaws.com),
which resolves to the private IP addresses of the interface endpoint in your VPC.

This setup allows your application to communicate with the service using its default DNS hostname,
without needing to change your application’s configuration. For example, in the case of Amazon Kinesis
Data Streams:

• Without Private DNS Enabled: An interface endpoint for Amazon Kinesis Data Streams is created
with an endpoint network interface in subnet 2. Instances in subnet 1 or 2 can send requests to
Kinesis using the endpoint-specific DNS hostname.

• With Private DNS Enabled: Instances in either subnet can use either the service’s default DNS
hostname or the endpoint-specific DNS hostname to communicate with Amazon Kinesis Data
Streams through the interface endpoint. This simplifies the communication process since no
changes are required for applications already using the default DNS hostname.
SECURING USER AND APPLICATION ACCESS: ACCOUNT USERS AND AWS IDENTITY AND
ACCESS MANAGEMENT (IAM):
AWS Identity and Access Management (IAM) is a service designed to securely manage access to AWS
resources. Permissions are defined to control which resources can be accessed by users. Authentication
(who can sign in) and authorization (what actions are permitted) are managed within AWS accounts,
providing the necessary framework for securing and controlling access to AWS resources.
Secure the root account:
When an AWS account is created, a root user is generated using the provided email address and
password. This root user has full access to all account resources, including billing and personal data. The
privileges of the root user cannot be restricted. Therefore, it should only be used for tasks that require
root-level permissions.
Best practices for securing the root account include:
1. Use of root user only for critical tasks: Tasks requiring root-level access should be limited.
For a list of these tasks, refer to AWS documentation.
2. Multi-factor Authentication (MFA): Enable MFA for an added layer of security. AWS supports
various MFA types, including passkeys, security keys, virtual authenticator apps, and hardware
TOTP tokens.
o Passkeys and Security Keys: Based on FIDO standards, these devices offer strong,
phishing-resistant authentication.
o Virtual Authenticator Apps: Use apps like Google Authenticator to generate TOTP codes
for secure sign-in.
o Hardware TOTP Tokens: These devices generate time-based numeric codes for
authentication.
Additional security tips:
• Review and update account settings and contact details before enabling MFA.
• In case of MFA device issues (e.g., lost or damaged), sign in using alternative authentication
methods via email or phone verification.
For regular account management, it’s recommended to create and use IAM user credentials instead of
relying on root credentials. Root user credentials should be securely stored and only accessed when
absolutely necessary.
AWS Identity and Access Management (IAM):
AWS Identity and Access Management (IAM) allows for fine-grained access control to AWS resources,
ensuring security by granting specific permissions to users and groups. By default, IAM provides no access
to resources until permissions are explicitly granted, promoting security best practices.
IAM is integrated into most AWS services, allowing centralized access control from the AWS Management
Console that applies across your entire AWS environment. You can use IAM to provide employees and
applications access to AWS services and APIs, using existing identity systems like Microsoft Active
Directory. IAM also supports multi-factor authentication (MFA), requiring users to enter a code from a
hardware or virtual MFA device, such as Google Authenticator, during login.
While IAM can create accounts with similar privileges to the root user, it's recommended to follow the
principle of least privilege. For example, if a database administrator doesn't need to provision EC2
instances, ensure their account has limited permissions accordingly. This minimizes the risk and ensures
more secure resource access.
IAM components: Review:
To effectively secure your AWS account using IAM, it’s important to understand the key components
involved:
1. IAM User: Represents a person or application that makes API calls to AWS services. Each user
has a unique name and a set of security credentials distinct from the AWS root user. These
credentials are not shared with others, and users are defined within a single AWS account.
2. IAM Group: A collection of IAM users. Groups help simplify permission management by allowing
you to assign permissions to multiple users at once, instead of configuring each user individually.
3. IAM Policy: A document that defines what actions users or groups can perform within an AWS
account. Policies outline permissions and control access to AWS resources.
4. IAM Role: A mechanism to grant temporary access to AWS resources. Roles allow users or
applications to assume certain permissions without needing long-term credentials, which enhances
security for specific tasks.
IAM permissions:
In IAM, permissions are defined through policy documents written in JSON format. These policies
determine which AWS resources and operations users are allowed to access. There are two types of
policies:
 1. Identity-based policies: Attached to an IAM principal (users, groups, or roles) to define their
access to AWS resources.
2. Resource-based policies: Attached directly to AWS resources, such as S3 buckets or IAM roles,
specifying who can access those resources.
IAM uses a principle of least privilege, meaning permissions should only allow the minimum access
necessary. When evaluating permissions, IAM first checks if there is an explicit deny. If none exists, it
then looks for an explicit allow. If neither is found, IAM applies an implicit deny, meaning access is denied
by default unless explicitly allowed.
To make policy development easier, the IAM Policy Simulator tool can be used to test and troubleshoot
policies before implementation.
Identity-based versus resource-based policies:
Identity-based policies are permissions that you attach to an IAM user, group, or role to control what
actions they can perform on AWS resources. There are three types of identity-based policies:
1. AWS managed policies: Predefined by AWS and can be attached to multiple identities in your
account. Ideal for beginners.
2. Customer managed policies: Created and managed by you, offering more flexibility and
control.
3. Inline policies: Embedded directly within a single user, group, or role for specific permissions.
Resource-based policies are policies attached to AWS resources like S3 buckets. These policies define
what actions specific users or services can perform on the resource. Resource-based policies are always
inline and control access at the resource level, but there are no managed resource-based policies.
IAM policy document structure:
IAM policies are stored as JSON documents in AWS. Identity-based policies are attached to users or roles,
while resource-based policies are attached to resources. Each policy document contains one or more
statements, each representing a single permission. When multiple statements are included in a policy,
AWS evaluates them using a logical OR.
The key elements in an IAM policy document are:
• Version: Specifies the version of the policy language in use. The 2012-10-17 version is
recommended for best practices.
 • Statement: Acts as the main container for policy elements, and multiple statements can be
included in a policy.
• Effect: Indicates whether access is allowed or denied, using "Allow" or "Deny."
• Principal: In resource-based policies, defines the account, user, role, or federated user to whom
access is granted or denied. In identity-based policies, the principal is implied.
• Action: Lists the actions that are allowed or denied by the policy.
• Resource: Specifies the resources to which the actions apply. This element is required in identity-
based policies and optional in resource-based policies.
• Condition (Optional): Defines the specific conditions under which permissions are granted.

ARNs and wildcards:

Amazon Resource Names (ARNs) are used to identify resources in AWS, following the format:
arn:partition:service:region:account
For example:
"Resource": "arn:aws:iam::123456789012:user/mmajor"
In IAM policies, wildcards (*) can be used to grant broad access to resources and actions. For example:
• "Action": "s3:*" grants access to all S3 actions.
• "Action": "iam:*AccessKey*" applies to all IAM actions related to access keys, such as
CreateAccessKey and DeleteAccessKey.
When writing IAM policies, the Resource element must specify the object or objects covered by the
policy. The ARN structure and format will vary depending on the service and resource being referenced.
Wildcards can be used in ARNs or action names to simplify permissions. For instance, using * allows
matching any set of characters, making the policy more flexible.
IAM policy example:

AWS CloudTrail:
AWS CloudTrail helps with governance, compliance, and auditing of AWS accounts by recording and
retaining account activity. It provides an event history for actions taken across AWS infrastructure,
including through the AWS Management Console, SDKs, and CLI.

Key Features:

• Logs User Activity: Tracks actions taken by users and services.

• Event History: Offers a 90-day history of events at no cost, detailing who accessed your account,
when, and from where.

• Increased Visibility: Helps in security analysis by identifying which actions were performed and
by whom.

• Compliance and Auditing: Assists in meeting compliance requirements and troubleshooting

issues.
Integration:

• Amazon EventBridge: Can trigger workflows based on specific events, such as applying a policy
to an S3 bucket if it becomes public.

CloudTrail records detailed information on each action, including the requester, service used, parameters,
and responses, enabling thorough security analysis and operational insights.

ORGANIZING USERS:
IAM groups:
Use IAM groups to grant the same access rights to multiple users.
• Granting Access: IAM groups allow multiple users to inherit the same permissions. By adding
users to a group, all members receive the group’s permissions, simplifying management.
• Managing Access: Groups streamline permission management for multiple users. Instead of
configuring each user individually, permissions are assigned at the group level.
• Combining Approaches:
o Use groups for standard access based on roles or job functions.
o Attach additional policies directly to individual users for exceptions.
• Group Management:
o Add or remove users from groups as needed.
o A user can be in multiple groups, but groups cannot be nested.
o Groups are used for managing permissions and do not have their own security credentials
or direct access to services.
Groups make it easier to manage user access, but they do not replace the need for individual policy
adjustments when necessary.
Example IAM groups:
Create groups that reflect job functions
• If a new developer is hired, add them to the Developer group
• Immediately inherit the same access granted to other developers
• If Ana takes on the new role of developer –
• Remove her from the Test group
• Add her to the Developer group
• Users can belong to more than one group
• However the most restrictive policy will then apply
Use case for IAM with Amazon S3:

Here's an example of configuring IAM permissions for an S3 bucket:

The awsexamplebucket S3 bucket has two main directories: home for individual work and share for team
content.
When a new developer, zhang, joins the team, follow these steps to grant the appropriate access:
1. Add to IAM Group: Add zhang to the IAM group for developers. This group has a policy that
provides access to the awsexamplebucket/share/developers directory.
2. Create Directory: Create a directory for zhang in S3 at awsexamplebucket/home/zhang.
3. Attach Direct Policy: Attach a policy directly to zhang's IAM user that grants access to the
awsexamplebucket/home/zhang directory.
By following these steps, zhang will inherit the permissions from the developer group and also receive
specific access to their individual directory.
FEDERATING USERS:
IAM roles:
Characteristics:
• Temporary Security Credentials: IAM roles provide temporary access to AWS resources.
• Not User-Specific: Roles are not tied to a specific individual but can be assumed by users,
applications, or services.
• Delegation: Often used to delegate access without assigning permanent credentials.
Use Cases:
• AWS Services Access: Allow AWS resources (e.g., EC2 instances) to access other AWS services.
• External Access: Grant access to users authenticated outside AWS.
• Third-Party Access: Provide permissions to third-party services without managing individual
accounts.
• Cross-Account Access: Enable access to resources across different AWS accounts.
How It Works:
• Define Permissions: Permissions are attached to roles, not individual users or groups.
• Assuming a Role: When a user or service assumes a role, they receive temporary credentials
and their existing permissions are overridden.
• Role Assumption: The role can be assumed by users or services within the same or different
AWS accounts.
• Management: Easier to manage temporary access without creating or deleting individual user
accounts. Roles can be modified or deleted to revoke access.
IAM roles streamline access management by avoiding the need for permanent security credentials and
allowing flexible, temporary permissions.
Grant permissions to assume a role:
To allow an IAM user, application, or service to assume a role:
1. Grant Permission: The entity must be granted permission to switch to the role.
2. Use AWS STS: AWS Security Token Service (STS) provides temporary, limited-privilege
credentials.
AWS STS:
• Purpose: Allows IAM users, federated users, or applications to assume a role and obtain
temporary credentials.
• Operation: When the AssumeRole API call is successful, STS returns temporary credentials with
the specified privileges.
• Use Cases: Commonly used for cross-account access and federation.
Example Policy: This policy allows an IAM user to assume any role in account 123456789012 where
the role name starts with Test.
Role-based access control (RBAC):
Traditional approach to access control:
• Grant Permissions by Role: Users are assigned specific permissions based on their job functions
(e.g., database administrator).
• Create Distinct Roles: Each unique combination of permissions is represented by a separate
IAM role.
• Update Permissions Individually: When new resources are added, permissions need to be
updated manually, which can be time-consuming.
RBAC Overview:
• RBAC has been a standard access control model both on-premises and in the cloud.
• Users are given access based on their roles. For instance, if a user is both a network administrator
and a developer, they are assigned roles for both, without needing a new policy for the combined
permissions.
• This model is familiar and straightforward, making it easier to manage access for defined roles.
• Maintaining and updating permissions can be cumbersome, especially when new resources are
created. Each update requires modifying the policy to include new ARNs and granting access as
needed.
Best practice: Tagging:
AWS allows you to assign metadata to resources and identities using tags. Each tag is a label with a key
and an optional value. Tags help manage, search, and filter AWS resources. For example, you might tag
an EC2 instance with "Name = web server," "Project = unicorn," and "Stack = dev."
Tags have various uses, including:
• Billing: Identify which department or project should be billed.
• Filtered Views: Organize resources by environment, project, or other criteria.
 • Access Control: Apply security-related tags to resources.
You can create up to 50 tags per resource, and each tag key must be unique with a single value. Tags
are case-sensitive and can also be applied to IAM users and roles.
Attribute-based access control (ABAC):
Attribute-based access control (ABAC) is a scalable approach to managing access. Instead of creating
specific permissions for each user or resource, ABAC uses attributes like tags to define access rules.
In ABAC, attributes are key-value pairs, such as:
• Team = Developers
• Project = Unicorn
Permissions are determined based on these attributes. For example, if a user is tagged as part of the
"Developers" team and a resource is tagged with "Project = Unicorn," the user can access the resource
if the policy allows it.
ABAC has several benefits:
• Scalability: Permissions automatically apply based on attributes, so you don't need to update
permissions for every new user or resource.
• Granularity: Fine-grained access control is possible without constantly adjusting permissions.
• Auditability: All access decisions are traceable and can be reviewed.
With ABAC, you can efficiently manage access across large and dynamic environments by applying and
matching tags rather than maintaining a detailed list of permissions for each role.
Applying ABAC to your organization:
To implement Attribute-Based Access Control (ABAC) in your organization, follow these steps:
1. Set Attributes on Identities: Start by applying attributes to IAM users or roles. For example,
assign tags like Team = Developers and Project = Unicorn to the Maria user.
2. Require Attributes for New Resources: Establish policies that mandate the inclusion of
attributes on new resources. For instance, enforce that all resources must have Project and Team
tags upon creation.
3. Configure Permissions Based on Attributes: Set up permissions so that access is granted
based on matching attributes. If an IAM user with Project = Unicorn and Team = Developers tries
to access a resource with the same tags, they should be granted access; otherwise, access should
be denied.
 4. Test Your Setup: Create a resource, such as an Amazon Aurora database, without the required
tags to ensure the policy denies creation. Then, create the resource with the correct tags and
verify that it succeeds. Finally, check that users with matching tags can access the resource, while
those without the tags cannot.
This approach ensures that access is automatically and appropriately granted based on the attributes of
users and resources.
Externally authenticated users:
Identity federation allows external systems to authenticate users, granting them access to AWS resources
without needing IAM users. Here’s a simplified overview:
Identity Federation:
This method lets users authenticate through external systems, like corporate directories, instead of
creating separate IAM users in AWS. It enables secure access using existing identities.
Federation Options
1. AWS Security Token Service (STS): This can integrate with:
o Public identity service providers (IdPs)
o Custom identity broker applications
2. Security Assertion Markup Language (SAML): Used for integrating with identity providers
that support SAML.
3. Amazon Cognito: A web identity provider that supports authentication through social logins and
other identity sources.
Identity federation with an identity broker:
To use an identity broker for federation, follow these steps:
1. User Accesses Application: The user logs in with their credentials (user ID and password).
2. Identity Broker: The broker receives the login request and verifies it with the corporate identity
store (e.g., Microsoft Active Directory or LDAP).
3. STS Request: Upon successful authentication, the identity broker requests temporary AWS
security credentials from AWS STS.
4. Access Granted: The user’s application receives these temporary credentials and redirects the
user to the AWS Management Console. This enables single sign-on (SSO), allowing the user to
 access AWS resources without needing separate AWS credentials. The application can also use
these credentials to access AWS services based on the permissions defined in the IAM policy.

Identity federation using SAML:

To use SAML for identity federation, follow these steps:
1. User Access: A user navigates to an internal portal that also acts as the identity provider (IdP)
for SAML.
2. Authentication: The IdP verifies the user’s identity against an identity store, like LDAP or
Microsoft Active Directory.
3. SAML Assertion: The IdP sends a SAML assertion to the portal.
4. AWS Integration: The portal posts the SAML assertion to the AWS sign-in endpoint. AWS STS
processes this request, uses the AssumeRoleWithSAML operation to generate temporary security
credentials, and creates a sign-in URL.
5. Access Granted: The client receives temporary AWS security credentials and is redirected to the
AWS Management Console, where the user is authenticated with these credentials.
Amazon Cognito:
Amazon Cognito is a fully managed service that handles authentication, authorization, and user
management for web and mobile apps. It supports sign-in via social identity providers like Facebook,
Amazon, and Google, or through SAML.
Cognito has two main components:
1. User Pools: These are directories where users can sign in to your app. They can use a username
and password or federate through third-party providers. Each user in a pool has a profile accessible
via an SDK.
2. Identity Pools: These create unique identities and assign permissions to users. With identity
pools, users can get temporary AWS credentials to access AWS services. Identity pools work with
user pools and support social logins and OpenID Connect (OIDC) providers.
Amazon Cognito example:
In this scenario, the process for using Amazon Cognito to authenticate a user and grant access to AWS
services is as follows:
1. Sign In: The user logs in through an Amazon Cognito user pool and gets authentication tokens.
2. Get AWS Credentials: The app exchanges these tokens for AWS credentials using an Amazon
Cognito identity pool.
3. Access AWS Services: The user uses the AWS credentials to access other AWS services.
MULTIPLE ACCOUNTS:
One account or multiple accounts?
When deciding between using one AWS account or multiple accounts, organizations generally opt for
multiple accounts. This approach offers several benefits:
• Isolation: Separate accounts can be used to isolate business units, development, testing, and
production environments.
• Auditing and Recovery: Different accounts can be used for auditing data and recovery data,
and for workloads with specific regulatory requirements.
• Cost Management: It’s easier to set up cost alerts and manage budgets for each business unit
individually.
In AWS, there are two main architectural patterns:
1. Single Account with Multiple VPCs: This approach involves using a single AWS account with
multiple virtual private clouds (VPCs). It simplifies security management but can be less flexible.
 2. Multiple Accounts: This approach involves creating separate AWS accounts for different
purposes, such as various business units or different environments (development, testing,
production). This method helps in clearly separating resources and offers additional security
benefits.
For efficient management, it’s common to:
• Use a single AWS account for shared resources like DNS services or directory services.
• Create separate accounts for different projects or departments to manage permissions and policies
effectively.

Challenges for managing multiple accounts:

Using multiple AWS accounts can present several challenges:
1. Security Management: Ensuring consistent IAM policies across all accounts can be complex.
This may involve custom automation or manual processes.
2. Account Creation: Creating and managing multiple accounts can be time-consuming and difficult
to track.
 3. Billing: Consolidating billing across accounts and assigning costs to the correct departments or
projects can be challenging.
4. Centralized Governance: Maintaining consistent governance and policies across multiple
accounts requires careful planning and oversight.

Manage multiple accounts with AWS Organizations:

AWS Organizations simplifies the management of multiple AWS accounts. It allows you to centrally
manage and enforce policies across accounts through group-based account management and policy-
based access control. With AWS Organizations, you can:
1. Group Accounts: Create groups of accounts and apply policies to each group to ensure consistent
access control and governance.
2. Automate Account Management: Use APIs to automate the creation of new accounts and
automatically apply policies when adding them to groups.
3. Consolidated Billing: Set up a single payment method for all accounts and view combined
charges for easier cost management.
4. Service-Level Control: Manage the use of AWS services at the API level by applying policies to
control access to specific resources, such as limiting IAM user access to read-only S3 data.
AWS Organizations helps centralize governance and streamline the management of multiple AWS
accounts.
AWS Organizations: Illustrated:
In the AWS Organizations primary account:
1. Create a hierarchy of organizational units (OUs)
2. Assign accounts to OUs as member accounts
3. Define service control policies (SCPs) that apply permissions restrictions to specific member
accounts
4. Attach the SPCs to root, OUs, or accounts
Example uses of SCPs:
• Characteristics of service control policies (SCPs)
• They enable you to control which services are accessible to IAM users in member accounts
• SCPs cannot be overridden by the local administrator
• IAM policies that are defined in individual accounts still apply
• Example uses of SCPs
• Create a policy that blocks service access or specific actions
Example: Deny users from disabling AWS CloudTrail in all member accounts
• Create a policy that allows full access to specific services
Example: Allow full access to Amazon EC2 and CloudWatch
• Create a policy that enforces the tagging of resources

.
 10. ASSIGNMENT

Assignment 1: Basic VPC Setup

Difficulty Level: Beginner

Creating and Configuring a Basic VPC Task: Set up a basic VPC with a public and private subnet.
Instructions:

1. Create a VPC with a specific CIDR range.

2. Configure a public subnet and a private subnet within the VPC.

3. Set up a basic route table to allow internet access for the public subnet.

4. Launch an EC2 instance in each subnet and verify connectivity.

5. Document each step with screenshots and explanations.

Expected Output: A guide with screenshots showing VPC creation, subnet configuration, route tables,
and instance verification.

Assignment 2: VPC and Internet Connectivity

Difficulty Level: Intermediate

Connecting VPC to the Internet Task: Configure internet access for a VPC and direct traffic between
resources.
Instructions:

1. Create a public subnet and configure an Internet Gateway.

2. Set up route tables to allow internet access for instances in the public subnet.

3. Configure Network Address Translation (NAT) to allow private subnet instances to access the
internet.

4. Demonstrate how to remap an IP address from one EC2 instance to another.

5. Document the configuration process with screenshots and explanations.

Expected Output: A detailed guide with screenshots showing internet connectivity setup and IP address
remapping.

Assignment 3: Securing Your VPC

Difficulty Level: Intermediate

Implementing Security Controls in a VPC Task: Set up security groups and network ACLs to secure
a VPC.
Instructions:

1. Create custom security groups with specific inbound and outbound rules.

2. Configure network ACLs for the VPC with appropriate rules.

3. Implement a layered security approach using both security groups and ACLs.

4. Demonstrate how these configurations protect your VPC resources.

5. Document the setup process with screenshots and explanations.

Expected Output: A comprehensive guide with screenshots showing security group and ACL
configurations.

Assignment 4: Advanced VPC Connectivity

Difficulty Level: Advanced

Configuring AWS Direct Connect and Site-to-Site VPN Task: Set up AWS Direct Connect and AWS
Site-to-Site VPN for secure connectivity.
Instructions:

1. Configure AWS Site-to-Site VPN with static or dynamic routing.

2. Set up AWS Direct Connect to extend your on-premises network to AWS.

3. Include high availability by adding a backup VPN connection.

4. Describe the setup process and how these connections ensure resiliency.
 5. Write a report detailing the configuration and benefits of each connectivity option.

Expected Output: A report with configuration steps, screenshots, and explanations of Direct Connect
and VPN setup.

Assignment 5: Scaling VPC Networks

Difficulty Level: Expert

Scaling and Managing Multiple VPCs Task: Implement AWS Transit Gateway and VPC peering for a
scalable network.
Instructions:

1. Create an AWS Transit Gateway and connect it to multiple VPCs.

2. Set up VPC peering connections between selected VPCs.

3. Update route tables for both the Transit Gateway and VPCs.

4. Explain the considerations for scaling and managing network traffic.

5. Document the process with architecture diagrams, configuration details, and explanations.

Expected Output: A detailed report with architecture diagrams, configuration steps, and explanations
of scaling and managing multiple VPCs.
 11. PART A QUESTIONS AND ANSWERS

1. What is the primary purpose of an Internet Gateway in an Amazon VPC? K2

An Internet Gateway in an Amazon VPC allows instances with public IP addresses to
connect to the internet. It enables both inbound and outbound internet traffic.
2. How would you set up a VPC to ensure that instances in a private subnet can access K3
the internet?
Configure a NAT Gateway or NAT Instance in a public subnet. This setup allows private
instances to make outbound requests while keeping them isolated from incoming
internet traffic.
3. Analyze the impact of using overlapping CIDR blocks when adding a new IPv4 CIDR K4
block to an existing VPC.
Using overlapping CIDR blocks causes routing conflicts and disrupts network traffic
management.
It prevents proper communication between instances and other resources within the
VPC.
4. Evaluate the advantages and disadvantages of using a single VPC for both development K5
and production environments.
Advantages: Simplified network management and reduced cost.
Disadvantages: Increased risk of accidental interference, less isolation, and potential
security concerns.
Separate VPCs are generally recommended for better environment segregation and
security.
5. Design a VPC with the following requirements: Two subnets in different Availability K6
Zones, one public subnet with internet access, and one private subnet for database
instances. Include necessary components.
• Create a VPC with a CIDR block (e.g., 10.0.0.0/16).
• Create two subnets: one public (e.g., 10.0.1.0/24) and one private (e.g.,
10.0.2.0/24), each in different Availability Zones.
 • Attach an Internet Gateway to the VPC and update the route table for the public
subnet to direct traffic to the Internet Gateway.
• Create a NAT Gateway in the public subnet to enable the private subnet to access
the internet.
• Update the route table for the private subnet to direct outbound traffic to the
NAT Gateway.
6. How would you use VPC Peering to enable communication between two VPCs in K3
different AWS Regions?
Set up an Inter-Region VPC Peering Connection.
Configure peering connections and update route tables in both VPCs to route traffic to
the peering connection, allowing secure communication between instances in both
VPCs.
7. What is the purpose of a NAT Gateway in an Amazon VPC? K2
A NAT Gateway allows instances in a private subnet to access the internet for outbound
traffic while keeping those instances isolated from inbound internet traffic.
8. What is the difference between a Default VPC and a Nondefault VPC? K2
A Default VPC is pre-configured by AWS with an internet gateway and default settings,
allowing easy launch of instances with internet access. A Nondefault VPC is custom-
configured by the user with specific settings, requiring manual setup of subnets, IP
addresses, and gateways.
9. How would you configure routing in a VPC to allow instances in a private subnet to K3
access resources in another VPC via VPC Peering?
To allow instances in a private subnet to access resources in another VPC via VPC
Peering, you need to:
• Create a VPC Peering Connection between the two VPCs.
• Update the route tables in both VPCs to add routes pointing to the peering
connection for the CIDR blocks of the peered VPC.
10. How would you set up a VPC to allow communication between an EC2 instance in one K3
subnet and an RDS instance in another subnet within the same VPC?
 Ensure both subnets are within the same VPC and configure the security groups
associated with the EC2 instance and RDS instance to allow inbound and outbound
traffic between them. Update the route tables, if necessary, to ensure network traffic
can flow between the subnets.
11. What is the role of an Internet Gateway (IGW) in a public subnet? K2
An Internet Gateway (IGW) allows resources in a public subnet to communicate with
the internet by handling IPv4 and IPv6 traffic and providing network address translation
(NAT) for public IP addresses in your VPC.
12. How does a NAT gateway help in connecting private subnets to the internet? K2
A NAT gateway allows resources in private subnets to access the internet by forwarding
requests from private instances to the internet while preventing inbound traffic from
reaching those instances directly.
13. If you need to allow HTTP traffic to your web server instances in a public subnet, what K3
configuration changes should be made to the security group?
You should configure the security group to allow inbound HTTP traffic by adding a rule
that permits traffic on port 80 from the internet (0.0.0.0/0) to the instances in the
public subnet.
14. How would you set up a route table to direct traffic from a public subnet to the internet? K3
You need to create a route in the route table with the destination set to 0.0.0.0/0 and
the target set to the Internet Gateway (IGW) ID. Associate this route table with the
public subnet.
15. Compare the use of security groups and network ACLs in managing traffic within a VPC. K4
What are their key differences?
Security groups are stateful and operate at the instance or network interface level,
tracking connection details and allowing return traffic automatically. Network ACLs are
stateless and operate at the subnet level, requiring explicit rules for both inbound and
outbound traffic. Security groups are used for detailed, instance-level control, while
network ACLs provide broader, subnet-level control.
16. Analyze why a bastion host is used in a VPC and its impact on security. K4
 A bastion host acts as a secure gateway between the private network and the public
internet. It allows controlled access to instances in private subnets by requiring users
to connect first to the bastion host. This enhances security by exposing only the bastion
host to potential attacks, reducing the attack surface of the private network.
17. Evaluate the effectiveness of using custom route tables versus default route tables in K5
managing VPC traffic.
Custom route tables offer greater control over routing traffic within a VPC by allowing
you to define specific rules for different subnets, whereas default route tables are more
generic and apply broad rules. Custom route tables are more effective for managing
traffic as they provide the flexibility to tailor routes to specific needs, enhance security,
and improve network performance.
18. Create a configuration plan for setting up a public subnet with internet access in a new K6
VPC.
• Create a new VPC and define its CIDR block.
• Create an Internet Gateway (IGW) and attach it to the VPC.
• Create a public subnet within the VPC and assign it a CIDR block.
• Create a route table, add a route with destination 0.0.0.0/0 and target IGW, and
associate this route table with the public subnet.
• Configure the security group for the instances in the public subnet to allow
inbound traffic on necessary ports (e.g., port 80 for HTTP).
19. What is the main purpose of AWS Site-to-Site VPN? K2
AWS Site-to-Site VPN is used to securely connect an on-premises network or branch
office to an AWS VPC using encrypted VPN tunnels, ensuring secure communication
between the networks.
20. How would you configure a route table to prioritize static routes over dynamic BGP K3
routes in AWS Site-to-Site VPN?
To prioritize static routes over dynamic BGP routes, add static routes to the route table
with the desired CIDR blocks. AWS will use these static routes before considering the
propagated BGP routes when both point to the same CIDR.
21. Analyze the benefits and limitations of using AWS Direct Connect (DX) over AWS Site- K4
to-Site VPN.
AWS Direct Connect offers higher performance, reduced costs, increased bandwidth,
and enhanced security by bypassing the public internet, making it ideal for high-
bandwidth and low-latency needs. However, it may involve higher setup costs and
complexity compared to Site-to-Site VPN, which is more straightforward and flexible for
encrypted connections over the internet but may suffer from variable performance due
to internet congestion.
22. Evaluate the effectiveness of combining AWS Direct Connect with a backup VPN K5
connection for high availability.
Combining AWS Direct Connect with a backup VPN connection is highly effective for
ensuring continuous connectivity. Direct Connect provides primary high-performance
and private connectivity, while the VPN serves as a failover, maintaining network access
if Direct Connect fails. This setup offers robust redundancy and failover capabilities but
requires careful configuration and management to ensure seamless transition between
connections.
23. What is AWS Transit Gateway in a VPC network? K2
AWS Transit Gateway simplifies the management of multiple VPCs and on-premises
networks by acting as a central hub. It connects VPCs and on-premises networks
through a single gateway, allowing for easier scaling and central management of
network traffic.
24. If VPC peering is used between VPC-A and VPC-B, but VPC-B is also connected to VPC- K4
C through AWS Transit Gateway, how does traffic between VPC-A and VPC-C get
routed?
Traffic between VPC-A and VPC-C will be routed through VPC-B. Since VPC-A and VPC-
C are not directly peered, the traffic will go from VPC-A to VPC-B via the VPC peering
connection, and then from VPC-B to VPC-C via the AWS Transit Gateway.
25. Evaluate the benefits of using VPC peering compared to AWS Transit Gateway for K5
connecting multiple VPCs.
 VPC peering is straightforward and does not require additional infrastructure, but it
becomes complex as the number of VPCs increases, leading to a large number of point-
to-point connections. AWS Transit Gateway, on the other hand, simplifies network
management by using a central hub, reducing the number of connections and scaling
more easily. Transit Gateway also supports up to 5,000 VPCs, which is more scalable
compared to VPC peering.
26. How would you grant a user access to a specific S3 bucket while ensuring that they K3
can only list the contents but not delete or upload files?
To grant a user access to list the contents of a specific S3 bucket without allowing file
deletion or uploads, you would create an IAM policy with the s3:ListBucket action
allowed and deny s3:PutObject and s3:DeleteObject actions. Attach this policy to the
IAM user.
27. How would you determine if an IAM user has the correct permissions when K4
troubleshooting access issues?
To determine if an IAM user has the correct permissions, you would analyze the IAM
policies attached to the user, group, or role. Use the IAM Policy Simulator to test
permissions and ensure they align with the intended access levels. Review any explicit
denies and policy conditions that might affect the user's access.
28. Evaluate the effectiveness of using IAM roles with temporary security credentials K5
compared to using long-term IAM user credentials for accessing AWS resources.
IAM roles with temporary security credentials offer enhanced security over long-term
IAM user credentials because they provide limited-time access and reduce the risk of
credential compromise. Roles can also be used to grant permissions dynamically
without managing long-term credentials, improving security and reducing
administrative overhead.
29. How would you assess the impact of attaching a policy with s3:* action to an IAM user K5
on overall AWS security?
Attaching a policy with s3:* action to an IAM user grants them full access to all S3
actions, which can pose a significant security risk if not carefully managed. Evaluate
 the impact by considering the principle of least privilege and the potential for
unintended data exposure or modification. It is advisable to restrict permissions to
specific actions and resources to reduce security risks.
30. What is the primary benefit of using IAM groups in managing user permissions? K2
The primary benefit of using IAM groups is to simplify the management of permissions
by allowing multiple users to inherit the same permissions. This makes it easier to
assign and manage access rights for a group of users with similar roles or job functions.
31. If a new developer named Alex joins your team and needs access to a specific S3 K3
directory, how would you configure his permissions using IAM groups and policies?
To configure Alex's permissions, add him to the IAM group designated for developers,
which has policies granting access to the relevant S3 directory. Additionally, create a
specific S3 directory for Alex and attach a policy directly to his IAM user that grants
access to this individual directory, ensuring both group and individual permissions are
applied.
32. Analyze the impact of removing a user from an IAM group. How does this action affect K4
the user’s access to resources?
When a user is removed from an IAM group, they lose all permissions granted by that
group’s policies. This affects their access to resources associated with the group’s
permissions. If the user had no additional permissions assigned individually or through
other groups, their access to those resources will be revoked.
33. Evaluate the security implications of using IAM roles with temporary credentials K5
compared to using long-term IAM user credentials.
Using IAM roles with temporary credentials enhances security by reducing the risk of
credential theft, as temporary credentials are short-lived and can be automatically
rotated. This approach avoids the risks associated with long-term IAM user credentials,
such as prolonged exposure if credentials are compromised. Additionally, roles can
provide granular and temporary access, minimizing unnecessary permissions.
34. Create an IAM policy that allows users to access S3 objects in a specific bucket but only K6
if they are tagged with a project attribute matching their own user attribute.
 {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "${aws:userid}"
}
}
}
]
}
35. How does IAM role-based access control (RBAC) differ from traditional role-based K2
access control in managing AWS permissions?
IAM role-based access control (RBAC) in AWS provides temporary access through roles,
allowing users or services to assume specific permissions without needing permanent
credentials. This contrasts with traditional RBAC, which often involves assigning fixed
permissions to users based on their roles. IAM RBAC is more flexible and secure
because it uses temporary credentials and allows for dynamic permission management.
 12. PART B QUESTIONS

1. Describe the process of creating an AWS networking environment. What are the key K2
components involved?
2. How would you configure your AWS networking environment to connect to the K3
internet? Include details on public subnets and internet access.
3. Compare and contrast different methods for securing your AWS networking K4
environment. What are the advantages and limitations of security groups versus
network ACLs?
4. Evaluate the effectiveness of various connection methods for integrating your remote K5
network with AWS. Consider options like Site-to-Site VPN and Direct Connect in your
assessment.
5. Design a strategy for connecting multiple virtual private clouds (VPCs) in AWS using K6
VPC peering. Include considerations for peering restrictions and resource sharing.
6. Explain how scaling your VPC network can be achieved with AWS Transit Gateway. K2
What are the basic steps involved?
7. Illustrate the process of connecting your VPC to supported AWS services using VPC K3
endpoints. How do interface endpoints differ from gateway endpoints?
8. Analyze the role of AWS Identity and Access Management (IAM) in securing user and K4
application access. What are the key components and their functions?
9. Assess the impact of using IAM roles and policies for managing user permissions K5
versus using IAM groups. How do these approaches influence access control and
security?
10. Develop a comprehensive plan for organizing users and federating access in AWS. K6
Include details on IAM groups, roles, and federated access methods such as SAML
and Amazon Cognito.
 13. ONLINE CERTIFICATIONS

1. AWS Certified Cloud Practitioner

AWS Certified Cloud Practitioner Certification | AWS Certification | AWS (amazon.com)

2. AWS Certified Solutions Architect – Associate

https://aws.amazon.com/certification/certified-solutions-architect-associate/
 14. REAL TIME APPLICATIONS

Lincoln Financial Transforms its Data Warehouse on AWS for Richer Business Insights
Lincoln Financial struggled with an inefficient data warehouse for its sales professionals that was
becoming more of a liability than an asset. To replace this warehouse, Lincoln Financial built a cloud-first
data platform on Amazon Web Services (AWS) using services such as AWS Glue, AWS Lambda, and
Amazon Simple Storage Service (Amazon S3). The new solution provides 360-degree views of sales
professionals and their interactions, leading to richer business insights and better business decisions.
Lincoln Financial Transforms its Data Warehouse on AWS for Richer Business Insights | AWS (amazon.com)
 15. ASSESSMENT SCHEDULE

Tentative schedule for the Assessment During 2024-2025 Odd semester

Name of the
S.NO Start Date End Date Portion
Assessment

1 IAT 1 22.08.2024 30.08.2024 UNIT 1 & 2

2 IAT 2 30.09.2024 08.10.2024 UNIT 3 & 4

3 REVISION - - UNIT 5, 1 & 2

4 MODEL 26.10.2024 08.09.2024 ALL 5 UNITS

 16. PRESCRIBED TEXT BOOKS AND REFERENCES

REFERENCES:

1. AWS Certified Solutions Architect Official Study Guide by Joe Baron, Hisham Baz, Tim Bixler
2. Architecting the Cloud by Michael Kavis.
3. AWS Documentation (amazon.com) - https://docs.aws.amazon.com/
4. AWS Skill Builder -
https://explore.skillbuilder.aws/learn/public/learning_plan/view/82/cloud-foundations-
learning-plan?la=sec&sec=lp
5. AWS Academy Cloud Architecting Course -
https://www.awsacademy.com/vforcesite/LMS_Login
 17. MINI PROJECT

Beginner
Miniproject 1: Basic VPC Setup and Subnet Configuration
• Objective: Create a simple VPC and configure basic subnets for a small application.
• Tasks:
1. Create a new VPC with a CIDR block of your choice.
2. Set up two public subnets within the VPC.
3. Configure a route table to allow internet access for the public subnets.
4. Launch a basic EC2 instance in one of the public subnets and verify connectivity.
• Difficulty Level: Beginner

Intermediate
Miniproject 2: Implementing Security Groups and Network ACLs
• Objective: Configure security groups and network ACLs to secure a web application.
• Tasks:
1. Create a new VPC with a public and a private subnet.
2. Set up an EC2 instance in the public subnet and another in the private subnet.
3. Configure security groups to allow HTTP/HTTPS access to the public instance and restrict
access to the private instance.
4. Implement network ACLs to control traffic between the public and private subnets.
5. Test connectivity between instances to ensure correct configuration.
• Difficulty Level: Intermediate

Advanced
Miniproject 3: VPC Peering and Cross-VPC Communication
• Objective: Set up VPC peering between two VPCs and configure routing for cross-VPC
communication.
• Tasks:
1. Create two separate VPCs with overlapping CIDR blocks.
2. Establish a VPC peering connection between the two VPCs.
 3. Update route tables in both VPCs to enable traffic between them.
4. Launch EC2 instances in both VPCs and test connectivity.
5. Ensure that security groups and network ACLs are correctly configured to allow
communication.
• Difficulty Level: Advanced

Expert
Miniproject 4: AWS Transit Gateway and Multiple VPCs
• Objective: Implement AWS Transit Gateway to connect multiple VPCs and manage routing.
• Tasks:
1. Create a Transit Gateway.
2. Attach multiple VPCs to the Transit Gateway.
3. Update VPC route tables and Transit Gateway route tables to manage traffic.
4. Verify that instances in different VPCs can communicate through the Transit Gateway.
5. Set up a VPC endpoint for a specific service (e.g., S3) and ensure it works through the
Transit Gateway.
• Difficulty Level: Expert

Advanced
Miniproject 5: Site-to-Site VPN and AWS Direct Connect Integration
• Objective: Establish a Site-to-Site VPN connection and configure AWS Direct Connect for hybrid
cloud access.
• Tasks:
1. Set up a Site-to-Site VPN connection between an on-premises network and AWS.
2. Configure static or dynamic routing for the VPN connection.
3. Set up AWS Direct Connect to provide a dedicated network connection from your on-
premises data center to AWS.
4. Integrate Direct Connect with the existing Site-to-Site VPN setup for redundancy.
5. Test connectivity and performance between your on-premises network and AWS resources.
• Difficulty Level: Expert
 Thank you

Disclaimer:

This document is confidential and intended solely for the educational purpose of RMK Group of
Educational Institutions. If you have received this document through email in error, please notify the
system manager. This document contains proprietary information and is intended only to the
respective group / learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender immediately by e-mail if you
have received this document by mistake and delete this document from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing or taking any action in
reliance on the contents of this information is strictly prohibited.