Wasabiとは｜料金・S3との違いと90日ルールを試算で判断

Wasabiは、Amazon S3 と同じ形の命令（S3 API）を受け付けます。そのため、S3 用に作ったツールやプログラムは、つなぎ先の URL（エンドポイント）を変えるだけで Wasabi に向けられます。

flowchart TD
    A[アプリ・バックアップ製品] --> B[S3 API で話す道具<br>aws cli・boto3・rclone]
    B --> S[S3<br>URL省略]
    B --> W[Wasabi<br>専用URL]
    B --> M[MinIO<br>127.0.0.1]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、MinIO RELEASE.2025-10-15T17-29-55Z を 127.0.0.1 の2つのポートに起動し、S3 互換の API がどう振る舞うかを再現しました。Wasabi と AWS には接続していません。クライアントは aws-cli 1.46.2（botocore 1.43.62・Python 3.13.18）、boto3 1.43.122、rclone v1.75.2 で、鍵はこの検証のためだけに作ったダミーの値です。Wasabi 固有の振る舞い（料金・最低保存期間・転送の決まり・リージョン・Object Lock・チェックサムの注意）は Wasabi の公式料金ページ・料金 FAQ・ナレッジベースで、比較先の料金は AWS・Cloudflare・Backblaze の公式ページで確かめました。S3 東京リージョンの保存単価は AWS の価格表を参照する料金計算サイトの値で、転送料は AWS 公式ブログの東京リージョンの単価です。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

Wasabiとは（S3互換のクラウドストレージ）

この節では、Wasabi がどんなサービスで、Amazon S3 とどういう関係なのかが分かります。

Wasabi（Wasabi Hot Cloud Storage）は、米国の Wasabi Technologies が提供するオブジェクトストレージ（ファイルを「バケット」という入れ物にキーと中身の組で置くストレージ）です。 公式の API ガイドは「Amazon S3 と 100% ビット互換になるよう作られている」と書いており、S3 の API（2006-03-01 版）と IAM の API（2010-05-08 版）を基準にしています。

S3 と大きく違うのは料金の組み立てです。S3 は「保存量」「リクエストの回数」「インターネットへの転送量」のそれぞれに料金がかかり、保存クラス（標準・低頻度・アーカイブ）も選びます。Wasabi は保存クラスが1つで、保存量にだけ課金し、転送料と API の料金を取りません。その代わりに、最低課金容量・最低保存期間・転送量の上限という決まりがあります。

耐久性は、公式ドキュメントで「1年あたり 99.999999999%（イレブンナイン）」を設計目標としています。用途は、バックアップの保管先、監視カメラや動画の保存、ログやアーカイブの置き場など、たくさん置いて、ときどき読むデータが中心です。

Wasabiの料金体系（2026年10月29日時点）

この節では、Wasabi の料金がどう決まるのかと、最低課金・最低保存期間などの決まりが分かります。

従量課金（Pay as You Go）は、保存量 1TB あたり月 7.99 ドルからです。 公式の料金 FAQ では 1GB あたり月 0.0078 ドル、1日あたり約 0.000260091 ドル（7.99 ÷ 1024 ÷ 30）と換算しています。北米・EMEA・APAC で同じ価格で、税と有料のオプション（プレミアムサポートなど）は含みません。

容量予約（RCS）

従量課金とは別に、容量と期間を先に買う RCS（Reserved Capacity Storage） があります。料金 FAQ によると、追加は25TB単位、最低保存期間は30日、プレミアムサポートの契約が必須で、返金と途中解約はできず、終了日の30日前までに解約しなければ同じ期間で自動更新されます。単価は公開されておらず、販売代理店や Wasabi の営業窓口から見積もりを取ります。国内では代理店経由で円建ての請求にできる場合もあるため、支払い方法は契約先に確かめるのが確実です。

請求書に出る2つの項目

• Timed Active Storage：その請求期間に置いていたデータの量。
• Timed Deleted Storage：90日たつ前に消したデータの、残りの日数分。

保存量が1TBに届かないときは、その差も「最低の保存料金」として請求されます。

Wasabiと S3・R2・B2 の料金を同じ条件で試算

この節では、Wasabi・Amazon S3（東京）・Cloudflare R2・Backblaze B2 を同じ使い方で比べたとき、どれがいくらになるかが分かります。

結果は使い方で大きく入れ替わります。 保存量が大きく、ダウンロードも多いほど Wasabi・B2・R2 が有利になり、100GB 程度の小さな保存では S3・R2・B2 のほうが安くなります。単価は次のとおりで、この単価を Python に入れて計算しました。

計算の前提：容量はすべて 1TB＝1,024GB、1か月＝30日、税・サポート費・リクエスト料金は含めません（R2 と S3 はリクエストの件数に応じて加わります）。S3 の転送料は最初の10TBの単価 0.114 ドルで計算しています。

単位はドルです（2026年10月29日時点の公式単価で計算）。計算に使ったコードの中心は次のとおりです。

GB_PER_TB = 1024
def wasabi(st_gb, eg_gb):
    billed = max(st_gb, 1024)                 # 最低1TB
    note = "" if eg_gb <= st_gb else "条件の外"  # 転送は保存量まで
    return billed / GB_PER_TB * 7.99, note
def s3(st_gb, eg_gb):
    return st_gb * 0.025 + max(eg_gb - 100, 0) * 0.114
def r2(st_gb, eg_gb):
    return max(st_gb - 10, 0) * 0.015
def b2(st_gb, eg_gb):
    return max(st_gb - 10, 0) / GB_PER_TB * 6.95 + max(eg_gb - 3 * st_gb, 0) * 0.01

B2 は保存単価だけ見ると Wasabi より安く、この5つの条件では B2 が最も安くなりました。それでも Wasabi が選ばれる理由は、日本（東京・大阪）にリージョンがあることと、API の回数で料金が増えないことです。Backblaze の公式ドキュメントが挙げるデータリージョンは米国東部・米国西部・EU 中央・カナダ東部で、日本はありません（2026年10月29日時点）。データを国内に置く決まりがある場合や、東京から近い場所に置きたい場合は、この差が料金より重くなります。

最低保存期間90日の計算（早く消すと課金される仕組み）

この節では、Wasabi の「90日ルール」で、早く消したデータや上書きしたデータがいくら課金されるのかが分かります。

90日より早く消したデータは、残りの日数分も保存していたものとして課金されます。 公式ドキュメントの例では、1日目に置いて16日目に消したオブジェクトは「15日分の Timed Active Storage」と「75日分の Timed Deleted Storage」になります。合わせて90日分です。

1TB のファイルで計算すると、次のようになります。

置いていた15日分 : 7.99ドル × 15/30 = 3.995ドル
消した後の75日分 : 7.99ドル × 75/30 = 19.975ドル
合計              : 23.97ドル（＝90日分。1日で消しても同じ）

上書きも「消した」扱いになる

公式ドキュメントは「上書きは、前のオブジェクトを暗黙に削除すること」と書いています。同じキーに毎日 1MB を上書きしても、課金が 1MB で済むわけではありません。前の 1MB は90日たつまで課金が続くため、毎日上書きを続けると、およそ90個分（90MB）が常に課金される計算になります。毎日 1GB のデータベースのダンプを同じ名前で上書きする運用なら、およそ 90GB 分です。

バックアップの保持日数で比べる

毎日 50GB のバックアップを置き、決めた日数がたったら消す運用を、365日分シミュレーションしました（最後の30日の平均）。

90日より短い保持日数では、何日にしても月額は変わりませんでした。 消しても課金は減らないので、Wasabi で保持日数を決めるときは「90日以上」にしても追加の費用はかかりません。逆に、30日で消す前提で見積もると、実際の請求は3倍になります（1,500GB 分の見積もりに対して 4,500GB 分の請求）。シミュレーションの中心は次のコードです。

def sim(daily_gb, keep_days, min_days=90, days=365):
    active = billed = 0
    for d in range(days - 30, days):              # 最後の30日を平均
        for up in range(d - max(keep_days, min_days) + 1, d + 1):
            age = d - up
            if age < keep_days:
                active += daily_gb                 # 実際に置いている
            billed += daily_gb                     # 90日までは課金が続く
    return active / 30, billed / 30

参考までに、ほかのサービスの最低保存期間は次のとおりです。S3 標準と R2 標準と B2 にはありません。S3 の標準 - 低頻度アクセス（Standard-IA）は30日、S3 Glacier Instant Retrieval と Flexible Retrieval は90日、Deep Archive は180日、R2 の低頻度アクセス（Infrequent Access）は30日です。

転送量無料の条件（Wasabiのエグレスの決まり）

この節では、Wasabi の「転送料無料」がどこまで無料なのかと、条件を超えたときに何が起きるのかが分かります。

毎月のダウンロード量（エグレス）が、保存しているデータ量以下であれば、転送料はかかりません。 料金 FAQ の例では、100TB を保存していれば毎月 100TB までダウンロードできます。

この量を超えた場合、追加の転送料の単価は示されていません。代わりに「その使い方は Wasabi に合わない」とされ、超える状態が続くと、Wasabi がサービスを制限したり止めたりすることがある、と書かれています。API の回数についても、Wasabi が確かめた市販のアプリはおおむね条件に合い、確かめていないアプリが不合理な負荷をかける場合は制限の対象になりうる、とされています。

• 向く：バックアップ（ふだんは置くだけで、戻すときに読む）、アーカイブ、監視カメラの録画。
• 向かない：動画や画像を多くの人へ直接配信し、毎月保存量の何倍も読まれる使い方。この場合は CDN を前に置くか、転送料が無料の R2 などと比べます。

なお、以前の料金プランのまま契約しているアカウントでは、ダウンロードに「Data Transfer (Out)」の料金が出ることがあると、公式のナレッジベースに書かれています。管理画面でファイルを開いたりダウンロードしたりした分も含まれます。

WasabiとS3の違い（できること・できないこと）

この節では、同じ S3 API でも Wasabi と Amazon S3 で何が違うのかを、MinIO で再現した結果と公式ドキュメントで確かめます。

基本の操作（バケットの作成・アップロード・ダウンロード・一覧・削除・署名付き URL・バージョニング・ライフサイクルでの削除）は同じ命令で通ります。 違いが出るのは、保存クラス、つなぎ先の指定、AWS の他サービスとの連携です。

保存クラスを指定するとエラーになる

保存クラスが1つのストレージで STANDARD_IA を指定すると、どうなるかを MinIO で確かめました。アップロードもライフサイクルの移行ルールも、同じエラーで断られます。

$ aws --endpoint-url $EP s3 cp hello.txt s3://t129-backup/ia.txt --storage-class STANDARD_IA --no-progress
upload failed: ./hello.txt to s3://t129-backup/ia.txt An error occurred (InvalidStorageClass) when calling the PutObject operation: Invalid storage class.

$ aws --endpoint-url $EP s3api put-bucket-lifecycle-configuration --bucket t129-backup --lifecycle-configuration file://lc2.json
An error occurred (InvalidStorageClass) when calling the PutBucketLifecycleConfiguration operation: Invalid storage class.

S3 で「30日たったら Standard-IA へ、90日たったら Glacier へ」と組んでいたルールは、Wasabi へ移すときに「何日たったら消す」だけのルールへ書き直します。削除のルールは、そのまま通りました。

$ aws --endpoint-url $EP s3api get-bucket-lifecycle-configuration --bucket t129-backup
{
    "Rules": [
        {
            "Expiration": {
                "Days": 120
            },
            "ID": "expire-backup-after-120d",
            "Filter": {
                "Prefix": "daily/"
            },
            "Status": "Enabled"
        }
    ]
}

削除までの日数は、前の節の理由から 90日以上 にしておくと、課金と実際の保存が一致します。MinIO での結果は S3 API の振る舞いの再現で、Wasabi の実際の応答文と同じとは限りません。

Wasabiのリージョンとエンドポイント（東京・大阪）

この節では、Wasabi のリージョンの一覧と、プログラムから指定するエンドポイントの URL が分かります。

日本には東京（ap-northeast-1）と大阪（ap-northeast-2）のリージョンがあります。 エンドポイントは s3.<リージョン>.wasabisys.com の形で、管理画面はどのリージョンでも console.wasabisys.com です。

公式の一覧では、ほかに米国（us-east-2・us-central-1・us-west-1・us-west-2）、カナダ（ca-central-1）、欧州（eu-central-2・eu-west-1〜3・eu-south-1）があり、合わせて16のリージョンです（2026年10月29日時点）。

公式の API ガイドには、バケットのあるリージョンと違う URL を使うと、GET はできても PUT や DELETE はできないと書かれています。読み出しだけ通って書き込みで失敗するときは、まずエンドポイントのリージョンを疑います。

aws cliでWasabiを使う（--endpoint-url）

この節では、AWS CLI に Wasabi 用のプロファイルを作り、--endpoint-url でつなぐ手順と、実際の出力が分かります。

AWS の鍵と混ざらないように、Wasabi 用のプロファイルを分けます。 公式の手順は aws configure --profile wasabi でアクセスキーとシークレットキーを入れ、各コマンドに --endpoint-url を付ける形です。設定ファイルは次のようになります（この記事ではダミーの鍵を使い、つなぎ先を手元の MinIO にしています）。

# ~/.aws/credentials
[wasabi]
aws_access_key_id = （Wasabi の管理画面で作ったアクセスキー）
aws_secret_access_key = （シークレットキー）

# ~/.aws/config
[profile wasabi]
region = ap-northeast-1

EP=https://s3.ap-northeast-1.wasabisys.com    # 東京。この記事の再現では http://127.0.0.1:19129
aws --profile wasabi --endpoint-url $EP s3 ls

MinIO に向けて実行した結果です（以降の出力では、プロファイルの指定を省いて --endpoint-url $EP と表記しています）。

$ aws --endpoint-url $EP s3 mb s3://t129-backup
make_bucket: t129-backup

$ aws --endpoint-url $EP s3 cp hello.txt s3://t129-backup/docs/hello.txt --no-progress
upload: ./hello.txt to s3://t129-backup/docs/hello.txt

$ aws --endpoint-url $EP s3 ls s3://t129-backup --recursive --human-readable --summarize
2026-10-30 12:16:07   20.0 MiB big.bin
2026-10-30 12:16:06   13 Bytes docs/hello.txt

Total Objects: 2
   Total Size: 20.0 MiB

$ aws --endpoint-url $EP s3api get-bucket-location --bucket t129-backup
{
    "LocationConstraint": "ap-northeast-1"
}

20MiB のファイルは、AWS CLI の既定（8MB を超えるとマルチパートアップロード）で3つに分けて送られました。ETag の末尾の -3 がその印です。マルチパートの ETag は中身の MD5 と一致しないため、後で整合性を確かめるときに意味が出てきます（rclone の節で触れます）。

$ aws --endpoint-url $EP s3api head-object --bucket t129-backup --key big.bin
{
    "AcceptRanges": "bytes",
    "LastModified": "Fri, 30 Oct 2026 12:16:07 GMT",
    "ContentLength": 20971520,
    "ETag": "\"e67077407b38acadd34e711163a7b724-3\"",
    "ContentType": "application/octet-stream",
    "Metadata": {}
}

コマンドそのものは、関連記事「aws s3コマンド一覧｜cp・sync・ls実行例とオプション早見表」で扱っています。Wasabi では、その各コマンドに --endpoint-url を付けるだけです。

チェックサムの既定が変わった点に注意

AWS CLI と SDK は、新しい版からアップロード時にチェックサム（中身が壊れていないかの確認値）を自動で付けるようになりました。Wasabi の公式ナレッジベースは、AWS CLI v2 の既定のアルゴリズムが CRC64NVME になったことへの対応として、--checksum-algorithm CRC32 を付ける回避策を案内しています。手元の aws-cli 1.46.2 で、送られたヘッダーを --debug で確かめました。

== 何も指定しない
'x-amz-sdk-checksum-algorithm': 'CRC32'
'x-amz-checksum-crc32': 'yPqGFg=='
'X-Amz-Checksum-Type': 'FULL_OBJECT'

== AWS_REQUEST_CHECKSUM_CALCULATION=when_required を付けた
（x-amz-checksum-* のヘッダーは付かない）

この版では既定で CRC32 が付き、when_required（API が必要とするときだけ付ける）にすると付かなくなりました。Wasabi 側でチェックサムのエラーが出たときは、公式の案内どおり --checksum-algorithm CRC32 を付けるか、設定ファイルに request_checksum_calculation = when_required を書いて切り分けます。

boto3でWasabiに接続する（エンドポイントと署名）

この節では、Python の boto3 から Wasabi につなぐ書き方と、手元で動かした結果が分かります。

endpoint_url と region_name を渡す以外は、S3 のときと同じコードです。 次のコードを MinIO に向けて実行しました。

import boto3
from botocore.config import Config
from botocore.exceptions import ClientError

ENDPOINT = "http://127.0.0.1:19129"   # Wasabi なら https://s3.ap-northeast-1.wasabisys.com
s3 = boto3.Session(profile_name="wasabi-demo").client(
    "s3", endpoint_url=ENDPOINT, region_name="ap-northeast-1",
    config=Config(request_checksum_calculation="when_required",
                  response_checksum_validation="when_required",
                  retries={"max_attempts": 5, "mode": "standard"}))

s3.put_object(Bucket="t129-backup", Key="daily/2026-10-29.json", Body=b'{"ok":true}')
for i in range(1, 1201):
    s3.put_object(Bucket="t129-backup", Key=f"logs/{i:05d}.txt", Body=b"x")

pages = s3.get_paginator("list_objects_v2").paginate(Bucket="t129-backup", Prefix="logs/")
counts = [len(p.get("Contents", [])) for p in pages]
print("pages:", counts, "total:", sum(counts))
print("get:", s3.get_object(Bucket="t129-backup", Key="daily/2026-10-29.json")["Body"].read())
try:
    s3.get_object(Bucket="t129-backup", Key="nothing.txt")
except ClientError as e:
    print("error:", e.response["Error"]["Code"], e.response["ResponseMetadata"]["HTTPStatusCode"])

pages: [1000, 200] total: 1200
get: b'{"ok":true}'
error: NoSuchKey 404

一覧は1回の呼び出しで最大1,000件までなので、paginator で続きを取ります。1,200件が1,000件と200件の2ページに分かれました。Wasabi は API の回数に料金がかからないため、S3 のように一覧の回数を減らす工夫は、料金の面では要りません（負荷の面では、むやみに増やさないほうが安全です）。boto3 の基本の操作は関連記事「boto3でS3を操作する方法｜アップロード・ダウンロード・一覧取得」で、鍵の読み込み順は関連記事「boto3 client・resource・sessionの違いと認証の優先順位」で扱っています。

署名付きURLは署名バージョンを決めて作る

手元の boto3 1.43.122 では、endpoint_url を指定したクライアントで署名付き URL を作ると、何も指定しない場合は AWSAccessKeyId=…&Signature=… の形（署名バージョン2）になりました。Config(signature_version="s3v4") を付けると、次のように署名バージョン4の形になります。

X-Amz-Algorithm=AWS4-HMAC-SHA256
X-Amz-Credential=(省略)
X-Amz-Date=20261030T121655Z
X-Amz-Expires=300
X-Amz-SignedHeaders=host
X-Amz-Signature=(省略)

どちらの URL も MinIO では curl で 200 が返りました。サービスや版によって扱いが変わる部分なので、コードの中で署名バージョンを明示しておくと、つなぎ先を変えたときに挙動が揃います。発行と PUT の使い方は関連記事「S3署名付きURLの発行方法 CLI・boto3とPUTアップロード例」で扱っています。

rcloneでS3からWasabiへ移行する手順

この節では、既存のバケットを Wasabi へ移す手順を、MinIO から MinIO へ実際にコピーした結果で確かめます。

rclone は Wasabi をプロバイダーとして持っていて、設定で provider = Wasabi を選べます。 移行元（src）と移行先（wasabi）の2つのリモートを作り、rclone sync でコピーします。この記事では、移行先のエンドポイントを2台目の MinIO にしました。

[src]
type = s3
provider = Minio          # S3 から移すなら provider = AWS
access_key_id = （移行元の鍵）
secret_access_key = （移行元のシークレット）
region = ap-northeast-1
endpoint = http://127.0.0.1:19129

[wasabi]
type = s3
provider = Wasabi
access_key_id = （Wasabi の鍵）
secret_access_key = （Wasabi のシークレット）
region = ap-northeast-1
endpoint = http://127.0.0.1:19229   # 本番は s3.ap-northeast-1.wasabisys.com

$ rclone sync src:t129-backup wasabi:t129-copy2 --transfers 8 -P
Transferred:   	   20.001 MiB / 20.001 MiB, 100%, 9.984 MiB/s, ETA 0s
Checks:                 0 / 0, -, Listed 1210
Transferred:         1207 / 1207, 100%
Elapsed time:         2.8s

$ rclone check src:t129-backup wasabi:t129-backup
NOTICE: S3 bucket t129-backup: 0 differences found
NOTICE: S3 bucket t129-backup: 1 hashes could not be checked
NOTICE: S3 bucket t129-backup: 1207 matching files

$ rclone check src:t129-backup wasabi:t129-copy2 --download
NOTICE: S3 bucket t129-copy2: 0 differences found
NOTICE: S3 bucket t129-copy2: 1207 matching files

「1 hashes could not be checked」は、マルチパートで送った big.bin の ETag が MD5 ではないために出た表示です。--download を付けると、両方を読み出して中身で比べるため、この表示は消えました。Wasabi は転送料がかからないものの、移行元が S3 なら --download の読み出しにも S3 の転送料がかかる点は見積もりに入れておきます。

移行で気をつけること

• 以前の版はコピーされない：移行元はバージョニングを有効にして ver.txt を3回上書きしていましたが、rclone sync がコピーしたのは最新の1つだけでした。以前の版まで移す必要があるかを先に決めます。バージョニングの扱いは関連記事「S3バージョニングの有効化と復元 削除マーカーの消し方CLI」で扱っています。
• 移行元の転送料：S3 から出すデータには S3 の転送料がかかります。10TB なら、最初の10TBの単価で約1,156ドル（10,240GB − 無料の100GB）× 0.114 ドルです。
• 移行直後の消去：移行してすぐに整理して消すと、90日ルールの対象になります。整理は移行元で済ませてから移します。

Wasabiのセキュリティ機能（暗号化・Object Lock・MFA）

この節では、Wasabi が持つ保護の仕組みと、ランサムウェア対策でよく使われる Object Lock の動きが分かります。

Object Lock の動きを再現する

公式ドキュメントでは、Object Lock はバケットを作るときにしか有効にできず、一度有効にすると外せません。有効にするとバージョニングも外せなくなります。MinIO で同じ流れを試しました。

$ aws --endpoint-url $EP s3api create-bucket --bucket t129-locked --object-lock-enabled-for-bucket
{
    "Location": "/t129-locked"
}
$ aws --endpoint-url $EP s3api put-object-lock-configuration --bucket t129-locked --object-lock-configuration {"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":1}}}
$ aws --endpoint-url $EP s3api get-object-retention --bucket t129-locked --key hello.txt
{
    "Retention": {
        "Mode": "GOVERNANCE",
        "RetainUntilDate": "2026-10-31T12:16:32.322Z"
    }
}
$ aws --endpoint-url $EP s3api delete-object --bucket t129-locked --key hello.txt --version-id 302cd787-e42a-4c17-9aaf-497805cf5b4f
An error occurred (InvalidRequest) when calling the DeleteObject operation: Object is WORM protected and cannot be overwritten

$ aws --endpoint-url $EP s3api put-object-lock-configuration --bucket t129-backup --object-lock-configuration {...}
An error occurred (InvalidBucketState) when calling the PutObjectLockConfiguration operation: Object Lock configuration cannot be enabled on existing buckets

保護期間中の版は消せず、既存のバケットには後から Object Lock を付けられませんでした。Object Lock で守ったデータは、保護期間が終わるまで課金も続きます。保護期間は90日以上にすることが多く、その場合は最低保存期間とも重なります。Wasabi の公式ドキュメントでは、Compliance のモードは保護期間の前に誰も解除できない、と説明されています。

• 1ルートの鍵をふだんの処理に使わないサブユーザーを作り、バケットごとに必要な操作だけを許すポリシーを付ける
• 2管理画面に MFA を設定する鍵を奪われても、バケットの設定を変えにくくする
• 3バックアップ用のバケットは Object Lock 付きで作る作成時にしか選べない。保護期間は課金と合わせて決める
• 4公開の設定を確かめるオブジェクトは既定で非公開。公開すると URL を知る人がダウンロードでき、転送量の条件にも響く

よくあるエラーとつまずき

この節では、Wasabi や S3 互換のストレージにつなぐときによく出るエラーの原文と、原因・直し方が分かります。

次の表のエラー文は、MinIO に向けて実際に起こしたときの原文です（最後の2行は Wasabi の公式ドキュメントの記述）。

もう1つ、エンドポイントの指定を忘れるつまずきがあります。--endpoint-url を付け忘れると、AWS CLI は Amazon S3 へつなぎに行きます。Wasabi の鍵は AWS では通らないため InvalidAccessKeyId になりますが、AWS の鍵も同じ端末に入っていると、意図せず S3 に書き込むことがあります。プロファイル名を分け、スクリプトの中ではエンドポイントを変数で必ず渡す形にしておきます。

Wasabiが向く・向かない判断表

この節では、Wasabi を選ぶかどうかを、使い方ごとに判断できます。

迷ったときは、次の順に問いを当てると決めやすくなります。

1. 1保存量は1TB以上か → いいえなら S3・R2・B21TB未満では最低課金が効く
2. 2ほとんどのデータを90日以上残すか → いいえなら最低保存期間の無いサービス短期のデータだけ別に置く手もある
3. 3毎月のダウンロードは保存量以下か → いいえなら R2 や CDN配信が主なら転送の条件が合わない
4. 4AWS の他サービスと直接つなぐか → はいなら S3S3 イベントや Athena を使う設計
5. 5ここまで全部合えば Wasabi を候補にする国内リージョンが要るなら B2 より優先

よくある質問

この節では、Wasabi について検索でよく聞かれる疑問の答えが分かります。

Q. Wasabiは無料で使えますか？ A. 無料のプランはありません。試用として、料金ページには会社のドメインのメールで30日・100GB、フリーメールで14日・10GBと表示されています（2026年10月29日時点）。試用の上限は変わることがあるため、申し込みの画面で確かめます。

Q. 料金は円で払えますか？ A. 公式の料金はドル建てです。国内の販売代理店を通すと、円建ての請求にできる場合があります。契約の形（従量課金か RCS か）と合わせて代理店に確かめます。

Q. 100GBしか使わなくても月7.99ドルですか？ A. はい。最低課金容量が1TBのため、100GB でも1TB分の 7.99 ドルです。この規模なら S3（約2.50ドル）、R2（約1.35ドル）、B2（約0.61ドル）のほうが安くなります（転送の条件はこの記事の C の条件）。

Q. 90日より前に消したデータは、すぐ見えなくなりますか？ A. バケットからは消えて見えなくなり、課金だけが残りの日数分続きます。消したデータを戻せるかどうかは別の話で、戻したいデータはバージョニングや Object Lock で守っておきます。

Q. S3 のコードはそのまま動きますか？ A. 基本の操作は、エンドポイントとリージョンを渡せばそのまま動きます。保存クラスの指定、Glacier からの取り出し、S3 イベントで Lambda を動かす部分などは書き換えが要ります。

Q. Wasabiと Amazon S3 の Glacier はどちらが安いですか？ A. 保存単価だけならアーカイブ向けの Glacier の各クラスが安くなる場合があります。ただし Glacier は取り出しに時間や料金がかかり、最低保存期間も90日〜180日です。すぐ読める状態で置いておきたいなら Wasabi、ほとんど読まないなら Glacier、と取り出し方で比べます。

Q. Wasabiと Cloudflare R2 の違いは何ですか？ A. どちらも転送料が無料です。R2 は 1GB 月0.015ドルで最低課金容量がなく、リクエストの件数に料金がかかります。Wasabi は 1TB 月7.99ドルで最低1TB・90日の決まりがあり、リクエストは無料です。小さく始めるなら R2、数TB以上を長く置くなら Wasabi が合いやすくなります。

Q. 個人のバックアップに使えますか？ A. 使えますが、1TB分の最低料金がかかります。スマホの写真を自動で預けるような個人向けのアプリは Wasabi 自体には無く、S3 互換に対応したバックアップソフトや rclone から使う形です。

Q. MinIO と Wasabi はどう違いますか？ A. MinIO は自分のサーバーに入れて動かす S3 互換のソフトウェアで、Wasabi は事業者が運用するクラウドのサービスです。この記事では、Wasabi の API の振る舞いを手元で再現するために MinIO を使いました。

Q. 転送量の条件を超えたらすぐに止められますか？ A. 料金 FAQ では、超える状態が「たびたび」続く場合に、制限や停止がありうると書かれています。1回の大きな復元ですぐに止まるとは書かれていませんが、配信のように毎月超える使い方は避けます。

まとめ

• Wasabi は S3 互換 API のクラウドストレージ。1TB 月7.99ドルで、転送料と API の料金がかからない（2026年10月29日時点）。
• 決まりは3つ。最低1TB分の課金、90日より早く消しても90日分の課金（上書きも同じ）、毎月のダウンロードは保存量まで。
• 同じ条件の試算では、10TB 保存・毎月5TB 取得で Wasabi 月79.90ドル、S3 東京 828.28ドル。100GB なら S3・R2・B2 が安い。保存単価は B2 が安いが、日本のリージョンは Wasabi にある。
• MinIO での再現では、aws cli・boto3・rclone が --endpoint-url だけの違いで動いた。保存クラスの指定は InvalidStorageClass、既存バケットへの Object Lock は InvalidBucketState で断られた。
• 移行は rclone sync → check（マルチパートは --download）→ 差分の sync の順。以前の版はコピーされず、移行直後の整理は90日ルールの対象になる。

参考・出典

確認日はいずれも 2026年10月29日です。

• Wasabi「Pricing」：https://wasabi.com/pricing
• Wasabi「Pricing FAQs」：https://wasabi.com/pricing/faq
• Wasabi Docs「Minimum Storage Duration Policy」：https://docs.wasabi.com/docs/how-does-wasabis-minimum-storage-duration-policy-work
• Wasabi Docs「Billing for Overwrites and Deleted Storage」：https://docs.wasabi.com/docs/billing-for-overwrites-and-deleted-storage
• Wasabi Docs「Data Transfer (Out) Charges」：https://docs.wasabi.com/docs/im-seeing-data-transfer-out-charges-on-my-bill-what-do-they-mean
• Wasabi Docs「Service URLs for Wasabi's Storage Regions」：https://docs.wasabi.com/docs/what-are-the-service-urls-for-wasabi-s-different-storage-regions
• Wasabi Docs「Wasabi API」：https://docs.wasabi.com/docs/wasabi-api
• Wasabi Docs「How do I use AWS CLI with Wasabi?」：https://docs.wasabi.com/docs/how-do-i-use-aws-cli-with-wasabi
• Wasabi Docs「Setting Lifecycle Policies Using the AWS CLI」：https://docs.wasabi.com/docs/how-to-set-lifecycle-policies-using-the-aws-cli
• Wasabi Docs「Object Lock: Enabling」：https://docs.wasabi.com/docs/object-locking
• Wasabi Docs「Durability, Security, Reliability」：https://docs.wasabi.com/docs/durability-security-reliability
• AWS「Amazon S3 の料金」：https://aws.amazon.com/jp/s3/pricing/
• AWS ブログ「AWS のデータ転送料金の値下げ（日本・オーストラリア）」：https://aws.amazon.com/jp/blogs/news/aws-data-transfer-price-reductions-up-to-34-japan-and-28-australia
• CostGoat「Amazon S3 Pricing Calculator」（S3 東京の保存単価の参照）：https://costgoat.com/pricing/amazon-s3
• Cloudflare「R2 pricing」：https://developers.cloudflare.com/r2/pricing/
• Backblaze「Cloud Storage Pricing」：https://www.backblaze.com/cloud-storage/pricing
• Backblaze「Cloud Storage Data Regions」：https://www.backblaze.com/docs/cloud-storage-data-regions
• rclone「Amazon S3 Storage Providers」：https://rclone.org/s3/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。