SAP ASE Backup Alert: AWS Backint Downloads Restricted Today and the Restore Risk for 2027

29 October 2026 | SAP on AWS infrastructure and disaster-recovery advisory. A backup is useful only if it can be restored. That is the uncomfortable question behind an AWS lifecycle milestone taking effect today for teams running SAP Adaptive Server Enterprise (SAP ASE) on AWS. From 29 October 2026, AWS Backint Agent for SAP ASE is no longer offered to new customers, and existing customers must use authenticated, allowlisted downloads. Existing installations can continue operating during the transition. The larger deadline is 29 September 2027, when AWS ends support for the agent. This is a scheduled change documented by AWS, not a claim that we have independently tested a blocked download in every account.

For a SAP Basis or infrastructure team, the immediate issue is not just the download. AWS warns that backup files created through this agent use a format incompatible with the recommended replacement backup methods. A replacement tool cannot simply pick up yesterday's backup file and restore it. The migration therefore needs new full backups and proven restore tests, not only a revised architecture diagram. See the AWS product-specific end-of-support and migration guide.

What changed on 29 October 2026?

AWS announced the lifecycle change on 29 September 2026 in its service availability notice. The download restriction starts on 29 October 2026. New customers can no longer download the AWS Backint Agent for SAP ASE. Existing customers are automatically allowlisted at the AWS-account level, but the IAM identity used to download still needs the relevant S3 read permission. A public URL, anonymous curl command or unauthenticated wget step in an installation script will no longer be sufficient. AWS says to use the AWS CLI or SDK with an authenticated account and the documented bucket path.

Existing installations are not switched off today. AWS says critical security updates, critical reliability fixes, support and documentation remain available until the end-of-support date. No new features are planned during that period. If an existing customer's authenticated download returns AccessDenied, AWS directs the customer to open a support case and supply the AWS account ID used for the download. Review the allowlisting, IAM and authenticated-download instructions before changing any scripts.

The real business risk: backups that a replacement cannot restore

Here is the scenario worth putting in front of a CIO. A team changes its nightly backup job from AWS Backint Agent for SAP ASE to another method. The new job reports success, and the project is marked complete. Months later, a database recovery is needed from an older backup generated by the retired agent. AWS states that this agent-specific backup format is not compatible with the recommended alternatives, including native SAP ASE S3 commands or third-party backup products. The old files may still be in Amazon S3, but retaining the files does not establish a viable recovery path after the agent's support ends.

That is why the AWS migration guidance calls for fresh full backups using the chosen replacement and restore testing during the migration period. Identify historical backups needed for audit or legal retention, and test restoration while the old agent is still supported. Re-create critical recoverable data with the new method. Do not delete legacy backup objects before retention requirements, restore validation and sign-off are complete.

Three migration choices, with important caveats

1. SAP ASE 16.1 native backup to Amazon S3

AWS recommends native SAP ASE 16.1 S3 backup where its prerequisites are met. This uses the syb_aws endpoint with SAP ASE dump and load operations rather than a separate Backint agent. Check the database version, IAM access, restore permissions, operational ownership and S3 bucket location. AWS documents a known limitation for S3 buckets in the us-east-1 Region with the native SAP ASE backup feature. Do not assume the existing bucket can be reused unchanged. Read the native ASE migration prerequisites and limitations and test in a non-production landscape before switching production backups.

2. AWS Storage Gateway with an NFS file share

AWS documents an Amazon S3 File Gateway approach that presents an NFS backup target to SAP ASE. It may fit teams that want to retain file-oriented backup processes, but it introduces gateway costs, cache-sizing decisions and asynchronous transfer considerations. A successful local write is not the same as proving the backup is safely present and restorable from the target storage. AWS provides a separate SAP ASE and S3 File Gateway walkthrough and migration steps in the end-of-support guide.

3. SAP-certified enterprise backup software

Organizations with centralized backup governance may assess a supported third-party product. Validate the product's SAP ASE integration, supported versions, S3 target, licensing, recovery-point objective and recovery-time objective. Do not infer that a third-party tool can read historical AWS Backint Agent backup files. AWS explicitly cautions that the existing agent-specific format is incompatible with the recommended alternatives.

A practical five-day assessment for SAP operations teams

1. Identify exposure: inventory SAP ASE instances, AWS accounts, installed Backint versions, S3 backup destinations and every script that downloads or calls the agent. Do not confuse this with AWS Backint Agent for SAP HANA, which AWS says is not affected.
2. Secure today's downloads: verify allowlisting, IAM permissions and authenticated AWS CLI/SDK access. Replace unauthenticated installation steps and record the owner of each automation.
3. Classify recoverability: distinguish legacy agent-format backups from new-format backups; map retention obligations, critical databases and recovery objectives.
4. Choose and test the target: compare native SAP ASE S3, File Gateway and certified third-party tools against version, region, cost, encryption, operations and disaster-recovery needs. Execute a full backup and restore test, not just a backup-success check.
5. Approve a transition date: schedule production cutover with a rollback plan, restore evidence, monitoring updates and formal sign-off well ahead of 29 September 2027.

Which deadline should teams use?

The detailed AWS technical guide and its September announcement specify 29 September 2027 as the end-of-support date. A separate AWS product landing page currently displays 30 September 2027. Because the official pages differ by one day, use the earlier 29 September date for planning and confirm the contractual support deadline with AWS if the distinction matters. The AWS Backint product page also distinguishes the affected SAP ASE agent from the continuing SAP HANA product.

Bottom line

The 29 October change is a download-access milestone, not an immediate shutdown of existing SAP ASE backups. But it starts a finite transition period for a critical recovery dependency. The safest response is straightforward: find every affected landscape, fix unauthenticated download automation, select a supported backup route, create fresh backups and demonstrate restoration before the agent reaches end of support. Backup success without recovery evidence is not a completed migration.

Primary sources: AWS SAP ASE end-of-support technical guidance; AWS September 29 availability announcement; AWS Backint product notice; AWS sunset-services register.