はじめに
現在、業務でAWSを扱う可能性があるため、キャッチアップを進めています。
ただし、現時点ではまだ実際に手を動かして構築した段階には至っておらず、主にドキュメントや資料ベースで理解を進めている状態です。
※本記事は実際の構築経験ではなく、ドキュメントや研修資料などをもとに整理した内容となります。
前回は、
- API Gateway
- Lambda
- DynamoDB
について整理してみました。
▼前回記事
今回は、Aurora / WAF / S3 について整理してみます。
特に、私自身、上記サービスを学習する中で、
- S3は何を保存するサービスなのか
- AuroraとDynamoDBは何が違うのか
- WAFはどのような攻撃を防ぐのか
といった点が曖昧だったため、自分なりに整理してみることにしました。
今回は各サービスの連携やシステム構成ではなく、
「そのサービスは何を担当するのか」
という観点で、それぞれの役割や特徴を整理していきます。
なお、本記事では、
- S3とGlacierの違い
- Aurora Replicaの役割
- AuroraとDynamoDBの違い
- WAF / Web ACL / Shieldの違い
についても触れていきます。
Aurora
Auroraとは
AuroraはAWSが提供するリレーショナルデータベースサービスです。
MySQL互換およびPostgreSQL互換のエンジンが提供されており、アプリケーションのデータを保存するために利用されます。
自分の理解としては、
「システムの台帳」
のような役割だと認識しています。
例えば、
- ユーザー情報
- 商品情報
- 注文情報
- 取引履歴
など、システムが管理するデータを保存する場所です。
前回整理したDynamoDBもデータを保存するサービスでしたが、AuroraはSQLを利用してデータを管理するリレーショナルデータベースという違いがあります。
良いと感じた点
- 高可用性が考慮されている
- 自動バックアップ機能がある
- MySQLやPostgreSQLの知識を活かせる
という点です。
データベース運用に必要な機能があらかじめ提供されており、運用負荷の軽減が見込まれます。
良いと感じた点
Auroraはマネージドサービスですが、
- テーブル設計
- インデックス設計
- SQLチューニング
などは引き続き重要になります。
このため、
「Auroraを使えばデータベース設計を意識しなくてよい」
というわけではない点に注意が必要です。
Aurora Replicaについて
Auroraを調査している中で、Aurora Replicaという機能が登場しました。
Replicaとは、
「読み取り専用の複製データベース」
です。
自分の理解としては、
「台帳のコピー」
のような役割だと認識しています。
例えば、
利用者A：データ参照
利用者B：データ参照
利用者C：データ参照
利用者D：データ更新
のようにアクセスが増えると、
1台のデータベースに負荷が集中する可能性もあります。
そのため、
- 更新処理はメインDB（Writer）
- 参照処理はReplica（Reader）
という形で役割を分担します。
良いと感じた点
Replicaを使用するメリットには下記が挙げられます。
- 読み取り性能を向上できる
- 負荷分散が可能
- 障害発生時の可用性向上に繋がる
Auroraでは、Writerに障害が発生した場合、Replicaが昇格して新しいWriterとして動作できる仕組みも提供されています。
そのため、システム停止時間の短縮にも繋がるようです。
特に参照処理が多いシステムでは、大きなメリットがありそうです。
気になった点
ReplicaはメインDBからデータを同期しますが、完全にリアルタイムではない場合があります。
そのため、更新直後のデータを必ず取得したい場合は、
- Writerへアクセスするのか
- Readerへアクセスするのか
を考慮する必要がありそうです。
DynamoDBとの違い
前回の記事ではDynamoDBについて整理しました。
どちらもデータを保存するサービスですが、仕組みや得意分野が異なります。
自分なりの理解
| サービス | イメージ |
|---|---|
| Aurora | 整理された台帳 |
| DynamoDB | 超高速な保管庫 |
というイメージを持ちました。
Aurora
Auroraはリレーショナルデータベースです。
データ同士の関係性を持ちながら管理できます。
例えば、
ユーザー
↓
注文
↓
商品
のような関連データを扱うケースが得意です。
また、
SELECT *
FROM orders
JOIN users
のようなSQLを利用して複雑な検索ができます。
DynamoDB
前回も整理しましたが、DynamoDBはNoSQLデータベースです。
テーブル設計の考え方が異なり、
- 高速
- 高スケーラビリティ
- シンプルなアクセス
を重視しています。
例えば、
ユーザーID = 1001
をキーにして高速にデータを取得するような処理が得意です。
WAF
WAFとは
WAF（Web Application Firewall）は、
Webアプリケーションを攻撃から保護するためのサービスです。
自分の理解としては、
「Webサイトを警備する警備員」
のような役割だと認識しています。
利用者からのアクセスを確認し、
- 不正なリクエスト
- 攻撃と思われる通信
- 異常なアクセス
などを検知・遮断します。
良いと感じた点
- 攻撃を自動で検知できる
- ルールベースで制御できる
- AWSサービスと連携しやすい
という点です。
アプリケーション側で全て防御するのではなく、入口で攻撃をブロックできるため、セキュリティ向上に役立ちます。
Web ACLとは
WAFを調査している中で、Web ACLという用語が頻繁に登場しました。
ACLは、
「Access Control List（アクセス制御リスト）」
の略称です。
自分の理解としては、
「警備員が参照するルールブック」
のようなものだと認識しています。
例えば、
- 特定IPアドレスを拒否する
- 特定国からのアクセスを拒否する
- SQLインジェクションを検知したら遮断する
といったルールを定義できます。
WAFは単体では何をブロックするか判断できず、
Web ACLに定義したルールを参照しながらアクセス可否を判断する仕組みとなっています。
AWS Shieldとは
WAFについて調査していると、AWS Shieldというサービスも登場しました。
AWS Shieldは、
「DDoS攻撃対策サービス」
です。
DDoS攻撃とは、
大量の通信を送り付けることでシステムを利用不能にする攻撃です。
自分の理解としては、
「施設の前で発生する大規模な押し寄せ事故を防ぐ警備体制」
のような役割だと認識しています。
WAFとShieldの違い
この二つは似たようなサービスですが、役割が異なります。
| サービス | 主な役割 |
|---|---|
| WAF | 不正なリクエストの内容を検査して遮断 |
| Shield | 大量アクセスによるDDoS攻撃を防御 |
例えば、
WAFが得意なこと
' OR 1=1 --
のようなSQLインジェクション攻撃を検知してブロック
Shieldが得意なこと
1秒間に数百万件のアクセス
のような大量通信によるサービス妨害攻撃の防御
つまり、
- WAF = 通信内容を見る
- Shield = 通信量を見る
という理解をすると分かりやすいかと思います。
Shield StandardとShield Advanced
AWS Shieldには2種類あります。
Shield Standard
AWSアカウントを作成すると自動的に利用できます。
追加料金なしで利用でき、一般的なDDoS攻撃への防御が提供されています。
Shield Advanced
有償サービスです。
以下のような機能が追加されます。
- 高度なDDoS対策
- 詳細な攻撃分析
- 専門チームによる支援
- コスト保護
大規模サービスやミッションクリティカルなシステムで利用されるケースが多いようです。
良いと感じた点
- アプリケーション到達前に攻撃を防御できる
- ルールベースで柔軟に制御できる
- Shieldと組み合わせることで幅広い攻撃に対応できる
という点です。
アプリケーション側だけで防御するのではなく、入口で攻撃をブロックできることは大きな良いと感じた点です。
気になった点
WAFを導入しただけで安全になるわけではなく、
- Web ACLの設計
- 誤検知への対応
- ルールの定期見直し
などが必要になります。
また、攻撃の種類によってはWAFだけでは十分でないため、Shieldなどのサービスと組み合わせる必要がありそうです。
S3
S3とは
S3（Simple Storage Service）は、AWSが提供するオブジェクトストレージサービスです。
画像や動画、PDF、バックアップデータなどのファイルを保存するために利用されます。
自分の理解としては、
「巨大な倉庫」
のような役割だと認識しています。
システムで扱う様々なファイルを保管し、必要なタイミングで取り出せるサービスです。
例えば、
- ユーザーがアップロードした画像
- 添付ファイル
- バックアップデータ
- システムログ
などを保存する際に利用されます。
良いと感じた点
- 容量をあまり意識せず利用できる
- 耐久性が高い
- AWSサービスとの連携が豊富
という点です。
オンプレ環境のようにストレージ容量を都度検討する必要が少なく、大量のファイルを保存できる点は大きな良いと感じた点です。
良いと感じた点
ファイルを保存するだけのサービスと思っていましたが、
- アクセス制御
- 暗号化
- ライフサイクル管理
なども考慮する必要があるようです。
Glacierについて
S3を調査している中で、Glacierというサービス（ストレージクラス）が登場しました。
最初は別サービスかと思いましたが、自分の理解としては、
「あまり立ち入らない倉庫奥にある長期保管エリア」
のような役割と認識しています。
通常のS3は頻繁に利用するファイルを保存することを想定していますが、
Glacierは、
- 数か月
- 数年
- 場合によっては数十年
といった長期間保管を目的としたデータ向けの仕組みです。
例えば、
- システムバックアップ
- 監査ログ
- 法令対応の保管データ
- 過去の帳票
など、普段はほとんど参照しないが削除はできないデータを保管する際に利用されるようです。
良いと感じた点
- ストレージコストを抑えられる
- 長期保管に向いている
- S3のライフサイクル機能と連携できる
という点です。
例えば、
保存から30日
↓
S3 Standard
保存から1年
↓
Glacierへ移動
のような運用も可能です。
利用頻度が低いデータを自動的に安価なストレージへ移動できるため、運用コスト削減に役立てることもできます。
良いと感じた点
Glacierへ保存したデータは、通常のS3と比較すると取り出しに時間を要す場合があります。
このため、
- 頻繁に利用するデータ
- リアルタイム性が必要なデータ
には向いていないようです。
逆に、
「ほぼ参照しないが、削除はできないデータ」
には非常に相性が良いと感じました。
現時点での理解
かなり単純化すると、
| 保管場所 | イメージ |
|---|---|
| S3 Standard | 倉庫の手前にある棚 |
| Glacier | 倉庫の奥にある保管庫 |
という違いだと理解しました。
すぐ取り出せる代わりにコストが高い保管場所と、
取り出しに時間がかかる代わりに安価な保管場所を使い分ける仕組みだと感じています。
おわりに
今回はあくまで「理解整理」の段階でした。
ただ、この段階で、
- S3とGlacierの違い
- AuroraとDynamoDBの違い
- Aurora Replicaの役割
- WAFとShieldの違い
などを含めて整理できたのは良かったと感じています。
調査を始める前は、それぞれのサービス名は聞いたことがあるものの、
「何を担当するサービスなのか」
「どのような場面で利用されるのか」
を明確に説明できる状態ではありませんでした。
今回整理したことで、
- S3 = ファイル保管
- Aurora = データ管理
- WAF = Webアプリケーションの保護
という大枠の役割は理解できたように感じています。
一方で、
- 実際の設計ではどのように利用されるのか
- 運用時には何を意識する必要があるのか
- どのような構成で組み合わせて利用されるのか
など、まだ理解が浅い部分も多くあります。
今後は実際にAWS環境を触りながら、ドキュメントや研修内容も踏まえて理解を深めていきたいと思います。
本記事が、AWS初学者の方にとって各サービスの役割を整理するきっかけになれば幸いです。
本記事が参考になった方は、いいねしていただけると励みになります。