【AWS経験者向け】S3とCloud Storage:オブジェクトストレージを徹底比較
はじめに:AWS S3の知識でGCP Cloud Storageを攻略する
皆さん、こんにちは!「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、4日目へようこそ。
AWSの学習を始めたとき、まず最初に触れるサービスの一つが、無限のストレージを提供する S3(Simple Storage Service) ではないでしょうか?サーバーレスアーキテクチャやデータレイク、バックアップなど、S3はAWSインフラの「要」となるサービスです。
GCPにも、S3と非常によく似た役割を持つサービス、Cloud Storageがあります。しかし、一見似ているようで、その料金体系、権限管理、データ一貫性モデルには、AWSと異なる独自の思想が隠されています。
この記事では、AWS S3の知識を前提に、GCP Cloud Storageを徹底的に比較し、以下の疑問を解消します。
- S3とCloud Storageの料金はどちらが安いのか?
- AWSのバケットポリシーはGCPでどう対応するのか?
- GCPのデータ一貫性モデルの強みとは?
- S3からCloud Storageへの具体的な移行方法
この記事を読めば、GCPでのオブジェクトストレージの設計と運用が明確になり、よりコスト効率の高いシステムを構築できるようになります。
料金体系の徹底比較
オブジェクトストレージの料金は、主にストレージ料金、リクエスト料金、データ転送料金の3つの要素で構成されます。
料金比較表(2025年8月時点・東京リージョン)
サービス | ストレージクラス | ストレージ料金 (1GB/月) |
---|---|---|
AWS S3 | Standard | $0.025 |
Standard-IA | $0.014 | |
One Zone-IA | $0.010 | |
Glacier Deep Archive | $0.00099 | |
GCP Cloud Storage | Standard | $0.020 |
Nearline | $0.010 | |
Coldline | $0.007 | |
Archive | $0.004 |
※料金は為替レートやキャンペーンにより変動する可能性があります。最新の正確な料金は必ず各クラウドプロバイダの公式ウェブサイトでご確認ください。長期利用を前提とする場合、GCPではCommitted Use Discounts(確約利用割引)などを活用することで、さらにコストを抑えられます。
リクエスト料金詳細比較(1,000リクエストあたり)
操作タイプ | AWS S3 | GCP Cloud Storage |
---|---|---|
書き込み系 | $0.0047 (PUT) | $0.005 (Class A) |
読み込み系 | $0.00037 (GET) | $0.0004 (Class B) |
アーカイブからの取得 | $0.058 (Glacier) | $0.050 (Archive) |
データ転送料金詳細比較(1GBあたり)
転送先 | AWS S3(東京) | GCP Cloud Storage(東京) |
---|---|---|
インターネット | $0.114 (最初の1TB) | $0.12 (最初の1TB) |
リージョン間 | $0.09 (アジア内) | $0.05 (アジア内) |
料金比較のポイント
- GCPのシンプルさ: リクエスト料金がClass A/Bの2種類に集約されており、料金体系が非常に分かりやすいです。
- リージョン間転送: GCPのVPCネットワークの強みが活かされ、リージョン間転送コストがAWSよりも圧倒的に安価です。
- 大規模利用: 大量転送ではGCPが大幅に有利な料金設定になっています。
ハンズオン:Cloud Storageの基本操作とIAM設定
1. バケットの作成とIAM設定
GCPでは、IAMが権限管理の中心です。AWSのバケットポリシーのような概念は使わず、IAMロールを直接付与します。
# バケットを作成
gsutil mb -p [PROJECT_ID] gs://my-first-gcs-bucket
# IAMロールをユーザーに付与
gcloud storage buckets add-iam-policy-binding gs://my-first-gcs-bucket \
--member="user:example-user@gmail.com" \
--role="roles/storage.objectViewer"
# サービスアカウントにIAMロールを付与
gcloud storage buckets add-iam-policy-binding gs://my-first-gcs-bucket \
--member="serviceAccount:my-app-sa@your-project-id.iam.gserviceaccount.com" \
--role="roles/storage.objectAdmin"
2. Private Google Accessの設定
前回構築したVPCネットワーク内のインスタンスから、インターネットを経由せずにCloud Storageにアクセスする方法を実践します。これはAWSのVPCエンドポイントに相当する機能です。
構成図イメージ
【手順】
-
VPCサブネットでPrivate Google Accessを有効化
gcloud compute networks subnets update tokyo-subnet \ --region=asia-northeast1 \ --enable-private-ip-google-access
-
サービスアカウントの作成とIAMロールの付与
gcloud iam service-accounts create my-gcs-sa gcloud storage buckets add-iam-policy-binding gs://my-private-gcs-bucket \ --member="serviceAccount:my-gcs-sa@your-project-id.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer"
-
Compute Engineインスタンスを作成
gcloud compute instances create my-vm-in-private-subnet \ --zone=asia-northeast1-a \ --subnet=tokyo-subnet \ --service-account="my-gcs-sa@your-project-id.iam.gserviceaccount.com" \ --scopes="https://www.googleapis.com/auth/cloud-platform" \ --no-address
-
動作確認
gcloud compute ssh my-vm-in-private-subnet --zone=asia-northeast1-a --command="gsutil ls gs://my-private-gcs-bucket"
【AWS VPCエンドポイントとの違い】
- VPCエンドポイントは、特定のサービス(例: S3)へのアクセス専用に設定するVPC内のインターフェースです。
- Private Google Accessは、サブネット単位で設定するVPCネットワークの機能です。これにより、サブネット内のインスタンスはGoogleのすべてのAPIにプライベートIP経由でアクセスできます。
この違いにより、GCPでは個々のサービスごとにエンドポイントを設定する手間が省け、運用がよりシンプルになります。また、外部IPアドレスを必要としないため、コスト削減とセキュリティ向上に貢献します。
パフォーマンスとセキュリティの比較
データ一貫性モデル
サービス | 一貫性モデル | 実践的影響 |
---|---|---|
AWS S3 | 強い読み取り後書き込み一貫性 | PUT直後のGETで最新データが確実に取得可能(2020年12月以降)。 |
GCP Cloud Storage | 強い一貫性 | 開始当初から強一貫性を提供。開発者は一貫性を気にしない設計が可能。例えば、ファイルアップロード直後にそのファイルを読み込むような処理でも、特別な待機処理が不要です。 |
S3からCloud Storageへの移行
AWS経験者が最も気になる、S3からCloud Storageへの具体的な移行方法を見ていきましょう。
方法1: gsutil rsync
を使用(小〜中規模データ)
aws s3 sync
コマンドと同様に、gsutil rsync
コマンドでデータを同期できます。
# S3からCloud Storageに同期
gsutil -m rsync -r -d s3://my-aws-bucket gs://my-gcp-bucket
方法2: Storage Transfer Serviceを使用(大規模データ)
大量のデータを一度に移行する場合、Cloud Storage Transfer Serviceが便利です。
# Transfer Jobの作成
gcloud transfer jobs create s3://source-bucket gs://destination-bucket \
--source-creds-file=aws-creds.json \
--description="S3 to GCS migration"
# Transfer Job の状況確認
gcloud transfer operations list
まとめ:AWSエンジニアがCloud Storageを使うときの落とし穴TOP3
最後に、AWS経験者がGCPのCloud Storageを使い始めるときに陥りがちな落とし穴を3つ紹介します。
-
オブジェクトACLを使ってしまう
- なぜ問題か? S3のACLに慣れていると、GCPでも同様にオブジェクトごとにACLを設定してしまいがちです。しかし、ACLは管理が複雑になり、権限の一貫性を保つのが難しくなります。
- どう対処すべきか? GCPでは、IAMを使うのがベストプラクティスです。IAMはバケットやプロジェクトといった階層で権限を管理するため、シンプルで一貫性のある運用が可能です。
-
バケット単位のIAM権限を忘れる
-
なぜ問題か? AWSではIAMユーザーにポリシーを付与するだけで権限が有効になりますが、GCPではサービスアカウント(IAMロールに相当)に
storage.objectViewer
などのロールをバケットに対して付与する必要があります。これを忘れると、インスタンスからバケットにアクセスできません。 - どう対処すべきか? サービスアカウントを作成したら、必ずそのアカウントに、アクセスしたいバケットに対する適切なIAMロールを付与する手順を忘れないようにしましょう。
-
なぜ問題か? AWSではIAMユーザーにポリシーを付与するだけで権限が有効になりますが、GCPではサービスアカウント(IAMロールに相当)に
-
Private Google Accessの勘違い
- なぜ問題か? GCPのVPCネットワークはデフォルトでGoogle APIへの通信が可能です。そのため、Private Google Accessを有効にするだけで、インターネットに出ることなくCloud Storageにアクセスできると勘違いしがちです。
-
どう対処すべきか? Private Google Accessを有効にした後も、ファイアウォールルールでGoogle APIへの通信が許可されているかを確認しましょう。デフォルトのルールは通常許可されていますが、厳格なセキュリティポリシーで
egress deny
ルールを設定している場合は、明示的に許可する必要があります。
GCPのCloud Storageは、シンプルなIAMとグローバルなVPCネットワークとの連携により、よりシームレスで統一された環境を提供します。
次回は、いよいよCompute EngineとEC2を徹底比較します。お楽しみに!
この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします!
シリーズ記事一覧
- 【1日目】はじめの一歩!AWSエンジニアがGCPで最初にやるべきこと
- 【2日目】GCPのIAMはAWSとどう違う?「プリンシパル」と「ロール」の理解
- 【3日目】VPCとVPCネットワーク:GCPのネットワーク設計思想を理解する
- 【4日目】S3とCloud Storage:オブジェクトストレージを徹底比較(この記事)
- 【5日目】EC2とCompute Engine:インスタンスの起動から課金モデルまで