駅メモ！開発基盤チームの id:xztaityozx です。 今回は複数のAWSアカウントにある CloudWatch ダッシュボードのスナップショットを定期的に作成する仕組みを EventBridge Scheduler / Lambda / S3 を使って再構築した話を書きます。 前提と課題 駅メモ！では複数のAWSアカウントを利用しており、それぞれの用途に合わせた CloudWatch ダッシュボードを作成しています。 これらのダッシュボードは、日常の負荷確認でも使いますが、長期的なトレンド把握や過去の施策の効果検証などにも利用しています。このとき困るのが CloudWatch Metrics の保存期間です。 通常、CloudWatch Metricsは1分単位のデータは15日分、5分単位のデータは63日分、1時間単位のデータは15か月分と集計期間ごとに保存期間が設定されています *1 。そのため長期的なトレンド把握や過去の施策の効果検証を行う際に詳細なデータが確認できなかったり、1分、5分粒度では取得できなくなっていることがあります。 これを回避するために、以前からCloudWatchの GetMetricWidgetImage API を使ってダッシュボードを構成するメトリクスウィジェットの画像を保存する仕組みを構築していました。 大まかな仕組みとしては以下の通りです。 before シンプルな構成です。EC2のcronで定期的にスナップショット保存の処理を実行するようにしていました。 初期はこの構成でも問題がなかったのですが、AWSアカウントが増えるにつれて以下のような課題が出てきました。 課題1: アカウントごとにEC2インスタンスを用意する必要がある 初期に仕組みが構成されていたアカウントにはcronを動かしているEC2インスタンスが存在していましたが、EC2を利用していないアカウントやVPCすら作っていないアカウントも出てきたため、単純な横展開は難しくなっていました。 また、多数のcronが同居しており、それぞれのジョブが異なる権限を必要とするため、適切なインスタンスプロファイルの設計が複雑になっていることも課題でした。 課題2: スナップショット作成スクリプトが、アプリケーションと同居している スナップショット作成スクリプトが、駅メモ！本体のリポジトリに存在しており、その変更を反映するためには駅メモ！本体のデプロイが必要になっていました。 ちょっとパラメータを変更したいだけなのに、本番に影響が起こりうるのはあまり好ましくありません。 課題3: スナップショットの保存先がS3バケットで、アカウントごとにバケットを用意している アカウントが増えるにつれて管理対象のバケットも増え、適切なバケットポリシーやネットワーク制限の設定など、運用コストが増えていました。 これらの課題を解決するために、この仕組みを見直すことにしました。 設計の話 前項で挙げた課題解決と、運用負荷低減のためのポイントは以下の通りです。 VPCの有無などに左右されない構成にする スナップショット作成スクリプトをアプリケーションから切り離す スナップショットの保存先をアカウントごとに分けない Lambda失敗時に自動でリトライする。所定の回数失敗したら処理を諦めてSlackに通知する これらのポイントを踏まえて、今回は以下のような構成にすることにしました。 after EventBridge Schedulerで定期的にLambdaを起動する EC2で動いていたcronの代わりにEventBridge Schedulerを利用 配信失敗時の再試行などもEventBridge Schedulerの機能で実装可能 LambdaでCloudWatchダッシュボードのスナップショットを作成する スナップショット作成スクリプトをLambdaに移行 アプリケーションから切り離す Lambda失敗時はEventBus->SNS->Amazon Q Developer in chat applications(旧Chatbot)経由で通知が送られる 関数エラーの場合は、初回に加えて最大2回リトライし、すべて失敗した場合、Lambda destinationsで失敗イベントをEventBusに送る EventBusを挟むのはLambdaの失敗イベントペイロードを変換するため Push型のアーキテクチャを採用する 後述 EventBridge Scheduler Lambdaの定期実行のトリガーにはEventBridge Schedulerを利用することにしました。管理すべきサーバーが不要なのでcronを動かすEC2の役割を減らすことができます。 配信失敗時のリトライはEventBridge Schedulerで、関数実行失敗時のリトライはLambdaの非同期呼び出し設定で実装できるので、運用負荷の低減にもつながります。 data "aws_iam_policy_document" "assume_role_policy" { statement { # 省略 } } data "aws_iam_policy_document" "allow_lambda_invoke" { statement { effect = "Allow" actions = [ "lambda:InvokeFunction" ] resources = [ aws_lambda_function.this.arn, "$ { aws_lambda_function.this.arn } :*" ] } } resource "aws_iam_role" "eventbridge_scheduler_role" { name = "scheduler-role" assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json path = "/service-role/" } resource "aws_iam_policy" "invoke_lambda_policy" { name = "scheduler-invoke-lambda-policy" policy = data.aws_iam_policy_document.allow_lambda_invoke.json path = "/service-role/" } resource "aws_iam_role_policy_attachment" "attach_invoke_lambda_policy" { policy_arn = aws_iam_policy.invoke_lambda_policy.arn role = aws_iam_role.eventbridge_scheduler_role.name } # EventBridge SchedulerはLambdaを非同期で呼び出すため、 # 後述のLambda destinationsによる失敗通知が利用できる resource "aws_scheduler_schedule" "this" { for_each = { for config in var.schedule_config : config.name => config } name = each.value.name schedule_expression = each.value.cron_expression schedule_expression_timezone = "Asia/Tokyo" group_name = aws_scheduler_schedule_group.this.name target { arn = aws_lambda_function.this.arn role_arn = aws_iam_role.eventbridge_scheduler_role.arn # Lambdaに渡すイベントペイロード # dashboard_names: ダッシュボード名のリスト # period: データの期間 (例: "1h", "1w" など) # s3_bucket: 書き込み先S3 # resolution: データの解像度 (例: "1m", "5m" など) input = jsonencode ( { "dashboard_names" : each.value.target_dashboards, "period" : each.value.period, "s3_bucket" : var.s3_bucket_name, "resolution" : each.value.resolution } ) } flexible_time_window { mode = "OFF" } } Lambda こちらは移行前のスクリプトを元にPythonに書き直したものです。 単純にAPIを呼び出して画像を保存、レポート用のHTMLファイルを生成して保存するだけの処理なので詳細は割愛させていただきます。 Terraformでの定義は以下のような感じです。 resource "aws_lambda_function" "this" { function_name = var.function_name role = aws_iam_role.lambda_execution.arn handler = "lambda_handler.handler" runtime = local.python_runtime timeout = 300 memory_size = 256 filename = data.archive_file.lambda.output_path source_code_hash = data.archive_file.lambda.output_base64sha256 layers = [ aws_lambda_layer_version.deps.arn ] } resource "aws_lambda_function_event_invoke_config" "send_to_eventbridge_on_failure" { function_name = aws_lambda_function.this.function_name destination_config { on_failure { destination = aws_cloudwatch_event_bus.failures_notice.arn } } # 関数エラーの場合は、初回に加えて最大2回リトライする maximum_retry_attempts = 2 } resource "aws_iam_role" "lambda_execution" { name = "$ { var.function_name } -execution-role" assume_role_policy = data.aws_iam_policy_document.lambda_assume_role_policy.json path = "/service-role/" } data "aws_iam_policy_document" "lambda_execution_policy" { statement { effect = "Allow" actions = [ "cloudwatch:GetMetricWidgetImage" , "cloudwatch:GetDashboard" , ] resources = [ "*" ] } statement { effect = "Allow" actions = [ "s3:PutObject" , ] resources = [ "arn:aws:s3:::$ { var.s3_bucket_name } /*" ] } statement { effect = "Allow" actions = [ # 失敗時にEventBusに送信するための権限 "events:PutEvents" , ] resources = [ aws_cloudwatch_event_bus.failures_notice.arn, ] } } data "aws_iam_policy_document" "lambda_assume_role_policy" { # 省略... } resource "aws_iam_policy" "lambda_execution_policy" { # 省略... } resource "aws_iam_role_policy_attachment" "attach_lambda_execution_policy" { # 省略... } EventBus->SNS->Amazon Q Developer in chat applications Lambda destinationsで失敗イベントをEventBusに送信、入力トランスフォーマーを使ってAmazon Q Developer in chat applicationsが受け取れる形式に変換してからSNSに送るという構成です。 Amazon Q Developer in chat applicationsが受け取れる形式はドキュメントによると以下のようになっています スキーマ: https://docs.aws.amazon.com/chatbot/latest/adminguide/custom-notifs.html サンプル: https://docs.aws.amazon.com/chatbot/latest/adminguide/sample-custom-action.html#custom-notifs-metadata { " version ": " 1.0 ", " source ": " custom ", " content ": { " title ": " IP Address Allowlist Request ", " description ": " We have received a request to allows list an IP address from 'sample@sample.com'. " } , " metadata ": { " additionalContext ": { " IPAddress ": " 192.168.0.1 " } } } これを参考に入力トランスフォーマーでLambdaの失敗イベントを変換します。例えば以下のような感じですね resource "aws_cloudwatch_event_target" "sns" { rule = "<snip>" target_id = "<snip>" arn = "<snip>" event_bus_name = "<snip>" input_transformer { input_paths = { id = "$.detail.requestContext.requestId" reason = "$.detail.responsePayload.errorMessage" } input_template = <<-EOT { "version": "1.0", "source": "custom", "id": "$ { var.function_name } -<id>", "content": { "textType": "client-markdown", "title": "Lambda Alert", "description": "$ { var.account_alias } アカウントで `<reason>` により失敗しました。ここに続けて何かお好きなメッセージ" } } EOT } } input_template 内の <id> や <reason> は input_paths で指定したJSONパスの値に置き換えられます。今回は投稿ごとにユニークなIDを付与したかったので、LambdaのリクエストIDを、失敗理由はLambdaのエラーメッセージをそれぞれ指定するようにしました。 このあたりは細かい調整が結構発生したので、試行錯誤しやすいWebコンソールからポチポチやってTerraformに取り込むほうが楽かもと思いました。 Push型のアーキテクチャを採用した理由 今回はPush型のアーキテクチャを採用することにしました。最小権限の原則を考えるとPull型の権限の広さは避けたかったのが大きな理由です。 このようなデータ収集を行う場合には、集約するアカウントでデータ収集コードを実行するPull型のアーキテクチャと、各アカウントがデータ収集を行い、一箇所に集約するPush型のアーキテクチャのどちらかを選択することになると考えています。例えば以下のようなイメージですね。 pull push このどちらかをベースに実装していく必要がありますが、正直実装の重さはほぼ変わらないので、検討すべきは運用の楽さ、可用性、権限管理のしやすさなどになりそうです。それぞれ考えてみると Pull 型 運用の楽さ 集約するアカウントにだけLambdaやスケジューラーがあればよい 権限管理 集約するアカウントに、データ収集対象アカウントのCloudWatchを読み取る権限を与える必要がある 集約するアカウントが侵害されたときに、全アカウントの監視情報が漏えいするおそれがある 可用性 集約するアカウントのLambdaの障害が全てのデータ収集に影響する Push 型 運用の楽さ 各アカウントが独立してデータ収集を行うため、Lambdaやスケジューラーの設定は各アカウントで行う必要がある 権限管理 権限の範囲をアカウント単位に限定しやすい 可用性 あるアカウントでLambdaに障害が起きても、他のアカウントのデータ収集への影響が出にくい やはりいいところ悪いところがありますが、権限管理に注目するとPush型のほうが良さそうに見えました。書き込み先S3バケットの権限(クロスアカウントな権限)はPush型でも必要になりますが、アカウントごとにS3 prefixを分け、ポリシーで制御するなどしておけば影響範囲は狭めることができます。 Pull型ではダッシュボードの取得権限は個別に制限できますが、GetMetricWidgetImageの権限はメトリクス単位に制限できません。そのため、各アカウントの読み取り権限を集約先に持たせないPush型を選んだ感じです。 まとめとネクストアクション 今回はCloudWatch ダッシュボードのスナップショットを保存する仕組みを EventBridge Scheduler / Lambda / S3 を使って再構築した話を書きました。 これにより、以前からの課題を解決し、運用負荷を下げることができました。 ネクストアクションとしては次のものがあります CloudWatch OAM経由を試してみる CloudWatch OAMを使ったクロスアカウントなダッシュボードを構築している部分がある これ経由ならPull型でも権限を狭められるかもしれない？ メトリクスデータ自体をアーカイブしてみる 現状は GetMetricWidgetImage で取得した画像をアーカイブするだけ これまでのアーカイブとの互換性維持のため 生のメトリクスデータを埋め込んだHTMLでも良い気はしている 試してみて新しい知見があればまた記事にしたいと思います。以上です。 *1 : https://aws.amazon.com/jp/cloudwatch/faqs/

開催概要 2026年9月2日に、AWS麻布台ヒルズオフィスにて「 AWS Cashless Frontier 」を開催いたしました。決済業界のIT推進・ビジネスリーダー約30社60名の皆様にご参加いただき、エージェンティック・コマースやステーブルコイン、AIエージェント活用といった最新テーマについて、実践知の共有とネットワーキングが行われました。本記事では、イベントを企画した背景から各セッションの様子、パネルディスカッションの内容をお届けします。 企画の趣旨 ― AIのプロダクション利用を見据えて 決済はあらゆる経済活動の重要な基盤であり、キャッシュレス化は生活者の利便性に直結します。キャッシュレスの推進に向けては、システムのサイロ化やレガシーシステムからの脱却をカード会社、決済代行会社、フィンテック企業など決済業界全体で進める必要があります。そのような背景から、ユーザーにシームレスな体験を届けるために「 決済をなめらかにつなぎ、お客様の感動を創出する 」というビジョンをAWS Cashless teamでは掲げています。ビジョンの実現に向けて、最新情報のお届けや業界課題について踏み込んだ意見交換を行うイベントを、毎年テーマを発展させながら行っています。 この1年で決済業界を取り巻く環境は大きく変わりました。AIエージェントが商品の検索・比較から決済まで自律的に実行するエージェンティック・コマースとその基盤となるステーブルコインやトークン化預金といったプログラマブルな通貨の台頭、不正検知や顧客対応の自動化など生成AIによる業務変革、そしてAI駆動開発と言われるようなAIネイティブな開発スタイルの浸透といったトレンドが同時に立ち上がりました。こうした変化の最前線に立つ決済企業の皆様と共に、リアルな実践知を交換し業界横断でのイノベーションを加速する場として、本イベントを企画しました。 イベント概要 日時: 2026年9月2日（水）15:00–19:30 会場: AWS麻布台ヒルズオフィス 参加者: 決済関連企業 約30社60名 オープニング・AWS 決済業界クラウド活用最新動向 AWS 新相よりこの1年間の国内外の動きを紹介しました。2025年末のAWS re:InventでCoinbaseがx402プロトコルによるエージェントがステーブルコインを使い即時決済できる仕組みを実装した事例、2026年5月のFinancial Services SymposiumでVisa・Stripeが発表したTrusted Agent ProtocolやMachine Paymentなど、エージェントが安全に決済するためのインフラが急速に整備されてきた流れを振り返りました。 日本についてはJPYCがAWS上にステーブルコイン発行基盤を構築した事例や、シンプレクスのオンチェーン関連の取り組み、DCPのトークン化預金と国際決済の事例を紹介しました。AIエージェントによる決済は目新しいものに捉えられがちですが、本セッションで実用化が進んでいることをお届けしました。 AWS 金融・決済関連 最新サービスのご紹介 技術セッションでは、AWS松原よりエージェンティック・コマースの定義と影響を体系的に発表しました。入力支援から完全自律型購買までエージェントのレベル分けと決済プロトコルの全体像を解説しました。 その上でAWSのサービスとして、USDCを利用したエージェントコマースの実現を支援する、買い手側のエージェント決済実装のための Amazon Bedrock AgentCore Payments と、売り手側リソースに支払いリクエストを追加する AWS Web Application Firewall (WAF) の機能を紹介しました。 決済プロトコルについては「エージェンティック・コマースのプロトコルが次々登場しているが、1つが全てを代替するものではなく相互に協調している」と述べ、AWSも決済プロトコルの領域において、x402 Foundation や UCP Tech Councilにメンバーとして参加し貢献していることを紹介しました。 Customer Lightning Session ― Frontier Builders、3社が語るAI実践知 三菱UFJニコス株式会社 ― クラウド活用のベストプラクティスと次の一手 三菱UFJニコス株式会社 システム基盤・運用部 共通システム基盤グループ 次長 中村 貴治 様には、DCカードとMUFGカードのシステム統合という大規模プロジェクトを乗り越えてきた経験と、次のステップとしてのAI活用について発表いただきました。 同社は2019年にAWSの利用を開始し、コロナ禍ではAmazon WorkSpacesを数ヶ月でリリースしました。2025年にはシステム統合プロジェクトで設置したお客様窓口でAmazon Connectを採用。ランニングコストの削減とともに、状況に応じたコールフローの迅速な変更を実現しました。導入にあたり社内に対してAWS担当者とともに説明を行い、約3ヶ月で導入を実現したエピソードは、多くの参加者の関心を集めていました。 今後に向けては、基幹システムのモダナイゼーションやAI活用を推進しています。AWS Transformを活用したリライト分析や、Kiroを活用したAI駆動開発の検証に取り組んでいます。また、AWS Security Agentを活用したソースコードレビューやペネトレーションテストの検証を進めており、新たな観点での評価できる可能性を確認しています。同サービスを検討・検証されている多くのご参加者からご関心が寄せられました。 SP.LINKS株式会社 ― CCoE主導のクラウド標準化とDevOps高度化の実践 SP.LINKS株式会社 IT Infrastructure Unit / Cloud Management1 Group 小柴 敦 様からは、ベンダー依存からの脱却と内製化推進のリアルな歩みを共有いただきました。 同社は決済代行事業を展開しており、2022年に決済サービスをオンプレミスからクラウドへ移行。CCoEを作り内製開発を推進してきました。参加者の多くがチャレンジしている、ベンダー委託の課題から脱却するために、クラウドネイティブな開発体制を構築した経緯を率直にお話しいただきました。 PCI DSS対象も含むシステムを内製で運用していくには統制が必要でしたが、サービス拡大の需要とのバランスが課題でした。そこで、AWS Professional Serviceサービスを活用して内製開発を安全に拡大するためのガイドラインや環境を整備しました。現在はAWS DevOps Agentを活用した問題調査の効率化、Kiroを用いたAI駆動開発の試行にも取り組んでいます。「標準化した知見をAIで活用し、DevOpsを高度化する」と紹介されたステップアップの道すじは、多くの企業が直面している「組織でAIをどう活用するか」のという課題へ示唆となる内容でした。 株式会社ネットプロテクションズ ― 顧客の「不安」を即時解決するAIサポート 株式会社ネットプロテクションズ AI Enablementグループ Enablement担当 田中 哉太 様には、後払い決済サービス「NP後払い」のコンタクトセンター業務にAIを活用した取り組みを発表いただきました。 支払い・請求に関する問い合わせに対して、FAQだけでは個人に合わせた回答ができず、データベースを参照した正確な回答が不可欠でした。しかしAIに直接SQLを生成させるとリスクが高いため、AWS Step Functionsで順序性を固定したフローを構築し、3段階のガードレール(①本人確認 ②DB参照成否チェック ③AIの自律判断)を配置しました。さらにヒューマン・イン・ザ・ループとして、DB参照を含む回答は必ず人間が確認してから送信する設計としました。 2026年8月のリリース後、対象カテゴリーにおいてAI回答率80%以上、うち60%はデータベース参照に成功という成果を達成。担当オペレーターからも他のカテゴリーに展開しても問題ないレベルという評価を得ています。一方で「フローの複雑化により、作成者本人でも全体像を追えなくなる」という率直な課題共有もありました。ハルシネーションという言葉が浸透してきていますが、実体験での取り組みや効果は参加者が直面する課題へのアクションにつながる内容でした。 Customer Panel Session ― Envisioning the Frontier、業界リーダーが描く決済の再定義 パネルディスカッションでは、株式会社インフキュリオン 代表取締役社長 CEO 丸山 弘毅 様、GMOペイメントゲートウェイ株式会社 専務執行役員 CTO 三谷 隆 様をパネリストに迎え、モデレーター：飯田 哲夫 様（株式会社ACSiON 社外取締役 兼 株式会社カンム 社外取締役）の進行により、4つのテーマで議論が交わされました。 テーマ1: エージェンティック・コマースの現在地 三谷様からは「エージェンティック・コマースでの取引は、B2B決済を中心にすでに広がってきている」というご体感、丸山様からは、自社で発表したエージェンティック・コマースのホワイトペーパーの反響と、すでにその内容を一般常識にしないといけない温度感になっていると双方より実体験をもとにした市場の勢いを共有されました。 テーマ2: 不正検知・セキュリティの新課題 三谷様は「AIエージェントはBOTに近い。これまではBOTをブロックする方向だったが、正しいBOTを判別する方向にルールチェンジが起きている」と見解を示されました。そして、正規のエージェントと悪意のあるBOTの判別が紙一重になっており、パケットレベルの監視が必要になるほど高度化していると述べました。 丸山様は「エージェントが本人のものかどうかの真正性、さらにマンデート（委任範囲）に沿っているかどうかの確認が最大の課題。」とコメント。チャージバックのルールやリスク負担ルールがまだ定まっていない現状の業界課題もあげられました。 テーマ3: 次世代決済プラットフォームに向けて（レジリエンス・AI駆動開発） 三谷様からは「入られる前提で考える」というサイバーセキュリティの方針転換について実践例が語られました。年に1回、経営陣向けのランサムウェア攻撃シミュレーションを実施しており、PCI DSSの再認証含めて考慮する必要があるという学びを共有されました。 丸山様からはAI駆動開発について、コーディング自体の効率化は進んでいるが、レビューは依然として人間が必要。求められる人材の質が変化してきているという見解を自社の経験から示されました。 テーマ4: 2030年のキャッシュレスビジョンとAWSへの要望 三谷様は「決済は気づかないうちに済ませておいてという世界。テクノロジーの観点では壁をなくして全日本で強くなりたい」と業界協力のビジョンを語りました。丸山様も同様に「テクノロジー面では業界全体で協力し、ビジネス面では競い合う。企業同士が協力して、表のコンシューマーには決済が見えなくても自由に取引ができる世界を作りたい」と呼応されました。 AWSへの要望としては、「グローバルで乱立するプロトコルを吸収できるレイヤーの役割」「政府に向けたクラウドの安全性の説明」「本イベントのような、企業の壁を越えた本音ベースのトークの場を続けてほしい」という率直な声をいただきました。ご登壇者の対話に加え、参加者からも質問が続き会場全体の熱意が感じられるセッションとなりました。 まとめ 本イベントではビジネス・IT両面のAIエージェントの活用について、一番大事なユースケースをお客様と深掘りました。懇親会でも社内や顧客向けに何が良くなるのかといった意見交換が活発にされ、ご参加者皆様の熱意を感じました。 AWSでは、差別化を生まない重労働をAWSに預けていただけるサービスを提供しています。AIエージェントをお客様が構築するにあたり、Amazon Bedrock AgentCore、さらには Amazon Bedrock AgentCore Payments や AWS WAF などのマネージドサービスを提供し、お客様の新たなビジネス創出を支援してまいります。 また、開発・運用に関しては、Kiro、AWS DevOps Agent、AWS Security Agentなどすぐにお使いいただけるフロンティアエージェントや、金融リファレンスアーキテクチャ日本版 をはじめとする実践的なコンテンツを提供し、各社のナレッジの体系化と金融システムにおけるミッションクリティカル領域の強化を支援いたします。 本イベントにご参加いただいた皆様、ご登壇いただいた皆様に改めて御礼申し上げます。今後もAWS Cashless Initiativeでは業種・業態の垣根を越えた対話と共創を通じて、新しい決済の未来を皆様と共に切り拓いてまいります。 関連ブログ 【開催報告】AWS Future of Money ～AI × ブロックチェーンが創る新金融エコシステム～ 金融リファレンスアーキテクチャ日本版 v2 リリース

みなさん、こんにちは。ソリューションアーキテクトの梅田です。 AWS Japan パブリックセクターチームでは、2026 年 4 月から、官公庁・自治体・教育・医療などパブリックセクターのお客様に向けて、セキュリティワークショップを月 1 回開催しています。これまでに「 ランサムウェア対策 」「 Claude Mythos 時代の脅威対策 」「 耐障害性ライフサイクル 」を取り上げてきました。第 6 回となる今回は、 AWS WAF を使った Web アプリケーションの防御をテーマにしました。本記事はその開催報告です。 ワークショップの概要 項目 内容 日時 2026 年 9 月 28 日（月）14:30 – 17:30 形式 オンライン 対象 システムアーキテクト、セキュリティ担当者、Web アプリケーション運用担当者 関連サービス AWS WAF, AWS Shield, Amazon CloudFront, Amazon Athena  構成は前半の座学と後半のハンズオンの 2 部です。座学では AWS WAF の仕組みと運用の考え方を解説し、ハンズオンでは WAF ルールの設定からログの分析までを実際に操作していただきました。講師はパブリックセクター 中央省庁担当のソリューションアーキテクト、伊藤 裕史が務めました。 座学: AWS WAF を活用した Web アプリケーションの保護 Bot は「止める」のではなく「見分ける」 Web のトラフィックのうち 30〜51% は、人間以外によるものだという調査があります。Bot の種類も変わってきました。以前からある検索エンジンのクローラーやスパム Bot に加えて、LLM の学習用にコンテンツを集める Bot や、人に代わってブラウジングや買い物をする AI エージェントが増えています。こうした Bot の中には、正規のものも悪意のあるものもあります。そのため「Bot だから止める」という一律の対応ではうまくいきません。種類ごとに適切なアクションを選ぶ必要があります。 図 1: Bot アクティビティの進化 マネージドルールとラベルで細かく制御する AWS WAF では、リクエストを検査するルールを Web ACL に設定します。ルールに一致したリクエストには、Allow、Block、Count、CAPTCHA、Challenge のいずれかのアクションを適用します。ルールを一から自作する必要はありません。AWS が管理・更新する マネージドルールグループ を有効にするだけで、SQL インジェクションやクロスサイトスクリプティングといった代表的な攻撃に対応できます。 Bot 対策には AWS WAF Bot Control ルールグループを使います。Bot Control は、逆引き DNS による検証や振る舞いの分析を組み合わせて、Bot が名乗っているとおりの「検証済みの Bot」かどうかを判別します。判別の結果はラベルとしてリクエストに付与され、後続のルールでそのラベルを条件に使えます。たとえば「利用している監視サービスの Bot は通し、それ以外の監視 Bot は止める」といった細かい制御ができます。 入れて終わりではなく、可視化しながら育てる ルールは、導入してしまえば終わりというものではありません。最初は Count で動かして影響を確かめ、誤検知がないことを確認してから Block に切り替えます。その後も監視を続け、結果に応じてルールを見直していきます。このサイクルを回すことが、WAF 運用の基本になります。 図 2: AWS WAF の運用全体像 運用を支える機能として、AWS WAF には組み込みのダッシュボードがあり、追加の設定なしで使えます。また、AI クローラーや AI エージェントからのアクセスに絞った AI トラフィック分析ダッシュボードも提供されています。このダッシュボードでは、650 以上の Bot とエージェントを識別し、それぞれのアクセス先や検証状況を一覧で確認できます。 図 3: AI トラフィック分析ダッシュボード 座学ではこのほかに、 AWS Shield の Standard と Advanced の違いも紹介しました。 ハンズオン: AWS WAF で Web アプリケーションの防御を強化する ハンズオンでは、公開教材「 AWS WAF を使って Web アプリケーションの防御を強化する 」を使いました。参加者ごとに用意した環境で、次の 3 つに取り組んでいただきました。 Count で動いているマネージドルールを Block に切り替え、SQL インジェクションやクロスサイトスクリプティングを防ぐ Bot Control とラベルを使ったカスタムルールで Bot を制御し、JSON 本文の検査で API への入力を検証する Amazon Athena で WAF のログを分析し、ブロックの多いルールや URI パスを特定する 環境には進捗ダッシュボードが用意されており、ルールを変更するとその効果がすぐに反映されます。 参加者からのフィードバック ハンズオンの難易度については、技術職の方のほとんどから「ちょうど良い」という回答をいただきました。質疑では、「生成 AI 経由の大量リクエストにマネージドな方法で対処できるか」という質問がありました。これに対しては、まず Bot Control が付与するラベルでアクセスの実態を把握し、悪意のない単一の送信元からのアクセスであればレートベースのルールで抑える、という考え方をご紹介しました。 まとめ 今回のワークショップでお伝えしたかったのは、次の 3 点です。 Bot を一律に止めず、種類を見分けて対応する マネージドルールを使って運用の負荷を抑える 可視化しながら、ルールを継続的に見直す 今後も、パブリックセクターのお客様に向けたセキュリティワークショップを引き続き開催していきます。開催が決まりましたら、あらためてご案内します。 AWS WAF の導入・運用や AI Bot への対策についてご相談がある場合は、担当の AWS アカウントチームまでお気軽にお問い合わせください。 著者 梅田 昌太 (Shota Umeda) — AWS Japan, Public Sector, Senior Solutions Architect 田村 健祐 (Kensuke Tamura) — AWS Japan, Public Sector, Solutions Architect