AWS Landscape 17: DNS

Centralized DNS with EC2-based servers and Route 53 Resolver provides consistent name resolution across hybrid SAP environments. Redundant DNS servers in private subnets, integrated with corporate AD and AWS private resources (ELBs, hosted zones), ensure high availability and seamless hybrid connectivity for SAP HANA, application servers, and supporting infrastructure.

Key Benefits

Automatic DNS configuration via DHCP for all EC2 instances.

Hybrid resolution: AWS private + on-premises AD + internet.

HA across AZs with Route 53 Resolver integration.

SAP-specific endpoints (ELBs, HANA clusters) always resolvable.

Objective

Deploy redundant DNS infrastructure ensuring:

Centralized name resolution for SAP workloads.

Route 53 Resolver integration for AWS private resources.

On-premises AD hybrid connectivity.

Automatic EC2 configuration via DHCP options.

Deployment Architecture

Technical Implementation Steps

Step 1: Launch DNS Server EC2 Instances

Configuration:

Parameter       Value

AMI         Windows Server 2022 / Amazon Linux 2

Type         t3.medium

Subnets  Private subnets (2+ AZs)

IPs         Static: 10.0.1.10 (AZ1), 10.0.3.10 (AZ2)

IAM Role AmazonSSMManagedInstanceCore

Step 2: Install & Configure DNS Role (Windows Server)

# Install DNS role

Install-WindowsFeature DNS -IncludeManagementTools

# Configure forwarders

Add-DnsServerForwarder -IPAddress "169.254.169.253"  # Route 53 Resolver (VPC DHCP)

Step 3: VPC DHCP Option Set

VPC Console → DHCP options sets → Create:

Domain name: yourcorp.local

DNS resolution: Enabled

DNS servers: 10.0.1.10,10.0.3.10,AWS-provided-DNS

NTP servers: AmazonTimeSyncService

Domain search list: yourcorp.local,internal

CLI:

aws ec2 create-dhcp-options --dhcp-configurations \

  "Key=domain-name-servers,Values=10.0.1.10,10.0.3.10" \

  "Key=domain-name,Values=yourcorp.local" \

  --tag-specifications 'ResourceType=dhcp-options,Tags=[{Key=Name,Value=SAP-DNS-DHCP}]'

Step 4: Route 53 Resolver Endpoints

Inbound Endpoint (On-prem → AWS):

Name: onprem-to-aws-resolver

Direction: Inbound

VPC: VPC-Prod

Private subnets: 10.0.1.0/24 (AZ1), 10.0.3.0/24 (AZ2)

Security Group: TCP/UDP 53

Outbound Endpoint (AWS → On-prem):

Name: aws-to-onprem-resolver

Targets: On-prem DNS (10.0.0.10:53 via VPN)

Step 5: DNS Forwarder Configuration (Windows DNS Manager)

Forwarders:

├── *.yourcorp.local → 10.0.0.10 (On-prem AD)

├── *.internal → 169.254.169.253 (Route 53)

├── * → 10.0.0.20 (Firewall/NAT for internet)

Step 6: Private Hosted Zone Integration

Route 53 → Hosted zones → Create private hosted zone:

Domain: sap.yourcorp.local

VPC: VPC-Prod

Records:

├── sap-app-elb → prod-app-elb-1234567890.ap-southeast-1.elb.amazonaws.com

├── sap-hana-db → 10.0.4.15

Step 7: Validation Tests (from SAP App Server)

# Corporate AD resolution

nslookup dc1.yourcorp.local 10.0.1.10

# 10.0.1.10 (DNS1)

# AWS ELB resolution  

nslookup prod-app-elb.ap-southeast-1.elb.amazonaws.com 10.0.1.10

# Dualstack ELB IPs

# SAP internal

nslookup sap-hana-db.yourcorp.local

# 10.0.4.15 (HANA)

# Failover test

sudo systemctl stop named  # On DNS1

nslookup sap-hana-db.yourcorp.local 10.0.3.10  # DNS2 works

Monitoring & Health Checks

CloudWatch Agent on DNS servers:

json

{

  "metrics": {

    "metrics_collected": {

      "DNS": {"queries": true, "responses": true}

    }

  }

}

Alarms:

Metric                         Threshold         Action

DNS query failures         >5%                 Critical

DNS server CPU                 >80%                 Warning

Resolver endpoint health Non-Zero failures Alert

Resolution Flow

SAP App Server → DHCP → DNS1(10.0.1.10)

         ↓

   sap-hana-db.yourcorp.local?

         ↓

   1. Check local zones → No

   2. Forward yourcorp.local → On-prem AD

   3. On-prem returns 10.0.4.15 → SUCCESS

         ↓

SAP HANA connection: 10.0.4.15:30015

SAP-Specific DNS Records

# ASCS

sap-ascs.yourcorp.local → 10.0.1.50:3600

# Application Servers (round-robin)

sap-app-01.yourcorp.local → 10.0.1.101

sap-app-02.yourcorp.local → 10.0.1.102

sap-app-03.yourcorp.local → 10.0.3.101  # AZ2

# HANA Cluster

sap-hana-primary.yourcorp.local → 10.0.4.15

sap-hana-secondary.yourcorp.local → 10.0.4.16

Best Practices

Static IPs: DNS servers outside DHCP range.

Split DNS: Corporate zones → On-prem, AWS zones → Route 53.

Health Checks: Route 53 health checks on DNS servers.

Automation: ASG + UserData for DNS server replacement.

Backup: Regular dnsmgmt.msc exports to S3.

Multi-Account Extension

Security OU → Central DNS servers

Prod OU → Prod-specific zones

Dev OU → Separate DNS (dev.yourcorp.local)

AWS Landscape 16: Active Directory (AD)

Deploying Active Directory (AD) Domain Controllers in AWS provides centralized authentication for SAP workloads across multi-account environments. High-availability DCs in private subnets, synchronized with on-premises AD via VPN/Direct Connect, enable SSO, GPO enforcement, and consistent identity management for SAP HANA, application servers, and supporting infrastructure.

Key Benefits

Centralized SSO across hybrid environments.

HA across AZs prevents authentication outages.

GPOs enforce security/compliance consistently.

Automatic DNS resolution via DHCP options.

Objective

Deploy redundant AD DCs for SAP workloads ensuring:

Multi-AZ high availability.

On-premises synchronization via VPN/Direct Connect.

EC2 domain join for SAP tiers.

Integrated monitoring and GPO enforcement.

Deployment Architecture

Technical Implementation Steps

Step 1: Launch AD Domain Controller EC2 Instances

Instance Configuration:

Parameter        Value

AMI                 Windows Server 2022 Base

Type                 m5.large (min)

Subnets                 Private subnets, 2+ AZs

Storage                 100GB EBS gp3

IAM Role         SSM-Agent, CloudWatchAgentServer

User Data Script (for automated AD setup):

# Install AD DS role

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Install-WindowsFeature -Name DNS -IncludeManagementTools

# Promote to DC (additional DC scenario)

Install-ADDSDomainController -DomainName "corp.yourcompany.com" `

    -SafeSystemRestart -Credential (Get-Credential) `

    -DatabasePath "C:\Windows\NTDS" -LogPath "C:\Windows\NTDS"

Step 2: Configure Static Private IPs

Assign IPs outside DHCP range for replication stability:

AZ1 DC1: 10.0.1.10

AZ1 DC2: 10.0.1.11

AZ2 DC1: 10.0.3.10

AZ2 DC2: 10.0.3.11

Step 3: VPC DHCP Options Set

VPC Console → DHCP options sets → Create:

Domain name: corp.yourcompany.com

DNS resolution: Yes

DNS servers: 10.0.1.10,10.0.1.11,10.0.3.10,10.0.3.11

NTP servers: AmazonTimeSyncService (optional)

Step 4: AD Sites and Services Configuration

On DC Manager:

Active Directory Sites and Services → New Site: AWS-Prod-APAC

Subnet objects: 10.0.0.0/16 → AWS-Prod-APAC

Cost: 100 (prefer over on-prem)

Replication: Bridgehead servers = all DCs

Step 5: Join SAP EC2 Instances to Domain

SAP Application Servers (via SSM Run Command):

# Add to domain

Add-Computer -DomainName "corp.yourcompany.com" -Credential $domainCred -Restart

# Verify

nltest /dsgetdc:corp.yourcompany.com

Step 6: Group Policy Objects (GPOs)

Security Baseline GPO:

Computer Configuration:

├── Windows Settings → Security Settings → Account Policies

│   ├── Password Policy: 14+ chars, 90-day expiry

│   └── Account Lockout: 5 attempts, 15-min lock

├── Restricted Groups: SAP admins only

└── Windows Firewall: SAP ports only

Step 7: AWS Integration

SSM → AD Auth (IAM roles assume domain credentials)

RDS SQL Server → AD Authentication

WorkSpaces → AD Join

Step 8: Monitoring & Health Checks

CloudWatch Agent Config:

json

{

  "metrics": {

    "metrics_collected": {

      "Processor": {"totalcpu": true},

      "LogicalDisk": [{"free": true}]

    }

  },

  "logs": {

    "logs_collected": {

      "windows_events": {

        "collect_list": [

          {"eventname": "Directory Service", "event_levels": ["ERROR","WARNING"]}

        ]

      }

    }

  }

}

Active Directory Health Alarms:

Metric   Threshold Action

DCDiag failures >0 Critical alert

Replication latency >15 min Warning

NTDS CPU >80% Scale concern

DNS query failures >5% Immediate

Validation Commands (from bastion/jumpbox):

# DC Health

dcdiag /test:replications

repadmin /replsummary

# Client connectivity

nltest /dsgetdc:corp.yourcompany.com

nltest /sc_query:corp.yourcompany.com

# DNS Resolution

nslookup sap-app01.corp.yourcompany.com 10.0.1.10

Architecture Diagram

Best Practices

DC Passwords: AWS Secrets Manager rotation.

Backup: Regular ntdsutil snapshots to EBS → S3.

Time Sync: Disable Windows NTP, use Amazon Time Sync Service.

Scaling: Auto Scaling Group with warm pool for DC replacement.

Disaster Recovery: Read-only DCs in DR region.

Multi-Account Strategy

Security OU → Logging Account (centralized Event Logs)

Production OU → SAP Prod DCs

Non-Prod OU → Dev/QA DCs (separate forest)

AWS Landscape 15: Monitoring

CloudWatch provides comprehensive visibility across your multi-account SAP environment, aggregating metrics, logs, and events from EC2 instances, SAP HANA, application servers, Transit Gateway, and Palo Alto firewalls. Centralized dashboards and automated alarms enable proactive operations while supporting compliance and multi-region deployments.

Key Benefits

End-to-end monitoring of infrastructure + SAP applications.

Cross-account dashboards reduce operational complexity.

Automated remediation prevents downtime.

SAP-specific metrics alongside AWS infrastructure data.

Objective

Enable continuous monitoring across all SAP tiers and AWS resources with:

Centralized dashboards for performance/security visibility.

Alarms with automated response workflows.

SAP HANA + NetWeaver integration with CloudWatch Agent.

Monitoring Scope

Resource Metrics                             Logs

EC2         CPU, Memory, Disk I/O, Network /var/log/messages, CloudWatch Agent

SAP HANA DB size, connections, alerts nameserver_trace, indexserver_trace

SAP App         Dialog response time, users dev_w*, workprocess logs

Network         TGW bytes/packets, Flow Logs VPC Flow Logs

Firewalls Threat logs, sessions         Palo Alto syslog

Technical Implementation Steps

Step 1: Deploy CloudWatch Agent

Install on all EC2 instances (SAP HANA, App Servers, ASCS):

Linux:

# Download and install

curl https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm -o agent.rpm

sudo rpm -U ./amazon-cloudwatch-agent.rpm

# Configure for SAP

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

Config JSON (/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json):

json

{

  "metrics": {

    "metrics_collected": {

      "Memory": {"measurement": ["mem_used_percent"]},

      "Disk": [{"device": "/dev/xvda1", "metrics": ["free"]}],

      "procstat": [{"exe": ["hdb", "sapstartsrv"]}]

    }

  },

  "logs": {

    "logs_collected": {

      "files": {

        "collect_list": [

          {"file_path": "/var/log/sap*", "log_group_name": "SAP-Application"},

          {"file_path": "/hana/shared/*/HDB*/trace/*", "log_group_name": "SAP-HANA"}

        ]

      }

    }

  }

}

Step 2: Enable Detailed Monitoring

EC2 Console → Instance → Actions → Monitor and troubleshoot → Manage detailed monitoring (1-min granularity).

Step 3: Create Cross-Account Dashboard

CloudWatch → Dashboards → Create dashboard:

Widgets:

1. EC2 CPU/Memory (Prod Account) - Line chart

2. SAP HANA Connections - Stacked area

3. TGW Traffic (bytes/packets) - Dual axis

4. Palo Alto Threat Events - Bar chart

5. Recent CloudTrail Events - Table

Step 4: Critical Alarms (CloudWatch → Alarms)

Metric Threshold Action

CPUUtilization >80% (5/5 mins) SNS → PagerDuty

MemoryUtilization >85% Scale ASG + Notify

DiskReadOps >1000 (spikes) Lambda → Add EBS volume

HANA_DB_Size >90% capacity Auto snapshot + alert

TGW_Packets_Dropped >100/sec Network team alert

CLI Example:

aws cloudwatch put-metric-alarm \

  --alarm-name SAP-CPU-High \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 300 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \

  --evaluation-periods 2 \

  --alarm-actions arn:aws:sns:region:account:CriticalAlerts

Step 5: EventBridge Automation

Event Pattern:

{

  "source": ["aws.ec2"],

  "detail-type": ["EC2 Instance State-change Notification"],

  "detail": {"state": [{"name": "stopped"}] }

}

Targets:

- Lambda: Auto-restart SAP ASCS

- SNS: Notify on-call engineer

- SSM: Run diagnostic playbook

Step 6: VPC Flow Logs + Firewall Logs

VPC Flow Logs → CloudWatch Logs → Metric Filters

Filter: REJECT → Alarm on blocked SAP traffic

Palo Alto → rsyslog → CloudWatch Logs

/syslog → Log Group: PaloAlto-Threats

Monitoring Architecture

SAP-Specific Metrics (via CloudWatch Agent):

HANA: hdbcons 'systeminformation' → Custom metrics

App: SM50 work process utilization → Log parsing

Solution Manager: EWA reports → CloudWatch Insights

Cross-Account Setup (Organizations):

Management Account: Create CloudWatch Monitors.

Member Accounts: Enable cross-account observability.

RAM: Share dashboards across OUs.

Retention & Compliance:

Prod Logs: 400 days → S3 Glacier

Dev Logs: 30 days → Delete

Audit Logs: 7 years → S3 + Athena

Validation Dashboard Queries:

# CloudWatch Logs Insights - SAP Errors

fields @timestamp, @message

filter @message like /ERROR|FAIL/

stats count(*) by bin(5m)

sort @timestamp desc

AWS Landscape 14: Security Groups

Security Groups (SGs) act as stateful instance-level firewalls, providing fine-grained control for SAP workloads while complementing NACLs, Transit Gateway, and Palo Alto firewalls. The layered approach—common SGs for baseline rules + workload-specific SGs—simplifies management across multi-account, multi-AZ SAP environments.

Key Benefits

Stateful: Automatic return traffic handling.

Layered: Common rules update everywhere instantly.

Least Privilege: Application-specific isolation.

Scalable: Auto Scaling Groups inherit SGs automatically.

Objective

Implement layered SGs for SAP tiers (ASCS, App Servers, HANA DB, Web Dispatcher) ensuring:

Instance-level protection beyond subnet NACLs.

Controlled east-west (tier-to-tier) and north-south traffic.

Auditability via AWS Config and tagging.

Layered SG Design

Layer              Purpose                   Examples

Common SGs Baseline subnet access SSH/RDP from VPN, NTP/DNS, Windows Update

Workload SGs Application-specific HANA 30015 (App→DB only), SAP GUI 32xx (LB→App)

Technical Implementation Steps

Step 1: Create Common Security Groups

SG-Common-Public (Bastions/Firewalls):

Inbound Rules  Type Port         Source

SSH Admin TCP 22 203.0.113.0/24 Corporate VPN

HTTPS Mgmt TCP 443 0.0.0.0/0 Admin access

Outbound: All traffic (0.0.0.0/0)

SG-Common-Private (All private instances):

Inbound Rules  Type Port Source

NTP UDP 123 10.0.0.0/16 VPC CIDR

DNS UDP 53 10.0.0.0/16 VPC CIDR

Outbound: All traffic (0.0.0.0/0)

CLI: aws ec2 create-security-group --group-name SG-Common-Public --description "Public subnet baseline" --vpc-id vpc-0a1b2c3d

Step 2: Create Workload-Specific Security Groups

SG-SAP-ASCS (ASCS Server):

Inbound         Type            Port         Source

SAP ASCS TCP 3600-3610         SG-SAP-App App Servers

Enqueue         TCP 3601         SG-SAP-App App Servers

Outbound Ephemeral 1024-65535 SG-SAP-App Reply traffic

SG-SAP-App (Application Servers):

Inbound         Type     Port      Port Range  Source

HTTP/HTTPS TCP     80/443      SG-Web-Dispatcher Load Balancer

SAP Dialog TCP     3200-3299        SG-Web-Dispatcher SAP GUI

JCo         TCP     50000-50100      SG-SAP-HANA HANA DB

Outbound Ephemeral   1024-65535      SG-SAP-HANA HANA Reply

SG-SAP-HANA (SAP HANA Database):

Inbound         Type   Port Range Source

HANA Port TCP   30015         SG-SAP-App

HANA System TCP   30017         SG-SAP-App

HANA Dist TCP   3##15-3##17 SG-SAP-App

Outbound Ephemeral 1024-65535 SG-SAP-App

CLI: aws ec2 authorize-security-group-ingress --group-id sg-0a1b2c3d --protocol tcp --port 30015 --source-group sg-sap-app

Step 3: Attach Layered SGs to Instances

Each EC2 instance gets 2 SGs:

SAP App Server: SG-Common-Private + SG-SAP-App

SAP HANA DB:    SG-Common-Private + SG-SAP-HANA

SAP ASCS:       SG-Common-Private + SG-SAP-ASCS

CLI: aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d --groups sg-common-private sg-sap-app

Step 4: Tagging & Monitoring

Tags:

Environment: Production

Tier: Application

Compliance: PCI-DSS

Owner: SAP-Team

AWS Config Rule: Monitor SG changes:

json

{

  "rule": "security-group-allow-ingress-from-internet-to-port",

  "scope": "security-group"

}

Step 5: Validation Commands

# Test SAP GUI port from load balancer subnet

nc -zv sap-app.internal 3201

# Test HANA connectivity from app subnet

nc -zv hana-db.internal 30015

# List effective rules for instance

aws ec2 describe-network-interfaces --filters "Name=attachment.instance-id,Values=i-0a1b2c3d"

SG Architecture

Traffic Flow Example (SAP GUI → App Server):

NACL (Public subnet): Allow TCP 3200-3299 → App subnet

SG-Web-Dispatcher: Allow 3200-3299 from LB

SG-Common-Private: Allow ephemeral from public CIDR

SG-SAP-App: Allow 3200-3299 from SG-Web-Dispatcher

Best Practices

SG Referencing: Use SG IDs, not CIDRs for tier-to-tier communication.

​No 0.0.0.0/0: Restrict to corporate VPN or specific CIDRs.

​Naming: SG-{env}-{tier}-{function} (SG-prd-app-dialog).

Limits: Max 60 inbound rules per SG; use NACLs for subnet rules.

Automation: CloudFormation/Terraform + AWS Config for compliance.

Complete Defense Stack:

Internet → NACL(Public) → SG-Common-Public → Palo Alto FW → 

NACL(App) → SG-Common-Private → SG-SAP-App → TGW → Other VPCs

AWS Landscape 13: Network Access Control Lists (NACLs)

Network Access Control Lists (NACLs) provide subnet-level security by controlling both inbound and outbound traffic. NACLs complement Security Groups, adding an additional layer of protection for SAP workloads across public and private subnets.

Key benefits:

• Stateless filtering at the subnet level.
• Adds east-west and north-south traffic control.
• Enhances compliance and security monitoring.

Objective

• Implement NACLs to restrict traffic per subnet in each VPC.
• Protect both public-facing and internal SAP workloads.
• Provide an additional layer of security beyond Security Groups.

Design Overview:

Default AWS NACLs: Allow all inbound/outbound traffic by default.

Custom NACLs:

• Apply specific rules per subnet.
• Stateless: define both inbound and outbound rules.
• Restrict access according to environment, workload, and subnet type.

Purpose:

• Control traffic entering/exiting subnets.
• Provide subnet-level protection for SAP workloads and shared services.

Technical Implementation Steps

Step 1: Create Custom NACLs

VPC Console → Network ACLs → Create NACL:

NACL Name      VPC Subnet Type

Prod-Public-NACL     VPC-Prod Public

Prod-App-NACL      VPC-Prod App Private

Prod-DB-NACL      VPC-Prod DB Private

CLI: aws ec2 create-network-acl --vpc-id vpc-0a1b2c3d --tag-specifications 'ResourceType=network-acl,Tags=[{Key=Name,Value=Prod-Public-NACL}]'

Step 2: Public Subnet NACL Rules (Bastions/NAT/Firewalls)

Inbound (100-199):

Rule # Type Protocol Port Range Source Description

100 SSH TCP 22 203.0.113.0/24 Corporate VPN

110 HTTPS TCP 443 0.0.0.0/0 Admin access

DENY All All All 0.0.0.0/0 Block all else

Outbound (100-199):

Rule # Type Protocol Port Range Destination Description

100 Custom TCP TCP 1024-65535 0.0.0.0/0 Ephemeral reply

110 Custom TCP TCP 3200-3299 10.0.1.0/24 SAP App servers

DENY All All All 0.0.0.0/0 Block all else

Step 3: Private App Subnet NACL Rules (SAP Application Servers)

Inbound:

Rule # Type Protocol Port Range Source Description

100 Custom TCP TCP 3300-3399 10.0.0.0/24 Public subnet

110 Custom TCP TCP 50000-59999 10.0.4.0/24 HANA DB

DENY All All All 0.0.0.0/0

Outbound:

Rule # Type Protocol Port Range Destination Description

100 Custom TCP TCP 1024-65535 10.0.0.0/24 Public reply

110 Custom TCP TCP 30015 10.0.4.0/24 HANA reply

DENY All All All 0.0.0.0/0

Step 4: Private DB Subnet NACL Rules (SAP HANA)

Inbound:

Rule # Type Protocol Port Range Source Description

100 Custom TCP TCP 30015 10.0.1.0/24 App servers

110 Custom TCP TCP 30017 10.0.1.0/24 HANA replication

DENY All All All 0.0.0.0/0

Step 5: Associate NACLs with Subnets

VPC Console → Subnets → Select subnet → Actions → Edit subnet associations → Select NACL.

CLI: aws ec2 associate-network-acl --network-acl-id acl-0a1b2c3d --subnet-id subnet-0a1b2c3d

Step 6: Enable VPC Flow Logs

Monitor NACL accepts/rejects:

CloudWatch Logs → VPC Flow Logs → Create for subnet → Filter action=REJECT.

NACL Architecture

Rule Numbering Strategy

100-199: Allow essential traffic

200-299: Allow management/monitoring

DENY: Block all else (lowest priority)

Rule *** (lowest): Allow established/related

Best Practices

Environment-Specific: Stricter Prod NACLs vs permissive Sandbox.

Rule Order: Lowest number = highest priority.

Ephemeral Ports: Always allow 1024-65535 for return traffic.

Testing: Use telnet or nc to validate before production.

Automation: CloudFormation/Terraform for consistent NACLs.

Quick Validation Commands

# Test SSH to bastion

nc -zv bastion.example.com 22

# Test SAP HANA port from app subnet

nc -zv hana-db.internal 30015