AWS Landscape 2: Environments

A well-architected SAP landscape in AWS requires multiple isolated environments to ensure security, compliance, and operational efficiency. Separating workloads into different accounts allows:

• Environment Isolation: Prevents accidental access between Production and non-Production environments.
• Centralized Services: Shared services like Active Directory, License Servers, and Secrets Manager can be centrally managed.
• Centralized Logging & Auditing: Logs from all environments can be aggregated for compliance and security monitoring.
• Cost Tracking & Governance: Each account can be monitored independently for usage and billing.
• Scalability: New environments, such as Disaster Recovery or Training, can be added without disrupting existing workloads.

Objective:
Define and implement SAP landscape environments in AWS to support deployment, testing, and production workloads. Each environment should reside in a separate AWS account to ensure:

• Isolation and security
• Clear billing and cost tracking
• Governance and compliance
• Scalability for future environments like Training or Disaster Recovery

Environment Overview

Environment	Purpose	AWS Account Mapping
Production	Live SAP workloads, mission-critical systems	Production Account
Development	Dev work, feature development, testing	Development Account
Pre-Production	Staging for pre-release validation	Pre-Production Account
Quality (QA)	Integration, functional, regression testing	Quality Account
Sandbox	Ad-hoc experiments, PoC, learning	Sandbox Account

Key Principles:

• Each environment has its own AWS account.
• Accounts are fully isolated for networking, security, and billing.
• Tagging ensures automation, reporting, and governance.

Technical Implementation Steps:

Step 1: Account Tagging
Purpose: Identify environment type, track costs, and enforce governance.
Action Items:

• Log in to each AWS account.
• Navigate to AWS Organizations → Accounts → Tags → Add tag.

Apply the following recommended tags:

Tag Key	Example Value	Purpose
Environment	Production / Development / QA / Sandbox / Pre-Prod	Identify environment for automation & policies
Project	SAP Migration Project	Track project-related costs
Owner	<Team Name>	Define responsible team

Best Practices:

• Use AWS Tag Policies to enforce consistent tags across accounts.
• Ensure new accounts inherit required tags automatically.

Step 2: VPC and Network Setup per Environment

Purpose: Isolate network traffic and prevent overlap between environments.
Action Items:

• Create one VPC per environment account.

Assign non-overlapping CIDR blocks:

Environment	VPC CIDR	Example VPC Name
Production	10.0.0.0/16	VPC-Prod
Development	10.1.0.0/16	VPC-Dev
Pre-Production	10.2.0.0/16	VPC-PreProd
Quality (QA)	10.3.0.0/16	VPC-QA
Sandbox	10.4.0.0/16	VPC-Sandbox

Subnets and Routing:
Public subnets: Bastion hosts, NAT Gateways
Private subnets: SAP application servers, databases, shared services
Spread subnets across 2–3 Availability Zones (AZs) for high availability

Route tables:

• Public → Internet Gateway (IGW)
• Private → NAT Gateway (one per AZ)

Attach Transit Gateway (TGW) in the Network Account for centralized inter-VPC communication

Step 3: Security and Access Control
Purpose: Enforce least privilege and protect production workloads.
Action Items:
IAM Roles & Policies:

• Production: Only approved administrators have access
• Dev/QA/Sandbox: Developers may have more access, restricted via IAM policies

AWS SSO / Identity Management:

• Centralized authentication across all accounts
• Assign roles per environment for consistent access

Encryption & Key Management:

• Create environment-specific AWS KMS CMKs for EBS, S3, RDS
• Restrict access per environment using key policies

Network Security:

• Security groups and NACLs enforce isolation
• No direct access from non-prod to production unless via approved pipelines or VPN

Additional Security Measures:

• Enable MFA for all privileged users
• Log all administrative actions for auditability

Step 4: Environment Isolation
Purpose: Prevent accidental impact between environments.
Implementation:
Network Isolation:

• Each VPC is in its own AWS account
• Transit Gateway routes only approved connections

Logging & Monitoring:

• Enable CloudTrail, CloudWatch, and AWS Config per environment
• Optionally, send logs to a centralized Logging Account

Access Control:

• Only approved pipelines or VPNs may access Production from non-prod environments

Step 5: Infrastructure Automation

Purpose: Standardize deployments, reduce human error, and allow scalability.
Action Items:
Use CloudFormation StackSets or Terraform to automate:

• VPC creation, subnets, and routing
• IAM roles and SSO groups
• KMS key creation
• Shared Services deployments

Track costs and usage per environment with AWS Cost Explorer and Budgets

Step 6: Optional Future Environments

• Training Account: For SAP training environments
• Disaster Recovery Account: DR site for Production workloads

Both can be added by creating new accounts, VPCs, and attaching to Network TGW, with minimal impact on existing setup.

Diagram – Environment to Account Mapping:

Environment Mapping:

Environment      AWS Account

---------------------------------------

Production       Production Account

Development      Development Account

Pre-Production   Pre-Prod Account

Quality (QA)     QA Account

Sandbox          Sandbox Account

Advantages

Security: Isolated blasts; centralized monitoring.

Governance: Tags/SCPs for compliance.

Cost: Per-account visibility.

Scale: Add accounts seamlessly.