【AWS研修レポート】Cloud Operations on AWS Day3 - セキュリティとストレージ編
はじめに
こんにちは、山本です。
この記事は「Cloud Operations on AWS」研修レポートのDay3(最終日)編です。
前回の振り返り
Day2では、Systems Managerによるリソース管理、ELB/Route53による高可用性、Auto Scalingによるスケーリング、CloudWatchによるモニタリングを学びました。今回のDay3では、セキュリティとストレージについて学んでいきます。
この日のサマリ
| 項目 | 内容 |
|---|---|
| テーマ | セキュリティ、ネットワーク、ストレージ |
| 主要サービス | IAM Access Analyzer, GuardDuty, Inspector, VPC, CloudFront, WAF, EBS, S3 |
| キーワード | 予防的統制/発見的統制, VPCフローログ, スナップショット, ストレージクラス |
モジュール内容
モジュール10: セキュリティとシステム監査
予防的統制(Access Analyzer, Permission Boundary)と発見的統制(CloudTrail, GuardDuty, Inspector)について学びました。
運用との関連として、予防的統制でセキュリティリスクを最小化し、発見的統制でセキュリティイベントを検出・対応することで安定性を高めます。また、セキュリティイベント対応を効率化することで運用効率を上げます。
予防的統制と発見的統制の違いを以下にまとめます。
| 種類 | 目的 | サービス例 |
|---|---|---|
| 予防的統制 | リスクある設定を早期検知・防止 | IAM Access Analyzer, Permission Boundary |
| 発見的統制 | セキュリティイベントを検出 | CloudTrail, GuardDuty, Inspector |
予防的統制のサービス
-
IAM Access Analyzer
- パブリックアクセス可能なリソースを検出
- 基本無料、デフォルト使用を推奨
- 検出項目: パブリックアクセス、クロスアカウントアクセス
-
Permission Boundary(アクセス許可の境界)
- IAMユーザー/ロールに設定可能な境界
- 通常ポリシーとBoundaryの重なる部分のみ有効
- ユースケース: 権限昇格の防止
発見的統制のサービス
-
AWS CloudTrail
- AWSサービスのAPIコールを記録
- マネコン、SDK、CLI等のアクセス時のAPI呼び出しを記録
- セキュリティインシデント発生時はまずCloudTrailを確認
-
GuardDuty
- 脅威(バックドア、CloudTrail無効化、不正アクセス、乗っ取り)を監視
- ボタンで有効化するだけ。リージョン単位で有効化が必要
- 裏側: CloudTrailイベント、VPCフローログ、DNSログを機械学習で分析
- 運用: GuardDuty → EventBridge → SNSで通知連携
-
Amazon Inspector
- AWS上のサービスに対して継続的に脆弱性を検出
- 前提: EC2にSSM Agent必要(ほとんどデフォルトでインストール済)
ConfigとCloudTrailの違いを以下にまとめます。
| サービス | 記録対象 |
|---|---|
| Config | 状態変化を継続的に記録 |
| CloudTrail | APIの記録 |
学び
セキュリティ対策を「予防的統制」と「発見的統制」に分類する考え方は整理しやすいと感じました。CloudTrailは「セキュリティインシデント発生時はまず確認する」という位置づけで、現場でも意識しておきたいポイントです。
モジュール11: 安全性と耐障害性に優れたネットワーク運用
セキュアなVPC設計、VPCフローログ、CloudFront/WAFについて学びました。
運用との関連として、セキュアなネットワーク構築でリスクを低減し安定性を高め、ネットワーク管理を効率化します。
セキュアなVPC構築は以下のステップで進めます。
- サブネット分割(役割・要件に応じて、複数AZ利用)
- 適切なルートテーブル設定
- NATゲートウェイ使用(アウトバウンド制御)
- ネットワークACL・セキュリティグループで通信制御
ネットワークACLとセキュリティグループの違いを以下にまとめます。
| 項目 | ネットワークACL | セキュリティグループ |
|---|---|---|
| 適用単位 | サブネット | サーバー(ENI) |
| ルール形式 | 番号順に評価、Allow/Deny | ホワイトリスト形式 |
| ステート | ステートレス(戻り通信も明記必要) | ステートフル |
セキュリティグループのチェーン
- 他のセキュリティグループを参照できる
- サーバー増加ごとに設定追加が不要になる
VPCフローログ
- デフォルトOFF、有効化必要
- IPトラフィック情報をキャプチャ
- 注意: 全情報取得はコスト増、必要な情報を取捨選択
VPC間接続の方式を以下にまとめます。
| 方式 | 用途 |
|---|---|
| VPCピアリング | VPC同士をプライベート通信経路で接続 |
| VPN接続 | オンプレとVPCを接続 |
| Transit Gateway | 複数VPCとオンプレNWを接続する単一GW。NWのハブとして機能 |
エッジサービス
-
CloudFront
- CDN(Content Delivery Network)
- エッジロケーション(700以上)でスタティックコンテンツを効率配信
- メリット: オリジントラフィック減 → 安定性向上 → コスト最適化
- 注意: キャッシュ不可情報(個人情報等)の取り扱い
-
AWS WAF
- 悪意のあるトラフィック(SQLインジェクション、XSS等)をブロック
- マネージドルール(AWS/ベンダー提供)の使用を推奨
- カウントモード: ブロックせずにカウントのみ(ルールテスト用)
-
ACM(AWS Certificate Manager)
- TLSサーバー証明書の取得・管理
- ALB等に証明書を提供、自動更新あり
学び
ネットワークACLがステートレスであるという点は見落としがちなポイントです。戻り通信用のアウトバウンドルールやエフェメラルポートの設定が必要になることを覚えておきたいと思います。
モジュール12: マウント可能なストレージ
EBSボリュームタイプ、スナップショット、AWS Backupについて学びました。
運用との関連として、データ損失防止とすぐに復旧できる仕組みで安定性を高め、性能最適化とコスト/パフォーマンス効率最大化で効率を上げます。
EBSの特徴
- EC2インスタンスにアタッチするストレージ
- 1つのEC2にのみアタッチ可能(EC2とは独立、NW接続)
- 同じAZ内でのみ使用可能
- 耐久性目的のRAID不要(EBSは冗長化済)
EBSボリュームタイプを以下にまとめます。
| タイプ | 種類 | 用途 |
|---|---|---|
| SSD | gp2, gp3(汎用)、io1, io2(プロビジョンドIOPS) | ランダムI/O |
| HDD | スループット最適化、コールドHDD | シーケンシャルI/O |
基本はgp3を使用し、シーケンシャルワークロードにはHDDが適しています。
IOPSとスループット
- IOPS: 1秒間の読み書き回数
- スループット: 1秒間の転送データ量(= IOPS × I/Oサイズ)
EBSスナップショット
- データのコピー、裏側でS3に保存(複数AZに冗長化)
- 増分スナップショット: 差分のみをバックアップ
- 復元時の注意: 復元直後はパフォーマンス低下
- Fast Snapshot Restore(FSR)で対策可能
AWS Backup
- スナップショットの自動化
- 各サービスのBackup機能を一元管理
- バックアップにはAWS Backupを使用推奨
EC2インスタンスストア
- 低レイテンシー、高IOPS
- 注意: インスタンス停止/終了でデータ消失
- ユースケース: バッファ、キャッシュ、一時データ
学び
EBSは「同じAZ内でのみ使用可能」という制約があることを再確認しました。マルチAZ構成でのデータ設計時に意識すべきポイントです。また、バックアップはAWS Backupで一元管理するのが推奨という点も覚えておきたいと思います。
モジュール13: オブジェクトストレージ
S3の耐久性、レプリケーション/バージョニング、ストレージクラスについて学びました。
運用との関連として、損失しにくく復旧できる仕組みで安定性を高め、性能最適化とコスト・パフォーマンス最大化で効率を上げます。
S3の特徴
- AWS提供のオブジェクトストレージ
- イレブンナインの耐久性: 99.999999999%(1千万オブジェクトで1万年に1個壊れる確率)
- 用途: 長期保存(ログ、アーカイブ、データレイク)、静的Webサイト、コンテンツ配信
データ損失防止の機能を以下にまとめます。
| 機能 | 説明 |
|---|---|
| S3レプリケーション | アカウント跨ぎ、リージョン跨ぎでレプリケーション可能。ディザスタリカバリに使用 |
| S3バージョニング | 上書き前データを保護、オペミス防止。注意: データ増加でコスト増 |
| オブジェクトロック | コンプライアンスモード(誰も触れない)、ガバナンスモード(特定権限者のみ更新・削除可) |
リスク削減の機能を以下にまとめます。
| 機能 | 説明 |
|---|---|
| ブロックパブリックアクセス | 誤ったパブリック公開を防止(ガードレール) |
| Access Analyzer for S3 | パブリックアクセス状態を検知 |
| S3アクセスログ | 監査・原因究明に活用 |
コスト効率化(ストレージクラス)
アクセス頻度に応じてデータの置き場所を変更できます。
| クラス | 特徴 |
|---|---|
| S3 Standard | デフォルト |
| Glacier Instant Retrieval | リアルタイム取得可 |
| Glacier Flexible Retrieval | 取得に時間必要 |
| Glacier Deep Archive | 取得に時間必要、最安 |
ストレージクラス管理
- ライフサイクル設定: 時間経過でストレージクラス変更・削除
- Intelligent-Tiering: アクセスパターンをモニタリングし自動移行
学び
S3のイレブンナイン(99.999999999%)の耐久性は改めて驚異的です。ストレージクラスの選択とライフサイクル設定を適切に行うことで、コスト最適化が図れることを学びました。
ラボ体験
ラボ5: AWS Backupを使ってアーカイブと復旧を自動化する
AWS Backupを使用したバックアップの自動化を体験しました。
実施内容
- SNSトピックのサブスクリプション設定
- バックアッププラン作成
- バックアップにリソース割り当て、SNS通知設定
- EBSボリュームのオンデマンドバックアップ
- Lambda関数で復元ジョブを自動開始しテスト
- CloudWatchログ確認
学び
以下の部分がSOA試験などに関連するので学びになりました。
- SNSトピックをサブスクライブしてメール通知
- AWS Backupでバックアッププラン・ボールトを作成
- Lambda関数で復元ジョブのテストを自動化
ラボ6: 最終ラボ
研修の総仕上げとして、指示が抽象的な課題に自分で考えて取り組みました。
パート1: EventBridgeとSystems Managerからの自動通知
- SNS通知を作成してサブスクライブ
- EventBridgeルールをセットアップ
パート2: CloudFormationと自動修正
- CloudFormationドリフト検出
- SSMドキュメントでセキュリティグループを修正
パート3: AWS Configルールと自動修正
- AWS Configで非準拠リソースを検出
- AWS Configルールの自動修正を設定
学び
以下の部分もSOA試験などに関連するので学びになりました。
- EventBridge + SNSでモニタリング・通知ソリューション構築
- AWS Configで非準拠構成を検出
- AWS Config + SSMドキュメントでコンプライアンス問題を修正
- CloudFormationドリフト検出でネットワーク構成変更を特定
疑問点と解消
Q: InspectorはLambdaも脆弱性検知できるか?
研修中に気になりましたが、時間の都合で確認できませんでした。
調査結果
Amazon Inspectorは、EC2インスタンス、コンテナイメージ(ECR)、Lambda関数の脆弱性を検出できます。
Lambdaスキャンの種類を以下にまとめます。
| スキャンタイプ | 対象 |
|---|---|
| Lambda Standard Scanning | アプリケーションの依存関係(サードパーティパッケージ)の脆弱性 |
| Lambda Code Scanning | カスタムアプリケーションコードの脆弱性 |
スキャン条件
- 過去90日以内に呼び出しまたは更新されたLambda関数が対象
$LATESTバージョンであること- エージェントのインストール不要
参考: Scanning AWS Lambda functions with Amazon Inspector
研修全体の振り返り
3日間の研修を通じて、以下の点を学びました。
運用の目的: システムを安定させ、かつ効率よく提供し続けること
この定義を軸に、各サービスが「安定」と「効率」のどちらに寄与するかを整理しながら学ぶことで、理解が深まりました。
特に印象に残ったサービス
- AWS Config: コンプライアンス違反を検出し、自動修復できる
- CloudTrail: セキュリティインシデント時の調査に必須
- X-Ray: マイクロサービスの障害切り分けに有効
今後試してみたいこと
- AWS CloudOps資格の受験: 研修で学んだ内容を資格で証明したい
- AWS Configの活用: コンプライアンス違反の自動検出・修復を現場に導入できないか検討
- CloudTrail/X-Rayの利用: 現場での監視・追跡機能として活用を検討
最後に
Day3では、セキュリティ(予防的統制/発見的統制)、ネットワーク(VPC、CloudFront、WAF)、ストレージ(EBS、S3)について学びました。
3日間を通じて、AWSの運用に関する体系的な知識を得ることができました。特にAWS Config、CloudTrail、X-Rayといったサービスは業務に応用できそうなので、今後試していきたいと思います。
研修で学んだ内容を活かして、AWS CloudOps資格にも挑戦する予定です。
参考リンク
- Amazon Inspector(Black Belt)
- Amazon CloudFront Cache Control編(Black Belt)
- EBS Fast Snapshot Restore
- Amazon S3 料金
- Patch Manager を使ったパッチ戦略
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました






