Amazon S3入門 バケット作成からアクセス制御まで現場で使える基礎知識

「AWSでファイルを保存したいけれど、S3の設定項目が多すぎてどこから手をつければいいかわからない」——クラウド移行の初期段階で、こう感じるインフラ担当者は多いのではないでしょうか。

オンプレ環境であれば、NFSやSambaでファイルサーバーを立て、ディレクトリのパーミッションを設定すれば済みました。しかしS3はオブジェクトストレージという、ファイルサーバーとはまったく異なるアーキテクチャを採用しています。

この記事では、Amazon S3の基本概念からバケットの作成手順、アクセス制御の設計、料金体系まで、オンプレ経験者が押さえるべきポイントを体系的に解説します。

なぜS3なのか？オンプレのファイルサーバーとの違い

オンプレのファイルサーバーは、RAIDを組んだディスクにNFSやCIFSでアクセスする構成が一般的です。容量が足りなくなればディスクを追加し、バックアップはテープやリモートサイトにコピーする。こうした運用を経験してきた方も多いでしょう。

Amazon S3は、この発想を根本から変えるサービスです。主な違いを整理します。

・容量の上限がない: オンプレではディスク容量を事前に見積もる必要があったが、S3は容量無制限。必要な分だけ保存し、使った分だけ課金される
・耐久性99.999999999%: いわゆる「イレブンナイン」。データは自動的に3つ以上のアベイラビリティゾーンに分散保存される。RAID構成やバックアップの設計が不要
・オブジェクトストレージ: ファイルシステムのようなディレクトリ階層は存在しない。「キー」と呼ばれるパスでオブジェクト（ファイル）を管理する
・HTTPベースのアクセス: NFS/CIFSではなく、HTTPSのAPIでアップロード・ダウンロードを行う

オンプレのファイルサーバーが「自分で管理する倉庫」だとすれば、S3は「必要なときに必要なスペースを借りられるトランクルーム」です。管理の手間が大幅に減る一方、使い方の作法が異なるため、基本をしっかり押さえておく必要があります。

バケットの作成と基本操作

1. バケットとは何か

S3の最上位のコンテナが「バケット」です。オンプレでいえば、ファイルサーバーのボリュームやパーティションに相当します。

バケット名はAWS全体でグローバルに一意である必要があります。たとえば「my-app-logs」というバケット名は、世界中の誰かが先に取得していれば使えません。社名やプロジェクト名をプレフィックスに付けるのが実務上の定石です。

2. マネジメントコンソールからバケットを作成する

1. AWSマネジメントコンソールにログインし、サービス一覧から「S3」を選択
2. 「バケットを作成」ボタンをクリック
3. バケット名を入力（例: mycompany-app-assets-prod）
4. リージョンを選択。日本国内のサービスであれば東京リージョン（ap-northeast-1）を選ぶのが基本
5. 「パブリックアクセスをすべてブロック」がデフォルトでONになっていることを確認。特別な理由がない限りONのまま
6. バージョニングは、本番環境では「有効」を推奨。誤って上書き・削除した場合に復元できる
7. 暗号化はデフォルトの「SSE-S3」で十分。コンプライアンス要件がある場合はSSE-KMSを選択
8. 「バケットを作成」をクリックして完了

3. AWS CLIでバケットを操作する

日常的な操作はCLIのほうが効率的です。よく使うコマンドを紹介します。

# バケットの作成（東京リージョン）（AWS CLI）
aws s3 mb s3://mycompany-app-assets-prod \
  --region ap-northeast-1

# ファイルのアップロード
aws s3 cp ./backup.tar.gz s3://mycompany-app-assets-prod/backups/

# ディレクトリごと再帰的にアップロード
aws s3 sync ./local-dir/ s3://mycompany-app-assets-prod/data/

# バケット内のオブジェクト一覧
aws s3 ls s3://mycompany-app-assets-prod/ --recursive

# ファイルのダウンロード
aws s3 cp s3://mycompany-app-assets-prod/backups/backup.tar.gz ./

`aws s3 sync`はrsyncに近い感覚で使えます。差分だけを転送するため、大量ファイルの同期にも適しています。オンプレでrsyncを使い慣れている方なら、すぐに馴染めるはずです。

アクセス制御の設計

S3のアクセス制御は複数のレイヤーが絡み合うため、最初は混乱しがちです。ここでは実務で押さえるべき3つの仕組みを整理します。

1. バケットポリシー

バケット単位でアクセス許可を定義するJSON形式のポリシーです。「このバケットに誰がアクセスできるか」をバケット側から制御します。

たとえば、特定のIAMロールからのみ読み取りを許可するバケットポリシーは以下のようになります。

# 特定IAMロールへの読み取り許可（バケットポリシーJSON）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AppReadRole"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mycompany-app-assets-prod",
        "arn:aws:s3:::mycompany-app-assets-prod/*"
      ]
    }
  ]
}

オンプレでいえば、NFSの/etc/exportsでアクセス元を制限するのと同じ発想です。

2. IAMポリシー

IAMユーザーやロールに対して「どのバケットのどの操作を許可するか」を定義します。バケットポリシーが「バケット側の門番」だとすれば、IAMポリシーは「ユーザー側の身分証」です。

実務では、バケットポリシーとIAMポリシーの両方でAllowになっていないとアクセスできません。どちらかでDenyがあれば拒否されます。IAMの詳しい設計については「AWS IAM入門 最小権限の設計と運用」で解説しています。

3. パブリックアクセスブロック

2023年以降に作成されたバケットは、デフォルトでパブリックアクセスが完全にブロックされています。これはAWSが過去に多発したS3の公開事故を受けて導入した安全装置です。

静的Webサイトのホスティングなどでパブリック公開が必要な場合を除き、この設定は絶対に無効化しないでください。公開が必要な場合でも、Amazon CloudFrontを前段に置いてOAC（Origin Access Control）経由でアクセスさせるのが現在の推奨構成です。

料金の仕組み

S3の料金は主に3つの要素で構成されます（2026年3月時点、東京リージョン）。

オンプレのファイルサーバーでは、ディスクの購入費用とサーバーの電気代が固定費としてかかりました。S3は従量課金なので、使わなければ費用はほぼゼロです。

コストを抑える最大のポイントは「ストレージクラスの使い分け」です。アクセス頻度に応じて以下のクラスを選択できます。

・S3 Standard: 頻繁にアクセスするデータ向け。デフォルトのクラス
・S3 Standard-IA（低頻度アクセス）: 月1回程度のアクセス。ストレージ料金はStandardの約半額だが、取り出し料金がかかる
・S3 Glacier Instant Retrieval: 四半期に1回程度のアクセス。ストレージ料金はStandardの約5分の1
・S3 Glacier Deep Archive: 年1〜2回のアクセス。最も安価で$0.002/GB/月。テープバックアップの代替に最適

S3 Intelligent-Tieringを有効にすれば、アクセスパターンに応じて自動的に最適なクラスへ移動してくれます。「どのクラスを選べばいいかわからない」という段階では、まずIntelligent-Tieringを選んでおくのが安全です。

応用・実務Tips

ライフサイクルルールで自動整理する

オンプレ環境では、古いログファイルの削除をcronとfindコマンドで自動化していた方も多いでしょう。S3ではライフサイクルルールがその役割を果たします。

たとえば「90日経過したらGlacierに移動」「365日経過したら削除」というルールを設定できます。

# ライフサイクルルールの設定例（AWS CLI）
aws s3api put-bucket-lifecycle-configuration \
  --bucket mycompany-app-assets-prod \
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "MoveToGlacierAndExpire",
        "Status": "Enabled",
        "Filter": {"Prefix": "logs/"},
        "Transitions": [
          {
            "Days": 90,
            "StorageClass": "GLACIER"
          }
        ],
        "Expiration": {
          "Days": 365
        }
      }
    ]
  }'

バージョニングで誤操作から守る

バージョニングを有効にすると、オブジェクトの上書きや削除を行っても以前のバージョンが保持されます。オンプレのスナップショットやシャドウコピーに相当する機能です。

本番環境のバケットでは、バージョニングを有効にしたうえで「MFA Delete」を設定しておくと、MFA認証なしではオブジェクトの完全削除ができなくなります。ランサムウェア対策としても有効です。

S3イベント通知でワークフローを自動化する

ファイルがアップロードされたタイミングでAWS LambdaやAmazon SQSに通知を飛ばせます。たとえば「画像がアップロードされたらサムネイルを自動生成」「CSVがアップロードされたらDBにインポート」といった処理を、S3をトリガーにして実現できます。

オンプレではinotifywaitでファイル変更を検知してスクリプトを起動していた方もいるかもしれません。S3イベント通知はそのマネージド版です。

よくあるトラブルと対処法

403 Forbiddenでアクセスできない

S3で最も多いトラブルです。原因を切り分けるチェックポイントは以下の通りです。

1. パブリックアクセスブロックが有効になっていないか
2. バケットポリシーでアクセス元が正しく許可されているか
3. IAMポリシーでs3:GetObjectやs3:ListBucketが許可されているか
4. VPCエンドポイントポリシーで制限がかかっていないか

バケットポリシーとIAMポリシーの両方を確認しても解決しない場合は、AWS CloudTrailのログで実際にどのポリシーでDenyされているかを確認してください。

意図しないパブリック公開

S3の設定ミスによる情報漏洩は、過去に大きなニュースになった事例が複数あります。防止策として以下を徹底してください。

・アカウントレベルで「S3パブリックアクセスブロック」を有効化
・AWS Configルール「s3-bucket-public-read-prohibited」を有効化して監視
・バケットポリシーに「Principal: *」を絶対に書かない（CloudFront OAC経由で公開する場合を除く）

料金が予想以上に高い

S3の料金で見落としがちなのがデータ転送料金です。S3からインターネットへのデータ送信は$0.114/GB（東京リージョン、2026年3月時点）かかります。

対策としては、CloudFrontをキャッシュとして前段に置く、同一リージョン内のEC2からアクセスする（リージョン内転送は無料）、不要なバージョンや不完全なマルチパートアップロードを定期的にクリーンアップする、といった方法が有効です。

本記事のまとめ

Amazon S3はAWSの中でも最も基本的で、かつ最も奥が深いサービスです。まずはバケットを1つ作成して、CLIでファイルをアップロードしてみてください。オンプレのファイルサーバーとの違いを体感できるはずです。

アクセス制御は「パブリックアクセスブロックをONのまま触らない」を鉄則にしておけば、大きな事故は防げます。その上でバケットポリシーとIAMポリシーを組み合わせて、必要な範囲だけアクセスを許可する設計を心がけてください。Linuxのパーミッション管理と同様に、「まず全部拒否、必要な分だけ許可」の原則がクラウドでも最も安全です。Linuxの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。