はじめに
こんにちは。
最近、AWSの構成図を読み解きながら、セキュリティ対応（異常検知や通知など）の仕組みについて学びました。
最初はAWSのサービス名が多くて「GuardDutyって何？」という状態でした。
私はITの基礎知識は学生時代に学んでいましたが、学生時代は、「インスタンス？」「API？」といった ITの基礎用語 でもつまずいていました。
この記事では、私と同じようにAWSやITを勉強し始めたばかりの人に向けて、 知っておきたいIT基礎用語を補足しながら、セキュリティ異常の検知から自動対応までの流れをわかりやすくまとめます。
まずはここから！知っておきたいIT基礎用語
AWSのサービスを知る前に、よく出てくる用語をざっくり噛み砕いておきます。
-
仮想マシン
大きなコンピューターの中に、ソフトウェアの力で「もう一つの仮想的なコンピューター」を作る技術のこと。AWSでは、これを使って自分専用のサーバーを簡単に用意できます。 -
インスタンス
上記で作った「1台1台の仮想サーバー」の実体のこと。「EC2インスタンス」＝「今起動している1台のEC2サーバー」と読み替えるとわかりやすいです。 -
API（エーピーアイ）
人間が画面を操作する代わりに、プログラム同士が裏側でやり取りするための「窓口」のこと。「APIを叩く」＝「プログラムから別のシステムに指示を出す」という意味です。 -
サーバーレス
「サーバーが存在しない」のではなく、「自分でサーバーの構築や管理をしなくていい（AWS側が全部やってくれる）」仕組みのこと。処理が動く一瞬だけ、AWSの巨大なサーバーを間借りするイメージです。
イベント駆動型アーキテクチャとは？
AWSでセキュリティの自動化を学ぶ上で、基本となるのが 「イベント駆動」 という考え方です。
これは、「何かが起きたら（イベント）、あらかじめ決めておいた処理を動かす」という仕組みです。
一般的なセキュリティ対応の流れは、リレーのように大きく3つのフェーズに分かれます。
- 検知（異常を見つける）
- 中継（条件を判定して次の処理へ渡す）
- 実行（通知やインフラの操作を行う）
1. 検知フェーズ：異常を見つける
システム上の不審な動きを見つける役割を持つサービスです。
Amazon GuardDuty
GuardDutyは、AWS上の怪しい動きを見つけてくれるセキュリティ監視サービスです。
例えば、EC2サーバー上で不審な通信やマルウェアの疑いがある動きがあった場合、GuardDutyがそれを検知します。
-
GuardDuty Finding（検知結果レポート）
GuardDutyは異常を検知すると、「Finding」というレポートを作成します。これには「どんな危険か」「どのEC2インスタンス（サーバー）か」などが含まれます。
※Finding自体が自動でサーバーを止めるわけではなく、あくまで「レポートを作成する」までが役割です。
2. 中継フェーズ：条件を判定する
作成されたレポートを受け取り、「特定の条件を満たしたら次の処理を動かす」役割を持つサービスです。
Amazon EventBridge
EventBridgeは、「何かイベントが起きたときに、次のアクションを呼び出す」サービスです。
すべてのイベントに反応するのではなく、細かい条件（ルール）を設定できます。
-
ルールの設定例
- GuardDutyのイベントであること
- 危険度が「高」であること
- 対象がEC2インスタンスであること
この条件に一致したときだけ、EventBridgeが後続の処理（Lambdaなど）にバトンを渡します。
3. 実行フェーズ：アクションを起こす
EventBridgeからの指示を受けて、実際に手を動かす役割を持つサービスです。
AWS Lambda
Lambdaは、先ほど用語解説で触れた 「サーバーレス」 でプログラムを実行できるサービスです。
Lambdaにコード（処理の手順）を書いておくことで、以下のような自動アクションを実行できます。
-
通知アクションの例
検知レポートから情報を取り出し、見やすいメッセージに整形して通知サービスへ渡す。 -
インフラ操作アクションの例
AWSのAPIを使って、対象のサーバー（EC2インスタンス）を停止させたり、調査のためのバックアップを作成したりする。
Amazon SNS（通知サービス）
SNSは、メッセージを配信するためのサービスです。Lambdaが作成した通知文を受け取り、設定された宛先（メールやチャットツールなど）に配信します。
- Publish：SNSの「Topic（送信先グループ）」に対して、メッセージを投稿する操作のことです。
インフラを構成する基本サービス群
LambdaがAPI経由で操作する対象となる、AWSのインフラ側の主要サービスです。
| 用語 | ざっくりした役割 |
|---|---|
| Amazon EC2 | サーバーとして使う仮想マシン。起動したものを「インスタンス」と呼ぶ。 |
| Elastic IP | EC2に固定で割り当てるパブリックIP。通信を遮断したい時は「関連付けを解除」します。 |
| Amazon EBS Snapshot | サーバーのディスクのバックアップ。事後調査のために取得することが多いです。 |
| AMI | EC2を起動するためのテンプレート（設計図）。これをもとに新しいインスタンスを作ります。 |
デプロイ自動化（CI/CD）の仕組み
ここまでの設定は手作業でも作れますが、実際の現場ではプログラムを使って自動でAWSに反映させます。ここでも少し開発用語を補足します。
- ビルド：人間が書いたコードを、システムが動かせる形に「準備・翻訳」する作業。
- デプロイ：準備できたものを、実際のAWS環境に「配置・反映」して使える状態にする作業。
これらを自動化するAWSサービスが以下です。
| サービス・用語 | ざっくりした役割 |
|---|---|
| GitLab / GitHub | ソースコードや設定ファイルを管理する場所 |
| AWS CodePipeline | ソース取得からビルド、デプロイまでの「全体の流れ」を管理するサービス |
| AWS CodeBuild | 実際にビルド作業（コマンド実行）を行う作業環境 |
| buildspec.yml | CodeBuildが何を実行すべきかを書いた「作業指示書」 |
| AWS CloudFormation | テンプレートファイルをもとに、AWS環境（Lambdaや権限など）を自動作成・更新するサービス |
構成図を読むときのコツ
今回、AWS構成図を読み解いてみて感じたのは、「初心者でも図から流れを掴むためのコツ」があるということです。
AWSの図はサービスアイコンが多くなりがちですが、以下の4点に注目すると全体像が見えやすくなります。
- 何をきっかけに動くか（トリガーは何か）
- どのサービスが、何を受け取っているか
- そこで何の処理（API操作など）をしているか
- 次にどこへつなぐか
また、自分で構成図やドキュメントを書く際は、EC2停止 (StopInstances) のように、 「日本語の処理内容」＋「実際のAWS API名」 をセットで書くと、初心者には意味が伝わりやすく、実装者にもコードとの対応がわかりやすくなるという学びがありました。
まとめ
AWSのサービスは一つ一つが独立したブロックのようなもので、それらを「イベント」という線でつなぐことで、複雑なセキュリティ対応も自動化できることがわかりました。
最初は専門用語の多さに戸惑いますが、「インスタンス」や「API」といった基礎用語とセットで理解していくことで、少しずつ全体像が見えてきます。今後は「何を受け取って、何を出力するのか」を意識しながら学習を進めていきたいと思います。