Case Study · Enterprise Applications
Enterprise SAP Modernisation on AWS
Four-Pillar Transformation · AI Agents · Contact Centre · Cloud Data Warehouse · Automated Governance
Based on AWS Guidance: Agentic ERP · Connect + SAP · SAP Data Warehouse · SAP Health Checks
Architecture study: a design exercise based on public AWS guidance, not a claimed client engagement
Executive Summary
This case study documents a four-pillar enterprise transformation of an SAP S/4HANA landscape running on AWS. Each pillar addresses a distinct operational gap: intelligent financial automation, connected customer experience, cloud-native analytics, and continuous compliance governance, using AWS-native services deeply integrated with SAP systems via standard protocols including OData, EventBridge, and the AWS Well-Architected Framework for SAP workloads.
The architecture is derived from four AWS Guidance solutions and synthesised into a coherent enterprise programme: Agentic ERP for AP/AR exception handling, Amazon Connect integration with SAP Sales and Service Cloud, SAP Cloud Data Warehouse on Amazon Redshift, and Automated SAP Configuration Health Checks. Together they represent a comprehensive modernisation of the SAP operating model: from reactive and manual to intelligent, automated, and continuously governed.
Pillar I · AI Finance
Bedrock agents resolve AP/AR exceptions autonomously, reducing manual invoice matching time by eliminating repetitive data lookup and contextual reasoning tasks.
Pillar II · CX Connect
Amazon Connect integrates bidirectionally with SAP Sales and Service Cloud, giving agents a unified view and pushing AI-generated call summaries directly into SAP customer timelines.
Pillar III · Data Warehouse
AppFlow extracts SAP data via OData into a Redshift-based cloud data warehouse, enabling Order-to-Cash and Procure-to-Pay analytics with SCD2 history and Amazon Q-powered natural-language queries.
Pillar IV · Governance
100+ automated health checks run on a schedule against SAP HANA and application servers, surfacing configuration drift against AWS Well-Architected Framework standards in QuickSight dashboards.
Business Context & Problem Statement
Global enterprises running SAP S/4HANA on AWS face a common set of structural challenges: high volumes of manual ERP exception handling consuming finance team capacity, disconnected contact centre systems creating fragmented customer experiences, SAP data trapped in proprietary formats inaccessible to cloud-native analytics tools, and SAP infrastructure configurations that drift from best practices without automated detection.
AP/AR Exception Backlog
Accounts payable teams spend 30–40% of processing time resolving exceptions: price variances between purchase orders and invoices, duplicate invoice submissions, two-way and three-way matching failures. Each exception requires a finance analyst to manually cross-reference scattered data sources (PO records, goods receipts, vendor master data, and approval workflows) before making a resolution recommendation.
Disconnected Contact Centre
Customer-facing agents handle calls with no real-time access to the customer's SAP interaction history. After each call, agents manually transcribe notes into SAP Service Cloud, a process prone to errors and delays. Call analytics (topics, sentiment, outcomes) exist in the contact centre platform but are not surfaced in SAP, preventing service managers from acting on patterns.
SAP Analytics Gap
SAP's embedded reporting tools (SAP BW, Embedded Analytics in S/4HANA) are tightly coupled to SAP's data model, requiring ABAP expertise to extend. Business analysts cannot query SAP data alongside non-SAP data sources in a single tool. The absence of a cloud data warehouse means strategic reporting is delayed by ETL cycles running overnight rather than near real-time.
Configuration Compliance Risk
SAP HANA and application server configurations drift from AWS Well-Architected Framework recommendations over time, through manual changes, patching, and ad-hoc adjustments. Without automated scanning, compliance reviews are point-in-time audits conducted quarterly. Configuration issues causing performance or security risks may persist undetected for months between reviews.
Architecture Overview
The four pillars share a common foundation of AWS-managed services: S3 for persistent storage, Secrets Manager for credential management, CloudWatch for observability, DynamoDB for operational state, and IAM for least-privilege access control. Each pillar integrates with SAP through a different protocol appropriate to its data access pattern: OData APIs for data extraction, EventBridge for real-time events, API Gateway for bidirectional integration, and AWS Systems Manager for infrastructure introspection.
Enterprise SAP on AWS: Architecture Overview · Official AWS Icons
Integration Protocols by Pillar
Pillar I
SAP ERP APIs
Bedrock agents call SAP BAPI/OData endpoints to fetch invoice, PO, and goods receipt data for contextual reasoning
Pillar II
EventBridge + API GW
Connect call events flow via EventBridge → Lambda → API Gateway into SAP Sales/Service Cloud in near real-time
Pillar III
OData / AppFlow
AppFlow extracts SAP data via SAP OData services exposed by SAP Gateway, landing records in S3 for downstream processing
Pillar IV
Systems Manager
SSM Run Command and Inventory query SAP HANA configuration parameters and application server settings directly on EC2 instances
Pillar I: Agentic AP/AR Exception Handling
Intelligent Financial Automation
Amazon Bedrock · Strands SDK · Amazon Q in BusinessAccounts payable and receivable exception handling is automated using Amazon Bedrock agents. The agents are built using either the Strands SDK (for developer-controlled, fine-grained agent logic) or the Amazon Quick Suite (for low-code deployment by finance business users). Both patterns connect to SAP S/4HANA via the ERP's standard API layer to retrieve invoice, purchase order, goods receipt, and vendor master data in real-time during agent reasoning.
Accounts Payable Exception Workflow
- Exception trigger: SAP S/4HANA flags an invoice for manual review (price variance, duplicate detection, or matching failure) and writes an event to the agent's input queue
- Context assembly: the Bedrock agent calls SAP OData APIs to retrieve the full invoice record, the linked purchase order, goods receipt confirmations, and the vendor's payment terms and history
- Reasoning: the agent applies business rules from a Bedrock Knowledge Base (containing the enterprise's AP standard operating procedures, variance tolerance thresholds, and vendor-specific overrides) to determine the appropriate resolution action
- Action: the agent either auto-resolves the exception within defined tolerance thresholds (posting the invoice with a tolerance adjustment), escalates to a human reviewer with a pre-drafted resolution recommendation, or requests a credit note from the vendor, all via SAP API calls
- Audit trail: every agent decision, the evidence considered, and the action taken is logged to Amazon S3 and indexed in the Bedrock Knowledge Base for compliance and audit review
Accounts Receivable Exception Workflow
- Order-to-Cash scope: the agent handles disputed invoices, short payments, deductions claims, and credit memo applications in the AR ledger
- Customer context: the agent retrieves the customer's order history, delivery confirmations, dispute history, and credit limit from SAP to inform resolution recommendations
- Deduction management: for short-payment deductions, the agent classifies the deduction type (promotional, freight, quality), matches it to the relevant trade agreement in SAP, and either auto-approves within policy or creates a deduction worklist item with supporting documentation
- Collections prioritisation: the agent ranks open AR items by risk score (days overdue, customer credit score, dispute history) to produce a prioritised collections call list, reducing collector time spent on low-risk items
Two Implementation Patterns
Strands SDK Pattern (Developer)
Amazon Bedrock AgentCore with the Strands SDK provides programmatic control over agent reasoning steps, tool definitions (SAP API wrappers), memory management, and multi-agent orchestration. Suited to complex exception scenarios requiring custom business logic, multi-step approval workflows, or integration with non-SAP systems. Requires Python development capability.
Amazon Quick Suite (Business User)
Pre-built agentic capabilities for P2P and O2C processes, deployable via a low-code/no-code interface. Finance managers can configure exception rules, tolerance thresholds, and escalation paths without engineering involvement. Trades customisability for speed-to-value: production deployments in days rather than weeks.
Pillar II: Amazon Connect + SAP Sales & Service Cloud
Connected Contact Centre
Amazon Connect · EventBridge · Lambda · API GatewayThis pillar integrates Amazon Connect (AWS's cloud contact centre) with SAP Sales Cloud and SAP Service Cloud using an event-driven, serverless architecture deployed via AWS CDK. The integration is bidirectional: SAP customer data is surfaced to agents during live calls, and post-call AI-generated summaries and analytics are pushed back into SAP customer timelines automatically.
Architecture and Data Flow
- Inbound call: a customer calls the contact centre; Amazon Connect initiates a contact flow and triggers a CTI screen-pop by querying SAP Sales Cloud via API Gateway for the customer's interaction history, open cases, and account status
- Live assist: during the call, the agent's workspace displays the customer's SAP timeline (recent orders, service tickets, and prior interactions) without switching applications
- Call events: Amazon Connect emits contact events (call started, transferred, ended) to Amazon EventBridge as the call progresses
- Lambda processing: EventBridge rules invoke Lambda functions that process each event, extracting call metadata, triggering real-time transcription via Amazon Transcribe, and staging data for SAP update
- Post-call analytics: Amazon Bedrock summarises the call transcript, classifies the contact reason, extracts action items, and generates a structured summary in the format expected by SAP Service Cloud's timeline object
- SAP update: a Lambda function calls the SAP Service Cloud API via API Gateway to create an interaction record in the customer timeline, attach the AI-generated summary, and, if the call resulted in a service issue, automatically create a service ticket with pre-populated fields
- S3 storage: call recordings, full transcripts, and metadata are persisted to S3 with a defined retention policy; CloudFront distributes recordings to authorised playback endpoints
Modular Architecture Benefits
- Each capability (screen-pop, call analytics, SAP timeline update, ticket creation) is a separate Lambda function invoked by distinct EventBridge rules, enabling incremental deployment of features without disrupting existing integrations
- CDK templates codify the entire integration stack as infrastructure-as-code, enabling repeatable deployment across multiple AWS accounts (e.g. separate accounts for development, staging, and production)
- Account segregation between the Connect AWS account and the SAP integration account is enforced via cross-account IAM roles, limiting the blast radius of a credential compromise to a single account
- Serverless Lambda execution automatically scales with contact centre volume; a bank holiday spike or campaign period doubles call volume without pre-provisioning additional compute
Operational Metrics Unlocked
Handle Time Reduction
Agents no longer manually search SAP for customer context during calls. The screen-pop surfaces relevant records at call answer, typically saving 45–90 seconds of handle time per contact.
After-Call Work Elimination
Manual post-call note entry into SAP is replaced by AI-generated summaries pushed automatically. Eliminates 2–5 minutes of after-call work per contact and improves note accuracy.
Service Intelligence
Contact reason classification, sentiment trends, and resolution rates are available in SAP Service Cloud dashboards, enabling service managers to identify systemic issues and coaching opportunities from call analytics.
Pillar III: SAP Cloud Data Warehouse
Analytics on SAP Data
AppFlow · S3 · Glue · Redshift · QuickSight · Amazon QThis pillar extracts SAP business data via OData APIs and constructs a cloud-native data warehouse on Amazon Redshift, enabling SQL analytics, business intelligence in Amazon QuickSight, and natural-language queries via Amazon Q. The architecture preserves SAP's embedded business logic and metadata during extraction, maintaining context that would otherwise be lost in a generic ETL process.
Data Pipeline Architecture
- Metadata replication: an AWS Lambda function queries SAP OData metadata services to discover available entities and their field definitions, then generates Amazon Redshift DDL statements automatically, eliminating manual schema definition for hundreds of SAP tables
- Data extraction: Amazon AppFlow connects to SAP via the OData protocol through SAP Gateway, extracting records and landing them in Amazon S3 as the raw data lake layer (corporate memory)
- Pipeline orchestration: AWS Step Functions coordinates the end-to-end pipeline, triggering metadata refresh, AppFlow extraction runs, Lambda transformation jobs, and Redshift load operations in the correct dependency order with error handling and retry logic
- Incremental CDC: after the initial full load, Change Data Capture (CDC) processes extract only modified records using SAP's delta token mechanism, keeping the data warehouse in near real-time sync with S/4HANA without full table re-extraction
- SCD2 modelling: the Redshift data mart implements Slowly Changing Dimension Type 2 (SCD2) for key business entities (customers, vendors, materials, and cost centres), preserving the full history of attribute changes for time-travel analytics (e.g. "what was this customer's credit limit at the time of this order?")
- Glue Data Catalog: AWS Glue crawlers catalogue all S3 raw data and Redshift tables, enabling Athena to query the raw layer directly without Redshift ingestion, useful for ad-hoc exploration and data quality validation before promotion to the curated layer
SAP Functional Coverage
Order-to-Cash (O2C)
Customer master, sales orders, deliveries, billing documents, accounts receivable line items, and customer payment history. Supports revenue analytics, DSO (Days Sales Outstanding) trending, order fulfilment metrics, and customer profitability analysis.
Procure-to-Pay (P2P)
Vendor master, purchase orders, goods receipts, vendor invoices, accounts payable line items, and payment runs. Supports spend analytics, DPO (Days Payable Outstanding) trending, supplier performance metrics, and working capital optimisation.
Custom Fields
SAP's AppFlow connector automatically includes custom fields added via SAP's Custom Fields and Logic app, eliminating the need to manually extend extraction logic when business teams extend SAP data models.
Conversion Rules
SAP stores quantities, amounts, and units in internal format. The extraction pipeline applies SAP conversion rules during ingestion, transforming internal units to display format so Redshift data is immediately usable by business users without understanding SAP internal coding conventions.
Analytics Layer
- Amazon QuickSight connects directly to Redshift via SPICE for sub-second dashboard performance; dashboards are pre-built for O2C KPIs (order cycle time, fill rate, AR ageing) and P2P KPIs (PO cycle time, invoice match rate, AP ageing)
- Amazon Q for Business provides natural-language query capability over the data warehouse; business users ask questions in plain English ("show me the top 10 vendors by overdue invoices this quarter") and receive answers drawn from the Redshift data warehouse without writing SQL
- Amazon Athena enables ad-hoc SQL queries directly against the S3 raw layer for data engineering and data quality analysis, with results available in seconds and billed per TB scanned
Pillar IV: Automated SAP Configuration Health Checks
Continuous Compliance Governance
Systems Manager · Lambda · DynamoDB · Athena · QuickSight · SESThis pillar automates the execution of 100+ configuration compliance checks against SAP HANA databases and SAP application servers running on AWS, aligned with the AWS Well-Architected Framework for SAP workloads. Checks run on a schedule via Amazon EventBridge, results are stored in DynamoDB and S3, and outcomes are visualised in QuickSight dashboards with email notifications via Amazon SES.
Health Check Categories
- Operational Excellence: SAP backup frequency and retention, HANA backup verification status, application server log rotation, SAP transport management configuration, and change management control compliance
- Security: HANA database user privilege audits, SAP Gateway service exposure, SSL/TLS configuration for SAP web services, unused RFC destination cleanup, and SAP Note application status for critical security patches
- Reliability: HANA system replication status and lag, application server high-availability configuration, AWS instance type alignment with SAP certification matrix, storage type and IOPS compliance for HANA data and log volumes
- Performance Efficiency: HANA memory allocation versus available RAM, CPU scheduling parameters for HANA, application server work process configuration, and SAP table statistics freshness
- Cost Optimisation: EC2 instance rightsizing relative to SAP sizing guidelines, unattached EBS volumes associated with SAP systems, S3 storage class alignment for SAP backup destinations, and Savings Plan or Reserved Instance coverage for SAP workloads
- Well-Architected SAP specific: multi-AZ deployment verification, placement group membership for HANA scale-out, AWS Systems Manager Patch Manager compliance, and CloudWatch alarm coverage for SAP-critical metrics
Scanning Pipeline
- EventBridge scheduled rule triggers the health check Lambda on a configurable cadence (default: daily at 02:00 UTC, outside SAP system peak hours)
- AWS Systems Manager Run Command executes check scripts on SAP EC2 instances without opening inbound SSH; the SSM agent handles secure execution and returns structured JSON results
- Lambda processes results, scores each check (PASS / WARN / FAIL / INFO), and writes records to DynamoDB (for current state) and S3 (for historical archive, partitioned by date and system ID)
- Amazon Athena queries the S3 archive to compute trend data, identifying checks that repeatedly fail, systems that are improving, and drift patterns over time
- QuickSight dashboards provide three views: (1) summary scorecard across all systems, (2) per-system drill-down with check-level detail and remediation guidance, (3) side-by-side comparison of two systems, useful for validating that a refreshed system matches the configuration standard of a reference system
- Amazon SES delivers an email digest to SAP Basis administrators upon each scan completion, listing all FAIL and WARN findings with links to the relevant QuickSight dashboard view
Multi-System Comparison
The side-by-side comparison dashboard is particularly valuable during landscape refresh projects. When a new SAP system is provisioned (e.g. a new development or quality system cloned from production), the comparison view immediately surfaces configuration gaps between the new system and the production reference, catching misconfigurations before the system is released to users.
Security & Governance
Security across the four pillars is governed by a common set of principles: least-privilege IAM, no long-lived credentials, encryption at rest and in transit, and full audit trails. The SAP integration layer is the highest-risk boundary because SAP systems contain sensitive financial, employee, and customer data, and receives the strongest controls.
Credential Management
- All SAP system credentials (RFC user passwords, OData service credentials, API keys) are stored in AWS Secrets Manager, never in code, environment variables, or configuration files
- Lambda functions access SAP credentials via IAM role with a resource-scoped SecretsManager:GetSecretValue permission on the specific secret ARN; no wildcard permissions
- AppFlow connections to SAP Gateway authenticate using OAuth 2.0 client credentials stored in Secrets Manager, with automatic token refresh managed by AppFlow
- Automatic Secrets Manager rotation is configured for SAP technical user passwords; the rotation Lambda calls the SAP user management API to change the password and update the secret atomically
Network Architecture
- SAP EC2 instances run in private subnets with no public IP addresses; all management access is via AWS Systems Manager Session Manager: no bastion hosts, no inbound SSH rules
- AppFlow SAP connector accesses SAP Gateway via AWS PrivateLink or a Direct Connect/VPN connection; OData traffic never traverses the public internet
- Amazon Connect integrates with SAP via API Gateway endpoints deployed behind an API key and IAM authentication; contact centre traffic to SAP is isolated in a dedicated VPC
- Cross-account IAM roles (for the Connect integration) use external ID conditions and are scoped to the minimum API actions required for each Lambda function's specific SAP operation
Data Classification and Encryption
- SAP financial data in Redshift is encrypted at rest using AWS KMS customer-managed keys (CMK); key policies are scoped to the specific IAM roles used by QuickSight, Athena, and the ETL pipeline
- S3 buckets for SAP data (raw layer, health check archives, call recordings) use SSE-S3 encryption with bucket policies blocking public access and enforcing secure transport (aws:SecureTransport condition)
- DynamoDB tables (health check state, revocation registry) are encrypted using AWS-owned keys with point-in-time recovery enabled
- CloudTrail data events are enabled on all S3 buckets containing SAP data; every GetObject and PutObject is logged for data access audit purposes
- Call recordings stored in S3 are subject to a data retention policy configured as an S3 Lifecycle rule; recordings transition to S3 Glacier Instant Retrieval after 90 days and are permanently deleted after 7 years per data protection policy
Cost Model
All four pillars are built on serverless and managed AWS services, meaning costs scale with usage rather than reserved capacity. The following estimates are indicative for a mid-size enterprise deployment (5,000 SAP users, 2,000 contact centre interactions/day, 10 TB SAP data warehouse, 50 SAP instances under health monitoring).
Pillar I: Agentic AP/AR
Amazon Bedrock: ~$0.003 per 1K input tokens (Claude 3 Sonnet). A complex invoice exception resolution requiring 10K tokens of context: ~$0.03 per exception. At 500 exceptions/day: ~$15/day, ~$450/month.
Lambda + S3 audit: <$5/month at this volume. Total Pillar I: ~$455/month.
Pillar II: Connect Integration
Amazon Connect: $0.018 per minute for inbound voice. 2,000 calls/day × 8 min avg = 16,000 min/day × $0.018 = $288/day or ~$8,600/month.
Lambda + EventBridge + Transcribe: ~$200/month. Total Pillar II (excl. Connect volume): ~$200/month infrastructure overhead.
Pillar III: Data Warehouse
AppFlow: $0.001 per 1,000 records. At 5M records/day: $5/day, ~$150/month.
Redshift ra3.xlplus (2 nodes): ~$1,200/month. QuickSight: $18/user/month. Step Functions: <$1/month. Total Pillar III: ~$1,500/month.
Pillar IV: Health Checks
Lambda (daily scans, 50 systems × 100 checks): ~$2/month. DynamoDB on-demand: ~$10/month. S3 + Athena: ~$5/month. QuickSight: shared with Pillar III. Total Pillar IV: ~$20/month.
Total Programme Estimate
AWS Well-Architected Framework
Operational Excellence
Infrastructure as Code: All four pillars are deployed via CloudFormation or AWS CDK, enabling version-controlled, repeatable deployments across development, staging, and production SAP landscapes.
Automated health checks: Pillar IV eliminates manual SAP configuration reviews, replacing quarterly point-in-time audits with daily automated scans and QuickSight trend dashboards visible to Basis and cloud engineering teams.
Observability: CloudWatch dashboards aggregate metrics from all four pillars (Bedrock agent invocation success rates, Connect call handling times, AppFlow flow run status, and health check pass rates) in a single operational view.
Security
No persistent credentials: Secrets Manager manages all SAP and inter-service credentials with automatic rotation. No passwords in code, environment variables, or SSM Parameter Store plain-text values.
Least privilege: Each Lambda function has an IAM role scoped to exactly the AWS API actions and resource ARNs it needs: no wildcard * resource permissions on any role interacting with SAP data.
Private networking: SAP systems remain in private subnets; all AWS service integration uses PrivateLink, VPC endpoints, or Direct Connect; SAP data never traverses the public internet.
Reliability
Step Functions retry: The Pillar III data pipeline uses Step Functions with exponential backoff and configurable retry counts on each state; a transient SAP API timeout does not fail the entire pipeline run.
Dead-letter queues: Lambda functions processing Connect events and AP/AR exceptions use SQS dead-letter queues; unprocessable messages are retained for inspection rather than silently dropped.
SAP HA validation: Pillar IV health checks include HANA system replication status and multi-AZ configuration checks, surfacing HA gaps before they become unplanned outages.
Performance Efficiency
Near real-time SAP data: AppFlow CDC in Pillar III keeps Redshift within minutes of S/4HANA, replacing overnight batch loads that left reports 12–24 hours stale.
Edge analytics: QuickSight SPICE caches Redshift data at query time, delivering sub-second dashboard load times for business users without adding query load to the Redshift cluster.
Serverless scale: Lambda in all four pillars scales from zero to thousands of concurrent invocations with no pre-warming; SAP integration throughput matches demand automatically.
Cost Optimisation
Consumption-based pricing: Bedrock, Lambda, AppFlow, Step Functions, and Athena all bill per-use; idle SAP systems (weekends, off-peak) incur near-zero integration costs.
Redshift reserved instances: Pillar III Redshift clusters are eligible for Reserved Instance pricing, committing to 1- or 3-year reservations reduces node costs by 40–60% versus on-demand.
Health check cost savings: Pillar IV surfaces EC2 instance rightsizing opportunities for SAP workloads: a single HANA instance downsized from r5.8xlarge to r5.4xlarge saves ~$1,000/month.
Sustainability (6th Pillar)
No idle compute: All four pillars use Lambda and Step Functions event-driven compute: zero idle energy consumption between SAP transactions, contact centre calls, and scheduled scan windows.
Right-sized SAP infrastructure: Pillar IV health checks surface over-provisioned SAP instances, enabling rightsizing that reduces the energy footprint of the SAP workload on AWS.
Managed service efficiency: AppFlow, Redshift, QuickSight, and Systems Manager run on shared AWS infrastructure with higher hardware utilisation than equivalent self-managed systems, reducing per-unit energy consumption.
Engineering Decisions & Tradeoffs
Decision 1: OData via AppFlow vs Direct HANA Database Connection
Chosen: AppFlow with SAP OData services via SAP Gateway.
Traded away: Direct HANA database connections (via JDBC/ODBC) provide lower-level access to all tables and can be faster for bulk extraction. OData is limited to entities explicitly exposed via SAP Gateway; custom tables must be explicitly wrapped in OData services.
Why acceptable: OData preserves SAP's application layer authorisation checks: a user credential used by AppFlow respects the same SAP role-based access controls as an interactive SAP user. Direct database access bypasses SAP authorisation entirely. For sensitive financial data, application-layer access control is a non-negotiable security requirement.
Decision 2: Bedrock Agents vs Deterministic RPA for AP/AR Exceptions
Chosen: Amazon Bedrock agents with LLM-based contextual reasoning.
Traded away: Traditional Robotic Process Automation (RPA) tools execute deterministic rules, faster, cheaper per invocation, and fully auditable. RPA cannot handle the unstructured variability of real-world invoice exceptions (vendor notes in free text, non-standard deduction descriptions, ambiguous PO references).
Why acceptable: Financial exception handling requires contextual reasoning: the ability to interpret a vendor's free-text comment on an invoice in the context of the associated PO, the vendor relationship history, and the company's exception handling SOP. LLMs handle this class of unstructured reasoning that deterministic rules cannot. Audit trail requirements are met by logging every agent decision and the evidence it considered.
Decision 3: Amazon Connect vs Existing On-Premises Contact Centre
Chosen: Amazon Connect as the contact centre platform for the SAP integration architecture.
Traded away: Organisations already running Genesys, Avaya, or Cisco UCCE have invested in those platforms and may not be able to migrate. The event-driven integration pattern (EventBridge + Lambda + API Gateway) can be adapted to other contact centre platforms that emit call events; Connect is not architecturally required for the SAP integration layer.
Why acceptable: For greenfield or migrating contact centres, Connect provides native AWS integration (EventBridge, Lambda, Transcribe, Bedrock) with no additional middleware. Organisations on other platforms can implement equivalent integration using CTI middleware and the same API Gateway / Lambda pattern.
Decision 4: Redshift as Operational Data Store vs Snowflake or Databricks
Chosen: Amazon Redshift as the SAP cloud data warehouse.
Traded away: Snowflake and Databricks offer multi-cloud portability and some customers have existing investments in those platforms. Redshift's AppFlow connector is the primary reason for this choice: AppFlow has a native SAP OData connector that lands data directly into Redshift without additional transformation infrastructure.
Why acceptable: The SAP OData → AppFlow → S3 → Redshift pipeline minimises the number of integration components. Adding Snowflake or Databricks would require an additional S3 → Snowflake/Databricks ingest layer. For organisations standardised on Databricks, the S3 raw layer produced by AppFlow is directly consumable by Delta Lake; the Redshift layer is optional if an alternative warehouse is preferred.
Phased Roadmap
The four pillars are independently deployable and do not require simultaneous rollout. A recommended sequencing:
- Phase 1 (Month 1–2): Pillar IV: Health Checks. No SAP system changes required; Systems Manager Run Command is read-only. Provides immediate visibility into the SAP landscape configuration baseline and identifies any critical gaps before other pillars are deployed.
- Phase 2 (Month 2–4): Pillar III: Data Warehouse. Deploy AppFlow + S3 + Redshift pipeline. Begin delivering O2C and P2P dashboards in QuickSight. Unlocks analytics capability independent of AI or contact centre changes.
- Phase 3 (Month 4–6): Pillar II: Connect Integration. Deploy the EventBridge + Lambda + API Gateway integration between Amazon Connect and SAP Sales/Service Cloud. Run in parallel with existing contact centre for validation before cutover.
- Phase 4 (Month 6–9): Pillar I: Agentic AP/AR. Build and test Bedrock agent exception handlers starting with a single exception type (e.g. price variances under 2% tolerance). Expand coverage iteratively as agent accuracy is validated against historical exception data.
RISE with SAP on AWS
RISE with SAP is SAP's bundled cloud transformation offering, combining SAP S/4HANA Cloud Private Edition, the Business Technology Platform (BTP), and managed services into a single subscription. When deployed on AWS, the SAP-managed infrastructure runs within AWS data centres, giving customers the benefits of AWS global infrastructure, Direct Connect private connectivity, and co-residency with their existing AWS workloads.
What RISE with SAP Includes on AWS
- SAP S/4HANA Cloud Private Edition: a dedicated, customer-specific S/4HANA instance managed by SAP; SAP handles basis administration, patching, HANA database management, and infrastructure operations
- SAP Business Technology Platform (BTP): integration, extension, and analytics capabilities, including SAP Integration Suite (formerly SAP Cloud Platform Integration) for connecting S/4HANA to third-party systems and BTP Extension Suite for custom application development
- SAP Business Network: access to the Ariba Network for procurement, Concur for travel and expense, and SuccessFactors for human capital management, all as part of the bundle
- SAP-managed infrastructure on AWS: SAP provisions and manages the underlying AWS resources (EC2 instances, EBS volumes, VPC networking) within a SAP-controlled AWS account adjacent to the customer's own AWS tenancy
Integration with Customer-Owned AWS Services
The four-pillar architecture in this case study applies equally to RISE with SAP deployments. The key difference is that the SAP EC2 instances are in a SAP-managed AWS account rather than a customer-managed account. Integration is established via:
- AWS PrivateLink: SAP exposes S/4HANA API Gateway endpoints via PrivateLink VPC endpoint services; customer Lambda functions, AppFlow connectors, and API Gateway integrations connect to SAP APIs privately without traversing SAP's public endpoints
- AWS Direct Connect: a dedicated RISE with SAP network connection from the SAP infrastructure account to the customer's AWS account, providing consistent low-latency connectivity for the high-throughput data extraction patterns used in Pillar III
- AWS Organisations trust: the SAP infrastructure account and customer AWS account can be placed under the same AWS Organisation, enabling AWS Config aggregation, Security Hub cross-account findings, and consolidated CloudTrail for a unified compliance view across the SAP boundary
- SAP BTP Integration Suite: for Pillar II (Connect + SAP CRM), SAP BTP Integration Suite acts as the middleware layer between Amazon Connect events and the SAP Sales/Service Cloud APIs, handling SAP-specific protocol transformations and mapping
Strategic Consideration
Disaster Recovery & Business Continuity
SAP systems are mission-critical: an unplanned outage affecting S/4HANA can halt order processing, financial close, and manufacturing operations within hours. AWS Elastic Disaster Recovery (AWS DRS) is the recommended disaster recovery service for SAP workloads on AWS, providing continuous block-level replication with recovery point objectives (RPO) measured in seconds and recovery time objectives (RTO) measured in minutes.
AWS Elastic DRS: Key Metrics
RPO: seconds. AWS DRS continuously replicates EC2 instance block storage to the recovery region; typical RPO is under 5 seconds for SAP HANA data and log volumes.
RTO: minutes. Recovery instances are pre-staged and can be launched in the recovery region within minutes; no manual infrastructure rebuild required during a failover event.
Cost Optimisation
AWS DRS eliminates the need for a fully provisioned stand-by DR environment. Recovery instances are only launched during a DR drill or actual failover; the continuous replication overhead is limited to the DRS replication server cost rather than running full SAP infrastructure in a second region.
Olli Salumeria reduced DR costs by 80% by moving from a fully provisioned stand-by environment to AWS DRS, eliminating idle stand-by compute that previously sat unused for 99.9% of its runtime.
DR Drill Automation
AWS DRS supports non-disruptive DR drills using point-in-time recovery snapshots, launching drill instances in an isolated network without disrupting the production replication chain. Drill results (RTO achieved, data integrity validation) are recorded for compliance reporting without impacting the production SAP systems.
Multi-Layer DR Architecture for SAP
- HANA System Replication (HSR): synchronous HSR provides zero-data-loss failover within the primary AWS region between the primary HANA node and a standby node in a different Availability Zone, with sub-second RPO for intra-region AZ failures
- AWS DRS cross-region: asynchronous replication to a secondary AWS region provides regional disaster recovery: RPO of seconds and RTO of minutes for full region failure scenarios
- SAP HANA Multi-Tier Replication: for organisations requiring a three-tier topology (primary AZ + secondary AZ + DR region), SAP HANA supports multi-tier replication: HSR from primary to secondary (synchronous) and secondary to tertiary DR region (asynchronous)
- AWS Backup: scheduled SAP HANA backups are taken via the AWS Backup service, stored in S3 with cross-region replication and immutable backup vaults, protecting against ransomware or accidental deletion with a Recovery Point Objective defined by backup frequency
- Immutable backup vaults: AWS Backup Vault Lock prevents deletion of backup recovery points for a defined retention period, even by privileged IAM identities, meeting regulatory requirements for backup immutability in financial services SAP environments
SAP Migration to AWS
AWS Application Migration Service (AWS MGN) is the primary migration service for lifting and shifting SAP application servers and HANA databases to AWS. MGN performs continuous block-level replication of source servers to AWS, enabling non-disruptive cutovers with minimal downtime, a critical requirement for SAP landscapes where maintenance windows are tightly constrained.
AWS MGN Migration Pattern for SAP
- Agent installation: the AWS MGN replication agent is installed on each SAP source server (application servers, HANA primary/secondary, SAP Web Dispatcher). The agent begins continuous block-level replication to the AWS replication servers in the target VPC
- Launch templates: for each source SAP server, a launch template defines the target EC2 instance type, VPC, subnet, security groups, and IAM role; these are validated against SAP's EC2 instance certification matrix before cutover
- Test launch: before production cutover, a test instance is launched in an isolated network partition; SAP Basis performs functional testing (HANA system check, application server startup, SAP logon) against the test instance without impacting the still-running source
- Cutover: during the maintenance window, a final sync is performed, the source servers are shut down, and the target EC2 instances are launched; SAP DNS entries are updated to point to the new AWS instances
- Post-migration optimisation: after cutover, HANA is migrated to AWS-native storage (EBS gp3 or io2 Block Express for HANA log volumes), EC2 instances are rightized using Systems Manager data, and Reserved Instances or Savings Plans are purchased for the validated instance types
Customer Migration Examples
Mercedes-Benz: 9 Months to AWS
Mercedes-Benz completed its SAP migration to AWS in 9 months, moving 40+ SAP systems including S/4HANA to AWS. The migration unlocked agility and scalability that the previous on-premises environment could not deliver, enabling rapid provisioning of development and test systems on demand rather than waiting weeks for hardware procurement.
3M: 11,000 Servers, 3 Months Early
3M migrated more than 11,000 servers (including its entire SAP landscape) to AWS, completing the migration 3 months ahead of schedule. The project used AWS MGN for lift-and-shift migration of the SAP infrastructure, combined with AWS professional services and partner support for HANA database migration and SAP Basis reconfiguration on AWS.
Toyota: High-Memory EC2 for HANA
Toyota runs SAP HANA on AWS using high-memory U7i instances, purpose-built for in-memory databases with up to 32 TB of DDR5 memory. The U7i instance family enables Toyota to run the largest HANA scale-up configurations on AWS without the constraints of physical hardware procurement cycles.
Deutsche Bahn: Seconds to Report
Deutsche Bahn reduced its SAP reporting from hours to seconds by migrating its SAP BW system to AWS and connecting it to a cloud-native analytics stack. The reduction in reporting latency transformed the organisation's ability to act on operational data: decisions previously made on yesterday's data are now made on data that is seconds old.
Enterprise Customer Stories
The following enterprise SAP deployments on AWS demonstrate the outcomes achievable with the architecture patterns described in this case study.
Adidas
Adidas runs its global SAP S/4HANA environment on AWS, supporting product lifecycle management, supply chain, and direct-to-consumer commerce. AWS elasticity allows Adidas to scale SAP capacity for product launch peaks without over-provisioning for normal operating periods.
Mondelez International
Mondelez (Cadbury, Oreo, Milka) migrated its SAP ERP to AWS to consolidate a fragmented global SAP landscape. The AWS cloud platform enabled Mondelez to standardise on a single S/4HANA instance, reducing SAP total cost of ownership while improving system performance for 90,000 employees globally.
Olli Salumeria
Italian food manufacturer Olli Salumeria achieved an 80% reduction in disaster recovery costs by replacing its fully provisioned stand-by SAP DR environment with AWS Elastic Disaster Recovery, maintaining the same RPO and RTO targets at a fraction of the previous infrastructure cost.
AWS SAP Competency
AWS maintains a dedicated SAP on AWS competency programme, a global network of SAP-certified APN partners, and the AWS SAP knowledge centre with architecture guidance, sizing tools (the SAP QuickSizer integration), and Well-Architected Framework SAP lens for formal workload reviews.