Aws

l l i ge nt
i nte ARCH
I T EC T URES
Next-Generation Security Platform

on Amazon AWS
Reference Architecture
Release 2
February 2018
Intelligent Architectures | Next-Generation Security Platform on Amazon AWS Reference Architecture
Contents
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Purpose of This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Amazon Web Services—Building Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Virtual Private Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Availability Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Subnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Route Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Network Access Control Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Security Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Source and Destination Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Internet Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Virtual Private Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Customer Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VPN Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Elastic IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Elastic Network Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Amazon Machine Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
AWS Direct Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
AWS Security and Traffic Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Inbound Traffic Inspection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Outbound Traffic Inspection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
East/West Traffic Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Palo Alto Networks VM-Series Licensing on AWS. . . . . . . . . . . . . . . . . . . . . . . . . . 21
Palo Alto Networks Firewall on AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Building a Secure AWS Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Single VPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Transit VPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
VPC Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
AWS Direct Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Related Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
What’s New in This Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Contents 2
IntelligentArchitectures | Next-Generation SecurityPlatform onAmazonAWS ReferenceArchitecture
Introduction
Many organizations take advantage of opportunities to deploy applications and services on public
cloud infrastructure; the advantages vary based on desired business outcomes. Some of the common
reasons include:
Business agility—Infrastructure resources are available when and where they are needed,
minimizing IT staffing requirements and providing faster, predictable time-to-market.
Virtualization in both public and private cloud infrastructure has permitted IT to respond to
business requirements within minutes instead of days or weeks.
Better use of resources—Projects are more efficient and there are fewer operational issues,
permitting employees to spend more time adding business value. Employees have the
resources they need when they need to bring value to the organization.
Lower capital expense—Costs are aligned directly with usage, providing a utility model
for IT infrastructure requiring little to no capital expense. Gone are the large capital
expenditures and time delays associated with building private data center infrastructure.
Purpose of This Guide

This guide provides a foundation for securing network infrastructure using Palo Alto Networks® VM-
Series virtualized next generation firewalls within the Amazon Web Services (AWS) public cloud. For
an organization with a desire to move to public cloud infrastructure, the next question is often “How
do I secure my applications in a public cloud?” This guide provides an overview of AWS components
and how they can be used to build a scalable and secure public cloud infrastructure on AWS using
the VM-Series. The architectures begin with a single virtual private cloud suitable for organizations
getting started and scales to thousands to meet any size organization’s operational requirements.
Audience
Individuals with a networking background and understanding of VM-Series will learn how to deploy
it on AWS in order to deploy a secure cloud infrastructure. The next section describes the relevant
AWS components, so no prior knowledge of AWS components is required.
Introduction 3
Amazon Web Services—Building Blocks

AWS has a shared security responsibility model in which AWS secures the foundational infrastructure
on which your services run, and you are responsible for securing everything else: firewalls, operating
systems, network traffic (data in flight), sensitive data (data at rest), encryption keys, etc.
To understand how to construct secure applications and services using Amazon Web Services, it is
necessary to understand the components of AWS Infrastructure Services. This section describes the
components used by this reference architecture:
Regions are AWS physical data center locations distributed around the globe.
Virtual private clouds (VPCs) are virtual networks associated with your Amazon account and
isolated from other AWS users.
Availability Zones are multiple isolated locations within a region.
A subnet is a logical subdivision of your VPC network and is unique to a single Availability
Zone.
Route tables provide source-based control of Layer 3 forwarding.
Network access control lists (ACLs) provide Layer 4 control of source/destination IP
addresses and ports.
Security groups (SGs) provide a Layer 4 stateful firewall for control of the source/destination
IP addresses and ports that are permitted.
Source and destination check (Source/Dest Check) validates whether traffic is destined to, or
originates from, an instance and prevents any traffic that does not meet this validation.
An internet gateway (IGW) allows communication between the internet and the instances in
your VPC.
The virtual private gateway (VGW) provides a VPN concentrator service attached to a VPC.
A customer gateway (CGW) identifies the target IP address of a peer device that terminates
IPsec tunnels from the VGW.
VPN connections are the IPsec tunnels between your VGW and CGW.
Elastic IP addresses are AWS-owned, static IPv4 addresses associated with your AWS
account.
Elastic network interfaces (ENIs) are virtual network interfaces that are attached to an
instance (see below) in a VPC.
Instances are virtual servers in the AWS cloud.
Amazon Machine Images (AMIs) are virtual machine images available in the Amazon
Marketplace.
AWS Direct Connect establishes a dedicated network connection from your location to
AWS.
This guide identifies potential costs when appropriate, but these do not represent all costs. For
example, costs for data transfer and storage are not covered.
4 Amazon Web Services—Building Blocks

Regions
Regions enable you to place services and applications in proximity to your customers, as well as to
meet governmental regulatory requirements for customer data residency. Regions represent Amazon
physical data center locations distributed around the globe. A region consists of several physically
separate and co-located data center buildings, which provides maximum fault-tolerance and stability.
Communications between regions is facilitated over the public internet. To ensure confidentiality of
communications between regions, encrypted transport, such as IPsec tunnels, is required.
Regions are specified beginning with two letter geographic region (us—United States, eu—European
Union, ap—Asia Pacific, sa—South America, ca—Canada), followed by regional destination (east, west,
central, south, northeast, southeast), followed by a number to distinguish multiple regions in a similar
geography. Examples of region designations: us-west-2 (Oregon), ap-northeast-1 (Tokyo), and eu-
central-1 (Frankfurt). Figure 1 shows approximate locations of current AWS regions.
Figure 1. AWS worldwide regions
Amazon Web Services—Building Blocks 5

Virtual Private Cloud

A VPC is a virtual network associated with your Amazon account and isolated from other AWS users.
You create a VPC within a region of your choice, and it spans multiple, isolated locations for that
region, called Availability Zones.
When creating a new VPC, you specify a classless inter-domain (CIDR) IPv4 address block and
optional, Amazon-provided IPv6 CIDR address block. All resources provisioned within your VPC use
addresses from this CIDR block. For information about CIDR prefix notation, see RFC4632. The IPv4
address block can be any valid IPv4 address range with a network prefix in the range of /16 (65535
hosts) to /28 (16 hosts). The actual number of host addresses available to you is less than the
maximum because some addresses are reserved for AWS services. After the VPC is created, the IPv4
CIDR block cannot be changed, so it’s recommended you chose a CIDR prefix that exceeds your
anticipated address space requirements for the lifetime of the VPC. There are no costs associated
with a VPC CIDR address block, and your VPC is only visible to you. Many other customer VPCs can
use the same CIDR block without issue. Two primary considerations when choosing VPC CIDR block
are the same as with any enterprise network:
Anticipated number of IP addresses needed within a VPC

IPv4 connectivity requirements across all VPCs
Unlike enterprise networks that are mostly static and where network addressing changes can be
difficult, cloud infrastructure tends to be highly dynamic, which minimizes the need to anticipate
growth requirements very far into the future. The next release of an application can easily replace
the current VPC infrastructure. Regardless of network address size, the general requirement for
communications across the enterprise network is for all network addresses to be unique; the same
requirement applies across your VPCs. When you create new VPCs, consider using unique network
address space for each, to ensure maximum communications compatibility between VPCs.
A VPC internet gateway (discussed below) provides network address translation (NAT) for traffic
to and from your VPC to the internet. Therefore, the following CIDR IP addresses from the private
address space defined in RFC1918 are recommended for VPCs:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
The minimum CIDR block prefix length for a VPC remains /16. RFC1918 defines much larger space
for 10.0.0.0/8 and 172.16.0.0/12, which must be further segmented into smaller address blocks
for VPC use. These private addresses are not internet-routable and are always unique for outbound
internet traffic.
Availability Zones
Availability Zones provide a logical data center within a region. They consist of one or more
physical data centers, are interconnected with low-latency network links, and have separate cooling
and power. No two Availability Zones share a common data center. A further abstraction is that
Availability Zone–mapping to physical data centers can differ according to AWS account. Availability
Zones provide inherent fault tolerance, and well architected applications are distributed across
multiple Availability Zones within a region. Availability Zones are designated by a letter (a,b,c) after
the region.

Figure 2. Availability Zones within a region
Subnets
A subnet identifies a portion of its parent VPC CIDR block as belonging to an Availability Zone. A
subnet is unique to an Availability Zone and cannot span Availability Zones, and an Availability Zone
can have many subnets. At least one subnet is required for each Availability Zone desired within a
VPC. The Availability Zone of newly created instances and network interfaces is designated by the
subnet with which they are associated at the time of creation. A subnet prefix length be as large
as the VPC CIDR block (VPC with one subnet and one Availability Zone) and as small as /28 prefix
length. Subnets within a single VPC cannot overlap.
Subnets are either public subnets, which means they are associated with a route table that has
internet connectivity via an internet gateway (IGW), or they are private subnets that have no route to
the internet. Newly created subnets are associated with the main route table of your VPC. In Figure
3, subnets 1 and 2 are public subnets, and subnets 3 and 4 are private subnets.

Route Tables
Route tables provide source-based control of Layer 3 forwarding within a VPC environment, which
is different than traditional networking where routing information is bidirectional and might lead
to asymmetric routing paths. Subnets are associated with route tables, and subnets receive their
Layer 3 forwarding policy from their associated route table. All route tables contain an entry for the
entire VPC CIDR in which they reside; the implication is any host (instance within your VPC) has
direct Layer 3 reachability to any other host within the same VPC. This behavior has implications
for network segmentation. An instance references the route table associated with its subnet for the
default gateway but only for destinations outside the VPC. Host routing changes on instances are
not necessary to direct traffic to a default gateway, because this is part of route table configuration.
Route tables cannot contain more specific routes than the VPC CIDR block. Any instance within a
VPC is able to communicate directly with any other instance, and traditional network segmentation
by subnets is not an option. Routes external to your VPC can have a destination that directs traffic to
an IGW, virtual private gateway (VGW), or another instance.
Route tables can contain dynamic routing information learned from Border Gateway Protocol (BGP).
No other routing protocols are supported within AWS. Routes learned dynamically show in a route
table as Propagated=YES.
A cursory review of route tables might give the impression of VRF-like functionality, but this is
not the case. All route tables contain a route to the entire VPC address space and do not permit
segmentation of routing information less than the entire VPC CIDR address space within a VPC.
Traditional network devices must be configured with a default gateway in order to provide a path
outside the local network. Route tables provide a similar function without the need to change
instance configuration to redirect traffic. Route tables are used in these architectures to direct traffic
to the VM-Series firewall without modifying the instance configurations. Note in Figure 3 that both
route tables 1 and 2 contain the entire VPC CIDR block entry, route table 1 has a default route
pointing to the IGW, and route table 2 has no default route. A route to 172.16.0.0/16 was learned
via BGP, which is reachable via its VGW.

Figure 3. Subnets and route tables
V PC us-west-2 (Oregon)
Internet Gateway (IGW) VPN Gateway (VGW)
Destination Target Status Propagated Destination Target Status Propagated

10.0.0.0/16 local Active No 10.0.0.0/16 Local Active No
0.0.0.0/0 igw Active No 172.16.0.0/16 vgw Active Yes
Route Table 1 Route Table 2
10.0.1.0/24 10.0.2.0/24 10.0.3.0/24 10.0.4.0/24
Subnet 1 Subnet 2 Subnet 3 Subnet 4

us-west-2a us-west-2b us-west-2c
10.0.0.0/16
Network Access Control Lists

Network ACLs provide Layer 4 control of source/destination IP addresses and ports, inbound and
outbound from subnets. Every route table contains a route to the entire VPC, so to restrict traffic
between subnets with your VPC, you must use network ACLs. When a VPC is created, there is
a default network ACL associated with it, which permits all traffic. Network ACLs do not provide
control of traffic to Amazon reserved addresses (first four addresses of a subnet) nor of link local
networks (169.254.0.0/16), which are used for VPN tunnels.
Network ACLs:
Are applied at subnet level.

Have separate Inbound and Outbound policies.
Have Allow and Deny Action rules.
Are stateless. Bidirectional traffic must be permitted in both directions.
Are rule-order dependent. The first match rule (allow/deny) applies.
Apply to all instances in the subnet.

Security Groups
Security groups provide a Layer 4 stateful firewall for control of the source/destination IP addresses
and ports that are permitted. SGs are applied to an instance’s network interface. Up to five SGs
can be associated with a network interface. AMIs available in the Marketplace have a default SG
associated with them.
Security Groups:
Apply to the instance network interface.

Allow Action rules only. There’s no explicit Deny action.
Have separate Inbound and Outbound policies.
Are stateful. Return traffic associated with permitted traffic is also permitted.
Are rule-order independent.
SGs define only network traffic that should be explicitly permitted. Any traffic not explicitly permitted
is implicitly denied. There are no explicit deny actions. SGs have separate rules for inbound and
outbound traffic from an instance network interface. SGs are stateful, meaning that return traffic
associated with permitted Inbound or Outbound traffic rules is also permitted. When you create a
new SG, the default setting contains no Inbound rule and the Outbound rule permits all traffic. The
effect of this default is to permit all network traffic originating from your instance outbound, along
with its associated return traffic, and to permit no external traffic origination inbound to an instance.
Figure 4 illustrates how network ACLs are applied to traffic between subnets and SGs are applied to
instance network interfaces.

Figure 4. Security groups and network access control lists
VPC us-west-2 (Oregon)
Network Network
Network ACL Network ACL
ACL ACL
Subnet3 Subnet4
Subnet1 Subnet2
Security Group Security Group

(App Servers) (Web Servers)
Host Host Host Host Host Host Host Host
Subnet1 Subnet2 Subnet3 Subnet4

us-west-2a us-west-2b us-west-2c
10.0.0.0/16
Source and Destination Check

Source and destination checks are enabled by default on all network interfaces within your VPC.
Source/Dest Check validates whether traffic is destined to, or originates from, an instance and
prevents any traffic that does not meet this validation. A network device that wishes to forward
traffic between its network interfaces within a VPC must have the Source/Dest Check disabled on
all interfaces that are capable of forwarding traffic. To pass traffic through the VM-Series firewall, you
must disable Source/Dest Check on all dataplane interfaces (ethernet1/1, ethernet1/2, etc.). Figure
5 illustrates how the default setting (enabled) of Source/Dest Check prevents traffic from transiting
between interfaces of an instance.
bbonly
SGs and Source/Dest Check can be changed on the instance. These changes apply
to the first interface (eth0) of the instance. For the VM-Series, the first interface
represents the management interface. To avoid ambiguity, SGs and Source/Dest Check
should be applied to individual network interfaces.

Figure 5. Source and destination check
src: 10.0.2.15
x
dst: 10.0.1.10
src: 10.0.1.10
x
10.0.1.10 dst: 10.0.2.15 10.0.2.15
Source/Dest. Check – Enabled (default)
src: 10.0.2.15
dst: 10.0.1.10
src: 10.0.1.10
10.0.1.10 dst: 10.0.2.15 10.0.2.15
Source/Dest. Check – Disabled
Internet Gateway
An IGW provides a NAT mapping of an internal VPC address to a public IP address owned by AWS,
known as an Elastic IP. This 1:1 private/public IP address mapping is part of a network interface
configuration of each instance. After creating a network interface, you can then associate an Elastic
IP to create the 1:1 NAT associated between both public and VPC private IP addresses. For internet
connectivity to your VPC, there must be an associated IGW. The main route table in your VPC
contains a default route (0.0.0.0/0) pointing to the IGW. The IGW resides in all Availability Zones of
your VPC.
Virtual Private Gateway

The VGW provides a VPN concentrator service attached to a VPC for creation of IPsec tunnels.
The tunnels provide confidentiality of traffic in transit and can be terminated on almost any device
capable of supporting IPsec. A VGW creates IPsec tunnels to a customer gateway; these constitute
the two tunnel endpoints for redundancy. This reference architecture uses IPsec tunnels to provide
secure connectivity from your subscriber VPCs over the public internet. Like with IGWs, the VGW
resides in all Availability Zones of your VPC.

Customer Gateway
A customer gateway identifies the target IP address of a peer device that terminates IPsec tunnels
from the VGW. This reference architecture uses VM-Series as the CGWs to terminate IPsec tunnels
from your subscriber VPCs.
VPN Connections
VPN connections are the IPsec tunnels between your VGW and CGW. VPN connections represent
two redundant IPsec tunnels from a single CGW to two public IP addresses of the VGW in your
subscriber VPC. When creating an VPN connection, you have the option of running dynamic
routing protocol (BGP) over the tunnels or using static routes. Dynamic routing provides resilient
network connectivity and is used in the reference architecture. After creating the VPN connections,
a template configuration in CLI format containing IP addresses, IPsec tunnel security, and BGP
configuration for the CGW device is downloaded and used to configure the firewall.
The AWS VPN connection configuration template for your VM-Series provides moderate security
for IPsec tunnel and IKE gateway crypto profiles. The template makes use of SHA-1 hash for
authentication of both IKE gateway and IPsec tunnels, which is now considered insecure and has
been deprecated for use in SSL certificates. Table 1 shows the template configuration provided
by AWS for both IKE and IPsec Crypto on the first line, and compatible versions as a top-down,
ordered list of higher to lower security for IKE and IPsec crypto profiles on your VM-Series. For
IPsec Diffie-Hellman protocol, only a single compatible option can be selected within the firewall
configuration. The VGW accepts any of the options in Table 1 for IKE crypto settings and any options
in Table 2 for IPsec crypto settings. Negotiation of crypto profile settings is done at the time of
tunnel establishment, and there is no explicit configuration of VGW crypto settings. You can change
your firewall crypto settings at any time, and the new settings reestablish the IPsec tunnels with
the compatible new security settings. Firewalls prefer options in top-down order. Your firewall uses
more secure options first (as shown in Table 1 and Table 2), or you can choose any single option you
prefer.
bbgcm)
Use of Galois Counter Mode options for IPsec Crypto Profile (aes-128-gcm or aes-256-
in your firewall configuration prevents VPN tunnels from establishing with your VPN
Gateway.
Table 1. Firewall and VGW compatible IKE Crypto Profile
IKE Crypto Profile Diffie-Hellman Hash Encryption

AWS template Group2 SHA-1 AES-128-CBC
Firewall compatible Group14 SHA-256 AES-256-CBC
Group 5 SHA-1 AES-128-CBC
Group2

Table 2. Firewall and VGW compatible IPsec Crypto Profile
IPsec Crypto Profile Diffie-Hellman Hash Encryption

AWS template Group2 SHA-1 AES-128-CBC
Firewall compatible Group14 SHA-256 AES-256-CBC
Group 5 SHA-1 AES-192-CBC
Group2 AES-128-CBC
The VPN connection represents a /30 IP network, which is user specified at the time of creation.
Elastic IP Address
Elastic IP addresses are AWS-owned, public IP addresses that you allocate and associate with an
instance network interface in your VPC. After they are associated, a network address translation is
created in the VPC IGW that provides 1:1 translation between the public IP address and the network
interface VPC private IP address. This permits direct internet access to your instance network
interface. Elastic IPs are used to provide internet connectivity to the VM-Series for management and
as an external “Untrust” interface providing firewall protected internet traffic to your VPC instances.
Elastic IP addresses have an hourly cost associated with each allocated IP address.
Elastic Network Interface

Elastic network interfaces are virtual network interfaces that are attached to instances and appear as
network interfaces to its instance host. ENI characteristics:
Private IPv4 address

Elastic public IPv4 address
IPv6 Address
One or more SGs
Source/destination check
Within the same Availability Zone, ENIs can be attached and reattached to another instance up to
the maximum number of interfaces supported by the instance type, and the ENI characteristics are
then associated with its newly attached instance.
Instance
An instance represents a virtual server that is deployed within a VPC. Much like their physical
counterparts, the virtual server on which your instance resides has various performance
characteristics: number of CPUs, memory, and number of interfaces. You have the option to optimize
the instance type based your application performance requirements and cost. You can change
the instance type for instances that are in the stopped state. Hourly operating costs are based on
instance type and region.

Amazon Machine Image

AMIs are virtual machine images available in the Amazon Marketplace for deployment as a VPC
instance. AWS uses public key authentication for access to new instances. A key pair can be used to
access many instances, and key pairs are only significant within a region. Key pairs can be generated
within a VPC. with you downloading the private key, or the public key can be imported to create a
key pair. Either way, it’s very important that the private key is protected, because it’s the only way
to access your instance. When you create an instance, you specify the key pair to be used, and
you must confirm your possession of the matching key at the time of instance creation. New AMIs
have no default passwords and the key pair is used to access your instance. AMIs have a default SG
associated with them and instructions for how to access the newly created instance. AMIs might
have an hourly operating cost.
AWS Direct Connect

AWS Direct Connect allows you to connect your network infrastructure directly to your AWS
infrastructure using private, dedicated bandwidth from a telecommunications provider. This direct
connection provides some advantages:
Hardware firewalls support

Higher bandwidth network connections
Lower bandwidth costs
Consistent network transport performance
Arbitrary inter-VPC traffic inspection/enforcement
AWS Direct Connect requires a network device, provided by you, to terminate the network
connection from the AWS backbone network. This same device also terminates your carrier
connection, completing the path between your private network and your AWS infrastructure. This
reference architecture uses Palo Alto Networks hardware firewall appliances as your co-location
network termination. AWS Direct Connect provides dedicated port options for 1 Gbps and 10
Gbps, and AWS partners provide hosted connections with options for 50-500 Mbps. Your firewalls
exchange BGP routing information with the AWS network infrastructure. There is no static routing
available. AWS charges for data that egresses from your AWS infrastructure as data-out. Charges
for data transfers are at a lower rate than using public internet. Because carrier-provided bandwidth
is dedicated to your use, this connection tends to have more consistent performance than public
internet transport.
For organizations requiring higher firewall performance and high-availability options offered
by physical firewall appliances, AWS Direct Connect might be the ideal solution. It provides a
direct connection from your hardware firewalls to each of your VPCs within the AWS Direct
Connect region. The port is an 802.1Q VLAN trunk. Virtual interfaces are created on the AWS
Direct Connect, and these virtual interfaces are then associated with a VPC via its VGW. Layer
3 subinterfaces on the firewall are tagged with the VLAN of the virtual interface, completing
the connection to your VPC. All VPCs within the region of your AWS Direct Connect can have a
connection to your firewall so that arbitrary security policy between VPCs is an option.

Virtual interfaces are of two types: public and private. As the name implies, private virtual interfaces
provide a private communication path from the AWS Direct Connect port to a VPC. Public virtual
interfaces provide access to other AWS services via their public IP addresses such as S3 storage.
Public virtual interfaces require the use of a public IP address. They may be public address space that
you already own, or the public IP address may be provided by AWS. Your BGP peering connection
between hardware firewalls and AWS requires the use of a public virtual interface.
An AWS Direct Connect has a limit of 50 virtual interfaces, if you require more than 50 VPCs
in a region, multiple connections might be required. For redundancy, you can also use multiple
connections within a region.
AWS Security and Traffic Types

There are three traffic-flow types that you might wish to inspect and secure:
Inbound—traffic originating outside and destined to your VPC hosts

Outbound— traffic originating from your VPC hosts and destined to outside
East/West— traffic between hosts within your VPC infrastructure
Inbound Traffic Inspection

Inbound traffic originates outside, destined to services hosted within your VPC, such as web servers.
Enforcing firewall inspection of inbound traffic requires Destination NAT on the VPC firewall. AWS
provides a 1:1 NAT relationship with public Elastic IP addresses and VPC private IP addresses and
does not modify the source or destination ports. There are two options for providing inbound
inspection for multiple servers through the firewall:
Destination IP address and port-mapping using a single Elastic IP address

Network interface secondary IP addresses and multiple Elastic IP addresses
Elastic IP addresses have a cost associated with their use. The first option above minimizes Elastic
IP cost with an increase in Destination NAT complexity on the firewall, as well as potential end-
user confusion when they are accessing multiple inbound services using the same DNS Name or IP
address with a different port representing different servers.
A single service port (that is, SSL) may have its external IP address mapped to a single server internal
IP address provided the service. Additional servers that provide the same service are represented
externally as offering their service on the same external IP address. The service port is used to
differentiate between servers having the same external IP address.
Figure 6 illustrates the dynamic nature of networking, showing what actions occur when packets
transition from state to state:
Packet 1 to packet 2—The IGW translates the packet’s destination address.

Packet 2 to packet 3—The firewall translates the packet’s destination IP address (and
optionally port).
Packet 5 to packet 6—The firewall translates the source IP address to the firewall internet
interface to match the IGW NAT.
Packet 6 to packet 7—The IGW translates source IP address to the public EIP address.

Figure 6. Inbound traffic inspection using Destination NAT address and port
1 dst = 52.1.7.85:80 2 dst = 10.0.3.18:80

src = 15.0.201.45 src = 15.0.201.45
Subnet 3 - 10.0.3.0/24
dst = 15.0.201.45 7
dst = 15.0.201.45
6
src =52.1.7.85
src = 10.0.3.18
Public IP Address Private IP Address

52.1.7.85 10.0.3.18
IGW NAT Table 10.0.3.18
e2
dst = 10.0.1.10:80 3
src = 15.0.201.45
e3
5 dst = 15.0.201.45
src = 10.0.1.10
10.0.1.10 Subnet1 - 10.0.1.0/24

e0
W eb dst = 10.0.1.10:80 Destination Target Status Propagated

10.0.0.0/16 Local Active No
src = 15.0.201.45 4 0.0.0.0/0 fw-e3 Active No
Subnet1 Route Table
Outbound Traffic Inspection

Outbound traffic is originating from your VPC instances, destined to external destinations, typically
the internet. Outbound inspection is useful for ensuring that instances are connecting to permitted
services (such as Windows Update) and permitted URL categories, as well as for preventing data
exfiltration of sensitive information. Enterprise networks often make use of Source NAT at their
internet perimeter for outbound traffic, in order to conserve limited public IPv4 address space and
provide a secure one-way valve for traffic. Similarly, outbound traffic from your VPCs that require
firewall inspection also makes use of Source NAT on the firewall, ensuring symmetric traffic and
firewall inspection of all traffic.
Figure 7 illustrates outbound traffic flow. Packet 1 has its source IP address modified to that of the
firewall interface in packet 2.

Figure 7. Outbound traffic inspection using Source NAT

Destination Target Status Propagated
4 dst = 52.134.76.85 5 dst = 10.0.3.18 0.0.0.0/0 fw-e3 Active No
src = winupdate src = winupdate Subnet3 Route Table
Subnet 3 - 10.0.3.0/24
dst = winupdate 3
src =52.134.76.85 dst = winupdate 2
src = 10.0.3.18
Public IP Address Private IP Address
52.134.76.85 10.0.3.18
IGW NAT Table 10.0.3.18
e2
dst = 10.0.1.10 6
src = winupdate
e3
1 dst = winupdate
src = 10.0.1.10
10.0.1.10 Subnet1 - 10.0.1.0/24

e0
W eb dst = 10.0.1.10 Destination Target Status Propagated

src = winupdate 7 0.0.0.0/0 fw-e3 Active No
Subnet1 Route Table

East/West Traffic Inspection

Network segmentation using route policy between subnets is a well-understood principle in network
design. You group services of a similar security policy within a subnet and use the default gateway as a
policy-enforcement point for traffic entering and exiting the subnet. AWS VPC networking provides direct
reachability between all instances within the VPC, regardless of subnet association; there are no native
AWS capabilities for using route policy-segmentation between subnets within your VPC. All instances
within a VPC can reach any other instance within the same VPC, regardless of route tables. You can use
network ACLs to permit or deny traffic based on Layer 4 IP address and port between subnets, but this
does not provide the visibility and policy enforcement for which many prefer VM-Series. For those wishing
to use the rich visibility and control of firewalls for east/west traffic within a VPC, there are two options:
For every instance within a subnet, configure routing information to forward traffic to the
firewall for inspection.
Use a floating NAT configuration on the firewall to direct intra-VPC subnets through the firewall,
and use network ACLs to prevent direct connectivity.
You can use instance routing policy to forward traffic for firewall inspection by configuring the instance
default gateway to point to the firewall. An instance default gateway configuration can be automated
at time of deployment via User Data field—or manually after deployment. Although this approach
accomplishes the desired east/west traffic inspection, the ability for the instance administrator to change
the default gateway at any time to bypass firewall inspection might be considered a weakness of this
approach. For inspection of traffic between two instances within the same VPC, both instances must be
using the firewall as default gateway in order to ensure complete visibility; otherwise, there is asymmetric
traffic through the firewall.
Using VPC route tables to forward traffic to the firewall for inspection removes the requirement to make
changes to instance configurations, along with removing the associated security risk of local instance
administrator bypassing the firewall. VPC routing always provides direct network reachability to all
subnets within the VPC. You can only modify route table behavior for networks outside the local VPC
CIDR block. Using intra-VPC routing policy to forward traffic for firewall inspection requires the use of
floating NAT configuration. For both source and destinations servers, floating NAT creates a virtualized IP
address subnet, which resides outside the local CIDR block, thus permitting route table policy to forward
all floating NAT IP address to the firewall for inspection. The design pattern for floating NAT is identical
to the scenario where you want to interconnect to two networks having overlapping IP address space; for
overlapping subnets you must use Source and Destination NAT. Network ACLs are used between the two
local subnets to prevent direct instance connectivity. For each destination virtual server desired, floating
NAT requires a NAT rule for both source and destination on the firewall, so it’s a suitable design pattern
for smaller deployments. When your AWS infrastructure grows in number of instances, you’ll want to
consider other design architectures presented later. Consider grouping instances within VPCs of similar
security policy; East/West inspection of inter-VPC becomes much simpler.
Figure 8 illustrates some of the details of floating NAT:
Packet 1 to packet 2—The firewall translates the destination IP address from the virtual server IP
address to its real IP address.
Packet 2 to packet 3—The firewall translates the real source IP address of the originating client
to its virtual IP address.
Packet 4 to packet 6—The firewall provides the same translation process in the reverse
direction.

Note that in this example, the last two octets of the IP address are identical across subnets in order
to make understanding the principle clearer, but there is no such requirement.
Figure 8. Floating NAT using Source and Destination NAT to provide intra-VPC firewall inspection
4
dst = 172.16.1.10
src = 10.0.2.17 App
e0
Subnet 2 - 10.0.2.0/24 10.0.2.17/24
3
dst = 10.0.2.17
src = 172.16.1.10 Destination Target Status Propagated
0.0.0.0/0 fw-e2 Active No
172.16.1.0/24 fw-e2 Active No
e2 Subnet2 Route Table
5 dst = 10.0.1.10 Rule # Type Protocol Port Range Destination Allow/Deny

src = 10.0.2.17 10 0 ALL Traffic ALL ALL 10 .0 .1.0/24 DENY
20 0 ALL Traffic ALL ALL 0.0.0 .0 /0 ALLOW
* ALL Traffic ALL ALL 0.0.0 .0 /0 DENY
Subnet2 Network ACL - Outbound
2 Rule # Type Protocol Port Range Destination Allow/Deny

10 0 ALL Traffic ALL ALL 10 .0 .1.0/24 DENY
20 0 ALL Traffic ALL ALL 0.0.0 .0 /0 ALLOW
dst = 10.0.2.17 * ALL Traffic ALL ALL 0.0.0 .0 /0 DENY
src = 10.0.1.10 Subnet1 Network ACL - Outbound
e3 Destination
10.0.0.0/16
Target
Local
Status
Active
Propagated
No
0.0.0.0/0 fw-e3 Active No
172.16.2.0/24 fw-e3 Active No
Subnet1 Route Table
dst = 172.16.2.17 1
src = 10.0.1.10
Subnet1 - 10.0.1.0/24 10.0.1.10/24

e0
6 dst = 10.0.1.10 W eb
src = 172.16.2.17

Palo Alto Networks VM-Series Licensing on

AWS
You purchase licenses for VM-Series firewalls on AWS through the AWS Marketplace or through
traditional Palo Alto Networks channels.
Pay as you go (PAYG)—Also called a usage-based or pay-per-use license. You purchase this type of
license from the AWS public Marketplace, and it is billed annually or hourly. With the PAYG license,
VM-Series are licensed and ready for use as soon as you deploy them; you do not receive a license
authorization code. When the firewall is stopped or terminated on AWS, the usage-based licenses
are suspended or terminated. PAYG licenses are available in the following bundles:
Bundle 1—Includes a VM-300 capacity license, Threat Prevention license (IPS, AV, and Anti-
Spyware), and a premium support entitlement.
Bundle 2—Includes a VM-300 capacity license, Threat Prevention license (IPS, AV, malware
prevention), GlobalProtect™, WildFire™, PAN-DB URL Filtering licenses, and a premium
support entitlement.
An advantage of the Marketplace licensing option is the ability to use only what you need, deploying
new VM-Series instances as needed, then removing them when they’re not in use.
Bring your own license (BYOL) and VM-Series Enterprise License Agreement (ELA)—A license
that you purchase from a channel partner. VM-Series firewalls support all capacity, support, and
subscription licenses in BYOL. When using BYOL, you license VM-Series firewalls like a traditionally
deployed appliance, and you must apply a license authorization code. After you apply the code to
the device, the device registers with the Palo Alto Networks support portal and obtains information
about its capacity and subscriptions. Subscription licenses include Threat Prevention, PAN-DB URL
Filtering, AutoFocus, GlobalProtect, and WildFire.
The VM-Series ELA provides a fixed price licensing option, allowing unlimited deployment of
VM-Series firewalls with BYOL. Palo Alto Networks offers VM-Series ELAs in one and three-year
term agreements. An advantage of BYOL is the ability to choose different capacity licenses for the
VM-Series compared to the two VM-300 bundle options. As of PAN-OS® version 8.0, Palo Alto
Networks supports use of VM-100/VM-200, VM-300/1000-HV, VM-500, and VM-700 on AWS,
using instance types that support the requirements for each VM firewall. BYOL provides additional
flexibility in that the license can be used on any virtualization platform (VMware, AWS, Azure) and is
transferrable. For more information about instance sizing and the capacities of Palo Alto Networks
VM firewalls, see VM-Series for Amazon Web Services.
bbsupported
When creating a new instance from a Marketplace AMI, AWS offers only instance types
by the AMI. The instance type chosen determines the CPU, memory, and
maximum number of network interfaces available. For more information, see Amazon
EC2 Instance Types in the AWS documentation.
Palo Alto Networks VM-Series Licensing on AWS 21

Palo Alto Networks Firewall on AWS

AWS VPCs make extensive use of Dynamic Host Configuration Protocol (DHCP) to assign network
address and associated information such as netmask, default gateway, and DNS server. For most
network interfaces, using DHCP to provide the automated network configuration is very helpful.
Although you can configure network interfaces on your VM-Series to use DHCP, there are a couple
reasons why you would not want to do so: BGP peering and IKE Gateways both require a static
IP address be configured on the firewall to be used for their respective configurations. A second
characteristic of DHCP configuration is the ability to automatically create a default route within the
virtual router, based on the default gateway provided by DHCP. Because you are not using DHCP, a
static default route needs to be configured.
bbaddress
While building out your infrastructure, you might find it useful to assign an Elastic IP
to your application instances that will be placed behind the firewall and install a
host-specific route within the protected subnet’s route table for your public IP address
from which you’ll access AWS. The host route points directly to the VPC IGW while the
default route points to the firewall internal interface. This permits direct access to your
instances for configuration and testing from your source IP address only. Don’t forget to
disable this host route when verifying traffic through the firewall, or test from a different
IP address.
The AMI configuration for your VM-Series firewall provides a network interface, the primary
interface for the instance (eth0), as the management interface. Additional ENIs attached to the
VM-Series provide dataplane interfaces in consecutive order as instance eth1 (firewall ethernet1/1),
instance eth2 (firewall ethernet1/2), instance eth3 (firewall ethernet1/3), etc. When you create your
firewall instance, the first two interfaces can be swapped in function for use with Amazon Elastic
Load Balancer via the User Data field. This configuration is not addressed in this guide.
22 Palo Alto Networks Firewall on AWS

Building a Secure AWS Infrastructure

Now that you understand the basic AWS components and how you can use your VM-Series,
you next use them to build your secure infrastructure. You can use the scenarios in this section
individually (as standalone and complete), combined with one another, or as adjuncts to other
components not covered in this guide. This architecture is intended as a building block for
constructing a secure cloud infrastructure that meets your current and future requirements.
For example, you might create a web farm as a single VPC, then extend it to back-end database
servers in another VPC via VPC peering. This would prevent direct internet access to database
servers, and only web servers would have direct access.
In another example, you might create a traditional enterprise infrastructure in the cloud. IT provides
internet access and common services in a transit VPC, with various business functions having their
own subscriber VPCs. With some subscriber VPCs requiring their own direct internet access, the
“Transit VPC” scenario could be used to provide this capability.
This reference architecture addresses the following scenarios:
Single VPC—Single purpose or small-scale deployments

Transit VPC—General purpose scalability
VPC Peering—Direct VPC Peering within a region
AWS Direct Connect—Large scale deployments, dedicated bandwidth, hardware appliances
Single VPC
A single standalone VPC might be appropriate for small AWS deployments that do not require
geographic diversity provided by multiple regions. For application high-availability, the architecture
consists of a pair of VM-Series in each of two Availability Zones within your VPC Region, and they
are capable of inbound, outbound, and east/west traffic inspection. SGs and network access control
lists can be used to further restrict traffic to individual instances and between subnets. This design
pattern provides the foundation for other architectures in this guide.
Building a Secure AWS Infrastructure 23

Figure 9. Single VPC architecture
Service-2a us-west-2a
Internet-2a 10.0.0.0/24
10.0.2.0/28
Web1-2a
e0
IGW NAT translations 10.0.0.146
e0
52.32.153.200 (fw-2a-mgt) 10.0.2.13
e2
10.0.0.184
e1
35.162.12.158 (fw-2a-internet) 10.0.2.6
54.70.112.212 (web1-2a) 10.0.2.7 Web2-2a
54.186.29.1 (web2-2a) 10.0.2.9 e0
fw-2a 10.0.0.127
Network Access Control List(s)

(Optional)
internet
IGW NAT translations Web1-2b

e0
e0 10.0.1.111
54.148.148.207 (fw-2b-mgt) 10.0.3.10 e2
10.0.1.38
e1
35.164.188.250 (fw-2b-internet) 10.0.3.14
34.212.238.47 (web1-2b) 10.0.3.13
34.208.90.172 (web2-2b) 10.0.3.12
fw-2b Web2-2b
e0
Internet-2b 10.0.1.123
10.0.3.0/28
Service-2b
10.0.1.0/24
us-west-2b
VPC 10.0.0.0/16
Assuming you have no current AWS infrastructure in place, you’ll begin with the basics by creating
a VPC and an SSH security key required to access all instances deployed within your VPC. AMIs
deployed within AWS have no default password and require the SSH public key pair for access. After
you create the key pair, you are provided with the matching private key file (PEM) for download.
24 Building a Secure AWS Infrastructure

Configuring AWS Basics for a Single VPC

Use the following procedures to configure a single VPC.
Quick Star
ÌÌ Procedure 1: Create a VPC

ÌÌ Procedure 2: Create Network Subnets and Route Tables
ÌÌ Procedure 3: Place Firewalls into Availability Zones
ÌÌ Procedure 4: Attach Network Interfaces to Your Firewalls
ÌÌ Procedure 5: Connect to your Firewalls in order to Enable webUI Admin Access
ÌÌ Procedure 6: Additional Firewall Configuration
Procedure 1: Create a VPC

The following steps create a VPC and provide internet connectivity via an IGW.
Step 1. Create a VPC, choosing a CIDR IP address block of appropriate size.
Step 2. Create an Internet Gateway, and then attach it to your newly create VPC.
Step 3. Create a key pair used to securely access your instances.
Step 4. Save the private key file. Your system might enforce higher security for the protection of
your SSH private key file. Mac OSX requires the file permissions be changed to prevent
the file being accessible by other users (chmod 400 keyfile.pem) and will not offer the
private key file for SSH authentication until the permissions are secured.
bbinstances.
Ensure you save your key file in a safe place, because it is only way to access your
Anyone with the file can also access your instances, and there is no option to
download a second time. If you lose the file, the only option is to destroy your instances
and recreate them.
Procedure 2: Create Network Subnets and Route Tables

The Single VPC architecture consists of a pair of VM-Series deployed across two Availability Zones
(-2a and -2b), each with publicly accessible management interfaces, as well as two dataplane
interfaces for Internet Zone and Service Zone. Outbound traffic uses Source NAT to an internet-
accessible IP address on the firewall, and inbound traffic uses Destination NAT. Protected server
instances are placed in the Service Zone.

The following steps create the network subnets within your VPC and are completed from VPC
Dashboard.
Step 1. Create two new subnets (Internet-2a and Internet-2b) for firewall management and Internet
network interfaces.
Step 2. Associate the subnets with the VPC Main route table.
Step 3. Create a default route (0.0.0.0/0) within Main route table, with a target of your VPC’s IGW).
Step 4. Create two additional subnets, with one in each AZ (Service-2a and Service-2b), ensuring
the IP address auto-assign is disabled. Failing to disable auto-assign function of the subnets
might expose your internal server to direct internet access.
Step 5. Create two route tables (Service-2a-RT and Service-2b-RT) and associate their respective
private subnets (Service-2a and Service-2b); you’ll modify the default route entry for each
route table after creating the firewalls in the next step.
Procedure 3: Place Firewalls into Availability Zones

Firewalls are deployed in each AZ with Management interface (eth0) placed in the internet subnet
of the respective AZs. When you deploy (Launch Instance) a VM-Series from Amazon Marketplace,
the initial configuration asks for the subnet. This selection places your new firewall instance in the
Availability Zone of the selected subnet and assigns an IP address to the management interface
from the chosen subnet and an associated public IP address. The AMI SG associated with VM-
Series permits tcp/22 and tcp/443 traffic to the management interface, which is suitable for most
applications.
The following steps deploy two firewalls, completed from EC2 Dashboard.
Step 1. Launch a firewall instance in both Availability Zones (fw-2a and fw-2b), choosing an instance
type that meets your needs from those available, and then confirm you wish to use the key
pair created earlier. Instance types can be changed for servers which have been stopped,
so you can always choose a different instance type later. Supported instance types are
still enforced as at initial deployment, but AWS does not make it obvious what types are
supported.
Step 2. To protect your important instances from accidental termination (deletion), it’s a good idea to
enable termination protection. Instances cannot be deleted when Termination Protection is
enabled. Protection must first be disabled before termination.
After the VM-Series firewalls have been deployed, it can take several minutes before you can
access them. You’ll need to wait until Instance Status Checks shows 2/2. To permit traffic through
your firewall, you need to provide dataplane interfaces for your VPC traffic. The order in which
network interfaces are attached to firewall instances is important, because they are reflecting within
the firewall in the order in which they were attached (ethernet1/1, ethernet1/2, etc.). AWS VPN
templates (used in later architectures) assume internet connectivity is on ethernet1/1, so to maintain
compatibility, it is recommended you attach the internet network interface first.

Procedure 4: Attach Network Interfaces to Your Firewalls
Step 1. Create an SG to permit traffic to firewall network interfaces, this guide assumes SG
associated with firewall network interfaces permit all traffic, Inbound and Outbound Rules:
All Traffic, Anywhere.
The next steps allocate public IP addresses (Elastic IPs) for firewall management and internet facing
data interface, they are accomplished from EC2 Dashboard.
Step 2. Allocate four Elastic IP addresses, two for firewall management access and two for firewall
internet interfaces.
Step 3. Create four network interfaces (ENIs), two for each firewall, one in each of public Internet
subnets (Internet-2a and Internet-2b) and one in each of private Service subnets (Service-
2a and Service-2b).
Step 4. Associate the allocated Elastic IP addresses with each of the above network interfaces.
There should only be a single private IP for each network interface, in later designs there
can be multiple private IPs.
Step 5. Disable Source/Dest Check on all firewall dataplane interfaces.
bbprevents
Step 5 is very important. Failure to disable Source/Dest Check on your firewall interfaces
any traffic flowing through your firewalls.
Step 6. Attach the network interfaces to each of their respective firewalls, beginning with Internet-
2a and Internet-2b first, then additional interfaces. You’ll only see instances within the
same Availability Zone as the network interface.
Step 7. Optionally create network access control list(s) to restrict traffic between subnets within
your VPC. By default, all instances within your VPC can communicate directly.
Procedure 5: Connect to your Firewalls in order to Enable webUI Admin Access
Step 1. Using SSH, connect to your firewall management port public IP address. How you
accomplish this depends on the system you’re using. For information about accessing your
AWS instances, see Connect to Your Linux Instance in the AWS documentation. Mac and
Linux clients use native cli command for ssh access.
ssh –i /path-to-key-pair/keypair.pem admin@<firewall-mgmt-elastic-ip-address>
Step 2. When you first connect to your firewall, there is no password required, because the key file
was used for authentication. Enabling webUI access to your firewall requires you set a
password for the admin account, because there is no default.
fw-2a> configure
fw-2a# set mgt-config users admin password
Enter password : ********
Confirm password : ********
fw-2a# commit

Step 3. In your browser, connect to your firewall management IP address. Use admin account and
password. (https://<firewall-mgmt-elastic-ip-address>)
At this point you should have two functional firewalls with public IP addresses on their management
interfaces and the network connectivity to deploy protected instances.
Procedure 6: Additional Firewall Configuration
Step 1. Configure your firewall network interfaces to use IP addresses assigned to VPC network
interfaces attached to the firewall.
Step 2. Create a static default route in the firewall virtual router, using the IGW’s Internet-2a and
Internet-2b subnet IP addresses as the next hop IP address. The default gateway of all
subnets is the first available IP address of the subnet.
The design makes use of additional public IP addresses for direct access to protected instances
(web1 and web2). Additional VPC private IP addresses can be added to an instance network
interface by using the Manage IP Addresses option, and an Elastic IP address assigned by the
Associate Address option. Destination NAT policy is then created in the firewall to direct inbound
connections.
Transit VPC
When your AWS infrastructure grows in number of VPCs, for scalability or the desire to segment
east/west traffic between VPCs, the question of how to secure your infrastructure arises. One
option is to continue using the Single VPC design. The cost and complexity of firewalls required
grows linearly with the number of VPCs. A popular option is the Transit VPC architecture. This design
pattern is a hub and spoke consisting of a central Transit VPC hub and Subscriber VPCs as spokes.
The Transit VPC provides common security policy for inbound and outbound traffic of Subscriber
VPCs, east/west segmentation between Subscriber VPCs, and shared infrastructure for services such
as DNS, identity, and authentication. The architecture provides VM-Series security capabilities on
AWS while minimizing cost and complexity of deploying firewalls in every VPC.
A Transit VPC easily accommodates organizations wanting to enable distributed VPC ownership
to different business functions (engineering, sales, marketing, etc.) while maintaining common
infrastructure and security policies, as well as accommodating organizations that wish to consolidate
ad hoc VPCs infrastructure within a common infrastructure. Transit VPC architecture provides a
scalable infrastructure for east/west inspection of traffic between VPCs.
Transit VPC builds upon the Single VPC, using the same design for the Transit hub, with a pair of VM-
Series firewalls in each of two Availability Zones. Subscriber VPCs are connected via an IPsec overlay
network consisting of redundant pair of VGW connections to each VM-Series within the Transit VPC
firewall. Dynamic routing using BGP provides fault tolerant connectivity between the Transit VPC
and Subscriber VPCs.
Inbound traffic uses Destination NAT policy on the firewalls and requires the addition of Source NAT
to ensure symmetric return traffic through the original firewall. Outbound traffic continues to use
Source NAT as in the Single VPC design, and east/west traffic between VPCs passes through the
Transit VPC firewalls for policy enforcement.

Figure 10. Transit VPC
Sub1-2a
172.16.1.0/25
e0
App1-2a
us-west-2a
Service-2a 172.16.1.111
Internet-2a 10.0.0.0/24
10.0.2.0/28
DNS-2a 172.16.1.181
e0
e0
e0 App1-2b
10.0.2.13 Sub1-2b
e2 172.16.1.128/25
e1
35.162.12.158 (fw-2a-internet) 10.0.2.6
54.70.112.212 (app1-2a) 10.0.2.7 Auth-2a Subscriber VPC #1
54.186.29.1 (app2-2a) 10.0.2.8 e0
52.16.2.117 (app3-2a) 10.0.2.9 fw-2a
Sub2-2a
172.16.2.0/25
e0
App2-2a
172.16.2.112
172.16.2.182
e0
App2-2b
Sub2-2b
172.16.2.128/25
DNS-2b
e0
e0 Subscriber VPC #2
10.0.3.10 e2
35.164.188.250 (fw-2b-internet) e1 Sub3-2a
10.0.3.14
34.212.238.47 (app1-2b) 10.0.3.13 172.16.3.0/25
34.208.90.172 (app2-2b) 10.0.3.12
52.212.9.17 (app3-2b) 10.0.3.11 fw-2b Auth2-2b e0
e0 App3-2a
Internet-2b 172.16.3.113
10.0.3.0/28
Service-2b
10.0.1.0/24
172.16.1.183
us-west-2b
e0
Transit VPC App3-2b
Sub3-2b
172.16.3.128/25
Subscriber VPC #3
The IGW provides Destination NAT as usual to a firewall secondary IP address (packet 1-2). When
received by the firewall, both Source and Destination NAT are applied (packet 2-3). Source NAT is
required in order to ensure the return traffic remains symmetric through the receiving firewall, if you
did not apply Source NAT, the VGW routing table might have chosen the other firewall for its default
route back to the internet, and the session would fail due to asymmetry. The return traffic from the
Subscriber instance is sent back to the translated source address of the firewall to match the existing
session and the reciprocal Source and Destination NAT translations are applied (packet 4-5). Lastly
the IGW modifies the source address to the public Elastic IP address (packet 5-6). Note that for
inbound traffic, the originating host IP address is opaque to the destination Subscriber VPC instance,
because it was source translated by the firewall. All inbound traffic appears to be originating for the
same source host.

Figure 11 provides details of Source and Destination NAT required for inbound traffic.
Packet 1 to packet 2—The IGW translates the destination IP address to its matching
firewall IP address.
Packet 2 to packet 3—The firewall translates the destination IP address to the IP address
of the destination server and translates the source IP address from the original internet IP
address to the firewalls ingress IP address.
Packet 4 to packet 5—The firewall translates the destination address from the firewall’s IP
address to the destination’s internet IP address and the source IP address of the server to
the firewall’s internet-facing IP address.
Packet 5 to packet 6—The IGW translates the source IP address to the matching public EIP
address.
Figure 11. Source/Destination NAT for Inbound Subscriber VPC traffic
6 5 4
dst = 129.219.1.24 dst = 129.219.1.24 dst = 10.0.2.7

src = 54.70.112.212 src = 10.0.2.7 src = 172.16.1.111 e0
tun1 IPsec tunnel 172.16.1.111

e1
IGW
dst = 54.70.112.212 dst = 10.0.2.7 dst = 172.16.1.111
src = 129.219.1.24 src = 129.219.1.24 src = 10.0.2.7
1 2 3
54.70.112.212 (app1-2a) 10.0.2.7 10.0.2.7 172.16.1.111

54.186.29.1 (app2-2a) 10.0.2.8 10.0.2.8 172.16.2.112
52.16.2.117 (app3-2a) 10.0.2.9 10.0.2.9 172.16.3.113
Outbound traffic requires only Source NAT on the firewall in order to ensure traffic symmetry. The
VGW BGP default route determines the outbound direction of all internet traffic and, in so doing,
the Source NAT IP address used for the associated outbound traffic. The outbound traffic is initiated
to the direct internet IP addresses desired and forwarded to the firewall by VGW, at the firewall.
Figure 12 provides details of Source NAT used for Outbound Subscriber VPC instance traffic.
Packet 1 to packet 2—The firewall translates the source IP address to one of its internet-
reachable IP addresses.
Packet 2 to packet 3—The IGW translates source IP address to the matching public EIP
address.
Packet 4 to packet 5—The IGW translates the public EIP address to the matching firewall IP
address.
Packet 5 to packet 6—The firewall translates the destination IP address to the original
client IP address.
For outbound traffic, the original internet IP address of the destination host is maintained.

Figure 12. Source NAT for Outbound Subscriber traffic
3 2 1
dst = 129.219.1.24 dst = 129.219.1.24 dst = 129.219.1.24

src = 54.70.112.212 src = 10.0.2.7 src = 172.16.1.111 e0
tun1 IPsec tunnel 172.16.1.111

e1
IGW
dst = 54.70.112.212 dst = 10.0.2.7 dst = 172.16.1.111
src = 129.219.1.24 src = 129.219.1.24 src = 129.219.1.24
4 5 6
54.70.112.212 (app1-2a) 10.0.2.7 10.0.2.7 172.16.1.111

54.186.29.1 (app2-2a) 10.0.2.8 10.0.2.8 172.16.2.112
52.16.2.117 (app3-2a) 10.0.2.9 10.0.2.9 172.16.3.113
VGW and BGP Routing
Subscriber VGWs’ implementation of BGP evaluates several criteria for best path selection. After
a path is chosen, all traffic for a given network prefix uses this single path; VGW’s BGP does not
support multipath, so only one destination route is installed. This behavior is most evident for
Outbound internet traffic from a Subscriber VPC, because all internet traffic takes a single path
regardless of connectivity. It can be desirable to influence the path selected to better distribute
Subscriber VPC traffic across each VM-Series firewall within the Transit VPC. You accomplish this by
using BGP Path Selection.
BGP Path Selection is a deterministic process based on an ordered list of criteria. The list is evaluated
top-down until only one “best” path is chosen and installed into the VGW routing table. The VGW
uses the following list for path selection criteria:
Longest prefix length

Shortest AS Path length
Path origin
Lowest multi-exit discriminator (MED)
Lowest peer ID (IP address)
The VPN connection templates provided by AWS have the first four criteria the same for every
configuration, so the default behavior is for path selection to choose the BGP peer (firewalls) with
the lowest IP address. The peer IP addresses are those assigned to the firewall tunnel interfaces and
specified by AWS. BGP Peer IP address is the least significant decision criterion, and one you cannot
change to influence path selection; however, there are ways to influence the path selection.
Prefix Length
Network efficiency and loop avoidance require that hosts and routers always choose the longest
network prefix for destination path selection. Prefix length can provide information regarding desired
routing policy but is most often related to actual network topology. This architecture uses prefix
length and NAT to ensure symmetric path selection in the absence of multi-path support by the
VGW for connectivity between Transit VPC and Subscriber VPCs.

The easiest way to consider this is to think of the two Availability Zones in your Transit VPC as
separate BGP routing domains within a single autonomous system. VM-Series firewalls within the
Transit VPC should only announce directly connected routes and a default route. You should avoid
BGP peering between firewalls within your Transit VPC because this will create an asymmetric path
for traffic arriving on the tunnel not being used by the VGW for outbound traffic.
AS Path Length
Autonomous systems (AS) Path length is the number of autonomous systems through which a route
path must traverse from its origin. Because our BGP AS is directly adjacent to that of the VGW,
AS Path length is always 1 unless modified by the firewall when advertised. If you could examine
AS Path length, you would see your private AS associated with all routes you announce to VGW
{65000}. Prepending AS Path adds the local AS as many times as the configuration indicates. A
prepend of 3 results in {65000, 65000, 65000, 65000}. AS Path Length is modified as part of an
Export Rule under BGP router configuration in the firewall. There are three configuration tabs for an
Export Rule:
General tab
Used by—Select BGP peer(s) for which you want to modify exported routes
Match tab
AS Path Regular Expression—Type the private AS used in your BGP configuration (65000)
Action tab
AS Path—Type=Prepend, type the number of AS entries you wish to prepend (1,2,3, etc.)
The AWS-provided BGP configuration templates for a VPN Connection places both tunnels into a
single peer group. Using this configuration, AS Prepend would apply to both peers.
Path Origin
BGP path origin refers to how a route was originally learned and can take one of three values:
incomplete, egp, or igp. An interior gateway protocol (igp) learned route is always preferred over
other origins, followed by exterior gateway protocol (egp), and lastly incomplete. By default, AWS
VPN connection templates announce routes with incomplete origin. Under BGP router configuration
in the firewall, you can modify path origin as either an export rule or redistribution rule. Default
Route (0.0.0.0/0) is advertised to the VGW via redistribution rule in the firewall and is the easiest
place to modify path selection for the default route. Changing the origin to either igp or egp prefers
this path over the other firewall. AWS does not document the use of path origin as part of route
selection.
Multi-Exit Discriminator
MED is a way for an autonomous system to influence external entities’ path selection into a multi-
homed autonomous system. MED is a 32-bit number, with a lower number used for preferred path.
MED is an optional configuration parameter, and an MED of <none> and 0 are equivalent. Under
BGP router configuration in the firewall, you can modify MED by export rules and redistribution
rules. AWS does not document the use of MED as part of route selection.

Lowest Peer-ID (IP address)
Given the selection criteria discussed above, if there are still multiple candidate paths remaining, the
route selection process of AWS BGP chooses the BGP peer with the lowest IP address. For IPsec
tunnels, these are the IP addresses assigned by AWS. The default behavior for the AWS-provided
VPN connection configuration templates uses lowest peer-ID for route selection.
The Transit hub and provides connectivity over IPsec tunnels from Subscriber VPCs to the Transit
VPC.
Figure 13. BGP Path Selection Process
Prefix AS Path Origin MED Peer-ID

10.8.0.0/24 65000,7224 incomplete 0 169.254.49.1
10.8.0.0/24 65000,65000,7224 incomplete 0 169.254.49.145
10.8.0.0/24 65000,7224 incomplete 0 169.254.58.30
10.8.0.0/16 65000,7224 incomplete 0 169.254.59.10
Longest Prefix
10.8.0.0/24 65000,7224 incomplete 0 169.254.49.1

10.8.0.0/24 65000,65000,7224 incomplete 0 169.254.49.145
10.8.0.0/24 65000,7224 incomplete 0 169.254.58.30
AS Path Length
10.8.0.0/24 65000,7224 incomplete 0 169.254.49.1

10.8.0.0/24 65000,7224 incomplete 0 169.254.58.30
Path Origin
10.8.0.0/24 65000,7224 incomplete 0 169.254.49.1

10.8.0.0/24 65000,7224 incomplete 0 169.254.58.30
Multi Exit
Discriminator
10.8.0.0/24 65000,7224 incomplete 0 169.254.49.1

10.8.0.0/24 65000,7224 incomplete 0 169.254.58.30
Lowest Peer-ID
10.8.0.0/24 65000,7224 incomplete 0 169.254.49.1

Creating the Transit VPC

Use the following procedures to configure a Transit VPC.
Quick Star
ÌÌ Procedure 1: Creating IPsec Tunnels to/from Subscriber VPCs

ÌÌ Procedure 2: Modify the Provided Configuration Template
Procedure 1: Creating IPsec Tunnels to/from Subscriber VPCs

This procedure begins with the Single VPC design and creates IPsec tunnels to/from Subscriber
VPCs to your Transit VPC firewalls. Repeat this procedure for each region in which Subscriber VPCs
reside.
Step 1. From the VPC Dashboard in which your Subscriber VPCs are located, create a customer
gateway with dynamic routing (BGP), using the internet dataplane network interface
public IP address of one VM-Series within the Transit VPC (Procedure 4, “Attach Network
Interfaces to Your Firewalls,” Step 2). Repeat this step for the second VM-Series firewall
within your Transit VPC.
Step 2. Create a virtual private gateway.
Step 3. Attach the virtual private gateway to the VPC.
Step 4. Create a VPN connection from your virtual private gateway to one customer gateway, using
dynamic routing. Repeat for the other customer gateway.
Step 5. Select one of your VPN connections created in the step above, download the configuration
for Palo Alto Networks (Software PAN-OS® 7.0+), and then save the configuration file.
Step 6. Repeat Step 5 for the other VPN Connection.
Procedure 2: Modify the Provided Configuration Template

VPN connections provide a configuration template to assist you with configuring your portion of
the customer gateway to establish IPsec tunnels to your Subscriber VPC VGW. The template in Step
5 below assumes your customer gateway (firewalls) are using the public IP addresses you provided
as part of the customer gateway configuration. The template must be modified to reflect the actual
private IP address configured on the firewall interfaces (IKE Gateway) The template terminates
IKE Gateways on ethernet1/1 of the Transit VPC firewalls, and assuming you followed Procedure
4, “Attach Network Interfaces to Your Firewalls,” you use ethernet1/1. Modify the peer-address IP
address to reflect the VPC private IP address assigned to your firewall ethernet1/1 interfaces. This
needs to be done for both IKE Gateways in the configuration template and for both configuration
templates to each firewall (customer gateway). The below steps describe the relevant part of the
configuration.

Step 1. Modify the provided VPN template to reflect the firewall’s internal interface IP address,
which will be used to terminate IPsec tunnels from the VGW. This is the internal NATed IP
address you used when you created the customer gateway in Procedure 7, “Creating IPsec
Tunnels to/from Subscriber VPCs,” Step 1.
edit network ike gateway ike-vpn-x-0
set protocol ikev1 ike-crypto-profile ike-crypto-vpn-x-0 exchange-mode main
set protocol ikev1 dpd interval 10 retry 3 enable yes
set authentication pre-shared-key key xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
set local-address ip x.x.x.x
set local-address interface ethernet1/1
set peer-address ip 35.126.5.45
The configuration template assumes the tunnel interfaces are the first to be configured on the
firewall and thus associates them with the first two tunnel interfaces: tunnel.1 and tunnel.2. When
you add additional VPN connections to a VM-Series within a Transit VPC, you need to adjust the
tunnel subinterface number used by both the IPsec tunnel and BGP peer to ensure they are unique
and not conflicting with other tunnels. Additionally, the configuration template associates your
tunnel interfaces with the untrust zone. Modify this security zone to something appropriate for your
environment.
Step 2. Modify the tunnel interfaces associated with the configuration template in order to ensure
tunnel interfaces are unique and not conflicting with other tunnel interfaces in use.
edit network interface tunnel units tunnel.1
set ip 169.254.x.x/30
set mtu 1427
top
Step 3. Modify the security zone used by IPsec tunnels.

set zone untrust network layer3 tunnel.1
Beginning with PAN-OS 8.0, VM-Series support multiprotocol BGP (ipv4 and ipv6 routing using
BGP). The configuration template assumes pre-PAN-OS 8.0, which supported only ipv4 for BGP.
PAN-OS 8.0 now requires explicit specification of IP address family type as part of the BGP peer
configuration. Failure to specify IP address type results in a failed commit process. Add the address-
family-identifier and adjust the associated tunnel interface appropriately within the BGP peer
configuration.

Step 4. Modify the VPN configuration template of the BGP configuration for PAN-OS 8.0
compatibility.
edit network virtual-router default protocol bgp
set router-id 35.166.188.255
set install-route yes
set enable yes
set local-as 65000
edit peer-group AmazonBGP
edit peer amazon-tunnel-vpn-x-0
set address-family-identifier ipv4
set peer-as 7224
set connection-options keep-alive-interval 10
set connection-options hold-time 30
set enable yes
set local-address ip 169.254.59.14/30
set local-address interface tunnel.1
set peer-address ip 169.254.59.13
The following snippet is in addition to the AWS configuration template and creates a route-
redistribution profile (called Connected). The snippet redistributes the connected network
(ethernet1/1) into BGP. This part of the configuration permits each VM-Series within the Transit VPC
to advertise its unique internet subnet to its Subscriber VPCs to ensure symmetric paths for NAT
traffic. The highlighted portion is only required for PAN-OS 8.0
Step 5. Create a redistribution profile to advertise directly-connected interfaces into BGP.

edit network virtual-router default protocol redist-profile Connected
set filter type connect
set filter interface ethernet1/1
set priority 5
set action redist
top
edit network virtual-router default protocol bgp

set redist-rules Connected address-family-identifier ipv4
set redist-rules Connected route-table unicast
set redist-rules Connected enable yes
set redist-rules Connected set-origin incomplete
top
Step 6. Copy/paste the relevant configuration template into your Transit VPC firewall CLI
configuration, and then commit the changes.
Step 7. On the firewall, verify that IPsec tunnels are connected to your VGW. From your Subscriber
VPCs, confirm that your VPN connections are on AWS and that routes are being propagated.
Step 8. Proceed with additional firewall configuration as needed.

VPC Peering
VPC peering is a native capability of AWS for creating direct two-way peer relationships between
two VPCs within the same region. The peer relationship permits only traffic directly between the
two peers and does not provide for any transit capabilities from one peer VPC through another to
an external destination. VPC peering is a two-way agreement between member VPCs. It’s initiated
by one VPC to another target VPC, and the target VPC must accept the VPC peering relationship.
VPC peering relationships can be created between two VPCs within the same AWS account, or they
can be created between VPCs which belong to different accounts. After a VPC peering relationship
is established, there is two-way network connectivity between the entire CIDR block of both VPCs,
and there is no ability to segment using smaller subnets.
At first glance, it might appear possible to create network connectivity that exceeds the native
capabilities offered by VPC peering if you manipulate route tables, even create transitive VPCs, and
get creative with your route tables. However, VPC peering strictly enforces source and destination
IP addresses of packets traversing the peering connection to only source and destinations within the
peered VPCs. Any packets with a source or destination outside of the two-peer VPC address space
are dropped by the peering connection.
VPC peering architecture uses network policy to permit traffic only between two directly adjacent
VPCs. Two example scenarios:
Hub and spoke

Multi-tier applications
In a hub-and-spoke model, Subscriber VPCs (spokes) use VPC peering with the Transit VPC (hub) to
provide direct communications between the individual Subscriber VPC instances and Transit VPC
instances. Peer Subscriber VPCs are unable to communicate with each other, because this would
require transit connectivity through the Transit VPC, which is a capability supported by VPC peering.
Additional direct VPC peering relationships can be created to permit communication between VPCs
as required. This design pattern provides a capability similar to Private VLANs in network switches,
and it can be useful for deployments requiring multi-tenant capabilities.
For multi-tiered applications, VPC peering uses network connectivity to enforce the policy that
only directly adjacent application tiers can communicate. A typical three tier application (web,
app, database) might provide web servers in the public-facing Transit VPC, with VPC peering to
a Subscriber VPC hosting the application tier, and the Application VPC would have another VPC
peering relationship with a third Subscriber VPC hosting the database tier. Network connectivity of
VPC peering would provide no outside connectivity directly to application or database VPCs. Figure
14 illustrates how a Transit VPC is employed to provide traffic inspect to instances within and directly
adjacent VPC peers.

Figure 14. VPC peering
App Tier DB Tier

App-2a App-2b DB-2a DB-2b
172.17.1.0/25 172.17.1.128/25 172.17.2.0/25 172.17.2.128/25
App-2a App-2b DB-2a DB-2b
e0 e0 e0 e0
Service-2a
Internet-2a 10.0.0.0/24
10.0.2.0/28 Web1-2a
e0
e0
e2
e1
Web2-2a Sub1-2a
e0
fw-2a 172.16.1.0/25
e0
App1-2a
172.16.1.113
172.16.1.183
e0
Web1-2b App1-2b
e0 Sub1-2b
e0 172.16.1.128/25
e2
e1 Subscriber VPC #1
Sub2-2a
Web2-2b
fw-2b 172.16.2.0/25
Internet-2b e0
10.0.3.0/28 e0
Service-2b App2-2a
10.0.1.0/24
172.16.2.113
Transit VPC 172.16.2.183
e0
App2-2b
Sub2-2b
172.16.2.128/25
Subscriber VPC #2
Inbound, outbound, and east/west traffic inspection for instances hosted in the Transit VPC is
identical to Single VPC. For VPCs that are peered directly to the Transit VPC, inbound traffic through
the firewall is available using Source and Destination NAT. Outbound traffic through the firewall is
limited to specific destination IP addresses. Figure 15 provides details of inbound NAT to a directly
peered VPC instance. IGW translates the destination address to secondary IP address on the firewall
(packet 1-2). NAT policy on the firewall matches the destination IP address and applies Source NAT
to the internal network, which is reachable by the VPC Peer and Destination NAT to the destination
peer IP address (packet 2-3). Return traffic from the VPC Peer instance matches the existing NAT
session, and the reverse is applied. Outbound NAT could also be applied for traffic originating
from the VPC Peer instance, but as you can see, the ultimate destination IP address is fixed in the
firewall NAT policy. A general outbound traffic flow is not permitted, because source and destination
networks are enforced by VPC peering.

Figure 15. Inbound Source and Destination NAT to VPC Peer instance
6 5 4
dst = 129.219.1.24 dst = 129.219.1.24 dst = 10.0.0.185

src = 54.70.112.212 src = 10.0.2.7 src = 172.16.1.111 e0
10.0.2.7
e2 172.16.1.111
e1
10.0.0.185
IGW
dst = 54.70.112.212 dst = 10.0.2.7 dst = 172.16.1.111
src = 129.219.1.24 src = 129.219.1.24 src = 10.0.0.185
1 2 3
54.70.112.212 (app1-2a) 10.0.2.7 10.0.2.7 172.16.1.111

54.186.29.1 (app2-2a) 10.0.2.8 10.0.2.8 172.16.2.112
52.16.2.117 (app3-2a) 10.0.2.9 10.0.2.9 172.16.3.113
Creating VPC Peering Connections

VPC peering makes use of the Single VPC design pattern for internet inbound and outbound
traffic inspection and policy enforcement. Network policy of VPC peering restricts VPCs that can
communicate with each other.
Use the following procedures to creating a direct two-way peer relationship between two VPCs
within the same region.
Quick Star
ÌÌ Procedure 1: Create a VPC Peering Connection Between Two VPCs within the Same
Region
ÌÌ Procedure 2: Modify VPC Route Tables for VPC Peering connections
Procedure 1: Create a VPC Peering Connection Between Two VPCs within the Same Region
Step 1. From within the region in which your two VPCs are located, create the VPC peering
connection, choosing a VPC Requester and VPC Accepter for the two VPCs you want to
communicate.
Step 2. If your two peering VPCs are within the same AWS account, select the peering connection
you just created and accept the request.
Step 3. If your peering VPCs are in different accounts, log in to the other account, highlight the
peering connection with status Pending Acceptance, and accept.
VPC peering connections do not exchange dynamic routing information, so you must update the
route tables for each VPC to direct traffic across the VPC peering connection.

Procedure 2: Modify VPC Route Tables for VPC Peering connections
Step 1. Select one of the route tables for a VPC in the above procedure.
Step 2. Create a route to the CIDR IP address of the peered VPC with a target of the peering
connection pcx-xxxxxx.
Step 3. Repeat above step for the other VPC peer, modifying its route table with a route back to the
other VPC.
You now have a VPC peering relationship with network routing between two VPCs and can continue
with additional firewall configuration as desired.
AWS Direct Connect

AWS Direct Connect provides the ability to extend your private VPC infrastructure and publicly
available AWS services directly to your data center infrastructure by using dedicated network
bandwidth. You have the option of placing your network equipment directly in an AWS regional
location, with a direct cross-connect to their backbone network, or using a network provider service,
such as LAN extension or MPLS, to extend your AWS infrastructure to your network.
AWS Direct Connect virtual interfaces exchange BGP routing information with your firewall. Because
AWS Direct Connect paths are usually preferred over VPN connections, the route selection criteria
reflect this preference and prefers AWS Direct Connect routes over VPN Connection routes. All
available path options are considered in order until there exists a single “best” path. In the event
there are multiple, equivalent paths for AWS Direct Connect routes, the traffic is load balanced using
equal cost multi-path. AWS Direct Connect dynamic routes of the same prefix length are always
preferred over VPN connection routes.
Creating a Direct Connect and Its Virtual Interfaces

Use the following procedures to configure AWS Direct Connect and the associated virtual interfaces.
Quick Star
ÌÌ Procedure 1: Request a Direct Connect

ÌÌ Procedure 2: Create Direct Connect Virtual Interfaces to a VPC
Procedure 1: Request a Direct Connect
Step 1. Log into the AWS account that will own the Direct Connect
Step 2. Choose the desired region, and from the Direct Connect dashboard, create the Direct
Connect. You are presented a list of partners that provide Direct Connect service within
your region

Step 3. Select a provider and port speed.

You receive an email from AWS verifying you requested a Direct Connect and asking for additional
information as to co-location data center or network provider with which you wish to create your
Direct Connect. Once your Direct Connect has been provisioned, continue with creating Private
Virtual Interfaces to connect your VPCs
Procedure 2: Create Direct Connect Virtual Interfaces to a VPC
Step 1. Create a private virtual interface and select the Direct Connect connection on which you
wish to create the virtual interface. Specify the name of the virtual interface, the AWS
account to which the virtual interface should be associated, the associated VGW VLAN ID,
your BGP peer IP address, the AWS BGP peer IP address, the BGP autonomous system,
and the MD5 BGP authentication.
Repeat this step for every VPC you wish to connect to your firewall.
You chose an AWS account to which a virtual interface is associated. This provides the ability for
a Direct Connect to be associated with one account and a virtual interface on the connection to
belong to a different AWS account. For example, corporate IT can own the Direct Connect while
Engineering and Finance have a virtual interface connecting their respective VPC infrastructures.
You have the option of configuring a static route within a route table that directs traffic to the VGW
or using dynamic routing to exchange routing information between your network and the VPC via
BGP.
Step 2. To enable dynamic routing between your network and your VPC, select the route table for
which you wish to enable dynamic routing, and on the Route Propagation tab, select the
associated VGW.
bbwhich
The VGW associated with your Virtual Interface advertises via BGP the VPC CIDR to
it is attached and only this one route. The VGW accepts up to 100 routes from
your network. It may be sufficient to advertise default route via your virtual interface and
use VPC route-table configuration to send VPC traffic in the correct direction, to either
the VGW or IGW.
Step 3. Configure the matching Layer3 subinterface and BGP peering on your firewall.
Public virtual interfaces are created in the same fashion as private virtual interfaces. The Public
virtual interface has an internet-reachable IP address, either a /31 subnet from an address space that
belongs to you or public address space (belonging to AWS) that is assigned to you for this purpose.

Figure 16. Direct Connect private virtual interfaces
169.254.1.2/30
10.0.1.0/24
BGP Peering
VPC #10
169.254.1.1/30 Direct Connect

Eth1/5.10 VLAN10
802.1Q Trunk
169.254.2.9/30 169.254.2.10/30
Eth1/5.20
VLAN20
169.154.3.2/30
Eth1/5.30
VLAN30
10.0.2.0/24
VPC #20
BGP Peering
169.254.3.1/30
10.0.3.0/24
VPC #30
Direct Connect provides many options for device and location redundancy. Two of these options
are illustrated in Figure 17. The first option provides redundant connections from a single firewall to
your VPC. When multiple Direct Connects are requested, they are automatically distributed across
redundant AWS backbone infrastructure. The BGP peering IP addresses must be unique across
all virtual interfaces connected to a VGW. The VLAN is unique to each AWS Direct Connect port
because it is only locally significant, so virtual interfaces can share a common VLAN.
The second option illustrates redundant firewalls distributed across to two separate AWS locations
servicing the same region. This option provides device, geographic, and (optionally) service provider
redundancy, as well.

Figure 17. Direct Connect redundancy options
10.0.2.0/24
AWS Location 1
AWS Location 1
10.0.2.0/24
AWS Location 2

Summary
Moving applications to the cloud requires the same enterprise-class security as your private network.
Deploying Palo Alto Networks VM-series firewalls in your AWS infrastructure provides scalable
infrastructure with the same protections from known and unknown threats, complete application
visibility, common security policy, and native cloud automation support. Your ability to move
applications to the cloud securely helps you to meet challenging business requirements.
Comments and Feedback

If you have feedback on this guide, please email us at referencearchitectures@paloaltonetworks.com
44 Summary
Related Content
Palo Alto Networks
VM Series for Amazon Web Services
Auto Scale VM-Series Firewalls with the Amazon Elastic Load Balancer
Amazon Web Services

Amazon Virtual Private Cloud User Guide
Related Content 45
What’s New in This Version

The following changes have been made since Palo Alto Networks last published this guide. We:
Initial version 1.0

Version 2.0
Changed Firewall Services VPC to Transit VPC to align with AWS branding
VPN Connections now support user-defined subnet assignment
Removed Large Firewall Services VPC design pattern due to overlapping VPN Connection
subnets
46 What’s New in This Version

Intelligent Architectures | Next-Generation Security Platform on Amazon AWS Reference Architecture
Headquarters
Palo Alto Networks Phone: +1 (408) 753-4000
4401 Great America Parkway Sales: +1 (866) 320-4788
Santa Clara, CA 95054, USA Fax: +1 (408) 753-4001
www.paloaltonetworks.com info@paloaltonetworks.com
© 2017-2018. Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can
be found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies. Palo Alto Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
rev.: 02/11/2018

Aws

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Aws

Încărcat de

Drepturi de autor:

Formate disponibile

l l i ge nt

Next-Generation Security Platform

Purpose of This Guide

Amazon Web Services—Building Blocks

4 Amazon Web Services—Building Blocks

Figure 1. AWS worldwide regions

Amazon Web Services—Building Blocks 5

Virtual Private Cloud

 Anticipated number of IP addresses needed within a VPC

6 Amazon Web Services—Building Blocks

Figure 2. Availability Zones within a region

Amazon Web Services—Building Blocks 7

8 Amazon Web Services—Building Blocks

Figure 3. Subnets and route tables

Destination Target Status Propagated Destination Target Status Propagated

Route Table 1 Route Table 2

10.0.1.0/24 10.0.2.0/24 10.0.3.0/24 10.0.4.0/24

Subnet 1 Subnet 2 Subnet 3 Subnet 4

Network Access Control Lists

 Are applied at subnet level.

Amazon Web Services—Building Blocks 9

 Apply to the instance network interface.

10 Amazon Web Services—Building Blocks

Figure 4. Security groups and network access control lists

VPC us-west-2 (Oregon)

Security Group Security Group

Host Host Host Host Host Host Host Host

Subnet1 Subnet2 Subnet3 Subnet4

Source and Destination Check

Amazon Web Services—Building Blocks 11

Figure 5. Source and destination check

Source/Dest. Check – Enabled (default)

Source/Dest. Check – Disabled

Virtual Private Gateway

12 Amazon Web Services—Building Blocks

Table 1. Firewall and VGW compatible IKE Crypto Profile

IKE Crypto Profile Diffie-Hellman Hash Encryption

Amazon Web Services—Building Blocks 13

Table 2. Firewall and VGW compatible IPsec Crypto Profile

IPsec Crypto Profile Diffie-Hellman Hash Encryption

Elastic Network Interface

 Private IPv4 address

14 Amazon Web Services—Building Blocks

Amazon Machine Image

AWS Direct Connect

 Hardware firewalls support

Amazon Web Services—Building Blocks 15

AWS Security and Traffic Types

 Inbound—traffic originating outside and destined to your VPC hosts

Inbound Traffic Inspection

 Destination IP address and port-mapping using a single Elastic IP address

 Packet 1 to packet 2—The IGW translates the packet’s destination address.

16 Amazon Web Services—Building Blocks

1 dst = 52.1.7.85:80 2 dst = 10.0.3.18:80

Public IP Address Private IP Address

10.0.1.10 Subnet1 - 10.0.1.0/24

W eb dst = 10.0.1.10:80 Destination Target Status Propagated

Outbound Traffic Inspection

Amazon Web Services—Building Blocks 17

Figure 7. Outbound traffic inspection using Source NAT

10.0.1.10 Subnet1 - 10.0.1.0/24

W eb dst = 10.0.1.10 Destination Target Status Propagated

18 Amazon Web Services—Building Blocks

Anticipated number of IP addresses needed within a VPC

Are applied at subnet level.

Apply to the instance network interface.

Private IPv4 address

Hardware firewalls support

Inbound—traffic originating outside and destined to your VPC hosts

Destination IP address and port-mapping using a single Elastic IP address

Packet 1 to packet 2—The IGW translates the packet’s destination address.

Single VPC—Single purpose or small-scale deployments

Longest prefix length