Welcome back to the architecture blog! Anyone running SAP HANA databases on AWS in 2020 often faces a massive cost and architectural problem: Backup design. Historically, HANA backups were written locally to the file system. In the AWS world, this means allocating expensive EBS volumes (Elastic Block Store, often io1 or gp2) just to store static backup files, which then have to be painstakingly moved to cheaper object storage via scripts.
This is architectural nonsense. With the introduction of the AWS Backint Agent for SAP HANA, Amazon has finally broken this paradigm. Today we dissect the architecture of this agent, which pumps backups directly into Amazon S3 – without detours, without intermediate storage, and with maximum enterprise security.
The Architecture Paradigm: Direct-to-S3 Streaming
The AWS Backint Agent is an SAP-certified backup solution (based on the official SAP HANA Backint API) that is installed directly at the operating system level (SUSE or RHEL) of the EC2 instance.
The fundamental difference to classic file backup: There is no more staging. When SAP HANA triggers a backup savepoint, the agent opens a high-performance C++ pipe. The data stream of the in-memory database is chunked "on the fly" and streamed directly into the S3 bucket in parallel via Amazon S3 Multipart Upload.
The result: The RPO (Recovery Point Objective) drops because log backups land directly in the cloud every minute, and storage costs are reduced by up to 80% because EBS volumes for backups are completely eliminated.
Zero Trust: IAM Instance Profiles Instead of Static Keys
Another massive architectural advantage is security. Previously, Basis admins often had to write static AWS Access Keys (Access Key ID and Secret Access Key) in plain text in configuration files on the Linux host to grant S3 write permissions. An absolute nightmare for any CISO.
The Backint Agent uses AWS IAM Instance Profiles.
The EC2 instance running HANA is assigned a dynamic IAM role. The agent retrieves temporary, rotating security tokens via the local Instance Metadata Service (IMDS). The configuration in the aws-backint-agent-config.yaml therefore requires no more passwords. The system is cryptographically locked down.
Configuration at the Database Level
To arm the agent, we must operate in the deepest layers of HANA. Native file backup is disabled and the Backint interface is forced in the global.ini of the SYSTEMDB (and the Tenant DBs):
[backup]
log_backup_using_backint = true
catalog_backup_using_backint = true
data_backup_parameter_file = /hana/shared/aws-backint-agent/aws-backint-agent-config.yaml
log_backup_parameter_file = /hana/shared/aws-backint-agent/aws-backint-agent-config.yaml
Once these parameters are active, the HANA Studio (or Cockpit) controls the agent completely transparently. A DBA doesn't even need to know that the data physically lands on an S3 bucket in the Frankfurt data center (eu-central-1).
📢 SAP & AWS ARCHITECTURE NEWS TICKER (As of: June 2020) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 New Instance Family: AWS announces the new r5b instances (Memory Optimized). Compared to the regular R5 family, they deliver three times the EBS bandwidth (up to 7,500 MB/s and 260,000 IOPS). For medium S/4HANA workloads, this is an absolute gamechanger for data-intensive batch jobs! 🔹 AWS Launch Wizard: First preview versions indicate that AWS will soon fully automate manual SAP installations (Infrastructure as Code). Stay tuned!
Conclusion
The AWS Backint Agent is not an optional gimmick, but an architectural must-have for any professional SAP cloud landscape in 2020. Anyone who still writes terabytes of HANA backups to provisioned SSD hard drives (EBS) today is not only burning through the IT budget but is also failing to scale according to public cloud best practices. Stream your data directly into S3, encrypt it via AWS KMS, and use IAM roles – that is senior-level cloud architecture.