AWS Landscape 12: Firewall

Deploying Palo Alto Virtual Firewalls ensures robust security for SAP workloads in AWS. This design enforces north-south traffic control (internet/on-prem) and east-west traffic inspection (VPC-to-VPC), while providing high availability (HA) and centralized monitoring.

Key benefits:

• Inspection of all inbound, outbound, and inter-VPC traffic.
• HA deployment across multiple AZs to prevent downtime.
• Centralized logging and management for compliance.

Objective:
Deploy Palo Alto Virtual Firewalls to:

• Enforce east-west (VPC-to-VPC via TGW) and north-south (Internet/On-Prem) traffic control.
• Ensure HA and fault-tolerant traffic flow.
• Enable centralized monitoring and logging.

Design Overview:

Technical Implementation Steps

Step 1: Launch VM-Series Instances

EC2 Console → Launch Instance → Community AMIs → Search "Palo Alto VM-Series".

Deploy 2 instances (HA pair):

Parameter             Value

Instance Type c5n.large (min) or m5n.xlarge

Subnet         Public subnet (1 per AZ)

EIP         Assign to Active FW

Security Group SSH(22), HTTPS(443) mgmt only

CLI: aws ec2 run-instances --image-id ami-xxxx --instance-type c5n.large --subnet-id subnet-public-az1 --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=PaloAlto-FW1}]'.

Step 2: Configure Network Interfaces

For each firewall instance (3 interfaces minimum):

eth0: Management (public subnet) → Palo Alto mgmt IP

eth1: Outside (untrust) → IGW/TGW

eth2: Inside (trust) → Private subnets

CLI (post-launch): aws ec2 assign-private-ip-addresses --network-interface-id eni-xxx --private-ip-addresses 10.0.1.10.

Step 3: Firewall Policy Configuration

North-South Rules:

1. Outbound: Allow SAP → HTTPS(443), HTTP(80), SAP Ports(3200-3299, 50000-59999)

2. Inbound: Allow Admin(443), SAP Router → Specific SAP ports only

3. Default: Deny All

East-West Rules (VPC→VPC via TGW):

1. Prod→Dev: Allow SAP app ports (3300-3399, 50000+)

2. All→Security: Allow logging (CloudTrail/Security Hub)

3. Default: Deny cross-environment unless explicitly allowed

Step 4: High Availability Setup

Palo Alto WebUI → Network → Interfaces → HA Interface (dedicated or spare).

Configure Active-Passive:

Setting       Primary (AZ1) Secondary (AZ2)

Group ID 1        1

Priority 100 (Active) 200 (Passive)

EIP         Primary  Failover target

Test: Power off Active → Passive takes EIP (~30s).

Step 5: Transit Gateway Integration

VPC Route Tables (Private subnets):

10.1.0.0/16 (Dev VPC) → eni-firewall-inside (not direct TGW)

Firewall Outside Interface → TGW attachment.

Traffic flow: SAP Prod → Firewall → TGW → SAP Dev (inspection enforced).

Step 6: Logging & Monitoring

Panorama (optional): Central management across accounts.

CloudWatch: Forward syslogs via rsyslog.

SIEM: S3 → Firehose → Security Lake.

CLI: aws logs create-log-group --log-group-name PaloAlto-ThreatLogs.

Traffic Flow Diagram

Route Table Example (Prod VPC Private Subnet)

10.0.0.0/16 → local (intra-VPC)

10.1.0.0/16 → eni-0a1b2c3d-firewall (Dev VPC via FW)

10.2.0.0/16 → eni-0a1b2c3d-firewall (QA VPC via FW)

0.0.0.0/0   → nat-gateway (outbound via FW)

Best Practices

Licensing: BYOL or PAYG via AWS Marketplace.

Auto Scaling: Use AWS Gateway Load Balancer (GWLB) for scale-out.

SAP Specific: App/VGUI ports (3200-3299), HANA (30015, 30017).

Cost: ~$0.50/hr per c5n.large + data processing.

Monitoring: Threat Prevention, URL Filtering, WildFire licenses.

Advanced: Deploy via AWS Gateway Load Balancer for horizontal scaling beyond HA pair.

AWS Landscape 11: Remote Connectivity

Secure remote connectivity is critical for SAP administrators and development teams to manage workloads in AWS. This design ensures least-privilege access, auditability, and compliance by combining Bastion Hosts, VPN access, and Active Directory integration.

Key benefits:

• Controlled and auditable remote access to private SAP workloads.
• Redundant access paths (Bastion hosts + VPN).
• Integration with AD for authentication and role-based access.

Objective:

• Provide secure, controlled, and auditable remote access for administrators and SAP teams by:
• Using Bastion Hosts and AWS Client VPN for connectivity.
• Enforcing MFA and least-privilege access.
• Logging all sessions for compliance.

Design Overview:

Bastion Hosts (Jump Servers):

• Located in public subnets across AZs for HA.
• Allow SSH/RDP access to private EC2 instances.

VPN Access:

• AWS Client VPN for secure connectivity to private subnets.
• Supports AD integration for authentication.

Security Measures:

• MFA required for all users.
• Security Groups restrict access to necessary resources only.
• CloudWatch logging captures all activity.

Active Directory Integration:

• AD credentials used for authentication.
• Role-based access enforced for SAP workloads.

Technical Steps for Remote Connectivity

Step 1: Deploy Bastion Hosts
Launch EC2 instances in public subnet per AZ for HA.
Configure Security Groups:

• Allow inbound SSH (22) or RDP (3389) only from corporate IP ranges.
• Enable CloudWatch Agent for session logging.

Step 2: Configure VPN Access
Navigate to AWS Client VPN → Create Client VPN Endpoint.
Configure Authentication:

• AD integration or certificate-based.
• Associate VPN endpoint with private subnets of workload VPC.
• Download VPN configuration for users.
• Choose split-tunnel or full-tunnel routing based on requirements.

Step 3: Configure Security

• Limit access to only required VPC resources using Security Groups.
• Implement IAM policies for session auditing and resource control.

Step 4: Enable Monitoring

• Enable CloudWatch logs for VPN connections and Bastion sessions.
• Optional: Use AWS Systems Manager Session Manager for audit-friendly remote access without exposing SSH/RDP.

Diagram – Remote Connectivity

Diagram Notes:

• Users access private resources through Bastion hosts or VPN only.
• Security Groups and firewall rules restrict connectivity.
• Centralized logging ensures audit compliance.

Notes 

• Least privilege access minimizes the attack surface.
• Bastion hosts + VPN provide redundant remote access paths.
• AD integration allows single sign-on (SSO) and centralized user management.
• Optional Session Manager removes need for open inbound SSH/RDP ports, improving security posture.

AWS Landscape 10: Internet Connectivity

Controlled internet access is critical for SAP workloads in AWS to ensure security, compliance, and reliability. This design uses Palo Alto VM-Series firewalls for centralized inspection of all north-south traffic while allowing private SAP applications and databases to remain isolated from direct internet exposure.

Key benefits:

• Centralized traffic inspection for inbound and outbound flows.
• High availability across multiple AZs.
• Controlled access to SAP services, updates, and external integrations.

Objective:

• Ensure secure and compliant internet access for SAP workloads and AWS resources by:
• Restricting direct internet access from private subnets.
• Routing all traffic through highly available Palo Alto firewalls.
• Controlling outbound and inbound traffic with fine-grained firewall rules.

Design Overview:
Public Subnets: NAT Gateways, Bastion Hosts, Internet-facing services.
Private Subnets: SAP Applications, SAP HANA DB – no direct internet access.
Firewalls: Palo Alto VM-Series deployed in HA pair across AZs.

Routing:

• Private/public subnet traffic → Palo Alto Firewall → Internet Gateway (IGW).
• Ensures all traffic is inspected for compliance and security.

Technical Steps for Internet Connectivity

Step 1: Deploy Internet Gateway (IGW)
Navigate to VPC → Internet Gateways → Create IGW.
Attach IGW to each VPC (per account).
Public subnets route 0.0.0.0/0 → IGW.

Step 2: Deploy Palo Alto Firewalls
Launch Palo Alto VM-Series in public subnets across AZs for HA.
Assign Elastic IPs (EIPs) for external access.
Configure firewall rules:

• Outbound: allow required protocols (HTTP, HTTPS, SAP ports).
• Inbound: restrict access to Bastion Hosts, NAT, and specific services.

Step 3: Configure NAT Gateways (Private Subnets)
Deploy NAT Gateways in public subnets behind firewalls.
Update private subnet route tables:

• Destination: 0.0.0.0/0 → Target: NAT Gateway
• NAT forwards traffic through firewalls before reaching IGW.

Step 4: Update Route Tables
Public Subnets: route via firewall → IGW.
Private Subnets: route via NAT Gateway → firewall → IGW.

Step 5: Monitoring

• Enable CloudWatch logs and firewall logging for all traffic.
• Monitor egress/ingress patterns to detect anomalies.

Diagram – Internet Connectivity Flow

Diagram Notes:

• All private subnet traffic passes through NAT → Firewall → IGW.
• Public subnet traffic (bastion hosts, ALBs) also passes through firewall.
• Firewalls provide north-south traffic inspection and ensure compliance.

Notes

• Centralized firewall ensures security inspection for all inbound and outbound traffic.
• Supports SAP patch downloads, updates, and external integrations securely.
• HA firewalls across AZs provide resilient internet access for production workloads.
• Monitoring via CloudWatch and firewall logs enables early detection of anomalies.

AWS Landscape 9: Peering Connections

Secure and scalable VPC-to-VPC communication is essential for multi-account AWS SAP landscapes. Instead of creating multiple VPC peering connections (which can become complex and hard to manage), this design leverages AWS Transit Gateway (TGW) as a centralized hub to simplify routing, control east-west traffic, and enable inter-VPC and inter-region connectivity.

Key benefits:

• Centralized routing: All VPCs communicate via a single TGW.
• Scalable: Supports hundreds of VPCs without mesh complexity.
• Secure: Uses private IPs; Security Groups and NACLs enforce access.
• Disaster Recovery Ready: Inter-region peering can replicate traffic to DR region.

Objective:

Enable secure, scalable inter-VPC communication across multiple AWS accounts and regions using Transit Gateway to:

• Simplify routing and avoid complex peering meshes.
• Allow SAP workloads, shared services, logging, and security accounts to communicate.
• Support DR and backup replication across regions if required.

Design Overview

• Transit Gateway (TGW) deployed in Network Service Account acts as the routing hub.
• All workload and shared services VPCs attach to the TGW.
• Traffic uses private IPs, no direct VPC-to-VPC peering is needed.
• Optional Inter-Region TGW Peering can connect Singapore → Tokyo for DR replication.

Technical Steps for Peering Connections

Step 1: Create Transit Gateway
Log in to Network Service Account.
Navigate to VPC → Transit Gateway → Create Transit Gateway:

• Name: SAP-TGW

• ASN: e.g., 64512

• Enable Default Route Table
• Enable DNS support if cross-VPC name resolution is required

Step 2: Attach VPCs to TGW

For each VPC (Workload, Shared Services, Security, Logging):

• Navigate to VPC → Transit Gateway Attachments → Create Attachment
  
• Select the VPC, subnets (1 per AZ for attachment), and TGW
  
• Wait until attachment status is available

Step 3: Configure Route Tables

In TGW, associate each VPC attachment with the TGW route table.
Update VPC route tables:

• Private subnets → route to other VPCs via TGW (0.0.0.0/0 or relevant CIDRs)
• Enables inter-VPC communication for SAP workloads and shared services

Step 4: Security Groups & NACLs

• Ensure Security Groups allow required intra-VPC communication.
• NACLs can be default or customized per environment for additional security.

Step 5: Optional – Inter-Region Peering

Enable TGW Inter-Region Peering if connecting Singapore → Tokyo region:

• Supports DR workloads and backup replication
  
• Maintains private IP routing between regions

Diagram – VPC-to-VPC Peering via Transit Gateway

Centralized TGW Routing

• All VPCs communicate through Transit Gateway
• Eliminates the need for multiple VPC peering connections

Shared Services, Security, Logging VPCs

• Reachable from all workload VPCs
• Centralized services for CI/CD, monitoring, and audit logging

Private IP Communication

• All traffic between VPCs uses private IPs for security and low latency

Simplified Connectivity

• New VPCs can attach to TGW without creating additional peering
• Reduces management overhead and scaling complexity

Notes and Best Practices

• TGW simplifies routing compared to multiple VPC peering connections.
• Supports east-west traffic for SAP workloads, shared services, logging, and security accounts.
• Highly scalable: Can attach hundreds of VPCs without mesh complexity.
• Inter-region peering supports disaster recovery replication.
• Maintain proper Security Group and NACL policies to enforce least privilege access across VPCs.

AWS Landscape 8: Hybrid Connectivity

Hybrid connectivity ensures secure, reliable communication between on-premises data centers and AWS for SAP workloads. The design leverages AWS Direct Connect (DX) as the primary high-performance link and Site-to-Site VPN (S2S VPN) as a backup. All connectivity integrates through the Transit Gateway to simplify routing across multiple accounts and environments.

Key benefits:

• High bandwidth and low latency for production SAP workloads.
• Automatic failover via VPN to ensure business continuity.
• Centralized routing using Transit Gateway for simplified multi-account management.

Objective:

• Establish secure, reliable hybrid connectivity between on-premises SAP infrastructure and AWS to support:
• Production SAP workloads with minimal latency.
• Backup connectivity in case of primary link failure.
• Centralized, scalable routing to all AWS accounts via Transit Gateway.

Design Overview

Connection Type	Purpose	Notes
Direct Connect	High bandwidth, low latency	Primary link for production SAP traffic
Site-to-Site VPN	Failover / backup	Automatically routes traffic if DX fails
Transit Gateway	Centralized routing	Connects all AWS accounts to on-prem

All SAP workload VPCs connect to the Transit Gateway in the Network Service account.
BGP is used for dynamic routing and redundancy.
Optional redundant DX connections at different locations increase resilience.

Technical Steps for Hybrid Connectivity

Step 1: Set Up AWS Direct Connect (Primary)
Log in to Network Service Account.
Navigate to Direct Connect → Create Connection:

• Location: nearest DX site to on-prem
• Port speed: 1 Gbps or higher
• Connection name: e.g., SAP-Prod-DX

Create Private Virtual Interface (VIF) for SAP workloads.
Configure BGP ASN for routing with on-prem.
Attach VIF to Transit Gateway for all account connectivity.

Step 2: Configure Site-to-Site VPN (Backup)

• Navigate to VPC → Site-to-Site VPN → Create VPN Connection.
• Attach VPN to Transit Gateway.
• Enable BGP routing for automatic failover.
• Test VPN connectivity to ensure proper routing if DX fails.

Step 3: Transit Gateway Routing

TGW acts as a hub connecting:

• All workload VPCs (Prod, Dev, QA, Sandbox)
• Shared Services, Security, and Logging VPCs
• On-premises via DX and VPN
• Update route tables in each VPC to send on-prem traffic to Transit Gateway.

Step 4: Redundancy and Monitoring

• Enable CloudWatch monitoring on DX connection.
• Configure BGP failover for VPN when DX is unavailable.
• Optionally deploy secondary DX connections in another location for additional resilience.

Diagram – Hybrid Connectivity

Transit Gateway (TGW)

• Centralizes routing between AWS accounts and on-premises network
• Simplifies multi-VPC and multi-region connectivity

On-Prem Connectivity

• Direct Connect: Primary, low-latency, high-bandwidth link
• Site-to-Site VPN: Backup/failover connectivity

Workload VPCs

• Prod, Dev, QA, Sandbox each in dedicated CIDR
• Private subnets host SAP workloads and connect via TGW to on-prem

Shared Services, Security, Logging VPCs

• Centralized services for CI/CD, monitoring, auditing, and security
• Connected via TGW for all AWS workloads

Notes and Best Practices

• Ensures low-latency, high-bandwidth connectivity for SAP workloads.
• Backup VPN provides business continuity if DX fails.
• Transit Gateway reduces complex peering management across accounts and VPCs.
• BGP dynamic routing ensures automatic failover and redundancy.
• Monitor DX and VPN using CloudWatch to detect issues early.