2026-03-19

【AWS】JAWS-UG 朝会で『OpenClaw を Amazon Lightsail で動かす理由』というタイトルで登壇しました

AWS

はいさい！クラウド事業部の上地やいびーん。

はじめに

2026年3月13日（金）に開催された JAWS-UG朝会 #79 で登壇してきました。

JAWS-UG朝会は、夜の勉強会に参加が難しい方向けに朝7:30から開催されているオンライン勉強会です。朝ごはんを食べながら、通勤しながらなど、何かをしながらの参加もOKというカジュアルな雰囲気が魅力です。

イベント概要

項目	内容
イベント名	JAWS-UG朝会 #79
日時	2026年3月13日（金）07:30〜
形式	オンライン
イベントページ	https://jawsug-asa.connpass.com/event/375345/

登壇資料

今回は 「OpenClaw を Amazon Lightsail で動かす理由」 というタイトルで発表しました。

https://speakerdeck.com/uechishingo/openclaw-wo-amazon-lightsail-dedong-kasuli-you

3行まとめ

OpenClaw は「対話型」から「自律実行型」へ進化した AI エージェント。メール整理や Web 情報収集など複雑なタスクを自律的に代行してくれる
動かす環境は自宅PC・EC2・Lightsail の3択。Lightsail はブループリントが用意されていて、少ない手順で起動でき、運用負荷も低い
Lightsail を選ぶ理由は「導入のしやすさ」「セキュリティのガードレール」「運用負荷の軽さ」「コストの見通し」の 4 点。小さく始めてクラウドで安定稼働させるのに最適

さいごに

最近は AI エージェントの進化が目まぐるしく、自律型エージェントを自分の環境で動かしたいというニーズが高まっています。その中で Amazon Lightsail は、手軽さと運用のバランスが取れた選択肢だと感じています。

JAWS-UG朝会は登壇者を通年で募集しています。AWS に関することであれば何でもOKとのことなので、気になる方はぜひ登壇してみてください。朝の短い時間（5 分）でカジュアルに発表できるので、登壇デビューにもおすすめです。

お知らせ

当社では、Datadog の導入支援から運用サポートまでをトータルでご支援するサービスを提供しています。

初期設計・エージェント展開・モニタリング設定・ダッシュボード構築まで、お客様のニーズに合わせた支援が可能です。

「自社だけでの導入が不安」「もっと効率的に監視環境を整えたい」という方は、ぜひお気軽にご相談ください。

www.ap-com.co.jp

一緒に働いていただける仲間も募集中です！

hrmos.co

投稿者: 上地申吾

Datadog の導入・運用のご支援を担当しています。

2026-02-05

【AWS】"AWS::SNS::TopicPolicy" と "AWS::SNS::TopicInlinePolicy" の違いをちゃんと知っておきたい

AWS CloudFormation

はじめに

こんにちは、クラウド事業部の坂口です。

先日 AWS CloudFormation での Amazon SNS (Simple Notification Service) のリソースタイプを眺めていたのですが、

SNSトピックポリシーに関連するリソースタイプが以下の2つあることにめちゃめちゃ今更気づきました。

AWS::SNS::TopicInlinePolicy
AWS::SNS::TopicPolicy

よくよく見ると違いは単純だったのですが、せっかくなのでブログとして残しておこうと思います。

※眺めていた AWS CloudFromation のAWSドキュメントページはこちら↓

docs.aws.amazon.com

結論

手っ取り早く、結論だけ書くと

とれる対象が 1対1 か 1対複数か の違いです。

AWS::SNS::TopicInlinePolicy では特定のトピックに対してのみトピックポリシーを適用するのに対して、

AWS::SNS::TopicPolicy では複数のトピックに共通のトピックポリシーを適用できます。

これはそれぞれのAWSドキュメントでもちゃんと書かれていて、

<AWS::SNS::TopicInlinePolicy>

(リソース定義)

Type: AWS::SNS::TopicInlinePolicy
Properties:
  PolicyDocument: Json
  TopicArn: String

(プロパティ)

TopicArn
The Amazon Resource Name (ARN) of the topic to which you want to add the policy.
︙
Type: String

<AWS::SNS::TopicPolicy>

(リソース定義)

Type: AWS::SNS::TopicPolicy
Properties:
  PolicyDocument: Json
  Topics: 
    - String

(プロパティ)

Topics
The Amazon Resource Names (ARN) of the topics to which you want to add the policy. You can use the Ref function to specify an AWS::SNS::Topic resource.
︙
Type: Array of String

AWS::SNS::TopicInlinePolicy では TopicArnプロパティで Topic の ARN を指定するのに対して、

AWS::SNS::TopicPolicy では Topicsプロパティで Topic の ARN を複数個リストで指定できるようになっています。

後者はプロパティの説明含めてばっちり複数形ですね！

捕捉なり確認なり

さて、以降は補足やついでで確認した内容をつらつらと記載していきます。

そもそもSNSトピックポリシーとは

SNSトピックポリシーは、トピックに対して、誰が Publish(発行) や Subscribe(購読) をしてよいか を定義しています。

いわゆる「リソースベースポリシー」です。

SNSトピックポリシーは、例えば以下のような用途などの時に必要になってきます。

クロスアカウントで接続したいとき：トピックポリシーで、外部のAWSアカウントからのアクセスを許可する
AWSサービスと連携したいとき：トピックポリシーで、例えばEventBridgeからメッセージを受け取るためのアクセスを許可する

AIに聴いてみた

せっかくなので、AWS::SNS::TopicInlinePolicy と AWS::SNS::TopicPolicy の違いについてAI (Gemini) にも聴いてみました。

※黒塗りしている箇所は、ついでに AWS::SNS::Topic の DataProtectionPolicyプロパティについて解説を求めていました。今回はノイズになるので黒塗りしています

Gemini くん ...。

AWS::SNS::TopicInlinePolicy はいつ頃追加されたの？

AWS::SNS::TopicInlinePolicy が新しいリソースとして追加されたのは、CloudFroamtionのAWSドキュメント上では 2023年8月2日らしいです。

(Document history より)

あくまでリリースではなくドキュメントでの更新情報ですが、時期的には大体この辺に使えるようになったんだと思います。

おわりに

今回は、AWS CloudFormationでの AWS::SNS::TopicInlinePolicy と AWS::SNS::TopicPolicy について記載しました。

IaCといっても、最近はなかなかCloudFormationテンプレートでリソースを定義する機会は減ってきているかもしれませんが、ふとした時にパッと確認できる情報があったら嬉しい気がしたので書いてみています。

この記事がどなたかの参考になれば幸いです。

それではご機嫌なAWSライフを！

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: さかぐち
AWSをメインにインフラ系のご支援を担当しています。 OCIにも少しずつ手を出し中。

2026-02-01

S3レプリケーション完了をトリガーにLambdaでファイルを日付リネームする

AWS Lambda S3

S3レプリケーション完了をトリガーにLambdaでファイルを日付リネームする自動化

はじめに

こんにちは、クラウド事業部の松岡です。インフラエンジニア3年目、AWS経験3か月の私が、S3のレプリケーション機能とEventBridge + Lambdaを組み合わせて、同期されたファイルを自動で整理（日付リネーム）する仕組みを構築しました。

「AWSの複数リソースを組み合わせて触ってみたい」という初級〜中級者の方に向けて、実務で意識すべき最小権限の原則を含めた手順を紹介します。

システム構成図

本構成では、S3間のレプリケーションが完了したことをEventBridgeで検知し、即座にLambdaがファイル名を変更して特定のディレクトリへ整理する仕組みを採用しています。

処理の流れ

アップロード: ユーザーが filetransfer-dev-source-bucket へファイルを配置。
同期: S3のレプリケーション機能により filetransfer-dev-destination-bucket へ自動コピー。
検知: EventBridgeが送信先バケットへの配置（Object Created）をリアルタイムで検知。
リネーム: Lambdaが起動。配置時間をファイル名に付与し、processed/ ディレクトリへ移動。

構築リソース一覧

リソース名は {systemname}-{Env}-{Resourcename} の規則に従い、管理を容易にしています。

下記にYAMLファイルを配置しているので必要でしたらご利用ください

https://github.com/tmatusoka-apc/s3-filetransfer.git

カテゴリ	リソース名	備考
S3 (Source)	`filetransfer-dev-source-bucket`	バージョニング有効 / レプリケーション元
S3 (Dest)	`filetransfer-dev-destination-bucket`	バージョニング有効 / EventBridge通知有効
EventBridge	`filetransfer-dev-s3-put-rule`	`Object Created` イベントを監視
Lambda	`filetransfer-dev-rename-function`	Python 3.12 / 無限ループ防止実装済み
IAM Role	`filetransfer-dev-replication-role`	S3間のコピー権限（最小権限）
IAM Role	`filetransfer-dev-lambda-role`	送信先S3の操作とログ出力権限

1. S3レプリケーションの設定

S3間のデータ同期を安全に行うための設定です。

設定のポイント

バージョニング: レプリケーションの必須要件のため、両バケットで有効化します。
最小権限のIAMロール:
- s3.amazonaws.com を信頼ポリシーに設定。
- 許可ポリシーでは、Sourceからの GetObject と Destinationへの ReplicateObject に限定して記述します。

2. Lambdaによるファイル転送の実装

EventBridgeから起動されるLambdaを構築します。

権限周りの設計

本番環境を意識し、以下の権限を持つIAMロールを作成します。 * S3: GetObject, PutObject, DeleteObject（送信先バケットのみ）。 * CloudWatch Logs: 実行ログ（/aws/lambda/filetransfer-dev-rename-function）の書き込み権限。

Lambdaコード（抜粋）

S3には「リネーム」コマンドが存在しないため、「コピー＋削除」の手順を踏みます。

import boto3
import os
from datetime import datetime

s3 = boto3.client('s3')

def lambda_handler(event, context):
    bucket = event['detail']['bucket']['name']
    old_key = event['detail']['object']['key']
    
    # 無限ループ防止: 既に処理済みディレクトリにある場合はスキップ
    if old_key.startswith('processed/'):
        return

    # 配置された時間を取得（YYYYMMDD-HHMMSS形式）
    timestamp = datetime.now().strftime('%Y%m%d-%H%M%S')
    new_key = f"processed/{timestamp}_{os.path.basename(old_key)}"
    
    print(f"Moving: {old_key} -> {new_key}")
    
    # 同一バケット内でのコピー＆元のオブジェクト削除
    s3.copy_object(
        Bucket=bucket,
        CopySource={'Bucket': bucket, 'Key': old_key},
        Key=new_key
    )
    s3.delete_object(Bucket=bucket, Key=old_key)
    
    return {"status": "success"}

3. 実行確認

Sourceへアップロード: test.png をアップロード。
レプリケーション確認: Destinationへ test.png が届くのを確認。
CloudWatch Logsを確認: Lambdaが正常に起動し、Moving... のログが出ているかチェック。
最終結果: Destinationの processed/ 配下に 20260129-120000_test.png が生成され、元のファイルが消えていれば成功。

おわりに

インフラエンジニアとして、単に「動く」だけでなく、「権限が適切か」「後で削除や変更がしやすい命名規則になっているか」を意識した構築を心がけました。

今後は、エラー発生時にSNSで通知する仕組みや、Step Functionsを用いたより複雑なワークフローにも挑戦してみたいと思います。

2026-02-01

CloudFormationのドキュメント更新を自動化する「cfn-docs」を触ってみた

aws #python IaC

はじめに

こんにちは、クラウド事業部の松岡です。 CloudFormationのテンプレート管理において、ドキュメントの鮮度を保つことは意外と難しいものです。
本記事では、テンプレートからMarkdown形式のドキュメントを自動生成できるツール 「cfn-docs」 を実際に触ってみた内容をまとめています。

対象読者

AWS経験が数ヶ月で、複数リソースの構築に挑戦したい方
IaC（Infrastructure as Code）のドキュメント保守を自動化したい方

解説のポイント

実務を想定した最小権限のIAM設定
運用の手間を減らすリソース管理方法
CloudFormationテンプレートの可視化によるレビュー効率化

cfn-docsとは？

cfn-docs は、AWS CloudFormation (Cfn) のテンプレートファイル（YAML/JSON）から、Markdown形式のドキュメントを自動生成してくれるコマンドラインツールです。

通常、CloudFormationのコードを読むには各リソースの定義を深く読み込む必要がありますが、cfn-docsを使うことで、誰でも読みやすい構成図のような「ドキュメント」として書き出すことができます。

主な特徴

Markdown出力
GitHub、Qiita、Notionなどでそのまま利用できる形式で出力されます。
メタデータの抽出
Description、Parameters、Outputs などの情報を表形式で整理してくれます。
リソースの可視化
テンプレートに含まれるリソース一覧を自動でリストアップ。

なぜ使うのか？（導入のメリット）

コードとドキュメントの乖離を防ぐ
自動生成により、常に最新のテンプレートに基づいたドキュメントを維持できます。
レビューの効率化
Parameters や Outputs が一覧化され、インフラ全体像を素早く把握できます。
チーム共有のコスト削減
エンジニア以外の担当者にも説明しやすいMarkdown形式で共有できます。

事前準備

1. 既存のIaCテンプレートを取得

例：test-ecs-traffic-change-lambda.yml

参考：https://github.com/tmatusoka-apc/Public/blob/main/blog/cfn-docs/test-ecs-traffic-change-lambda.yml

2. cfn-docgen のインストール

参考：https://pypi.org/project/cfn-docgen/

3. CloudShellの場合：Pythonを3.10以上にアップデート

※cfn-docgen の仕様のため
参考：https://qiita.com/minorun365/items/baa5038b5bfa4e35f6ad

実施手順

0. 事前準備を完了させる

・パッケージダウンロード・テンプレートファイルを指定ディレクトリに配置

1. コマンドを実行

cfn-docgen docgen \
    --format markdown \
    --source <IaCテンプレート> \
    --dest <出力先ディレクトリ>

2. 出力結果をダウンロードして確認する

触ってみて感じたこと・わかったこと

生成AIが使えない環境でも、詳細設計に落とし込む際に便利
AWSコンソール（AWS UI）からコピペするより圧倒的に楽にドキュメント化できる

感想（個人の見解です）

カスタムフォーマットがもっと気軽に使えると嬉しい
→ カスタム可能な参考サイトはあるが、指定フォーマットに落とし込むには工夫が必要
https://github.com/horietakehiro/cfn-docgen/blob/master/docs/custom-specification.json
一部フォーマットとリソースが異なる場合がある
※今回の場合は Lambda などで差異を確認

ほかの方法も調べてみる

調査を進めると、AWS公式の Bedrock などでも似たようなことが実現できそうなサービスがあることが分かりました。
用途に応じてツールを使い分けるのも良さそうです。

2026-01-22

【AWS】JAWS-UG 沖縄支部で『AWS監視を「もっと楽する」ために』というタイトルで登壇しました

AWS

はいさい！クラウド事業部の上地やいびーん。

はじめに

2026 年 1 月 17 日に JAWS-UG 沖縄支部の勉強会を開催しました！私自身も運営メンバーとして企画し、登壇もさせていただきました。

沖縄と言えば「那覇」を最初に思い浮かべる方も多いと思います。実は那覇市での開催は今回が初めてなんです。これまでは那覇市から少し離れた宜野湾市での開催でした。今回はモノレールなど公共交通機関の便が良いおかげか、初めて参加される方も多く（合わせて 30 名！！）、非常に活気がありました。 jawsug-okinawa.connpass.com

イベント概要

今回の勉強会のテーマは、昨年 12 月にラスベガスで開催された AWS の年次カンファレンス「AWS re:Invent」の re:Cap（おさらい）です。冒頭、参加者の皆さんに挙手してもらったところ、沖縄からラスベガスへ現地参加された方はまだまだ少ない様子……。私自身も「今年こそはラスベガスに行きたい！」と強く思いました。

登壇資料

勉強会のタイトルに「re:Cap」が入っていますが、先述の通り、私は現地には行けてません。そこで今回は、re:Invent といえば毎年恒例となっている「Datadog の滑り台」にちなみ、Amazon CloudWatch と Datadog の比較についてお話ししました。

タイトルは『AWS監視を「もっと楽する」ために』です。

https://speakerdeck.com/uechishingo/awsjian-shi-wo-motutole-suru-tameni

3行まとめ

CloudWatchは「データの収集・保管場所」
Datadogは「日々の監視・調査ツール」
「Datadogで気づき、深堀する」のがおすすめ

さいごに

次回の JAWS-UG 沖縄支部の勉強会は、 4 月の後半に大人気企画「Cloud on the BEACH」を予定しています！

コロナ禍を経て一昨年から再開したのですが、毎回すぐに定員オーバーになってしまうほどの人気イベントです。「今年こそは参加したい！」という方は、私の X（旧Twitter）をフォローしていただくと、募集開始のタイミングに気づきやすいかもしれません。

勉強会の部では、今回強い要望があった Agent Core のハンズオンを実施予定しています。

2025 年の Cloud on the BEACH（勉強会の部） jawsug-okinawa.connpass.com

2025 年の Cloud on the BEACH（ビーチパーティの部） jawsug-okinawa.connpass.com

お知らせ

当社では、Datadog の導入支援から運用サポートまでをトータルでご支援するサービスを提供しています。

初期設計・エージェント展開・モニタリング設定・ダッシュボード構築まで、お客様のニーズに合わせた支援が可能です。

「自社だけでの導入が不安」「もっと効率的に監視環境を整えたい」という方は、ぜひお気軽にご相談ください。

www.ap-com.co.jp

一緒に働いていただける仲間も募集中です！

hrmos.co

投稿者: 上地申吾

Datadog の導入・運用のご支援を担当しています。

2025-12-23

S3 × EventBridge × Lambda の連携手順

AWS

はじめに

こんにちは、株式会社エーピーコミュニケーションズの西村です。
今回はS3にファイルを置くとLambdaが動くシンプルな構成を作成しました。

構成図

手順

1.Lambda関数を作成する。

基本的な情報には以下の値を入力する。

オプション：一から作成
関数名：<任意>
ランタイム：Python3.12
アーキテクチャ：x86_64

コードソースにコードを張り付けdeployをクリックする。

※サンプルコード　

def lambda_handler(event, context):
    # 1. 届いたデータの中から「バケット名（フォルダ名）」を取り出す
    bucket = event['detail']['bucket']['name']
    
    # 2. 届いたデータの中から「ファイル名」を取り出す
    file_name = event['detail']['object']['key']
    
    # 3. 画面（ログ）に「〇〇というバケットに、△△というファイルが届いたよ！」と表示する
    print(f"S3にファイルが届きました！")
    print(f"場所：{bucket}")
    print(f"名前：{file_name}")

    # 4. 最後に「無事に終わったよ」という合図を送る
    return "完了！"

2.S3バケットを作成する

一般的な設定には以下の値を入力する。

バケットタイプ：汎用
バケット名：任意

プロパティをクリックする。

Amazon Event Bridgeセクションで編集をクリックする。

Amazon Event Bridgeの通知の送信をonにする。

3.EventBridgeを作成する

トリガーイベントにS3のObject Createdを設定する。
※bucketnameは作成したS3バケット名を設定してください。

ターゲットにLamda関数を設定する。

作成をクリックすると画面が表示されるため任意のRule nameを入力して作成する。

4.テストを実施する

S3にテスト用のファイルをアップロードする。

LamdaのモニタリングからCloudwatchログを表示をクリックする。

対象のログストリームをクリックする。

Lamda関数に設定した内容がログから確認できる。

2025-12-18

NLB→ALB→ECS構成を作成してみた

AWS

はじめに

こんにちは、株式会社エーピーコミュニケーションズの西村です。
今回はNLB→ALB→ECS構成の作成手順を紹介します。
本来この構成はNLBで固定IPアドレスを用いたドメインの紐づけやALBのリスナールールを使った通信の振り分けが利点としてありますが今回は構成の作成方法のみの学習のため省略します。

構成図

前提条件

VPC ×1
アベイラビリティゾーン ×1
パブリックサブネット ×2

手順

1.セキュリティグループの作成

1-1.NLB用のセキュリティグループを作成する。

基本的な詳細には以下の値を入力する。

セキュリティグループ名：NLB-sg
説明：Security Group for NLB
VPC：事前に作成したVPCを選択する

インバウンドルールには以下の値を入力してセキュリティグループを作成をクリックする。
※インバウンドルール入力後にアウトバウンドルールは自動で作成される。

タイプ：すべてのTCP
ソース：Anywhere-IPv4

1-2.ALB用のセキュリティグループを作成する。

基本的な詳細には以下の値を入力する。

セキュリティグループ名：ALB-sg
説明：Security Group for ALB
VPC：事前に作成したVPCを選択する

タイプ：HTTP
ソース：カスタム NLB-sg

1-3.ECS用のセキュリティグループを作成する。

基本的な詳細には以下の値を入力する。

セキュリティグループ名：ECS-sg
説明：Security Group for ECS
VPC：事前に作成したVPCを選択する

タイプ：HTTP
ソース：カスタム ALB-sg

2.ECSの作成

2-1.クラスターを作成する。

クラスターの作成には以下の値を入力しする。

クラスター名：Test-cluster

インフラストラクチャには以下の値を選択し作成 をクリックする。

コンピューティングキャパシティの取得方法を選択：Fargateのみ

2-2.タスク定義を作成する。

タスク定義の設定には以下の値を入力する。

タスク定義ファミリー：Test-task-definition

インフラストラクチャの要件には以下の値を選択する。

起動タイプ：AWS Fargate

※他の設定はデフォルトのままとします。

コンテナの詳細には以下の値を入力し作成をクリックする。

名前：Test-container
イメージURI：amazon/amazon-ecs-sample ※コンテナのイメージURIにはAWSが用意したコンテナイメージのサンプルを指定します。

2-3.サービスを作成する。

サービスの詳細には以下の値を入力する。

タスク定義ファミリー：Test-task-definition
サービス名：Test-task-definition-service

環境には以下の値を選択する。

コンピューティングオプションー：キャパシティプロバイダー戦略 ※ここは起動タイプでも問題ありません。

デプロイには以下の値を選択する。

スケジューリング戦略：レプリカ

ネットワーキングには以下の値を選択する。

VPC：事前に作成したVPC
サブネット：事前に作成したパブリックサブネット
セキュリティグループ名：ECS-sg

2-4.作成されたタスクの確認

Amazon Elastic Container Service > クラスター > Test-cluster > タスク > 作成されたタスクをクリックしプライベートIPを確認する。

3.ターゲットグループとロードバランサーの作成

※設定の都合上ターゲットグループ→LBの作成を交互に行います。

3-1.ECSへ向けたターゲットグループを作成する。

設定には以下の値を入力する。

ターゲットの種類：IPアドレス
ターゲットグループ名：Target-ECS
プロトコルHTTP
ポート：80
IPアドレスタイプ：IPv4
VPC：事前に作成したVPC
プロトコルバージョン：HTTP1

IPアドレスには以下の値を入力する。

ネットワーク：事前に作成したVPC
VPCサブネットからのIPv4アドレスを入力します。：2-4で確認したプライベートIP

設定を確認しターゲットグループの作成をクリックする。

3-2.ALBを作成する。

基本的な設定には以下の値を入力する。

ロードバランサー名：Test-alb
スキーム：インターネット向け
ロードバランサーのIPアドレスタイプ：IPv4

ネットワーキングマッピングには以下の値を入力する。

VPC：事前に作成したVPC
アベイラビリティゾーンとサブネット：事前に作成したパブリックサブネット

セキュリティグループには以下の値を入力する。

セキュリティグループ：ALB-sg

リスナーとルーティングには以下の値を入力する。

プロトコル：HTTP
ポート：80
アクションのルーティング：ターゲットグループへ転送
ターゲットグループ：Target-ECS

設定を確認しロードバランサーの作成をクリックする。

3-3.ALBへ向けたターゲットグループを作成する。

設定には以下の値を入力する。

ターゲットの種類：Application Load Balancer
ターゲットグループ名：Target-alb
プロトコルTCP
ポート：80
VPC：事前に作成したVPC

ターゲットを登録には以下の値を入力する。

Application Load Balancer を登録：今すぐ登録
ポート：ターゲットグループポート 80を使用
Application Load Balancer：Test-alb

設定を確認しロードバランサーの作成をクリックする。

3-4.NLBを作成する。

基本的な設定には以下の値を入力する。

ロードバランサー名：Test-nlb
スキーム：インターネット向け
ロードバランサーのIPアドレスタイプ：IPv4

ネットワーキングマッピングには以下の値を入力する。

VPC：事前に作成したVPC
アベイラビリティゾーンとサブネット：事前に作成したパブリックサブネット
IPv4アドレス：AWSによって割り当て済み

セキュリティグループには以下の値を入力する。

セキュリティグループ：NLB-sg

リスナーとルーティングには以下の値を入力する。

プロトコル：TCP
ポート：80
ターゲットグループ：Target-alb

設定を確認しロードバランサーの作成をクリックする。

4.ECSで作成したコンテナ上のWebサイトにアクセスする

4-1.作成したNLBからDNS名をブラウザに入力し以下の画面が表示されることを確認する。

2025-12-03

AWS Cost Explorer の分析を Cline に丸投げしてみた

AWS

はじめに
Cline の設定
MCP Server 登録
コスト分析と「MFAの壁」
終わりに
お知らせ

はじめに

こちらはエーピーコミュニケーションズ Advent Calendar 2025 3日目の記事です！

こんにちは、クラウド事業部の梅本です。

今回は Cline (VSCode) × MCP × AWS Cost Explorer を組み合わせて、AWS のコスト解析作業を AI に 「丸投げ」 してみようと思います。

具体的には、最近話題の自律型 AI エージェント Cline に、マネジメントコンソールを開くことなく AWS Cost Explorer のデータを分析してもらいます。

本記事で登場する技術の位置づけは以下の通りです。

Cline (VSCode拡張機能): 本記事の「主役」です。コードを書くだけでなく、コマンド実行やファイル操作も自律的に行う AI エージェント。今回は彼に分析の指示を出します。
MCP (Model Context Protocol): 本記事の「カギ」となる技術です。AI モデルと外部サービス（今回は AWS）を標準的な方法で接続するためのプロトコル。これを使うことで、Cline が AWS のデータを安全かつスムーズに扱えるようになります。
AWS Cost Explorer: 今回の「分析対象」です。通常はコンソールや CLI から叩くものですが、今回は MCP サーバー経由で Cline に直接参照させます。

つまり、「MCP という共通言語を使って、Cline（AI）に AWS Cost Explorer（データ）を直接見に行ってもらう」というアプローチです。

それでは、早速環境を作っていきましょう！

Cline の設定

まずはベースとなる環境の準備です。 VSCode および Cline 拡張機能のインストール手順については、本記事では割愛します。未導入の方は以下よりインストールしてください。

marketplace.visualstudio.com

Cline から AWS を操作する際の認証には、以前の記事で紹介した AWS Profile + MFA セッショントークンを利用する方法を採用しています。これにより、MFA (多要素認証) を必須としている環境でも、安全に Cline に権限を渡すことができます。

techblog.ap-com.co.jp

設定画面は以下の通りです。

今回の実行環境とモデルは以下の通りです。

ソフトウェアバージョン
- VSCode : 1.106.3
- Cline : 3.39.0
AI Model Settings
- Provider : Amazon Bedrock
- Model : Claude 4.5 Haiku

MCP Server 登録

さて、MCP (Model Context Protocol) で AI に外部ツールを使わせるためには、AI とツールの間を取り持つ「MCP Server」という仲介役プログラムを動かす必要があります。今回は AWS Cost Explorer を扱いたいので、AWS と対話できる MCP Server を手元の PC で起動しておく必要があります。

本来であれば、AWS Labs が公開している公式リポジトリの手順に従い、設定ファイル ( cline_mcp_settings.json ) を自分で書き換えてセットアップしていきます。

github.com

しかし、今回は「サクッと」進めるために、Cline の Marketplace 機能を頼ることにしました。 Cline の画面にある「MCP Servers」タブから Cost Explorer そのものズバリなサーバーが見つかります。

インストールボタンを押し、Cline にセットアップを任せてみました。最初はREADMEを読んで順調だったのですが...

どうやら様子がおかしいです。処理が進んでいるようでいて、肝心の環境構築が完了せず、エラーや確認待ちで止まってしまいました。

ログをよく見てみると、この MCP Server を動かすために必要な Python のパッケージ管理ツール uv が、私の端末に入っていなかったようです。 Cline はインストールしようとしてくれたものの、権限や環境の都合でうまくいかなかった模様。

そこで、手動で PowerShell を開き、uv をインストールして助け舟を出します。

PS> powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Downloading uv 0.9.14 (x86_64-pc-windows-msvc)
Installing to C:\Users\t_umemoto_ap-com\.local\bin
  uv.exe
  uvx.exe
  uvw.exe
everything's installed!

uv のインストールが完了した後、Cline の画面に戻り「Proceed Anyways（とにかく続ける）」をクリックして、先ほどの続きを行わせます。

何度か「Proceed Anyways」で背中を押し、試行錯誤してもらった結果...

設定ファイルを書き換えてもらい、

なんとか動くところまでできました。

コスト分析と「MFAの壁」

環境準備が整ったので、意気揚々と Cline に AWS のコストを聞いてみます。ここからは VSCode のチャット欄に自然言語で指示を出していきます。

まずは手始めに、シンプルに先月の利用料を聞いてみました。

プロンプト:

先月のAWSのコストを教えてください。

しかし、返ってきたのはエラーメッセージでした。

"error": "AWS Cost Explorer API error: ... explicit deny in an identity-based policy"

これは MFA 必須環境でよくある躓きポイントです。MCP Server の設定が、MFA 認証を経ていない default Profile を参照していたことが原因でした。Cline に依頼して Profile を書き換えてもらい、再度実行します。

プロンプト:

cline_mcp_settings.json の cost-explorer の設定にある AWS プロファイルを、default から mfa に変更してください。その後、MCP サーバーを再起動して、もう一度コスト分析を試みてください。

今度こそ成功しました。Cline は単に合計金額を返すだけでなく、内訳まで自律的に分析して提示してくれました。おかげで、段階的に深掘りしようと考えていた追加の指示も不要になりました。

最後に、この分析結果をレポートにして作成してもらいます。

プロンプト:

この分析結果をふまえてレポートをMarkdown形式で作成してください。ファイル名は cost_report_202511.md

Cline は瞬時に要点をまとめ、Markdown ファイルを生成してくれました。

作成されたレポートには、合計コストだけでなく、主要なコスト要因や必要に応じてテーブルまで綺麗に整形されていました。マネジメントコンソールを開いてコピペして回る手間が、たった数行のチャットで完結しました。

終わりに

今回は Cline × MCP × AWS Cost Explorer を組み合わせて、VSCode から一歩も出ずに AWS のコスト分析を行ってみました。

MCP は非常に強力であり、自然言語で AWS のデータを自在に引き出すことができました。また、「コスト教えて」と言うだけで、勝手に内訳を分析し、「レポート書いて」と言えばファイルまで作ってくれる自律性には驚かされました。

ただ、便利な反面、uv コマンドの有無や MFA 認証の壁など、環境周りではまだ人間のサポート（トラブルシューティング）が必要な場面もありました。

しかし、一度環境が整ってしまえば、毎月の面倒なコスト確認作業が 「Cline、先月のレポート作っといて」 の一言で終わる未来が見えました。皆さんもぜひ、明日の業務効率化のために MCP 環境を整えてみてはいかがでしょうか。

引き続きエーピーコミュニケーションズ Advent Calendar 2025 をお楽しみください！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

一緒に働いていただける仲間も募集中です！今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

hrmos.co

本記事の投稿者: t-umemoto
コンテナや k8s をメインにインフラ系のご支援を担当しています。
更新が滞っている Qiita や Zenn はこちら。

2025-12-01

【AWS】GithubActionsでCDKデプロイをやってみる

AWS

はじめに

こんにちは、クラウド事業部の上村です。
GithubActionsを使ってCDKをデプロイする機会があったので試してみます。

どんなひとに読んで欲しい

GithubActionsでとりあえずCICDを試したい人
CDKでCICDを利用したい人

事前準備

Githubアカウント CDK環境の準備リポジトリの作成

CDK 初期セットアップ

mkdir cdk-githubactions-test && cd cdk-githubactions-test
cdk init app --language typescript
cdk boostrap

Boostrapで生成されるロールについて

Boostrapで生成される4つのロールは各役割があります。
デプロイ時の権限移譲は下記のようになります。 1.アクターがcdk-deploy-roleを引き受け(AssumeRole)を行います
2.cdk-deploy-role は、管理者権限を持つ cfn-exec-role を iam:PassRole で CloudFormation サービスに渡します。
3.CloudFormation サービスが cfn-exec-role を引き受け (AssumeRole)、実際のデプロイ処理を実行します。

セキュリティを向上させたい場合は、Boostrapで生成されるデフォルト修飾子(hnb659fds)の変更や
Permissions BoundaryやSCPを利用してガードレールで担保しておくことも有効かと思います。

詳細は下記リンクを参照してください。
https://github.com/aws/aws-cdk/wiki/Security-And-Safety-Dev-Guide

GithubActions用のロール/ポリシーの作成

今回はシンプルにBoostrapで生成したロールを利用します。
またmainブランチを対象とします。
branchに制限を行う場合は、oidcDeployRole及びworkflowの調整が必要となります。
注意点としてプロバイダーURLはアカウント内でユニークである必要があり、既に存在する場合はエラーとなるので注意してください。

lib/cdk-githubactions-test-stack.ts

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as s3 from 'aws-cdk-lib/aws-s3';


export class CdkGithubactionsTestStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    
    const accountId = this.account;
    const region = this.region;
    // 各gihhub情報を入力してください。
    const user = 'userName';
    const repo = 'repoName';
    const branch = 'main';
    
    const oidcProvider = new iam.OpenIdConnectProvider(this,'GithubOIDCProvider',
       {
         url: 'https://token.actions.githubusercontent.com',
         clientIds: ['sts.amazonaws.com'],
       }
    );
        
    const oidcDeployRole = new iam.Role(this, 'GithubOidcRole',{
      roleName: 'github-oidc-role',
      assumedBy: new iam.FederatedPrincipal(
        oidcProvider.openIdConnectProviderArn,
        {
          StringLike: {
            'token.actions.githubusercontent.com:sub': `repo:${user}/${repo}:*`,
            // 'token.actions.githubusercontent.com:sub': `repo:${user}/${repo}:ref:refs/heads/${branch}`,
          },
        },
        'sts:AssumeRoleWithWebIdentity'
      ),
    });
    
    const deployPolicy = new iam.Policy(this, 'deployPolicy', {
      policyName: 'deployPolicy',
      statements: [
        new iam.PolicyStatement({
          effect: iam.Effect.ALLOW,
          actions: ['sts:AssumeRole'],
          resources: [
            `arn:aws:iam::${accountId}:role/cdk-hnb659fds-deploy-role-${accountId}-${region}`,
            `arn:aws:iam::${accountId}:role/cdk-hnb659fds-file-publishing-role-${accountId}-${region}`,
            `arn:aws:iam::${accountId}:role/cdk-hnb659fds-image-publishing-role-${accountId}-${region}`,
            `arn:aws:iam::${accountId}:role/cdk-hnb659fds-lookup-role-${accountId}-${region}`,
          ],
        }),
      ],
    });
    oidcDeployRole.attachInlinePolicy(deployPolicy);
  } 
  // RoleArn Output
  new cdk.CfnOutput(this, 'RoleArn', {
    value: oidcDeployRole.roleArn,
  });

}

bin/cdk-githubactions-test.ts

import * as cdk from 'aws-cdk-lib';
import { CdkGithubactionsTestStack } from '../lib/cdk-githubactions-test-stack';
import 'source-map-support/register';

const app = new cdk.App();
const env = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: process.env.CDK_DEFAULT_REGION,
};

new CdkGithubactionsTestStack(app, 'CdkGithubactionsTestStack', {
  env: env  
});

ロールやOIDCプロバイダーをデプロイします。

cdk deploy

githubActions workflow用ファイルの作成

workflow用のファイルを作成します。
Push実行時には cdk deploy が実行され、PR実行時には cdk diff が実行されるように設定します。

.github/workflows/deploy.yml

name: CDK

# mainブランチにプッシュ時にトリガー
on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main
  workflow_dispatch:

# OIDC設定
permissions:
  id-token: write
  contents: read
  pull-requests: write
    
jobs:
  cdk-deploy:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
              
      - name: Install dependencies
        run: npm ci
            
      - name: CDK Deploy
        run: npx cdk deploy --all --require-approval never           
            
  cdk-diff: 
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
    
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: CDK Diff
        run: npx cdk diff --all

Secretの設定

workflowが環境変数を参照できるように設定を行います。
今回はシークレットに下記を登録して利用するようにします。
ロールARNは、コンソール又はCDKデプロイ時に出力されたものを登録してください。

AWS_REGION: ap-northeast-1
AWS_ROLE_TO_ASSUME: arn:aws:xxx

動作確認

Push時の動作確認を進めていきます。
S3を作成するコードを追加して、githubにPushします。

lib/cdk-githubactions-test-stack.ts

  // RoleArn Output
  new cdk.CfnOutput(this, 'RoleArn', {
    value: oidcDeployRole.roleArn,
  });
  //add s3
  const s3bucket = new s3.Bucket(this, 'testBucket', {
  });

Githubから確認するとDeployが実行されていることが確認できました。
CDK Deployの箇所を確認するとログを確認することができます。

次はPR作成時の動作確認をします。
今回はコンソールで進めていきます。
ブランチの作成を行います。

先程追加したS3バケット作成部分を削除します。

変更後にPRリクエスト作成を行うとcdk diff が実行されていることが確認できます。

おわりに

初めてGithubActionsを利用しましたが簡単に設定できました。
cdk-nagやtrivyなどを組み込んだケースも試してみようかと思います。

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

2025-11-20

【AWS】ハンズオン「サーバーのモニタリングの基本を学ぼう」（CloudWatch）にチャレンジ！(後編)

AWS 学習

はじめに

こんにちは、クラウド事業部の木幡です。

「AWS Hands-on for Beginners 監視編」やってみたブログの後編です。

前編では、メトリクスの確認、アラーム設定、そしてログ分析までを行いました。
後編では、それらの情報を集約して「監視ダッシュボード」を作成し、さらにシステムの状態変化（イベント）を検知する設定を行っていきます。

どんなひとに読んで欲しい

AWS SAAの認定試験を勉強中で、CloudWatchの実践的な理解を深めたい人
AWSを使い始めたけれど、「監視」と言われても何から手をつければいいか分からない人
EC2インスタンスは立てたことがあるけど、CloudWatchのコンソールはあまり触ったことがない人
公式ハンズオンの動画や資料は見たものの、一人で実践するのが少し不安な人

前提

この記事は、AWS公式のハンズオン資料「AWS Hands-on for Beginners 監視編」を基に、私の学習体験をまとめたものです。
ハンズオンでは、以下の図のような一般的なWebシステムの構成を、CloudFormationテンプレートを使って自動で構築します。

構成図

VPC内にMulti-AZ(1a, 1c)で構成されています。
ALB(Application Load Balancer)がパブリックサブネットに配置され、トラフィックを2台のEC2インスタンスに振り分けます。
データベース(RDS)もMulti-AZで、プライベートサブネットに配置されています。
まさにSAAの試験対策で学ぶ、耐障害性とセキュリティを考慮した基本的な構成です。
この構成を「監視する」という体験ができるのは、非常に実践的だと感じました。

手順

[ハンズオン⑤]：WordPressの監視ダッシュボード作成

いよいよ集大成です。
これまで見てきた「メトリクス」「アラーム」「ログ分析結果」を、1つの画面にまとめて可視化します。

1.CloudWatchコンソール操作

「ダッシュボード」→「ダッシュボードの作成」をクリック。

2.ダッシュボード名: `WordPress_dashboard` と入力し、作成

3.「ウィジェットの追加」画面が表示

4.ウィジェット1：EC2のCPU（メトリクス）

「折れ線」を選択 → 「メトリクス」を選択。
AWS/EC2 → インスタンス別メトリクス から、2台のEC2インスタンス（WebServer01とWebServer02）の CPUUtilization を両方選択します。
「ウィジェットの作成」をクリック。
　これで、2台のEC2のCPU使用率が1つのグラフにまとまりました。

5.ウィジェット2：ディスク使用率（アラーム）

「ウィジェットの追加」→「アラーム」を選択。
ハンズオン②で作成した monitoring-1-alarm を選択し、「ウィジェットの作成」をクリック。
これで、ダッシュボードを見るだけでディスクアラームが「OK」なのか「ALARM」なのかが一目で分かります。

6.ウィジェット3：アクセスログ分析（Logs Insights）

「ウィジェットの追加」→「クエリの結果」を選択。
Logs Insightsの画面に切り替わるので、wordpress_access_log を選択し、ハンズオン④で実行したクエリを再度貼り付けます。
「クエリの実行」を行い、結果が表示されたら「ウィゲストの作成」をクリック。

7.完成！

3つのウィジェット（EC2 CPUグラフ、ディスクアラーム、ログ分析結果）が並んだ WordPress_dashboard の完成図

ウィジェットはドラッグ＆ドロップで自由に配置変更できます。
自分だけの「WordPress監視ダッシュボード」が完成しました。

[このハンズオンでの学び]

ダッシュボードの威力を体感しました。
これぞ「監視の単一ペイン（Single Pane of Glass）」です。

メトリクス（数値）、アラーム（状態）、ログ（分析結果）という異なる種類の情報を、1つの画面に集約できるCloudWatchダッシュボードは非常に強力だと感じました。

[ハンズオン⑥]：EC2インスタンス停止時の通知

次は、メトリクス（数値）ではなく、「イベント（出来事）」をトリガーにした通知です。

1.EventBridgeルールの作成

※注意点: ハンズオン資料は2020年のもので、「CloudWatch Events」と記載されています。
しかし、現在（2025年）コンソールで「CloudWatch Events」は無く、「Amazon EventBridge」で行う必要があります。

SAAの勉強でも「CloudWatch EventsはEventBridgeに統合された」と学びましたが、まさにそれを体感しました。
サービスが進化しても、基本的な概念（イベントをルールで拾ってターゲットに渡す）は同じです。

Amazon EventBridgeコンソールで、「ルール」→「ルールを作成」をクリック。
名前: monitoring-1-event-rule

2.イベントパターンの定義

イベントソース: 「AWS のイベントまたは EventBridge パートナーイベント」
イベントパターン:
- イベントソース: 「AWS サービス」
- AWS サービス: EC2
- イベントタイプ: EC2 Instance State-change Notification
特定の状態（stopped）だけを拾うように、イベントパターンを編集します。

JSON

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"]
  }
}

3.ターゲットの設定

ターゲットタイプ: 「AWS のサービス」
ターゲット: SNS トピック
トピック: ハンズオン②で作成した monitoring-1-topic を選択します。
「作成」をクリックしてルールを有効化します。

4.テスト

EC2のコンソールを開き、monitoring-1-ec2-WebServer01 を選択し、「インスタンスの状態」→「インスタンスを停止」をクリックして手動で停止させます。
数分後...
メールが届きました！

内容はJSON形式で、「state": "stopped"」となっていることが確認できました。
大成功です。

[このハンズオンでの学び]

「メトリクス監視」（CloudWatch Alarms）と「イベント監視」（EventBridge）の明確な違いを理解しました。

前者は「CPUが90%を超え続けている」という状態を監視し、後者は「EC2インスタンスが停止した」という出来事（イベント）をトリガーにします。
この使い分けが重要ですね。

[ハンズオン⑦]：お片付け/リソースの削除

ハンズオンで最も重要な作業です。
お財布を守るために、使ったリソースは必ず削除（お片付け）しましょう。

ここで非常に重要な学びがありました。
ハンズオン資料によると、CloudFormationスタックを削除すればOK...
かと思いきや、それだけでは不十分です。

CloudFormationは、自分が作成したリソース（EC2, ALB, RDS, VPCなど）は削除してくれます。

しかし、ハンズオンの途中で手動で作成したリソース（アラーム、ダッシュボード、SNSトピック、EventBridgeルール、ロググループ）は、CloudFormationの管理外です。

したがって、これらは手動で個別に削除する必要があります。これは非常に重要な学びです。
削除手順 (チェックリスト) ハンズオン資料を参考に、以下の順番で削除しました。

1.CloudFormation スタックの削除

CloudFormationコンソールで monitoring-1 スタックを選択し、「削除」をクリック。
DELETE_IN_PROGRESS になります。（EC2やRDSが消えるまで時間がかかります）

2.EventBridge (CloudWatch Events) ルールの削除

EventBridgeコンソールで monitoring-1-event-rule を選択し、「削除」。

3.CloudWatch アラームの削除

CloudWatchコンソール > アラームで monitoring-1-alarm を選択し、「削除」。

4.CloudWatch ダッシュボードの削除

CloudWatchコンソール > ダッシュボードで WordPress_dashboard を選択し、「削除」。

5.SNS トピックの削除

SNSコンソール > トピックで monitoring-1-topic を選択し、「削除」。

6.CloudWatch ロググループの削除

CloudWatchコンソール > ロググループで wordpress_access_log と wordpress_error_log を選択し、「アクション」→「ロググループの削除」。

これで、ハンズオンで作成したリソースは（ほぼ）すべて削除され、クリーンな状態に戻りました。

おわりに

前後編にわたり、「AWS Hands-on for Beginners 監視編」の体験記をお届けしました。

実際に手を動かしてみることで、

Agentを入れないとメモリやディスクが見えないこと
Logs Insightsを使えばログファイルもSQLのように分析できること
EventBridgeとAlarmの使い分け
など、テキスト学習だけではイメージしづらかった部分がクリアになりました。

特に、前編の「事前準備」でRDSのインスタンスタイプのエラーに遭遇した際は焦りましたが、トラブルシューティングも含めて良い経験になりました。

これからAWS監視を学ぶ方には、自信を持っておすすめできるハンズオンです。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

2025-11-20

【AWS】ハンズオン「サーバーのモニタリングの基本を学ぼう」（CloudWatch）にチャレンジ！(前編)

AWS 学習クラウド

はじめに

こんにちは、クラウド事業部の木幡です。

AWS認定 SAA(ソリューションアーキテクトアソシエイト)の取得を目指して、日々勉強中です。
IT歴は2年ほどありますが、AWSはまだまだ初心者です。

SAAの試験勉強をしていると、監視サービスの「Amazon CloudWatch」が頻出トピックの一つであることが分かります。
しかし、テキストで「メトリクス」「アラーム」「ログ」...と覚えるだけでは、ピンと来ていませんでした。

そこで今回は、AWS公式が提供している
「AWS Hands-on for Beginners 監視編サーバーのモニタリングの基本を学ぼう」に挑戦してみました。

本記事は、私と同じAWS初学者の皆さんに向けて、ハンズオンの体験記（やってみたブログ）として、手順や学び、躓いたポイントを共有するものです

どんなひとに読んで欲しい

AWS SAAの認定試験を勉強中で、CloudWatchの実践的な理解を深めたい人
AWSを使い始めたけれど、「監視」と言われても何から手をつければいいか分からない人
EC2インスタンスは立てたことがあるけど、CloudWatchのコンソールはあまり触ったことがない人
公式ハンズオンの動画や資料は見たものの、一人で実践するのが少し不安な人

前提

構成図

VPC内にMulti-AZ(1a, 1c)で構成されています。
ALB(Application Load Balancer)がパブリックサブネットに配置され、トラフィックを2台のEC2インスタンスに振り分けます。
データベース(RDS)もMulti-AZで、プライベートサブネットに配置されています。
まさにSAAの試験対策で学ぶ、耐障害性とセキュリティを考慮した基本的な構成です。
この構成を「監視する」という体験ができるのは、非常に実践的だと感じました。

手順

[事前準備]：CloudFormationとWordPressセットアップ

まずは監視対象のWebサーバー群を構築します。

1.CloudFormationテンプレートの実行

ハンズオンの資料ページから、資材(monitoring-1.yaml)をダウンロードします。
AWSマネジメントコンソールで「CloudFormation」サービスを開き、「スタックの作成」→「新しいリソースを使用(標準)」を選択。
「テンプレートファイルのアップロード」を選び、ダウンロードしたmonitoring-1.yamlを指定します。

注意点 ：EC2インスタンスクラスt2.microが今では対応していない為、t3.microに書き換える。
RDSのインスタンスクラスも同様にdb.t2.micro→db.t3.microへ

スタック名は「monitoring-1」としました。

　　注意点: デフォルトのVPC上限（5個）に達している場合はエラーになります。
　　私は大丈夫でしたが、ハマりポイントかもしれません。

全てのステップをデフォルトのまま「次へ」進み、最後に「スタックの作成」をクリックします。
ステータスが CREATE_IN_PROGRESS から CREATE_COMPLETE になるまで10分程度待ちます。

コーヒーでも淹れるかサンバでも踊って一息つきましょう。
私はスクワットしてました。

2.WordPressの初期設定

スタックが CREATE_COMPLETE になったら、「出力」タブを開きます。

EC2WebServer01DNS のキーの「値」（DNS名）をコピーし、ブラウザでアクセスします。
WordPressのインストール画面が表示されます。「さあ、始めましょう！」をクリック。

次の画面で、データベースの接続情報を入力します。
この情報はハンズオン資料とCFnの「出力」タブに記載されています。

項目	値
データベース名	wordpress
ユーザー名	`dbmaster`
パスワード	`H&ppyHandsOn`
データベースのホスト名	CFn出力の RDSEndpointAddress の値
テーブル接頭辞	wp_ （デフォルト）

CFnの出力からRDSのエンドポイントをコピペする作業、いかにもクラウド構築っぽいですね。

「送信」をクリックし、次の画面でサイト情報を入力します。

項目	値
サイトのタイトル	`Monitoring #1`
ユーザー名	`admin`
パスワード	(生成された強力なパスワードを必ずコピーしてメモ帳などに控えておきます)
メールアドレス	`username@example.com`（ダミーでOK）
検索エンジンでの表示	「検索エンジンがサイトをインデックスしないようにする」にチェックを入れます。

「WordPressをインストール」をクリック。
成功画面が出たら、ログインしてWordPressのダッシュボードが表示されることを確認します。
同じことををもう一つのEC2インスタンスにも設定。EC2WebServer02DNSから設定すればOK！

[ハンズオン①]：EC2、ALB、RDSのメトリクス確認

1.CloudWatchコンソール操作

「メトリクス」→「すべてのメトリクス」を選択します。

2.EC2のメトリクス

AWS/EC2 → インスタンス別メトリクスをクリック。

monitoring-1スタックで作成したインスタンス（monitoring-1-ec2-WebServer01など）の CPUUtilization を見つけ、チェックボックスをオンにします。

)

これがEC2のCPU使用率のグラフです。

さっきWordPressをインストールしたので、少しスパイクが立っているのが分かりました。
これが「監視」の第一歩ですね。

3.ALBのメトリクス

AWS/ApplicationELB → ELB 別 をクリック。
monitoring-1-elb を見つけ、RequestCount にチェックを入れます。

今は自分しかアクセスしていないのでRequestCountは小さいですが、これが急増したり0になったりしたら「何かあった」と気づけます。

4.RDSのメトリクス

AWS/RDS → DBClusterIdentifier をクリック。
monitoring-1-rds を見つけ、CPUUtilization にチェックを入れます。

データベースのCPU使用率も監視できるんですね。
アプリケーション（EC2）だけでなく、バックエンド（RDS）も監視することがシステム全体の安定稼働に不可欠、とSAAの勉強で習った通りのことが確認できました。

[このハンズオンでの学び]

AWSの主要サービス(EC2, ALB, RDS)は、デフォルトで多くの「標準メトリクス」をCloudWatchに送信していること。

しかし、EC2の「メモリ使用率」や「ディスク使用率」はこの一覧に見当たらないこと。
これが次のハンズオンへの伏線回収されます。

[ハンズオン②]：EC2のディスク使用率90%以上時のアラート発報

ここが最初の「なるほど！」ポイントでした。

1.アラームの作成

CloudWatchコンソールで「アラーム」→「すべてのアラーム」→「アラームの作成」をクリック。
「メトリクスの選択」をクリック。

先ほどのハンズオン①で、EC2のディスク使用率は「標準メトリクス」(AWS/EC2)に無いことを確認しました。
では、どこにあるのか？答えは「前提」で触れたCloudWatch Agentです。

Agentが収集したメトリクスは、AWS/EC2のようなAWS/で始まる名前空間ではなく、カスタム名前空間（Agentの設定で決めた名前）に保存されます。
このハンズオンでは、CWAgentというカスタム名前空間が作られていました。
CWAgent をクリックします。
InstanceId, path, fstypeなどのディメンションが表示されます。
path = / (ルートディレクトリ)で、メトリクス名disk_used_percent を探します。
monitoring-1-ec2-WebServer01 インスタンスの disk_used_percent を選択します。

2.アラームの条件設定

メトリクスがグラフ表示されたら、条件を設定します。
しきい値の種類: 「静的」
条件: より大きい (>)
しきい値: 90

3.アクションの設定

「次へ」進み、アクションを設定します。
アラーム状態トリガー: 「アラーム状態」
通知の送信先: 「新しいSNSトピックの作成」
トピック名: monitoring-1-topic
通知用Eメールエンドポイント: 自分のEメールアドレスを入力します。
「トピックの作成」をクリック。

重要: この直後、入力したメールアドレスに「AWS Notification - Subscription Confirmation」という件名のメールが届きます。
必ずメール本文の「Confirm subscription」リンクをクリックしてください。
これを忘れると、アラームが発報してもメールが届きません。（私はここで数分ハマりました）

4.アラーム名と作成

アラーム名: monitoring-1-alarm
「アラームの作成」をクリックして完了です。
アラーム一覧に monitoring-1-alarm が「データ不足」として表示されます（メトリクスを評価中）。
しばらくすると「OK」（緑色）に変わります。

[このハンズオンでの学び]

標準メトリクスとカスタムメトリクスの決定的な違いを体感できました。

CloudWatch Agentの役割（ディスクやメモリ情報を収集してCloudWatchに送信する）が明確に理解できました。

Metric → Alarm → Action(SNS) という、CloudWatchアラームの基本的な流れを実際に手を動かして構築できました。
これはSAA試験でも超重要です。

[ハンズオン③]：WordPressのアクセスログ、エラーログ確認

メトリクス（数値データ）の次は、ログ（テキストデータ）の監視です。

1.CloudWatchコンソール操作

「ログ」→「ロググループ」を開きます。

2.`monitoring-1` や `wordpress` で検索

wordpress_access_log と wordpress_error_log という2つのロググループが見つかりました。
これも、CloudWatch AgentがEC2インスタンス上の
/var/log/httpd/access_log などを監視して、CloudWatch Logsに転送してくれているおかげです。

3.`wordpress_access_log` をクリック

4.中に2つの「ログストリーム」が表示

これは、monitoring-1-ec2-WebServer01 と WebServer02 の2台のEC2インスタンスからそれぞれ送られてきているログです。

5.どちらかのログストリームをクリック

6.`wordpress_error_log` も同様に確認

エラーログが収集されていることを確認しました。

[このハンズオンでの学び]

ログの集中管理の威力を体感しました。これが100台のサーバーだったらと思うと...ぞっとします。

CloudWatch Logsの「ロググループ」（例：wordpress_access_log）と「ログストリーム」（例：各EC2インスタンス）という階層構造を理解できました。

[ハンズオン④]：WordPressのアクセスログの分析

ログが読めるのは便利ですが、障害調査の際は「大量のログから特定のエラーを探す」作業が必要です。
そこで登場するのが「Logs Insights」です。

1.CloudWatchコンソール操作

「ログ」→「Logs Insights」を開きます。

2.「ロググループの選択」で、`wordpress_access_log` を選択

3.クエリエディタに、クエリを入力

ハンズオン資料に記載されているクエリを確認。
これは、Apacheの共通ログ形式をパース（解析）するクエリです。

SQL

parse '* - * [*] "* * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes, referrer, userAgent
| filter statusCode like /(4\d\d)/

※ここのクエリは配布資料が間違っています。上記が合っています。

* parse でログの1行を各フィールド（httpVerb,url, statusCodeなど）に分解し、* filter でステータスコードが200番台のものに絞り込み、 * stats でHTTPメソッドとURLごとに集計（count(*)）し、 * sort で件数が多い順に並び替えています。

4.「クエリの実行」をクリック

5.実行結果

WordPressのどのURLに、どのメソッドで、どれくらいアクセス（400番台）があったかが一覧表示されました。

[このハンズオンでの学び]

CloudWatch Logs Insightsを使えば、テキストのログファイルが、まるでデータベース（SQL）のように検索・集計できることが分かりました。

filter statusCode like /5\d\d/ のようにクエリを変えれば、サーバーエラー（500番台）だけを即座に抽出できます。
これは障害対応で絶大な威力を発揮しそうです。

ハンズオンの続きは後編へ

おわりに

前編では、CloudFormationでの環境構築から、CloudWatchを使った基本的なメトリクス監視、そしてログの分析（Insights）までを行いました。

「標準メトリクス」と「カスタムメトリクス」の違いや、ログをSQLライクに検索できるInsightsの便利さを体感できました。

後編では、これらを一つの画面にまとめる「ダッシュボード作成」と、サーバー停止を検知する「イベント監視」
そして最後のお片付けについてまとめます。

ぜひ後編もご覧ください！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

2025-11-18

【AWS】「JAWS-UG会津」＆「JP_Stripes会津」合同勉強会 2025 Autumnに参加＆登壇してきました！

AWS JAWS

はじめに

こんにちは、クラウド事業部の馬藤です。

11月7日に開催されました「JAWS-UG会津」＆「JP_Stripes会津」合同勉強会 2025 Autumnに参加＆登壇してきました。

jaws-tohoku.connpass.com

「会津ってどこ？」というのがまず皆さんの最初の疑問かと思いますが、会津は福島県にあります。

福島県は西から会津地方、中通り、浜通りと3つの地域に分かれており、勉強会は私が住んでいる会津若松市(白虎隊やNHK大河ドラマの八重の桜が有名ですね)で開催されました。

これまでJAWSなどのイベントをオンライン視聴やアーカイブ動画で確認することはあったものの、オフライン参加や登壇は未経験＆せっかくの会津開催ということで参加してきました！

会場は會津稽古堂(正式には「会津若松市生涯学習センター」のようです)で、子供と図書館で本を借りに来ている施設で馴染み深い場所でした。

勉強会の概要

タイトルの通り勉強会はAWSとStripeに関するもので、以下の内容が印象的でした(勉強会の写真はconnpassの公開情報から引用しています)。

RevOps

RevOpsとはRevenue Operationsの略で、マーケティング、営業、カスタマーサクセス等の収益(Revenue)に直接関わる部門のシステムを統合・最適化するアプローチ

利点としては収益を生み出すプロセス全体(顧客獲得から維持まで)の効率性と透明性を向上させ、収益成長を加速させることが出来る

StripeはRevOpsチームを運営し、決済の多様性や不正利用対策などを支援している

SaaSの利点

顧客の利点：ソフトウェアのインストール無しですぐに使え、不要になったらやめられる(その月内など)

開発者の利点：実行環境をコントロール出来、統一化されたデプロイメントが可能(顧客ごとのカスタムが不要)

事業者の利点：サブスクモデルのため収益予測がしやすく、その予測から投資計画などが立てやすい

Buy for Meの魅力

他社ブランドの商品を代理で購入できるAmazonの機能

この機能によりAmazonで取り扱いが無い商品もAmazonから購入できるようになるため、ネット購入の入り口をAmazonに集約しやすくなる

Buy for Meで購入処理をすると裏でAIエージェントがブランドサイトで注文処理を実行してくれる

私の登壇

検証した生成AIの論理構成やTIPSなどを記載していますので、是非見てください！

勉強会に参加して感じたこと

レベルが高かった

経営に関わる話から技術的な詳細な部分に至るまで、全体的にレベルが高い勉強会だったと感じました。

本題に入る前の場の和ませ方(開催場所を間違えてタクシーに1時間以上乗って3万円弱かかちゃった話)や、周りを巻き込んだ話し方、視覚的な伝え方など参考になりました。

自身の登壇

初めてのオフライン参加＆登壇だったものの、想定したより緊張はせず参加者の表情を見ながら話すことが出来ました。

ただ緊張はしなかったものの、ところどころ噛んだり、説明の順序が乱れたのでそこは改善点かなと思います。

発表資料のスライド毎に参加者の反応を確認でき、どのスライドの注目度が高いかを知ることが出来たのは面白かったです。

おわりに

初めてのオフライン参加＆登壇でしたが、色々と勉強となることが多く、とても有意義な時間でした。

基本的には春と秋に開催予定ということなので、今後も参加したいと思います！

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

2025-10-30

【AWS】バージニア北部リージョンの障害レポートを読んだので図解してみた

AWS 障害

はじめに

こんにちは、クラウド事業部の上野です。

今回はAWSのバージニア北部（us-east-1）リージョンにて、10月19日午後11:48分（PDT）〜 10月20日午後2時20分（PDT）に発生した障害について調べてみました。（日本時間: 10月20日 15:48～ 10月21日 06:20）

詳しい障害の内容については以下レポートを参考にします。この時の障害について図解することで、AWSの内部構造（あくまで記事から読み取れる範囲の想像）まで理解しやすい記事になればと思います。

aws.amazon.com

※注意点

以下に様々な図を出していますが上記の障害レポートから読み取って独自に作成したものであるため、実際にその通りであるかは分かりませんし、公開情報として調べても特に出てこないものです。あくまで読み取れる範囲で整理しただけのものである点にご注意ください。

障害の内容

大きく以下の流れで障害は発生したようです。

10月19日午後11時48分〜10月20日午前2時40分
1. バージニア北部（us-east-1）リージョンにおいてAmazon DynamoDBのAPIエラー率が上昇
10月20日午前5時30分〜午後2時9分
1. バージニア北部（us-east-1）リージョンの一部ロードバランサーにおいてNetwork Load Balancer（NLB）の接続エラーが増加。
2. NLBフリートのヘルスチェック失敗が原因で、一部のNLBで接続エラーが増加したため
10月20日午前2時25分〜午前10時36分
1. 新規EC2インスタンスの起動失敗が発生。午後1時50分までには解決。

障害発生の理由

1. DynamoDBの障害理由

全体の障害の起因となったのはDynamoDBでした。 DynamoDBの障害理由についてですが、まずDynamoDBのDNS管理アーキテクチャについての説明がされており読み取れる限り以下のような構成となっているようです。

大きく2つのコンポーネントがあり、DNSプランナーとDNS Enactorが処理の中心にある。
DNSプランナーは各サービスエンドポイントとロードバランサーの紐付けを行うDNSレコードを生成する。この紐付けはロードバランサーのcapacityチェックを行い都度適切なロードバランサーに切り替えるためDNSレコードプランは定期的に更新される。
このDNSレコードプランをポーリングして、DNS EnactorがRoute53サービスにDNS更新リクエストを行っている。この時複数のEnactorが同時に更新処理をして不整合を起こさないようトランザクションを貼って更新するような挙動になっている。

障害発生の流れ

1~2. まず一部DNS Enactorが想定外の遅延を発生させ（以下画像だとAZ3）、他のEnactorのDNSプランが先に適用された。

3.上記画像2.の処理でRoute53 へのプラン適用後、AZ3のEnactorが遅延によって遅れて実行されることで古いDNSで上書きされる。

4.AZ1はDNSプラン適用後、クリーンアッププロセスにより古いDNSを削除する。この時3.で登録されたものが削除される。これによってDNS上のレコードが消えてしまった。

5.DNS Enactorは不整合を起こして更新処理が失敗するようになった。

DynamoDBに接続できなくなったのは上記1~5の理由でDNSレコードが削除されて不整合状態に陥り自動回復できなくなったことが原因だった。

2. Amazon EC2の障害理由

上記DynamoDBの障害はEC2にも伝播して影響を与えていたようです。

ここで最初に理解しておく必要があるのはEC2の物理サーバー基盤とEC2にネットワーク設定を伝搬するコンポーネントの存在です。

Network Manager
- Internet通信, 同一VPC内のEC2との通信, VPC内のネットワーク機器などとの通信設定をEC2に伝搬させるためのもの。
DropletWorkflowManager
- EC2の物理サーバー群であるdropletsをリースと言うプロセスか何かに紐付けてそれごとにdropletsを管理するもの。

障害発生(1)

今回はこのdropletsのリース確立プロセスにDynamoDBが使用されているせいで、リースチェック失敗->リース切れ扱い → 新規インスタンスの候補から除外という流れで新規EC2が立ち上がらなくなっていた。

その後、DynamoDBが正常に動き始めたことでこちらのプロセスも正常に動き始めるかというとそうはならなかった。

まず処理しないといけないdropletsが多すぎた結果全て処理しきれずtimeoutが大量に発生。

2~3. timeoutしたタスクはキューに積まれるがキューが増える一方で輻輳崩壊状態に陥って処理ができない状態になったとのこと。（すでに処理の必要がないタスクなども溜まりっぱなしになっていたなどが想像される）

4.最終的にはキューをクリアするためにDWFMを一部再起動することで処理を再開できたとのこと。

障害発生(2)

DropletWorkflowManager（DWFM）に関する問題はこれで完了したが、この後Network Manager側で問題が発生した。

起動し始めたEC2へネットワーク伝搬が大量に発生し遅延が発生してしまったとのこと。

これについてはエンジニアが手動で負荷軽減措置を実施して解決。

3. Network Load Balancer (NLB)の接続エラー増加の原因

上記で紹介したEC2のNetwork Managerからのネットワーク伝搬遅延により、NLBのHealth checkに影響が発生していた。

まずNLBのアーキテクチャについてだが、NLBは複数のAZにまたがるNode上に構築されておりそのNodeはHealth checkサブシステムによって監視されている。もしHealth checkに失敗するとDNSから削除されて通信対象から排除される。

障害発生

今回、EC2のネットワーク伝搬遅延によってNodeとEC2の経路構築前にHealth checkが実行されて失敗することで大量にDNSからNodeが削除される結果となった。

このHealth checkの失敗増加は、その失敗が増加しているNodeのあるAZへの転送をDNSレベルで流れないようにDNSフェイルオーバーをトリガーした。

2~3. 1.のせいで他AZのNLB Nodeへトラフィックが増加したことで負荷が増えてEC2への接続エラーを引き起こすなどした。

4.ネットワーク伝搬が完了してHealth checkが成功したEC2も、Nodeの置き換えなどが発生するとネットワーク伝搬が再度必要になり、これによって再度遅延によるHealth check失敗が起きるため成功と失敗を繰り返す状態となっていた。

5.NLBの問題についてはHealth checkサブシステムの負荷増加によるフェイルオーバー発生が問題だったので、エンジニアが自動フェイルオーバーを無効化することで対応したとのこと。

まとめ

全ての原因はDynamoDBでありAWS内部でもDynamoDBは様々な用途で使用されていることがわかって面白かったです。

また、この機会にAWSの内部構造について障害レポートを通じて理解を深めることができ学びになりました。

多少図では説明しきれてない部分もあると思うので、気になる方はレポート本体を読んでみることをお勧めいたします。

2025-10-30

MFA 必須環境下で Amazon Bedrock を Cline (VSCode) から利用しようとしたときの奮闘録

AWS

はじめに
Cline の設定
壁となった IAM Policy（MFA 関連）
試行1：AWS CloudShell で一時クレデンシャル利用（失敗）
試行2：ローカル AWS CLI でセッショントークンを取得（成功）
終わりに
お知らせ

はじめに

こんにちは、クラウド事業部の梅本です。

今回は VSCode で Cline を使った AI 活用を行おうとしたときの話です。

Cline は VSCode の拡張機能で提供される、AI を活用したコーディング支援ツールです。チャットによるコーディング支援のほか、MCP（Model Context Protocol）による外部のツールやデータソースとの連携が可能です。

github.com

そんな Cline の AI 部分の設定を Amazon Bedrock（Claude）にして利用を考えていたところ、IAM Policy が壁となりました。今回は、その奮闘録になります。

Cline の設定

Cline の AI モデル設定画面は以下の通りです。 AI プロバイダー（ Amazon Bedrock や OpenAI など）や、利用する生成 AI のモデルなどを選択できます。

AWS の場合、認証情報として以下の選択肢が用意されています。

AWS Bedrock API Key
AWS Profile（ローカルの AWS CLI のプロファイル）
AWS Credentials（Access Key/Secret Key）

今回は、この認証設定が壁となりました。

調査開始前までは、以下の2つの方法で試したのですがアクセスできませんでした。

AWS Bedrock API Key
AWS Credentials（Access Key/Secret Key）

エラー時のチャット画面

エラーメッセージ

[ERROR] Failed to process response: User: arn:aws:iam::xxxx:user/xxxx@xxxx.co.jp is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource: arn:aws:bedrock:us-east-1:xxxx:inference-profile/us.anthropic.claude-haiku-4-5-20251001-v1:0 with an explicit deny in an identity-based policy

壁となった IAM Policy（MFA 関連）

壁となっていたのは、以下の IAM Policy でした。

{
    "Version": "2012-10-17",
    "Statement": [
        ...
        （途中省略）
        ...
        {
            "Sid": "xxxxx",
            "Effect": "Deny",
            "NotAction": [
                ...
                （途中省略）
                ...
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

このポリシーは、「MFAで認証されていない（aws:MultiFactorAuthPresent が "false" の）場合、NotAction に記載されているアクション以外は、すべて "Deny"（拒否）する」という意味です。

前章のエラー（bedrock:InvokeModelWithResponseStream）がこの NotAction のリストに含まれていなかったため、MFA 認証を経ていないアクセスキーや Bedrock API Key でのリクエストが拒否されていたのです。

社内の検証環境のポリシーなのですが、セキュリティ意識高めな設定ですね。

参考

docs.aws.amazon.com

dev.classmethod.jp

試行1：AWS CloudShell で一時クレデンシャル利用（失敗）

（先に結論を言うと）最短の解決策は、端末にインストールした AWS CLI から MFA を使ってセッショントークンを作成することです。

が、普段から使い勝手の良い（アクセスキーを発行せずに済む）AWS CloudShell（以降 CloudShell）を利用していたため、これでどうにかならないかを模索してしまっていました・・・。

まず、 CloudShell からセッショントークンが発行できないか試してみました。

# コマンド例
aws sts get-session-token \
    --serial-number [MFAデバイスのARN] \
    --token-code [6桁のMFAコード]

# 実際の実行ログ
aws sts get-session-token \
    --serial-number xxxx \
    --token-code 012345

An error occurred (AccessDenied) when calling the GetSessionToken operation: Cannot call GetSessionToken with session credentials

これは、CloudShell が起動時点で既に一時的なセッショントークン（セッションクレデンシャル）を自動で読み込んで動作しているためです。エラーメッセージ（Cannot call GetSessionToken with session credentials）が示す通り、「セッションクレデンシャルを使って、さらにセッショントークン（GetSessionToken）を取得する」ことはできないため、エラーとなっていました。

参考

repost.aws

では、払い出されているセッショントークンを参照すればと思い、、、

# CloudShell 内で利用する認証情報を取得
# 環境変数は CloudShell を起動した段階で設定されている
curl -H "Authorization: ${AWS_CONTAINER_AUTHORIZATION_TOKEN}" \
"${AWS_CONTAINER_CREDENTIALS_FULL_URI}"

# 実行例
curl -H "Authorization: ${AWS_CONTAINER_AUTHORIZATION_TOKEN}" \
"${AWS_CONTAINER_CREDENTIALS_FULL_URI}"

{
        "Type": "",
        "AccessKeyId": "xxxx",
        "SecretAccessKey": "xxxx",
        "Token": "xxxx",
        "Expiration": "2025-10-27T15:23:13Z",
        "Code": "Success"
}

取得はできたものの、ここで取得できるクレデンシャルは CloudShell の実行環境内でのみ有効なキーです。そのため、ローカル PC で動作している Cline からはこのクレデンシャルを利用できず、この方法も失敗に終わりました。

試行2：ローカル AWS CLI でセッショントークンを取得（成功）

原点に立ち返り、ローカル PC に AWS CLI をインストールし、セッショントークンを取得することにしました。

まず、MFA 認証の元となる IAM ユーザーのアクセスキー/シークレットキーを生成し、

# default Profile に登録
aws configure

AWS Access Key ID [None]: xxxx
AWS Secret Access Key [None]: xxxx
Default region name [None]: us-east-1 
Default output format [None]: json

# default Profile を使って MFA 認証を実行し、セッショントークンを取得
aws sts get-session-token --serial-number ${ARN} --token-code xxxx
{
    "Credentials": {
        "AccessKeyId": "xxxx",
        "SecretAccessKey": "xxxx",
        "SessionToken": "xxxx",
        "Expiration": "2025-10-30T02:57:12+00:00"
    }
}

この払い出された一時的なクレデンシャル（AccessKeyId, SecretAccessKey, SessionToken）を Cline の設定（AWS Credentials）に直接登録しても良いのですが、折角なのでAWS CLI に「MFA認証済み」のプロファイルを追加します。

# 「mfa」という名前で新しいプロファイルを作成
# get-session-token で取得した「一時的な」キーを登録する
aws configure --profile mfa

AWS Access Key ID [None]: [get-session-token で取得した AccessKeyId]
AWS Secret Access Key [None]: [get-session-token で取得した SecretAccessKey]
Default region name [None]: us-east-1
Default output format [None]: json

# 対話モードでは設定できないセッショントークンを、mfa プロファイルに追加
aws configure set aws_session_token [取得したSessionToken] --profile mfa

aws configure の対話モードではセッショントークン（aws_session_token）は設定できないため、最後の aws configure set コマンドで明示的に追加しました。

これで準備は整いました。

Cline の設定画面で、認証方法として「AWS Profile」を選択し、先ほど作成したプロファイル名（mfa）を指定します。

この設定で Cline からチャットを行うと、、、

無事にチャットを開始することができました。

終わりに

今回はちょっと遠回りをしてしまいましたが、何とか Cline を始めるまで至ることができました。

今回の「奮闘」の核心は、やはり aws:MultiFactorAuthPresent: "false" を条件に持つ IAM ポリシーでした。ローカル PC で動作するツールには、CloudShell のような（すでにセッションが発行済みの）環境のクレデンシャルを流用するのではなく、ローカルの AWS CLI で MFA 認証を通過させた「セッショントークン」が必須だという、基本に立ち返る結果となりました。

次回は AWS から提供されている MCP を Cline から試してみたいと思います。

Explicit Deny エラーや MFA ポリシーで同じ様に詰まっている方の参考になれば幸いです。

お知らせ

APC は AWS Advanced Tier Services (アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

一緒に働いていただける仲間も募集中です！

hrmos.co

本記事の投稿者: t-umemoto
コンテナや k8s をメインにインフラ系のご支援を担当しています。
更新が滞っている Qiita や Zenn はこちら。

2025-10-27

【AWS】JAWS FESTA 2025 in 金沢ボランティアスタッフ参加レポート！！

AWS JAWS

(画像はイベントサイトtopより)

はじめに

こんにちは、クラウド事業部の坂口です。

去る2025年10月11日(土)に JAWS FESTA 2025 in 金沢が開催され、幸いにも参加することができました！

今回はボランティアスタッフとして参加させていただけたので、スタッフとしての感想を中心につらつらとレポートを書いていこうと思います。

弊社で、同じくボランティアスタッフとして参加された方のレポート記事はコチラ↓

techblog.ap-com.co.jp

イベントについて

JAWS FESTA とは

こちらのページより抜粋

JAWS-UGの活動は各支部が独立して運営しています。この各支部の勉強会とは別に年に2回、全国規模のイベントが開催されます。春のJAWS DAYS、秋のJAWS FESTAです。

JAWS DAYSは毎年東京で行われ、秋のJAWS FESTAは東京以外の地方で行われます。JAWS FESTAは、広島(2024)、福岡(2023、2015)、北海道(2019)、大阪(2018,2013)、愛媛(2017)、愛知(2016)、宮城(2014) で開催されました。今年のJAWS FESTAの会場は金沢となり、北陸地方では初の開催となります。

全国各地で活動している各支部のリーダーが集まり、オフラインによるネットワーキングを「再構築」し、お互いに刺激を受けあい、また地元に帰って活動する、というリズムを作り出しています。

JAWS FESTA 2025 in 金沢

そんな JAWS FESTA ですが、今年 (2025) は金沢(石川県金沢市)で開催されました！

JAWS FESTA 2025 in 金沢のイベントサイトはこちらになります。

jawsfesta2024.jaws-ug.jp

本題には全く関係ない小話

何を隠そう、筆者は金沢市にそこそこ縁があります。

なので、今回のJAWS FESTA画像にある文言について完全自己満足で説明しようと思います。

※なお、あえて何も調べず書いているため、事実と異なる部分がある場合はすみません

『やっとるげん』

取り上げるのはコチラ『秋の金沢 AWS やっとるげん』

『やっとるげん』という箇所がいわゆる金沢弁で、『秋の金沢 AWS やっています』というような意味になります。

単純にそれだけの意味ではあるのですが、会話の中だとあまりうまく認識してもらえず聞き返されることがあります。少なくとも筆者はありました。

『せんがん』

またその他の金沢弁として『勉強せんがん』→『勉強しないのか』というものもあります。

動詞を変えて『JAWS FESTA 行かんがん』→『JAWS FESTA 行かないのか』というように使います。

ちなみに、この金沢弁についても北海道札幌の地で聞き返されたことがあります。

筆者が不注意で使ってしまったので仕方ない部分はありますが、

『潤かす』や『押ささる』を筆頭に、なまらなまら言って突撃してくる札幌の方に不思議な顔をされたので記憶に残っています。

『ねーじ』

加えて、『〇〇ねーじ』という金沢弁もあります。

こちらは『PC ねーじ』→『PC が無いじゃないか』という使われ方をし、金沢弁の例文として『ネジねーじ』という人類みな全てが笑う文が頻出します(世界平和)。

※ネジは、そのままプラスとかマイナスとかのネジです

金沢の民へ

という訳で、簡単な金沢弁の説明でした。

これで読者の方は金沢の民なので、引き続きよろしくお願いします。

本題

会場に関して

今回、会場は2か所。

ITビジネスプラザ武蔵4〜6階
- ITビジネスプラザ武蔵

近江町交流プラザ4階まなびぃ広場
- 近江町交流プラザ／金沢市公式ホームページいいね金沢

会場が2か所になった理由としては、主要な駅(金沢駅)から近い場所での開催であるため、1つの会場では300人近い参加者をまかなえなかったのかと推察します。

実際に 2023(九州)JAWS FESTA 2023 KYUSHU, 2024(広島)JAWS FESTA 2024 in 広島での開催時は、若干郊外にある大学講堂等を借りていました。

とはいえ、金沢駅から近場だったことと、各会場間が遠かったということも無く、個人的には移動が気分転換も兼ねた形になったので悪くなかったです。

ボランティアスタッフの流れ (～前日)

さて、冒頭でも記載した通り、今回はボランティアスタッフとして参加しました。

過去のJAWS FESTAでもボランティアスタッフとして参加したことはあったのですが、今後、同様にボランティアスタッフとして参加されるかもしれない方に向けて今回経験した流れだけ簡単に記載しておきます。

※念のためで、一部は画像を使わずテキストのみでの説明となります

①ボランティアスタッフへの申し込み

ボランティアスタッフには、基本的にJAWS FESTAのイベント本ページに申し込みの案内が出されます。

今回は以下のようなページでした。

ページ下部の「応募フォーム」から必要事項を入力して申し込みができます。

募集の案内自体は X(旧Twitter) でもされていました！

ボランティア募集に関する詳細ページはこちら！https://t.co/YhYOh1H0wx #jawsfesta2025 #jawsfesta #jawsug
— JAWS-UG (@jawsdays) 2025年8月8日

なお、JAWS FESTA本編への参加申し込みとは別になります。

JAWS FESTA本編の参加申し込みは例年 Doorkeeper (2025のページ: JAWS FESTA 2025 in Kanazawa - JAWS-UG | Doorkeeper) でされており、ボランティアスタッフ募集よりも早いタイミングで公開されます。

事前に本編への申し込みをしておきましょう。ただし一般の参加枠含め埋まるのがかなり早いため、その点は注意です。

②ボランティアスタッフの受け付け

ボランティアスタッフとして申し込みを行うと、JAWS-UG の Slackワークスペース (もしくはX(旧Twitter)) で実行委員の方から連絡がきます。

なおスタッフとしてのやり取りや共有なども Slack で行われるため、申し込みの段階でワークスペースに参加しておくのが良いと思います。

実行委員の方から連絡を受け、問題なくボランティアスタッフとして参加できるようであればSlackのスタッフ用チャンネルに追加いただけるので、以降はこのチャンネルでやり取りを行います。

またJAWS-UGのSlackワークスペースでは一般のJAWS-UGイベントの告知などもされるため、ボランティアスタッフ参加に関わらずワークスペースに参加しておいてあまり損はないかなと思います。

③ボランティアスタッフとしての役割確認

Slackのスタッフ用チャンネルに参加後、開催が近くなるとボランティアスタッフとしての役割・シフト表やスタッフのガイドを共有いただけます。

このタイミングで、当日ボランティアスタッフとして何をするかの役割分担が分かります。

また、ボランティアスタッフに向けての説明&質問会も別途実施をいただけます。会の実施はいくつか候補日があるので、都合の良いタイミングで参加しましょう。

役割・シフト表やガイドは適宜アップデートが入ることもあり、当日手元で見られるようにしておくと便利でした。

基本的にはこの説明&質問会を経て、当日を迎えることになります。

(個人としての)④開催前日

※前日までのボランティアスタッフの流れとしては ③ボランティアスタッフとしての役割確認 で完了していますが、ここからは少しだけ補足として書いていきます。

今回はスタッフの会場集合時間が8時台だったこともあり、私は前日入りをしました。

ただ、お仕事の都合で当日朝に金沢に現地入りされる方も当然いらっしゃいましたが、実行委員の方に到着時間等は配慮いただけているようでした。なので (しんどくなければ) どちらでも良さそうかな、という感想です。

また、自身は用事があったため参加できませんでしたが、前日入りして時間がある方に向けて前日準備の依頼なんかもありました。

交流の時間が持てるので、似た機会があれば参加してみて良いかもしれません。

ボランティアスタッフの流れ (当日)

いよいよ当日です。

以降はボランティアスタッフとして私が担当した役割の動きをざっくりと書いていきます。

ちなみに、役割としては「受付(懇親会)」でした。

①会場への集合、参加のチェックイン

前述の通り、当日朝8時台に会場の1つである ITビジネスプラザ武蔵に集合。

見知った顔の方と挨拶をしたりして時間をつぶします。

時間になったら受付の設営フロアへ。

配布用Tシャツやトートバック、トランシーバーなんかが並べられています。

Tシャツは紫色がボランティアスタッフ用、黒色が実行委員用とのこと。

まずは受付担当が割り振られている方からDoorkeeperでのチェックインを済ませます。

チェックイン後は、自分用のトートバッグとスタッフTシャツを受け取りました。モノはこんな感じ。

②受付対応の説明、受付開始

ストラップへの名前記入やスタッフTシャツに着替えた後は、荷物を置いて受付対応の説明を受けることに。

なお会場にはスタッフ用の荷物置き場もあり、大変助かりました！

先述の通り、今回の役割としては懇親会受付で、こんな感じのテーブルで受付を行います。

懇親会受付の対応内容としてはこんな感じでした。

懇親会参加を申し込んだ方に、Doorkeeperのチェックインを実施
- 貸与のスマートフォンで、DoorkeeperチェックインアプリでQRコードを読み込む感じでした
QRコードでのチェックインを完了した方の、プラスチックホルダーやネームプレートにチェックイン完了のシールを貼る
チェックイン完了のシールを貼った方に、同様に "お酒飲めます" シールを貼る
- 20歳未満の方やお酒飲まない方を区別する目的
写真撮影がNGの方へのネックストラップ配布
- SNS等で写真がアップされることもあり、そういった写り込みを避けたい方向け

(右上から順に、チェックイン用スマートフォン・シール2種・ネックストラップ)

配置についた後はスタッフの方のチェックイン対応をしつつ、スタッフの朝礼に参加。

その後、イベント開場時間になると参加者の方が見え始めました。

懇親会参加しない方には基本的に対応不要であったものの、大まかに4つの対応があるため(写真を撮る暇があまり無いぐらいには)そこそこ忙しかったです。

③受付会場の移動、引き続き受付

最初に受付していた会場は午前中までで、午後からは受付場所を移動して更に受付対応を継続。

移動後の受け付け会場はサポーター企業ブースがあるフロアのエレベーター前で、午前中に比べるとかなりコンパクトになりこんな感じ。

なお余談ですが、幕の移動はエレベーターを使っていたものの高さがギリギリで大変そうでした。

また午後からの受付は特にシフト等はなく有志が実施する感じでした。

私はとりあえずで残って対応していた時間が多かったですが、主に以下の理由で忙しいタイミングもそれなりにあった印象です。

午後から来場する方がそこそこいらっしゃった
分からないことがあると受付でとりあえず聞いてみる方が多かった
懇親会に限らず受付全般の対応となった
- イベント本編のDoorkeeperチェックイン、Tシャツ・トートバックの配布など

とはいえ、同じスタッフが常に受付にいたわけではなく、聴きたいセッションのタイミングやお昼休憩で適宜交代して対応をしていました。

※私自身も、セッションを聴きに行ったり、休憩を取ったりできました

④イベントの終盤、片付けなど

午後からの受付対応は実施しつつ、イベントの終盤では徐々に撤収の対応もお手伝いしていました。

こちらも私含めて手が空いている方が有志でお手伝いしていた感じです。

途中、余ったお菓子の配布なんかもしていました。

とりあえずで閉幕挨拶中も片付けをしていましたが、人が少なかったこともあり寂しげな雰囲気で楽しかったです。

(閉幕中のサポーター企業ブースの様子: 顔が写ってしまっていたので一部黒塗りしています)

閉幕後は、会場を後にする方をエレベーター前で見送ってボランティアスタッフも適宜撤収となりました。

感想

今回は縁のある石川県金沢市での開催ということで、個人的には若干テンションが上がっていました。

イベントでの受付スタッフは初めてだったものの、交流が多く持てて楽しかったです。

JAWS FESTAは年々内容がアップデートされていることもあり、毎年違った発見や楽しさに驚かされます。

来年以降も、何かしらの形で関われれば良いなと思いました。

なんだかんだ終了後には参加して良かったと思えるのは凄い。ありがとうございました！

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: さかぐち
AWSをメインにインフラ系のご支援を担当しています。 OCIにも少しずつ手を出し中。

はじめに

イベント概要

登壇資料

3行まとめ

さいごに

お知らせ

はじめに

目次

結論

捕捉なり確認なり

そもそもSNSトピックポリシーとは

AIに聴いてみた

AWS::SNS::TopicInlinePolicy はいつ頃追加されたの？

おわりに

お知らせ

S3レプリケーション完了をトリガーにLambdaでファイルを日付リネームする自動化

はじめに

システム構成図

処理の流れ

構築リソース一覧

1. S3レプリケーションの設定

設定のポイント

2. Lambdaによるファイル転送の実装

権限周りの設計

Lambdaコード（抜粋）

3. 実行確認

おわりに

はじめに

対象読者

解説のポイント

cfn-docsとは？

主な特徴

なぜ使うのか？（導入のメリット）

事前準備

1. 既存のIaCテンプレートを取得

2. cfn-docgen のインストール

3. CloudShellの場合：Pythonを3.10以上にアップデート

実施手順

0. 事前準備を完了させる

1. コマンドを実行

2. 出力結果をダウンロードして確認する

触ってみて感じたこと・わかったこと

感想（個人の見解です）

ほかの方法も調べてみる

はじめに

イベント概要

登壇資料

3行まとめ

さいごに

お知らせ

はじめに

目次

構成図

手順

1.Lambda関数を作成する。

2.S3バケットを作成する

3.EventBridgeを作成する

4.テストを実施する

はじめに

目次

構成図

前提条件

手順

1.セキュリティグループの作成

1-1.NLB用のセキュリティグループを作成する。

1-2.ALB用のセキュリティグループを作成する。

1-3.ECS用のセキュリティグループを作成する。

2.ECSの作成

2-1.クラスターを作成する。

2-2.タスク定義を作成する。

2-3.サービスを作成する。

2-4.作成されたタスクの確認

3.ターゲットグループとロードバランサーの作成

3-1.ECSへ向けたターゲットグループを作成する。

3-2.ALBを作成する。

3-3.ALBへ向けたターゲットグループを作成する。

3-4.NLBを作成する。

4.ECSで作成したコンテナ上のWebサイトにアクセスする

4-1.作成したNLBからDNS名をブラウザに入力し以下の画面が表示されることを確認する。

はじめに

2.ダッシュボード名: `WordPress_dashboard` と入力し、作成