AWS S3可用性を活かすバケット配置設計｜VPC構成と組み合わせた冗長化パターン

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWS S3可用性を活かすバケット配置設計｜VPC構成と組み合わせた冗長化パターン
「S3はAWSが可用性を担保してくれるから、設計側で気にすることは何もない」と思っていませんか。
確かにS3の耐久性は11 ninesと非常に高いですが、ストレージクラスの選び方やVPC経路の設計次第で、アプリケーションからS3へのアクセスが遮断されるシナリオは実際に存在します。

この記事では、AWS S3の可用性SLAの実態から、VPC構成と組み合わせた冗長化設計の判断基準までを整理します。Amazon Linux上のAWS CLI環境を想定環境として説明します。

この記事のポイント

・S3 StandardはAZ間分散で99.99%可用性を提供する
・One Zone-IAは単一AZ障害でデータが失われるリスクがある
・Gateway型VPCエンドポイントは全AZのルートテーブルに追加が必要
・CRRで別リージョンへレプリケーションしRPOを担保できる


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AWS S3の可用性SLAを正しく読む

S3の可用性SLAは、ストレージクラスによって異なります。よく引用される「99.999999999%（11 nines）」は「耐久性」（データが消えない確率）であり、「可用性」（サービスにアクセスできる確率）とは別の概念です。

可用性SLAは以下のとおりです。

・S3 Standard：99.99%（年換算で約52分のダウンタイムが許容される水準）
・S3 Standard-IA（低頻度アクセス）：99.9%（年換算で約8.7時間）
・S3 One Zone-IA：99.5%（年換算で約43.8時間）
・S3 Glacier Instant Retrieval：99.9%

注目すべきはOne Zone-IAです。他のストレージクラスが複数のAZにデータを分散格納するのに対し、One Zone-IAは文字どおり単一AZにしかデータを持ちません。その結果、可用性SLAが99.5%に下がり、対象AZで障害が発生した場合にデータそのものへのアクセスが失われる可能性があります。

S3 Standardの場合、AWSはリージョン内の複数のAZ間にデータを自動で分散します。ユーザーが明示的にマルチAZ設計をしなくても、AZ障害に対してはS3インフラ側で冗長性が担保される仕組みです。

ストレージクラスと可用性の関係

1. StandardとStandard-IAの可用性の違い

StandardとStandard-IAはともに複数のAZにデータを分散格納しますが、可用性SLAに差があります。

Standard-IAは取得コストが発生するため、頻繁にアクセスするデータには向きません。可用性の観点でいえば、SLAが99.9%であることに加え、取得リクエストのレイテンシがStandardより高くなるケースがある点を考慮します。

バッチ処理のログ保管など「滅多にアクセスしないが障害時に確実に取得できなければならないデータ」には、Standard-IAよりもStandardを選択する判断が適切です。

2. One Zone-IAを使ってはいけないケース

One Zone-IAはコスト削減の観点から選ばれることがありますが、以下のケースには使わないことを推奨します。

・再現できないデータ（顧客アップロード画像・医療記録など）の格納先
・可用性SLAを99.9%以上で担保する必要があるサービスの主要ストレージ
・クロスリージョンレプリケーションの宛先バケット（レプリカが単一AZでは冗長性の意味が半減する）

One Zone-IAはS3 Inventoryの結果保存や一時的な変換済みファイルの置き場など、「消えても再生成できるデータ」に限定するのが実務上の原則です。

VPC構成とS3アクセスを組み合わせた設計パターン

EC2などのVPCリソースからS3にアクセスする場合、インターネットゲートウェイ（IGW）経由とVPCエンドポイント経由の2ルートがあります。可用性と通信コストの両面から、VPCゲートウェイエンドポイントを使うパターンが推奨されます。

1. Gateway型VPCエンドポイントとルートテーブル設定

Gateway型VPCエンドポイントは、S3とDynamoDBのみ対応する無料のエンドポイントです。作成後、サブネットのルートテーブルにエントリを追加することで、VPC内のリソースがインターネットを経由せずS3にアクセスできます。

エンドポイント作成後、ルートテーブルには以下のようなエントリが自動追加されます。

# ルートテーブルの設定例（抜粋）
# 宛先: pl-xxxxxxxxx（S3のプレフィックスリスト）
# ターゲット: vpce-xxxxxxxxx（Gateway型VPCエンドポイント）

# AWS CLIでエンドポイントを作成する例（出力例は環境により異なります）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.ap-northeast-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0123456789abcdef0 rtb-0123456789abcdef1 rtb-0123456789abcdef2
この設定により、VPC内からS3への通信はAWSのバックボーンネットワーク経由になります。NAT Gateway経由の場合に発生するデータ転送料も削減できます。

2. マルチAZサブネット設計でS3到達経路を冗長化する

マルチAZでEC2を冗長化している場合、各AZのサブネットのルートテーブルすべてにVPCエンドポイントのエントリを設定する必要があります。

たとえばap-northeast-1（東京リージョン）でAZ-a・AZ-c・AZ-dの3つのAZにプライベートサブネットを展開している場合、3つすべてのルートテーブルにGatewayエンドポイントへのルートを追加します。これを怠ると、特定のAZのEC2インスタンスだけがS3にアクセスできない状況が発生します。

Amazon LinuxをベースにAWS CLI環境を整える手順や、EC2・S3を組み合わせた基礎設計の考え方はAmazon Linux入門も参考にしてください。

設定を確認するには以下のコマンドが使えます。

# VPCエンドポイント一覧の確認（出力例は環境により異なります）
aws ec2 describe-vpc-endpoints \
  --filters "Name=service-name,Values=com.amazonaws.ap-northeast-1.s3"

# 出力例（環境により異なります）
# {
#     "VpcEndpoints": [
#         {
#             "VpcEndpointId": "vpce-0123456789abcdef0",
#             "VpcEndpointType": "Gateway",
#             "State": "available",
#             "RouteTableIds": [
#                 "rtb-0123456789abcdef0",
#                 "rtb-0123456789abcdef1",
#                 "rtb-0123456789abcdef2"
#             ]
#         }
#     ]
# }
RouteTableIdsに期待するすべてのルートテーブルIDが含まれているかを確認します。3つのAZのサブネットを使っているなら、3つのルートテーブルIDが含まれているべきです。

クロスリージョンレプリケーション（CRR）で障害対策を強化する

S3 Standardはリージョン内で複数AZにデータを冗長化しますが、リージョン全体に影響する障害や法規制上の要件（データの地理的分散義務）には、クロスリージョンレプリケーション（CRR）が有効です。

1. CRRの基本設定と用途

CRRはバケット単位で設定し、指定した別リージョンのバケットへ非同期でオブジェクトをコピーします。主な用途は以下のとおりです。

・リージョン障害時のデータ参照先の確保
・法規制によるデータの地理的分散義務への対応
・開発環境・本番環境など複数リージョンへの同一データ配布

CRRの設定にはバージョニングの有効化が前提条件です。送信元・宛先の両バケットでバージョニングを有効化した上で、送信元バケットのレプリケーション設定に宛先バケットと適切なIAMロールを指定します。

# バージョニング有効化（送信元バケット）（出力例は環境により異なります）
aws s3api put-bucket-versioning \
  --bucket my-source-bucket \
  --versioning-configuration Status=Enabled

# レプリケーション設定の確認
aws s3api get-bucket-replication --bucket my-source-bucket

2. CRRと可用性の限界

CRRは非同期レプリケーションのため、送信元バケットにオブジェクトが書き込まれてから宛先バケットに反映されるまでに時間差があります。標準設定ではこの時間差は保証されません。

RPO（目標復旧時点）を厳格に設定する必要がある場合は、S3 Replication Time Control（S3 RTC）を有効化することで、99.99%のオブジェクトを15分以内にレプリケートするSLAが追加されます（追加料金が発生します）。

また、CRRは設定後に追加されたオブジェクトのみをレプリケートします。設定以前から存在するオブジェクトは対象外となるため、既存オブジェクトを含めた完全な複製が必要な場合はS3 Batch Replicationを使います。

障害モードと設計時の注意点

S3を利用したアーキテクチャで発生しうる障害パターンと、設計段階での対処方針を整理します。

・VPCエンドポイントの設定漏れ：特定のAZのEC2からのみS3アクセスが失敗するケースの典型的な原因です。全AZのルートテーブルを確認し、エンドポイントへのルートが漏れなく設定されているかを検証します
・バケットポリシーによるVPCエンドポイント限定：VPCエンドポイントからのアクセスのみを許可するポリシーを設定している場合、インターネット経由のフォールバックが使えません。障害時の回避経路が設計上存在しないことを事前に認識した上で判断します
・One Zone-IAのAZ障害：使用しているAZが停止すると、データへのアクセスが完全に失われる可能性があります。再現不可能なデータに使わないことが大前提です
・CRRの遅延による整合性問題：フェイルオーバー先リージョンのバケットが最新状態ではない場合があります。読み取りは最終的整合性に基づく設計にする、またはS3 RTCを使って遅延の上限を定義します

本記事のまとめ

AWS S3の可用性設計とVPC構成の組み合わせをまとめます。
設計の観点 推奨アプローチ
ストレージクラス選択 再現不可能なデータはStandard。頻度が低くても可用性99.9%以上が必要ならStandard-IA。消えても再生成できるデータのみOne Zone-IA
VPCエンドポイント Gateway型エンドポイントを作成し、すべてのAZのサブネットルートテーブルにエントリを追加する
リージョン間冗長 RPOが厳しい要件にはCRR＋S3 RTCを検討。通常要件はCRRのみでも十分
既存オブジェクトのレプリケーション CRR設定以前のオブジェクトにはS3 Batch Replicationを使う
バケットポリシーの設計 VPCエンドポイント限定ポリシーを設定する場合は、フォールバック経路の有無を事前に確認する
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AWSのAmazon Linux環境でのサーバー構築・運用の基礎から実践までをまとめています。
＞＞ Amazon Linux入門はこちら

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

運営

リナックスマスター.JP（代表 宮崎智広）

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。