Configuring Amazon S3 Access Keys Securely for UpdraftPlus (WordPress)

medo
February 10, 2026
3 min read
37 Views
No Comments
Development

Using Amazon Web Services S3 as remote storage for UpdraftPlus is a common and reliable approach for backing up a WordPress site.
However, many users are confused when AWS warns against long-term access keys and suggests alternative authentication methods.

This article explains the correct and secure way to configure S3 access for UpdraftPlus, why AWS shows those warnings, and what best practices actually apply in a real WordPress environment.

Why AWS Warns About Long-Term Access Keys

AWS strongly encourages modern authentication mechanisms such as:

IAM Roles
Temporary credentials (STS)
Workload identity federation

These are excellent practices when your application runs inside AWS (EC2, ECS, Lambda).

However, classic WordPress hosting does not support IAM roles.

If your WordPress site runs on:

Shared hosting
A VPS (DigitalOcean, OVH, Hetzner, etc.)
On-premise infrastructure

then access keys are the only supported and correct solution.

AWS warnings are contextual, not prohibitions.

The Correct AWS Use Case for UpdraftPlus

When creating an access key in IAM, AWS asks you to select a use case.

✅ Correct choice:
Application running outside AWS

This matches the reality:

UpdraftPlus is a third-party PHP application
It runs outside AWS
It only needs programmatic access to S3

Selecting this option does not weaken security and does not change how credentials work.
It simply helps AWS categorize usage internally.

Secure Architecture Overview

WordPress
 └─ UpdraftPlus
      └─ IAM User (restricted)
           └─ S3 Bucket (private)

Key principle: least privilege.

Step 1 – Create a Dedicated S3 Bucket

Best practices:

Private bucket (Block all public access)
Dedicated to backups only
Optional versioning enabled
Optional lifecycle rules (auto-delete old backups)

Example bucket name:

my-wp-backups-prod

Step 2 – Create a Dedicated IAM User

Never use:

Root credentials
A shared IAM user
Broad policies like AmazonS3FullAccess

Create a single-purpose IAM user, for example:

updraftplus-wordpress

Programmatic access only.

Step 3 – Attach a Minimal IAM Policy

This policy allows only what UpdraftPlus needs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UpdraftPlusS3Access",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-wp-backups-prod",
        "arn:aws:s3:::my-wp-backups-prod/*"
      ]
    }
  ]
}

This prevents:

Access to other buckets
Account-wide damage if credentials leak

Step 4 – Generate Access Keys

Generate:

Access Key ID
Secret Access Key

Store them securely and never commit them to Git.

Add a description such as: UpdraftPlus – production backups

Step 5 – Configure UpdraftPlus

In WordPress:

Settings → UpdraftPlus → Settings
Select Amazon S3
Enter:
- Access Key ID
- Secret Access Key
- Bucket name
- Region
Set a bucket subpath (recommended):

wordpress/site-prod/

Save and test the connection

If it fails, the cause is almost always:

Wrong region
Incorrect IAM policy
Typo in bucket name

Optional Hardening (Recommended)

Lifecycle Rules

Automatically delete old backups:

Daily: keep 14 days
Monthly: keep 6 months

This avoids silent storage cost growth.

Server-Side Encryption

Enable default SSE-S3 (AES-256).
No code changes required.

IP Restriction (Advanced)

If your hosting provider has a static IP, you can restrict IAM access to that IP range.

Common Mistakes to Avoid

Using root access keys
Granting AmazonS3FullAccess
Making the bucket public
Skipping lifecycle rules
Reusing credentials across multiple sites

Final Verdict

For WordPress + UpdraftPlus:

Long-term access keys are normal
AWS warnings are generic
Least-privilege IAM policies are what actually matter

Used correctly, this setup is secure, stable, and industry-standard.