こんにちは、SCSKの坂木です。 本記事では、 Zabbixサーバのインストールを自動化するシェルスクリプトを紹介 します！ 検証環境 今回、検証に使用した環境は以下の通りです。 コンポーネント バージョン/種類 備考 OS Amazon Linux 2023 RHEL系のディストリビューション データベース MySQL Community Server Zabbixで広く利用されているデータベース Zabbix Zabbix7.0 LTS 2025/08時点での最新の長期サポート版 この構成に基づき、本ブログで公開するスクリプトは 「RHEL系OS ＋ MySQL」の環境に、Zabbix 7.0 LTSをインストール するものとなっています。 もし異なるOS（Ubuntuなど）やデータベース（PostgreSQLなど）をご希望の場合は、一部カスタマイズが必要となりますので、あらかじめご了承ください。   前提条件 MySQLサーバが起動していること 本スクリプトはZabbixサーバのコンポーネントをインストールし、DBに接続する設定を行いますが、MySQLサーバ自体のインストールや起動は行いません。あらかじめMySQLが利用可能な状態にしておいてください。 OSがZabbixサーバのバージョンに対応していること Zabbixサーバはバージョンごとに公式にサポートされるOSが定められています。対応しているOSのバージョンは こちら を確認してください。 RHEL系のOSであること このスクリプトは、パッケージ管理にdnfコマンドを利用するなど、RHEL系のOSに特化して作成されています。   インストールスクリプト スクリプトはこちらになります。 #!/bin/bash set -e # 1. MySQLのrootユーザーのパスワード MYSQL_ROOT_PASS='<MySQLのrootユーザーのパスワードを入力してください>' # 2. Zabbixがデータベース接続用に使う新しいパスワード ZABBIX_DB_PASS='<MySQLのzabbixユーザのパスワードを入力してください>' echo "--- Zabbixリポジトリの追加とパッケージのインストールを開始します ---" rpm -Uvh https://repo.zabbix.com/zabbix/7.0/amazonlinux/2023/x86_ 64/zabbix-release-latest-7.0.amzn2023.noarch.rpm dnf clean all dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-agent echo "--- Zabbix用データベースとユーザーを作成します ---" mysql -u root -p"${MYSQL_ROOT_PASS}" <<EOF CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'zabbix'@'localhost' IDENTIFIED BY '${ZABBIX_DB_PASS}'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost'; SET GLOBAL log_bin_trust_function_creators = 1; EOF echo "--- Zabbix初期スキーマとデータをインポートします ---" zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p"${ZABBIX_DB_PASS}" zabbix echo "--- log_bin_trust_function_creators の設定を元に戻します ---" mysql -u root -p"${MYSQL_ROOT_PASS}" <<EOF SET GLOBAL log_bin_trust_function_creators = 0; EOF echo "--- Zabbixサーバーの設定ファイル(/etc/zabbix/zabbix_server.conf)を編集します ---" sed -i "s/^# DBPassword=/DBPassword=${ZABBIX_DB_PASS}/" /etc/zabbix/zabbix_server.conf echo "--- 関連サービスを再起動し、自動起動を有効化します ---" systemctl restart zabbix-server zabbix-agent httpd php-fpm systemctl enable zabbix-server zabbix-agent httpd php-fpm echo "--- Zabbixのセットアップが正常に完了しました ---"   適当なディレクトリに配置してスクリプトを実行してください。 [root@ip-10-0-30-48 work]# ll total 4 -rwxr-xr-x. 1 root root 1769 Aug 28 14:15 zabbixautoinstall.sh [root@ip-10-0-30-48 work]# ./zabbixautoinstall.sh   実行確認 スクリプト実行後、問題なくzabbixが起動しているか以下のポイントを確認します。 systemctl statusコマンドでzabbixサーバ、zabbixエージェントが起動していること # systemctl status zabbix-server ● zabbix-server.service - Zabbix Server Loaded: loaded (/usr/lib/systemd/system/zabbix-server.service; enabled; preset: disabled) Active: active (running) since Thu 2025-08-28 14:17:48 UTC; 1min 25s ago # systemctl status zabbix-agent ● zabbix-agent.service - Zabbix Agent Loaded: loaded (/usr/lib/systemd/system/zabbix-agent.service; enabled; preset: disabled) Active: active (running) since Thu 2025-08-28 14:17:48 UTC; 1min 31s ago   zabbixのwebインタフェースにアクセスできること     まとめ 本記事では、スクリプトを実行するだけでZabbix 7.0を自動インストールする手順をご紹介しました。なお、本記事で提供するスクリプトは、以下の環境を前提としています。 OS: RHEL系 (Rocky Linux, AlmaLinux など) データベース: MySQL Zabbixバージョン: 7.0 もし上記以外の環境（例: Ubuntu, PostgreSQL）でZabbixを構築されたい場合は、本スクリプトは対応しておりませんのでご注意ください。その場合は、Zabbix公式ドキュメントを参考に手動でインストールをお試しいただくか、今後の記事で別の環境向けのスクリプトを公開するまでお待ちいただけますと幸いです。  

こんにちは！ Catoクラウド 技術担当の中川です。 この記事はCatoクラウドのPoCの進め方をご説明する記事になります。 SCSKはこれまで多くのお客様へPoCのご支援をさせていただきました。 この記事ではそれらの実績をもとに、PoC前に準備しておくべきことから、PoCのよくある検証項目、困ったときの対処方法までご紹介しています。 また検証項目のご説明は、TechHarmonyで私たちが作成してきたブログを引用しリンク集のような記載にしています。 気になる機能は随時各リンクへアクセスください。 Step0 PoCを始める前に PoC概要 PoCの概要としては、以下のようになっています。期間やライセンス数にご注意いただければと思います。 期間：30日 モバイルユーザ：5ライセンス　※1ライセンスにつき端末3台まで利用可能 Cato Socket X1500：1台　※原則1台ですが、台数調整は可能 Siteの帯域：上限なし　※接続回線に合わせて設定 セキュリティオプション：すべて利用可能 PoC構成 PoCのよくある構成例 CatoクラウドのPoC構成について CatoクラウドでのPoC実施において、本番通信に影響を与えずにテストを行うためのネットワーク構成をご紹介します。よくあるネットワーク構成を例に、Cato Socketの設置位置やルーティング設定を解説します。 blog.usize-tech.com 2025.07.07 既存のNW環境にSocketをどのような構成で検証したらいいのか、上記ブログで詳しくご紹介しています。 PoC期間は30日間しかなく、普段の業務と併行して検証いただくケースも少なくないと思います。 PoCを始める前に、構成や検証予定の項目を事前によく決めておくことが重要です。 Socketのスペースを確保 構成が決まったら、拠点でSocketの設置スペースを確保します。 Socketのサイズは次の通り2パターンあります。どちらの貸し出しになるかは選択いただけませんので、ご容赦ください。 W165mm x D105mm x H43mm (X1500) W180mm x D130mm x H30mm (X1500B) サイズご参考写真（上がCato Socket X1500、下はサイズ比較用の Cisco 891FJ） 検証用端末を準備 検証用端末（PCやスマートフォン）の準備もお忘れなくお願いします。 Socket配下に接続する端末と、Catoクライアントをインストールして拠点外から接続する端末が必要です。 ※両方同じ端末でも問題ございません Catoクライアントは、他のVPN・リモートアクセスソフトと競合し、正常に動作しない場合がございます。 Catoクライアントをインストールする端末では、事前にアンインストールをお願いします。 また、拠点外からのインターネット接続環境（自宅回線、モバイルルータ、テザリング等）も準備ください。   Step1 いざCatoクラウドへ接続 Step0の前準備が終わったら、いよいよPoC開始です！ Socketの接続とモバイル接続 まずはCatoクラウドへ接続するところからです。 はじめの一歩 を参考に、Socketを使ったSite接続とモバイルユーザの接続から行いましょう。 Site接続とモバイル接続 Catoクラウド はじめの一歩 Catoクラウドのテナント開設後、テストユーザ・テスト拠点をCatoクラウドへ接続するまでの流れを紹介します。 blog.usize-tech.com 2023.08.18 vSocketで接続 Site接続でvSocketを利用される場合には、FAQサイトへご契約社様のアカウントでログインいただき、下記のFAQにて提供している手順書をご参考ください。 なお、AWS vSocketの構築方法は近日中にTechHarmonyでも公開予定です！ vSocketの構築 よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp モバイルユーザのプロビジョニング モバイルユーザを手動ではなく、プロビジョニングで作成してみたい場合には下記のブログをご参考ください。 Entra IDとの連携 【Catoクラウド】SCIMプロビジョニングでユーザを作成・管理する SCIMプロビジョニングによるユーザ作成・管理について、注意点も含めて紹介いたします。 blog.usize-tech.com 2025.04.03 LDAP連携 【Catoクラウド】ADからユーザをプロビジョニングしてみた CatoへADからLDAP連携でユーザをプロビジョニングする際の手順と注意点をまとめております。 blog.usize-tech.com 2024.12.14 CMAの見方 Catoの管理コンソールをCMAと呼びますが、CMAの見方・使い方を解説した記事もありますので不明点があればこちらもご参考ください。 CMA（Catoの管理コンソール）解説 【入門編】Catoの管理画面 Cato Management Application（CMA）を解説！ Catoクラウドの管理画面 Cato Management Application (CMA) を実際の画面を交えて見方と主に使用する項目について紹介していきます。 blog.usize-tech.com 2023.09.29   STEP2 ネットワーク設定とログの確認 ネットワーク設定 各リソースへ接続テストされる際に、必要となる可能性のある設定が2つあります。 社内ドメインへのアクセス 1つは社内ドメインにあるリソースです。 CatoではデフォルトのDNSが設定されており、社内ドメインのサイトを名前解決するには追加で設定が必要です。 PoC時に社内ドメインのサイトへ検証される場合は、下記ブログのDNS Forwardingの項でご紹介している方法で追加ください。 社内ドメイン接続用のDNS設定 CatoクラウドのDNS設定について CatoクラウドのDNS設定について網羅的に解説します。 blog.usize-tech.com 2024.08.12 固定IP制御しているSaaSへの接続 もう1つは、送信元IPを固定してアクセスする必要があるSaaSなどです。 Catoでは、グローバルの固定IPをお客様テナントで取得できます。固定IP取得の仕方、ルーティングの仕方などは以下ブログをご参考ください。 固定IPで制御しているSaaSへの接続 CatoクラウドにおけるEgress IP（送信元IP、出口IP）について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 ログの確認 各リソースへアクセスできるようになりましたら、CMAでログを確認してみましょう。 Catoクラウド導入後の日々の運用は、イベントログから調査することになります。ぜひPoC時に使い慣れておくことをオススメします。 ログの確認 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22 【Catoクラウド】イベントログ（Events）確認方法・2025年版 Catoクラウドでのイベントログ（Events）の確認・調査方法を解説する記事です。2025年5月までに追加された、便利な機能更新も含めて紹介してまいります。 blog.usize-tech.com 2025.06.16   STEP3 セキュリティ機能を使ってみる テストしたいリソースへ接続確認できましたら、セキュリティ機能を使ってみましょう。 PoCでは、本番導入時には有償のセキュリティオプションがすべて利用できます。検証しておかない手はありませんね。 PoC時点では使う予定がなくても、本番導入後に追々、セキュリティ対策が必要になることも多くございます。 是非この機会にお試しください！ セキュリティ機能 セキュリティ機能ごとにブログのご用意があります。各ブログをご参考の上、検証いただければと思います。 Firewall CatoにはInternet FW、WAN FW、LAN FWの3種類の機能が用意されています CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 Threat Prevention Threat Preventionには、「Anti-Malware」「次世代Anti-Malware（NGAM）」「IPS」の3機能があります 【Catoクラウド】Anti-Malware・IPSの操作方法と挙動について Catoクラウドのセキュリティ機能のうち、Threat Preventionオプションにて提供されるAnti-MalwareとIPSについて詳しく紹介いたします。 blog.usize-tech.com 2025.08.08 CASB クラウドアプリケーションに対する操作の可視化・制御をする機能です CatoクラウドのCASBについて Catoクラウドのセキュリティオプション CASB について解説します。 blog.usize-tech.com 2023.09.12 CASBの制御って何をしたらいいの? ～ルールの設定例 CASBでの一般的なクラウドサービス制御ルール例をご紹介します。 blog.usize-tech.com 2025.01.23 DLP CASBをベースとして、アプリケーション制御に追加するデータおよびコンテンツの検査を行う機能です CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ blog.usize-tech.com 2023.10.06 DLPって具体的に何ができるの? ～ルールの設定例 データ持ち出し対策のひとつである、Data Loss Prevention(DLP)の設定例をご紹介します。 blog.usize-tech.com 2025.03.10 デバイス制御 モバイルユーザに対するデバイスの制御です。 すべての機能が無償でご利用でき、特にAlways-Onは多くのお客様にご利用いただいている機能です。 Always-On 端末が常時Catoクラウドを必ず経由するようにする機能です CatoクラウドのAlways-Onを試してみた Catoクラウドで「Always-On」を試してみました。設定方法～動作検証までやってます。 blog.usize-tech.com 2023.08.28 Cato クラウド Always-On の新機能を徹底解説！ ～2023.11のアップデートについて～ 2023年11月にアナウンスされた Cate クライアント Always-On のアップデート情報です。 blog.usize-tech.com 2023.12.13 デバイス証明書認証 指定した電子証明書がインストールされている端末からのみ、Catoへの接続を許可する機能です Catoクラウドでのデバイス証明書認証について Catoクラウドでのデバイス証明書認証の設定方法、エラー事例をご紹介します。 blog.usize-tech.com 2024.01.11 デバイスポスチャー ウイルス対策ソフトやパッチ管理ソフトなど、特定のセキュリティソフトがインストールされている端末からのみ、Catoへの接続を許可する機能です CatoクラウドでDevice Postureを利用したい Device Postureの簡単な設定例と動作検証結果をご紹介します。 blog.usize-tech.com 2024.05.17   困ったときは 上記の通り、TechHarmonyではたくさんのCato機能をご紹介していますが、解決しない事象が発生することもあると思います。 そんな時は、SCSK、Catoそれぞれが提供している以下のサポートをぜひご活用ください。 SCSKがご提供するサポート SCSKでは以下のサポートをご提供しています。コンテンツの拡充、機能拡張を随時行っておりますのでぜひご活用ください！ FAQサイト よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp これまでのご支援実績をもとに様々な問い合わせにお答えしています。 SCSKでPoCをご契約いただきますと、ご契約者様用のアカウントを発行させていただきます。ご契約者様用のFAQでは、詳しい仕様の確認や手順書のダウンロードが可能です。 AIチャットボット 「SCSK Cato クラウド AI チャットボット」をリリースしました SCSKが開発した「Catoクラウド AIチャットボット」の機能・利便性・導入効果をご紹介します。 blog.usize-tech.com 2025.02.14 CatoのKnowledgeBaseおよび、FAQサイト、TechHarmonyを情報源として、チャット形式でお問い合わせに回答します。 Youtube動画リンク集 よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp トラブル事例やセキュリティ機能を動画形式でご紹介しています。 特に、よくいただくお問い合わせを以下にピックアップしてみました。 最初につまづきやすい事例をご説明していますので、お困りの際はまずはこれらのサイトからご確認いただければと思います。 Catoクラウドで接続したときのみ、特定のWebサイトが表示できない 特定Webサイトへのアクセスができない | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Catoクラウド経由で、特定のWebサイトへアクセスができないことがあります。Webブラウザによりエラー内容は異なりますが「403 Forbidden」「このページは動作しておりません」「アクセスしよ... cato-scsk.dga.jp Catoクラウドで接続したときのみ、特定のWebサイトで証明書エラーが表示される TLS Inspection 除外について | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK TLS Inspection機能をOnにすると、Catoクラウドで暗号化通信（HTTPS）を復号化して各種セキュリティチェックを行い、Catoの証明書を用いて暗号化を行うため、クライアントには、Catoのルート... cato-scsk.dga.jp Catoクライアントが繋がらない Catoクラウド トラブルシュート ～Catoクライアントが繋がらないお悩みの方へ～ Catoクラウドをご利用いただいてるお客様から、よくいただくご質問に「Catoクライアントが繋がらないです」といったお問い合わせを頂きます。対処法や問題の切り分け方をご紹介いたします。 blog.usize-tech.com 2023.12.15 Catoが提供するサポート Cato社が提供しているサポートは以下の2つがあります。 Cato社へお客様から直接お問い合わせすることも可能ですが、英語のみでの問い合わせになることにご注意ください。 また、弊社のAIチャットボットとは別に、Cato社提供のAI機能がございます。 Cato社へのチケットによる問い合わせ　 ※問い合わせ言語は英語のみ Cato Networksへの問い合わせ、調査依頼方法について | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Catoクラウド利用時にトラブル等が発生した際は、Cato Networks社のサポートへ直接問い合わせや調査を依頼することが可能です。Cato社のサポートとのやり取りは、すべて英語となります。日本... cato-scsk.dga.jp CatoのAIアシスタント　 ※情報源はKnowledgeBaseのみ 【Catoクラウド】新機能「AIアシスタント」がリリース Catoクラウドより、2025年1月6日のアップデートにてAIアシスタントがリリースされました。AIアシスタントの実際の使用感や回答精度などについて記載しています。 blog.usize-tech.com 2025.01.30   最後に いかがでしたでしょうか。 ご覧いただいた通り、Catoでは様々な機能がありますので、PoCでは特に気になる機能からピックアップして検証いただくことをオススメします。 また、SCSKでのPoCご支援では、これまでの多くのご支援実績に基づいたサポートと、FAQサイトやAIチャットボットなどをご提供させていただきますのでご安心してご依頼いただければと思います！

こんにちは、SCSKの伊藤です。 保守業務とは切っても切れないトラブルシュート。 本記事では、LifeKeeperでのイベント監視および参照方法について、設定方法も含めてご紹介します。 LifeKeeperイベント監視の種類について イベント監視の種類について、LinuxとWindowsで下記の方法があります。 【Linux】 ログ SNMPトラップ メール 【Windows】 ログ SNMPトラップ   LifeKeeperログの確認方法 LifeKeeperのログについては、下記の方法で参照することができます。 [Linux]CLIコマンドでログファイル「/var/log/lifekeeper.log」を表示する。 [Windows]WindowsのイベントビューアからApplicationおよびシステムを表示する。   [Windows/Linux共通]LifeKeeper GUIまたはLifeKeeper Web Management Consoleから、リソースツリーのサーバ名を右クリックし、表示されたメニューから[View Log](日本語の場合は[ログの表示])をクリック   LifeKeeperログの見方 LifeKeeperのログは、以下のような形式で出力されます。 LifeKeeper for Linuxのログ Aug 25 13:25:19 rhel01 quickCheck[4974]: ERROR :qsp: quickCheck : QSP-snmptrapd : 134607 : systemctl command has failed for “QSP-snmptrapd” ERROR 　　　　　：　重大度 quickCheck 　　　：　実行処理 QSP-snmptrapd  　：　リソース名 134607 　　　　　：　コード systemctl～ 　　　：　メッセージ   LifeKeeper for Windowsのログ [08/29/2025 11:25:36] EventType: Error, Source: LifeKeeper, Category: General Process: lkresfail.exe(1168) * ERROR * (No. 1620 ) Local recovery of resource IP-192.168.10.55 failed. ERROR　  　　　　　：　重大度 1620 　　　　　　　：　コード Local Recovery～ 　：　メッセージ 色を付けた部分の意味は、それぞれ下記の通り。   重大度 EMERG/FATAL LifeKeeper自体の動作に影響を及ぼす可能性のある内容 ERROR LifeKeeperのサービスやリソースに影響を与える障害 WARN LifeKeeperのサービスやリソースに対し、直ちに異常を示すものではない注意や警告 NOTIFY LifeKeeper自体やリソース等の状態が遷移したこと示す通知 INFO LifeKeeperに関する情報のメッセージ   実行処理(Linuxのみ) restore リソースの起動処理 remove リソースの停止処理 quickCheck リソースの監視処理 deepCheck リソースの詳細監視処理 recover リソースの回復処理 <空白> 上記のいずれにも該当しないLifeKeeperの内部処理など   リソース名(Linuxのみ) アラート元のリソース名が表示されます。   コード・メッセージ 各コードおよびメッセージは、SIOSマニュアルサイトのメッセージカタログに記載されておりますが、記載がないメッセージの詳細を確認したい場合はSIOSへの問い合わせが必要になります。 LifeKeeperメッセージカタログ(Linux) https://docs.us.sios.com/spslinux/9.9.1/ja/topic/combined-message-catalog LifeKeeperメッセージカタログ(Windows) https://docs.us.sios.com/sps/8.11.0/ja/topic/combined-message-catalog DataKeeperメッセージカタログ(Windows) https://docs.us.sios.com/sps/8.11.0/ja/topic/message-catalogs Linux版はv9.9.1、Windows版はv8.11.0のリンクとなります。 Linux版は、LifeKeeperメッセージカタログにDataKeeperのメッセージも含まれます。   SNMPトラップによるイベント通知 LifeKeeperは、SNMPトラップでイベント通知することができます。 LifeKeeperのSNMPトラップはOSの機能を使用しているため、Windowsの場合は『SNMP サービス』の機能を追加、Linuxの場合は「net-snmp-utils」(RHEL5以降)または「net-snmp」(SLES11以降)のパッケージ導入を事前に完了しておく必要があります。 WindowsにSNMPサービスをインストールせずLifeKeeperをインストールした場合、LifeKeeperのSNMPトラップ設定がスキップされてLifeKeeperでSNMPトラップで利用できなくなりますので、LifeKeeperの再インストール処理を実行する必要があります。   LifeKeeper for LinuxのSNMPトラップ設定方法 CLIにて「/opt/LifeKeeper/bin/lk_configsnmp <IPアドレスorホスト名> –query」コマンドを実行 CLIにて「/usr/share/snmp/snmp.conf」ファイルに”defCommunity <コミュニティ名>”の記載を追加 (snmp.confファイルが存在しない場合は作成)   LifeKeeper for WindowsのSNMPトラップ設定方法 1. Windowsツールのサービスから『LifeKeeper External Interfaces』 を起動（デフォルトは自動起動） 2. Windowsツールのサービスから『SNMP サービス』のプロパティを開き、「トラップ」タブより”コミュニティ名”と”トラップ送信先”を追加 3. Windowsツールのサービスから『SNMP サービス』を再起動   SNMPトラップ通知の見方 LifeKeeperのSNMPトラップは、以下のような形式で出力されます。   LifeKeeper for LinuxのSNMPトラップ Aug 27 16:22:18 snmpserver01 snmptrapd[2343]: 2025-08-27 16:22:18 lkserver02 [UDP: [192.168.10.102]:33294->[192.168.10.100]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (6370) 0:01:03.70#011SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.7359.1.0. 100 #011SNMPv2-SMI::enterprises.7359.1.1 = STRING: “LifeKeeper Startup Complete” lkserver02　 　　　 ：　SNMPトラップ送信元サーバ 100 　 　　　　　　  ：　トラップコード “LifeKeeper～ 　　　：　メッセージ   LifeKeeper for WindowsのSNMPトラップ Aug 27 15:42:47 snmpserver01 snmptrapd[2343]: 2025-08-27 15:42:47 192.168.10.99 (via UDP: [192.168.10.99]:51372->[192.168.10.100]:162) TRAP, SNMP v1, community public#012#011SNMPv2-SMI::enterprises.7359.1 Enterprise Specific Trap ( 111 ) Uptime: 0:06:28.38#012#011SNMPv2-SMI::enterprises.7359.1.1.0 = STRING: “LifeKeeper Manual Switchover Complete” #011SNMPv2-SMI::enterprises.7359.1.3 = STRING: “LKSERVER01″#011SNMPv2-SMI::enterprises.7359.1.3 = Hex-STRING: 32 30 32 35 94 4E 20 38 8C 8E 20 32 37 93 FA 20 #01290 85 97 6A 93 FA 20 31 35 3A 34 32 3A 34 38 20 #01220 20 20 #011SNMPv2-SMI::enterprises.7359.1.3 = STRING: “ IP-192.168.10.111 “ 192.168.10.99　 　：　SNMPトラップ送信元サーバ 100 　 　　　　　　  ：　トラップコード “LifeKeeper～ 　　　：　メッセージ IP-192.168.10.111 ：　リソース名   使用するSNMPクライアントおよびMIB導入状況によって、表示形式が若干異なる場合があります。 色を付けた部分の内、トラップコードおよびメッセージ以外の意味については「LifeKeeperログの見方」箇所を参照。 トラップコード・メッセージ 各トラップコードおよびメッセージは、SIOS技術情報サイトに一覧が記載されております。 SNMP トラップのメッセージが出力されるケース https://lkdkuserportal.sios.jp/hc/ja/articles/900004364383–Linux-Windows-SNMP   特定アラートのみをSNMPトラップ送信するような設定はありませんので、SNMPトラップの受信先で振り分けする必要がある点に注意してください。   メールによるイベント通知 LifeKeeperは、メールにてイベント通知することができます。 LifeKeeperのイベントメール通知機能は、mailxまたはs-nailパッケージのメールユーティリティを使用して通知を送信するため、事前にメールユーティリティの導入および設定が必要となります。 メールの設定については、その環境に合わせた設定が必要になります。   ・LifeKeeper for Linuxのイベントメール通知設定方法 CLIにて「/opt/LifeKeeper/bin/lk_confignotifyalias <送信先メールアドレス>」コマンドを実行   イベントメール通知の見方 LifeKeeperのイベントメール通知は、以下のような形式で出力されます。   LifeKeeper for Linuxのイベントメール通知 差出人　：　送信元サーバのメールアドレス(メールの設定により異なります) 件名　　：　メッセージ 内容　　：　メッセージ(件名と同じ)   メッセージ 各メッセージは、SIOSマニュアルサイトに一覧が記載されております。 メールが生成される LifeKeeper のイベント https://docs.us.sios.com/spslinux/9.9.1/ja/topic/overview-of-lifekeeper-event-email-notification   一部のイベントのみ送信または除外するような設定はありませんので、メールを受信する環境にて振り分けおよび除外する必要がある点に注意してください。   さいごに 今回はLifeKeeperのイベント監視についてご紹介させていただきました。 メール通知に関しては、お客様から問い合わせをいただくことも多々ありますので、少しでも参考になれば幸いです。   詳しい内容をお知りになりたいかたは、以下のバナーからSCSKLifekeeper公式サイトまで

こんにちは。SCSK渡辺(大)です。 外を歩いていたら目が痒くなり、クシャミが出ました。 秋花粉の足音が聞こえた気がして震えています。 さっそく納品 500円で音声付きアニメーション動画は作れます。 ただし何かしらの妥協が必要だということが以下の成果物から感じていただけるかと思います。 アニメーション動画 キャラクターの造形が若干崩れ、音声は機械的な声になっています。 苦手な方は視聴をお控えください。 本当は30秒にしたかったのですが、キャラクターの造形が崩れてしまうものが多く、比較的綺麗に仕上がった動画を採用しました。 奇跡的に8～9秒あたりで音がハマっています。 「ワン！」の後の言葉は犬が話していると思ってください…。 document.createElement('video'); https://blog.usize-tech.com/contents/uploads/2025/08/anime.mp4 概要資料 6スライド目の構築手順フローは想像していたものと異なっているため、後半で補足します。   まずは感想 画像や動画、音声を直感的に作れるのは凄く楽しかったです。 AWS Elemental MediaConvertは正直存在を認知できていませんでした。便利なサービスですね。私のような一般人はどちらかというと日常生活で使う機会が多いのかと思います。 Amazon Nova Reelは発展途上という感じがしました。 現状だとファインチューニングが出来ないので、プロンプトが重要かと思います。 今回は奇跡的にキャラクターの造形が大きく崩れない動画が生成されましたが、本来は意図的に生成できないといけないと思います。他サービスと比較するとコストが高いので、慎重に使わないとですね。 Amazon PollyのエンジンにGenerative（生成AI）があるのですが、残念ながら日本語は非対応でした…。 Amazon Nova Sonicも日本語は非対応なので、Amazon PollyのGenerativeはAmazon Nova Sonicを使っているのかと思われます。 以下の記事にあるようにAmazon Nova Canvasはファインチューニングできるので、現在の環境下で想像通りのアニメーション動画を作成したい場合にはAmazon Nova Canvasだけでもファインチューニングしたほうが良い気がしました。 Amazon BedrockでWordPress記事のアイキャッチ画像を自動生成する Amazon Bedrockを用いて、WordPress記事のアイキャッチ画像を自動生成・付与する仕組みをつくってみました。 blog.usize-tech.com 2025.08.31   背景 もともと、業務とは別に、AWS上で何か子供向けのコンテンツを作りたいなとは考えており、「ゲーム」「絵本」「アニメ」が候補でした。 前々回、前回と２回連続で「ゲーム」に関する記事を書いてみたところ、前回の記事について同僚から「Amazon Nova SonicでBGMも作れるのかな？」というコメントをいただいたので、Aamzon Nova Sonicを調べてみました。 Aamzon Nova SonicのコンセプトからするとBGMを作成する用途ではなさそうでしたが、簡単に「声」を作成できるという点に興味を持ちました。 その後、Amazon Novaに関する勉強会に参加し、Amazon Nova Reelで6秒以上の動画（最大120秒)を作成できるようになったことを知りました。 最後に、最近ついにKiroと友達になれたことで、今回の記事執筆に至りました。   新しい友達のKiro まだ数日触っただけですが、個人的に気に入っていることは以下です。 軽い ログが分かりやすい MCPの実行結果を畳んで表示してくれる AWSCLIの実行状況がターミナルで見れる 本当はKiroのSpecモードを利用してみたかったのですが、今回の方法でアニメーション動画を作るにはオーバースペックに感じたため、Vibeモードを利用しました。 近いうちにSpecモードも触ってみたいです。 ちなみに、はじめに掲載した概要資料はHTML×CSS×JavaScriptで作られており、こちらはKiroに作ってもらいました。 以下のイベントに参加したときに紹介されていた手法です。 HTML、CSS、JavaScriptを扱える人は、たたき台を作ってKiroに渡すか、Kiroにたたき台を作ってもらって自身で修正するほうが早いと思います。 Amazon Q Developer Meetup #2 Amazon Q Developer を業務で活用した成果共有と最新情報 Update | AWS Startups Amazon Q Developer Meetup #2 Amazon Q Developer を業務で活用した成果共有と最新情報 Update aws.amazon.com 作成を依頼したら快諾してくれました。 AWS公式アイコンを使ってくれたのは嬉しいポイントです。 配色を変えたパターンも作成してくれました。 Hey Kiro, Spotifyのプレイリストで打線組んで。 AWSが発表した次世代エージェント型IDE「Kiro」を実際に触ってみて、Webアプリケーションを構築してみた体験記となります。 blog.usize-tech.com 2025.08.14 KiroでTerraformコードのテストをする 先日AWSからリリースされたKiroは、AIが仕様書やタスクリストを作成しながら実装を行ってくれる「仕様駆動開発」が特徴です。Terraformのテストコードの作成とテストを実施しようと思います。 blog.usize-tech.com 2025.08.25   アニメーション動画の作り方 概要資料の6スライド目にある構築手順フローは大雑把なので、もう少し詳細に記載します。 画像生成用プロンプトの生成 利用サービス：Amaozn Nova Pro インプット：自身のVibe（ex.キャラクターは犬、場所は草原、日本人向けの見た目） アウトプット：画像生成用プロンプト（英文） 画像の生成 利用サービス：Amazon Nova Canvas インプット：Amazon Nova Proで生成したプロンプト アウトプット：画像（ローカルにダウンロード） 補足：8枚の生成で満足した結果になりました。概要資料にある21枚を大きく下回りました。 動画生成用プロンプトの生成 利用サービス：Amaozn Nova Pro インプット：Amazon Nova Canvasで生成した画像、自身のVibe（ex.キャラクターを動かして欲しい） アウトプット：動画生成用プロンプト（英文） 動画の生成 利用サービス：Amazon Nova Reel インプット：Amazon Nova Canvasで生成した画像、Amazon Nova Proで生成したプロンプト アウトプット：動画（自動でAmazon S3バケットにダウンロード） 補足：今回の難所でした…。納品した12秒の動画はテストで生成したものです。その後に30秒の動画をいくつか生成しましたが造形が崩れてしまい公開は難しいと判断しました…。 音声生成用プロンプトの生成 利用サービス：Amazon Nova Pro インプット：Amazon Nova Reelで生成した動画、自身のVibe（ex.キャラクター同士で会話して欲しい） アウトプット：音声生成用のプロンプト 補足：生成後に動画の時間に合うよう手動で調整しました 音声の生成 利用サービス：Amazon Polly Neural インプット：Amazon Nova Proで生成したプロンプト アウトプット：音声（ボタン１つでAmazon S3バケットにダウンロード） 動画と音声の結合 利用サービス：AWS Elemental MediaConvert インプット：動画、音声（どちらもAmazon S3バケットに存在している必要あり） アウトプット：音声付きの動画（Amazon S3バケットに出力） 補足：知識ゼロだったのでKiroにやってもらいました。参考記事にあるSTS一時認証情報を1コマンドでcredentialsファイルに保存できるPythonスクリプトを導入しておくと便利です。 【Amazon Nova入門】テキスト・画像・動画・音声を扱うモデルの種類と特徴まとめ AWSの基盤モデル「Amazon Nova」について、基礎からビジネス活用までを徹底解説します。Amazon Bedrockで利用可能なNovaファミリー「Micro, Lite, Pro, Premier」をはじめ、画像生成AI「Nova Canvas」、動画生成AI「Nova Reel」、音声AI「Nova Sonic」など、各モデルの特徴を分かりやすく表で比較。AWSコンソールを使った具体的な有効化手順からPlaygroundでの試し方まで、初心者でもすぐに始められるようにガイドします。さらに、ビジネス活用の事例もご紹介。Amazon Novaの基本を学びたい方、知識をおさらいしたい方、生成AIの導入を検討している方に最適な内容です。 blog.usize-tech.com 2025.07.28 Amazon Nova を触ってみた (画像＆動画生成編) 画像生成モデルAmazon Nova Canvas、動画生成モデルAmazon Nova Reelについてまとめました。 blog.usize-tech.com 2025.02.17 Amazon Nova Canvas で画像生成してみた Re:Invent2024で発表されたAmazon Bedrockの新しい画像生成モデル「Amazon Nova Canvas」は新たな選択肢として注目を集めています。今回、Canvasを使って画像生成をしてみようと思います。 blog.usize-tech.com 2025.01.30 STS一時認証情報を1コマンドでcredentialsファイルに保存する AWSアカウントポリシーで多要素認証が強制される場合、アクセスキーとシークレットキーのみではAWS CLIを使用することができず、MFAによる認証を経て一時的なセッションキーを取得する必要があります。それらの情報を取得しcredentialsファイルに簡単に保存するpythonスクリプトをご紹介します。 blog.usize-tech.com 2022.05.09 AWS Elemental MediaConvert の API エンドポイントがアカウント固有でなくなっていた件 突然？AWS Elemental Media Convert の API エンドポイントが変わっていたので気付いたことを紹介します。 blog.usize-tech.com 2024.07.16 [React] react-player を使ってストリーミング動画ビューア画面をつくる React アプリ内にストリーミング用動画ファイルを再生させる動画ビューア画面の作成方法を紹介します。react-player というモジュールを使用します。 blog.usize-tech.com 2022.06.29   画面キャプチャで振り返り すべて画面キャプチャを取得したわけではありませんが、参考までに掲載します。 Amazon Nova ProにAmazon Nova Canvasに渡すプロンプトのテンプレートを聞きました。（メモからですみません） Amazon Nova ProにAmazon Nova Canvasに渡すプロンプトを英文で作ってもらいました。（メモからですみません） Amazon Nova Canvasではじめに生成してもらった画像の1つです。 この後、カラーパレットに赤を追加したり調整しました。 Amazon Nova ProにAmazon Nova Reelに渡すプロンプトのテンプレートを聞きました。 Amazon Nova Reelで動画生成をしました。 Amazon Nova Reelで生成された動画がAmazon S3バケットに格納されました。 Amazon Pollyで生成された動画がAmazon S3バケットに格納されました。 AWS Elemental MediaConvertはKiroに助けてもらいました。

こんにちは。最近、認定資格更新の波に追われグロッキー状態なSCSKの山口です。 「やる気に満ち溢れてたあの頃を思い出そう。」というわけで、今回はGoogle Cloud認定資格に初めてチャレンジする方向けのブログを、あの頃を思い出しながら書こうと思います。 ついでに、自分が更新の波を乗り切るための弾みにしようという魂胆です。 それではさっそく内容です。 Google Cloud認定資格一覧 執筆時点（2025年8月）の認定資格一覧です。 正式名称 略称（※大文字部分をとってます） Cloud Digital Leader CDL Generative AI Leader GAIL Associate Cloud Engineer ACE Associate Data Practitioner ADP Associate Google Workspace Administrator AGWA Professional Cloud Architect PCA Professional Cloud Developer PCD Professional Cloud DevOps Engineer PCDOE Professional Data Engineer PDE Professional Cloud Database Engineer PCDE Professional Cloud Security Engineer PCSE Professional Cloud Network Engineer PCNE Professional Machine Learning Engineer PMLE   多すぎてせっかく湧いたやる気が減りそうですが、Google Cloud認定資格の「入門編」のこのブログでは、 Cloud Digital Leader CDL Associate Cloud Engineer ACE にのみフォーカスします。   どれから受ける？ このブログを見てくれている方は技術職の方だけでなく営業職の方も見てくださっていると思います。 また、技術職の中でもベンダー資格がそもそも初めての方、他ベンダーの資格にチャレンジしたことある方、と状況が様々だと思うので、今日はできるだけ細かく場合分けします。 できるだけ細かくといいましたがこれが限界でした。 やっぱり最初の分岐が大事です。ちょっとでも「受けてみようかな？」と思った方は、是非このブログ読んでチャレンジして頂きたいです。やる気がまだ1％もない。という方も（もしかすると）このブログでやる気が湧くかもしれないのでぜひ最後まで見ていってください。   どんな資格？ 受ける資格を決めたら次に気になるのは試験の詳細と内容です。 まずはそれぞれの試験情報です。 試験情報   CDL ACE 試験時間 90分 120分 登録料（≒受験料） $99（税別） $125（税別） 言語 英語、日本語、スペイン語、ポルトガル語、フランス語 英語、日本語、スペイン語、ポルトガル語 試験形式 50~60問の多肢選択式 50 ～ 60 問の多肢選択（複数選択）式 実施方法 オンライン監視（自宅や職場で受験） オンサイト監視（テストセンターで受験） オンライン監視（自宅や職場で受験） オンサイト監視（テストセンターで受験） 有効期間 3年間 3年間 この2試験に限らずですが、Google Cloudの認定資格試験は基本的に50 ～ 60 問の多肢選択（複数選択）式です。 問題量がそこまで多いわけではないので、見直しまで完了したら 試験時間を待たずに終了 できます。 私はテストセンター受験派なのですが、120分の試験時間をフルで使ったことはなく、だいたい60~90分くらいで完了して帰ります。 そしてなんと、 受験後すぐに合否がわかります 。（落ちても精悍な顔つきで会場出ましょう。。。そして帰宅して泣きましょう） 正式な合否のメールは後日届きます。ただ、何度も試験受けていますが、私の経験で言うと、受験後わかる結果が覆ったことは一度もないです。   では、出題される内容を紹介していきます。 出題内容：CDL Google Cloudの最も基礎的なレベルの資格であり、 非技術者向けのビジネス寄りの内容 が中心です。 クラウドの概念から始まり、 Google Cloudのサービスがビジネス課題をどのように解決するか 、 デジタル変革（DX）の基本原則 について問われます。 デジタル変革の基本原則って何？となると思います。（私もなりました） 一般的に重要とされる、いくつかの基本的な原則を書いておきます。基本的にこれに則った回答が正解なことが多いです。 顧客中心主義：デジタル技術を活用して、顧客のニーズや行動を深く理解し、より良い体験を提供することを最優先とします。 データ駆動：収集・蓄積されたデータを活用して、意思決定を行います。 アジャイル：変化の激しいビジネス環境に迅速に対応するため、小規模な改善を短期間で繰り返し行います。 文化・風土の変革：デジタル技術を使いこなすための組織文化と従業員のマインドセットを変革します。 例えば、クラウド活用しようとしてるのに「手動でやってやるぜ、」みたいな力業な回答は間違いである可能性が高いです。 このように一般的な内容も問われますが、もちろんGoogle Cloudのサービスについてたくさん問われます。 最低限、「 なんとなくどんなサービスかわかる 」状態になっておいたほうが良いサービスをまとめておきます。 サービスカテゴリ 主なサービス コンピューティング Compute Engine (GCE)  App Engine (GAE) Cloud Functions (CF) ストレージ Cloud Storage (GCS)  Cloud SQL BigQuery ネットワーキング Virtual Private Cloud (VPC) Cloud Load Balancing (CLB) セキュリティと管理 IAM (Identity and Access Management) Cloud Logging / Cloud Monitoring AI・機械学習 Vertex AI ビッグデータ BigQuery Dataflow API管理 Apigee 同じサービスカテゴリで複数のサービスがある場合は、 ユースケースや要件に合わせて サービスを選ぶ必要があります。 出題内容：ACE CDLと比較すると、Google Cloudのリソースを実際に 構築・運用する能力 が多く問われます。 そのため、各サービスの機能や、コマンドラインでの操作方法、設定項目など、より 具体的な知識 が必要です。CDLの内容に加え、より深く、そして広範なサービスを理解する必要があります。 頻出のサービスは下記です。 サービスカテゴリ 主なサービス コンピューティング Compute Engine (GCE) Kubernetes Engine (GKE) App Engine (GAE) Cloud Functions (CF) ストレージ Cloud Storage (GCS) Cloud SQL Cloud Spanner BigQuery Memorystore ネットワーキング Virtual Private Cloud (VPC) Cloud Load Balancing (CLB) Cloud DNS Cloud CDN セキュリティと管理 IAM (Identity and Access Management) Cloud Logging / Cloud Monitoring IAM Cloud KMS 管理ツール Cloud Shell  Cloud SDK gcloudコマンド デプロイ・CI/CD Cloud Build CDLの頻出サービスとあまり大差ないように見えますが、その分、 各サービスを深堀した内容 が問われるので注意が必要です。 少しでも心配な方は、CDL→ACEと着実にステップアップしていくことをお勧めします。 そして、このブログでは深く触れませんが、ACEが取れるならプロフェッショナル資格の 「Professional Cloud Architect（PCA）」 に必要な知識のほとんどが身についているはずです。 内容もかなり重複しているため、ACEが取れたらすぐPCAを受験することをお勧めします。 【GCP】?Google Cloud 認定資格 全冠までの2年間を振り返る? Google Cloud歴2年の筆者が二年間で全冠を達成した軌跡と所感を、筆者の主観たっぷりで書きます。 オススメの取得順序も紹介しているのでぜひご覧ください。 blog.usize-tech.com 2024.09.24   どう対策する？ 受ける資格を決めたら早速対策を始めましょう。 私がいつもやっている対策は下記です。どの試験の時も概ね共通しています。 順番通りに書きます。 公式ドキュメントを見る CDLで言うと、下記のサイトです。 Cloud Digital Leader  |  Learn  |  Google Cloud Cloud Digital Leader の認定資格を取得し、クラウドの基礎、Google Cloud の製品とサービス、ビジネスのリーダーシップに関する専門知識を検証します。 cloud.google.com このページで何するかというと 必要な知識分野 試験ガイド読み込む わからない単語、用語を一通り調べてみる 模擬試験を受ける の三つです。 必要な知識分野 CDLの公式ドキュメントを見ると、ページの上部に Cloud Digital Leader の認定試験では、次の分野の知識が評価されます。 Google Cloud によるデジタル トランスフォーメーション Google Cloud によるデータ トランスフォーメーションの探求 Google Cloud の AI を活用したイノベーション Google Cloud によるインフラストラクチャとアプリケーションのモダナイゼーション Google Cloud で実現する信頼とセキュリティ Google Cloud 運用でのスケーリング という記載があります。 この情報から実際に私が読み取る情報は、 AIも出るんか インフラ、データ、アプリ全部出るんやな セキュリティと運用も抑えとくか です。ここでドキュメントばかり見て時間を食うのももったいないのでこのくらいで次に行きます。 試験ガイドを読み込む 次に試験ガイドです。CDLのガイドは下記です。 https://services.google.com/fh/files/misc/cloud_digital_leader_exam_guide_japanese.pdf?hl=ja services.google.com なんだか長いPDFで見るの疲れそうですね。 ただ、先ほど見た知識分野の出題割合とかの情報があるので、有益な情報が多いです。 2,3年前の私はここを頑張って一通り見ていましたが、 NotebookLM で簡単に 要約と知りたい情報の抽出 ができます。 【Google】【AIML】Googleが提供する『NotebookLM』が日本語対応されたので触ってみた NotebookLM について実際に触ってみたキャプチャと共にその魅力について少しだけご紹介させていただければと思います。 blog.usize-tech.com 2024.06.10 NotebookLMのデータソースとして試験ガイドを食わせることで、ガイド内の情報から 効率よく 情報収集すること可能になるので個人的にかなりおすすめです 。 わからない単語、用語を一通り調べてみる 試験ガイド内でわからなかった単語、用語を調べます。 ここでもNotebookLMが大活躍します。 模擬試験を受ける ここまで来たら、思い切って模擬試験を受けてみましょう。 本番の試験に近い問題が多く出題されるので、雰囲気をつかむことができます。 Google Formで問題に回答する形なので、スマホ一つで移動中にも簡単に受験することができます。 回答完了後、登録したメールアドレス宛にすぐに結果が届くので、復習しましょう。 ここまで来たら、ある程度戦える力がついていると思ますが、できるだけわからない単語をなくした状態で試験に臨むことを個人的に強くお勧めします。   まとめ いかがでしたでしょうか。 無事合格出来たら、数日以内にGoogleより公式のデジタルバッチが付与されます。自慢しまくりましょう。   このブログが、皆さんの “Google Cloud 認定エンジニア” としての第一歩の一助となれれば幸いです。

本記事では、TerraformでAzure環境構築を行う際に、ステートファイルをAzure Blob Storageで管理するための手順を解説します。 ステートファイルとは ステートファイルは、Terraformが管理するリソース（仮想マシン、ストレージ、ネットワーク等）の最新の状態が記述されたファイルです。このファイルによりTerraformは現在のインフラの構成を認識し、次回の処理時にどのリソースを追加・変更・削除するかを判断します。   ステートファイルの主な管理方法 1. ローカル 複数人での共有/ロック管理/バージョニングが行えません。個人開発や試験的利用では、ローカル管理でも問題ありません。 2. クラウド上のストレージ AWSではS3、AzureではAzure Blob Storage、Google CloudではGoogle Cloud Storageで管理できます。 複数人での共有/ロック管理/バージョニングも設定次第で行えます。 本記事では、Azure Blob Storageで管理する方法を解説します。 3. Terraform Cloud Hashicorpが提供しているTerraform公式のマネージドサービスです。クラウド上のストレージでの管理と同様に、複数人での共有/ロック管理/バージョニングも可能なため、Terraform Cloudを利用している場合はこのサービスで管理することをお勧めします。   手順 Azure Blob Storageの構築 Azure Blob Storageの作成はポータル上で行っても問題ありません。 Terraformで構築する場合は以下ようなファイルを使用し、リソースグループ、ストレージアカウント、Azure Blob Storageを構築します。 provider "azurerm" { features {} } # リソースグループ resource "azurerm_resource_group" "example" { name = "myResourceGroup" location = "japaneast" } # ストレージアカウント resource "azurerm_storage_account" "example" { name = "mytfstateaccount" resource_group_name = azurerm_resource_group.example.name location = azurerm_resource_group.example.location account_tier = "Standard" account_replication_type = "LRS" } # Azure Blob Storage resource "azurerm_storage_container" "example" { name = "tfstate" storage_account_name = azurerm_storage_account.example.name container_access_type = "private" } Terraformのバックエンド設定 Terraformの設定ファイル（構築するリソースのパラメータやTerraform自体の設定を記述するファイル）に以下のコードを記述し、手順1で作成したストレージをステートファイルの管理先として指定します。 terraform { backend "azurerm" { resource_group_name = "myResourceGroup" storage_account_name = "mytfstateaccount" container_name = "tfstate" key = "terraform.tfstate" } } Terraform初期化 以下のコマンドを実行し、Terraformを初期化します。 terraform init 初期化に成功するとプラグインのダウンロードやバックエンドの初期化が行われ、手順2で管理先として指定したストレージにステートファイル（terraform.tfstate）がアップロードされます。（下記画像参照） 以降Terraformを使用してAzureリソースを構築/変更するたびに、そのリソースのパラメータがステートファイルに書き込まれていきます。 Azure Blob Storageのtfstateコンテナにステートファイルがアップロードされました！   まとめ チームで作業を行う場合には、ステートファイルの共有とロック機能が重要となります。 本記事で紹介したように、ストレージを作成しTerraformの設定ファイルに数行追記するだけで簡単にAzure Blob Storageでの管理に設定できますので、Azureリソース構築にTerraformを使う際にはぜひご参照ください。

こんにちは。SCSKの嶋谷です。 今回もMackerelに関する記事を投稿します。 弊社が提供している監視サービスではNW機器の監視をしたいというお客様が一定数います。 Mackerelはエージェント型の監視サービスであるため、NW機器のようなエージェントをインストールすることができない機器の監視はどのように実現すると思いますか？ 例えば、NW機器の死活監視(Ping監視)を実現する機能があります。しかしこの機能だけでは不足おり、一例としてSNMP(特にTrap監視)での監視が挙げられます(後述)。そのため、お客様に対してMackerelを利用した監視サービスを提供する場合、Mackerelの標準機能ではSNMP監視を提供することが難しいです。 どうにかしたいなとMackerelのドキュメントを読み漁っていると、SNMP Get監視についてはプラグインが提供されていることを発見しました。しかし、SNMP Trap監視の機能については発見することができませんでした。そこで、SNMP Trap監視についてはTrapをログファイルに出力してMackerelのログ監視機能で代替できるのではないかと考え、実装してみました。 MackerelでのSNMP監視 Mackerelでは、メトリックプラグインを利用してSNMP Get監視を実現することが可能です。 こちらのプラグインはSNMP v2cに対応しております。 SNMP Trap監視はMackerelの機能としてはサポートされておりません。 そのため、SNMP Trap監視については監視不可能だと考えていました。 部署の先輩に相談すると、「Trapをログファイルに出力して、ログ監視で実現できそう」と助言をいただき、代替できそうと考え実装することにしました。 今回はSNMP GetのプラグインとSNMP Trapのログ監視を検証してみました。 機器構成 今回は検証機器の都合上NW機器をサーバで代替して検証を実施しました。それぞれのサーバの役割・機能については下記に示しております。 サーバA：監視マネージャー(ポーリングによる値取得、SNMP Trap受信) サーバAはsnmptrapdサービスとmackerel-agentがインストールされており、取得したSNMP監視に関するデータをMackerelに送信します。 サーバB(NW機器)：監視エージェント(SNMP Trap送信) サーバBはSNMPサービスがインストールされており、TrapデータをサーバA(監視マネージャー)に送信します。 SNMP Get監視 SNMP Get監視はMackerelのメトリックプラグインを利用することで実現することができます。 実装方法を以下に示します。(監視マネージャーにmackerel-agentがインストールされていることとファイアウォールでの通信が許可されていることを前提とします。) ① 監視エージェントにSNMPサービス(Linuxではsnmpd)をインストール 監視マネージャーからのポーリングに応答するためにインストールする必要があります。 ② SNMPサービスをインストール後、コミュニティ名、ポーリングを許可するIPアドレスを設定します。 (検証では監視エージェントをWindows Serverで構築しています) ③ 監視マネージャー側のmackerel-agentのコンフィグファイルに設定を追記 プラグイン名、メトリック名は任意で設定可能です。 コミュニティ名は監視エージェントで設定した名前を設定します。 [plugin.metrics.プラグイン名] command = ["mackerel-plugin-snmp", "-name", "グラフ名", "-community", "コミュニティ名", "OID:メトリック名"] ④ mackerel-agentを再起動 sudo systemctl restart mackerel-agent SNMP Trap監視 SNMP Trap監視はTrapをログファイルに出力してMackerelのログ監視で代替します。 実装方法を以下に示します。(ファイアウォールでの通信が許可されていることを前提とします) ① 監視マネージャーにnet-snmpをインストール これにより、snmptrapdサービスを利用することが可能となります。 ② snmptrapdのコンフィグファイルに以下を追記 コミュニティ名からのTrap受信を許可するための記述です。 authCommunity log, execute, net コミュニティ名 ③ snmptrapd.serviceに以下を追記 受信したログを指定したファイルに出力するための記述です。 ExecStart=/usr/sbin/snmptrapd -Lf ログファイルパス ④ snmptrapdサービスの永続化・再起動 下記コマンドを実行します。 systemctl daemon-reload systemctl enable --now snmptrapd systemctl restart snmptrapd   実行結果 SNMP Get監視 今回は検証としてCPU使用率を取得してMackerelに連携してみました。 SNMP標準のCPU使用率はコアごとのCPU使用率となっており、全体としての使用率ではありません。 実施方法を以下に示します。 ① コアごとのCPU使用率を確認 snmpwalk -v 2c -c コミュニティ名 IPアドレス .1.3.6.1.2.1.25.3.3.1.2 ② コアごとのOIDをmackerel-agentのコンフィグファイルに設定してデータを取得 プラグイン名、グラフ名、メトリック名は任意で設定可能です。 コミュニティ名は監視エージェントで設定した名前を設定します。 [plugin.metrics.プラグイン名] command = ["mackerel-plugin-snmp", "-name", "グラフ名", "-community", "コミュニティ名", ".1.3.6.1.2.1.25.3.3.1.2.1:メトリック名"] ③ mackerel-agentを再起動 ④ Mackerelのコンソールにグラフが表示される 今回対象としたサーバのコア数は2つであったため、2つの値を同じグラフに可視化しています。 値を取得してグラフに表示することは簡単にできましたが、取得したい値のOIDを調査することに苦戦しました。 SNMP Trap監視 今回は検証のため、snmptrapのテストコマンドを監視エージェントで実行し、監視マネージャーのログファイルに出力されるかを確認しました。確認後にMackerelでログ監視の設定を行い、検知可能かを確認しました。 実施方法を以下に示します。 ① 監視エージェントでテストコマンド実施 今回はlinkDownを疑似的に発生させました。 snmptrap -v 2c -c コミュニティ名 IPアドレス "" IF-MIB::linkDown IF-MIB::ifIndex i 1 ② ログファイルに出力されているかを確認 ログファイルにTrapが出力されていることを確認しました。Trapの内容を下記に示します。 NET-SNMP version 5.9.3 2025-08-25 09:52:51 ホスト名 [UDP: [送信元IPアドレス]:50163->[送信先IPアドレス]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (29120791) 3 days, 8:53:27.91 SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkDown IF-MIB::ifIndex = INTEGER: 1 ③ Mackerelでログ監視の設定を実装 今回はlinkDownを検知文字列としてコンフィグファイルに設定を追記しました。追記した内容を下記に示します。 Mackerelのログ監視の仕様については下記をご参照ください。 チェックプラグイン – check-log – Mackerel ヘルプ [plugin.checks.snmptraplog] command = ["check-log", "--file", "/var/log/snmptrapd.log", "--pattern", "linkDown", "--return", "--check-first"] ④ mackerel-agentを再起動 ⑤ アラートの確認 linkDownが含まれているログを検出し、アラートとして検知できました！ ここで1点注意点があります。 Mackerelのログ監視は1分間隔で監視を実施し(実行間隔については調整可能です)、1分間の間にログファイルへ出力されたTrapを対象とします。1分間に大量のTrapが出力され、ログ監視の実行間隔内で処理が完了できないとエラーが出力されます。 ログ出力の条件や実行間隔の設定も柔軟に行うことが必要かもしれません。 課題 SNMP Get、SNMP Trapともにデータの取得からMackerelへの連携やアラート検知を実装することができました。 今回の検証では標準のOIDを利用しており、ベンダー固有のOIDについては検証していません。 今後の検証を通して、標準情報だけでなくベンダー固有の情報もMackerelで監視可能か確認する必要があります。 ただ、MackerelでSNMPの監視を実現する第一歩になったと感じています。   まとめ 今回はMackerelのプラグインとログ監視の機能を用いて、SNMPの監視を実装することができました。 SNMP監視については触れたことがない領域だったため、概念を学習してから環境を構築する必要があったため時間がかかりました。 時間がかかった分、Mackerel上でグラフの可視化やアラートを検知できたときは感動しました！ 今後は、ベンダー固有のOIDでも監視が可能か検証することが必要と考えています。 最後までご覧いただきありがとうございました！

本記事は 夏休みクラウド自由研究2025 8/31付の記事です 。 こんにちは、SCSKの木澤です。 夏休みクラウド自由研究2025も最後の記事ですね。 アクセス頂いた皆様、記事投稿にご協力いただいた皆様、ありがとうございました。 今年の投稿を総括すると、特にAWSエンジニアからAmazon Q Developer CLIやKiroを用いてVibe Codingにチャレンジしてみた系の記事発信が多かったですね。 Kiroは仕様(Spec)駆動開発と、弊社のようなSIerのシステム開発手法に馴染みある開発手法に近いので私も期待しています。 自社のシステム開発（アプリケーション開発）に直接適用するには、まだハードルはあると感じますが、インフラ系の部署に所属する属するメンバーが多いTechHarmonyへの寄稿者（登録者）からの発信が多いことを踏まえると、今後の変革に期待できるなと思いました。 さて、今日は本サイトのようなWordPressサイトの管理業務を少しだけ改善する話をしたいと思います。 はじめに 本サイトはCMSとしてWordPressを利用しているのですが、WordPressでの記事の寄稿においては記事のタイトルと本文以外にも設定が必要な項目が多数あります。主なものとしては カテゴリ設定 タグの付与 メタディスクリプション（記事概要文）の入力 アイキャッチ画像の設定 特にアイキャッチ画像については作成が多少面倒なところもあり、寄稿者からの設定が漏れていることが多いかと思います。 本サイトでも一旦差し戻して設定をお願いしていますが、アイキャッチ画像は記事の本質的な部分でも無いので 寄稿者の手間を煩わすのもなぁ… というのが、当サイトのレビュー担当者としての感覚でした。 そこで今回は生成AIを利用してアイキャッチ画像の自動生成にチャレンジしてみたいと思います。   アーキテクチャ WordPress投稿時に自動的にCloudFrontのキャッシュクリアを行う方法について投稿について以前に記事化していますが、基本の仕組みとしては同じです。 WordPress記事更新時にCloudFrontのキャッシュを自動的にクリアする方法 WordPress記事の投稿・更新・削除、画像の差し替え時にCloudFrontのキャッシュをクリアする仕組みを開発しましたのでご紹介します。 これにより直ぐに更新を反映することができます。またキャッシュ時間を延ばしヒット率を上げることも期待できます。 blog.usize-tech.com 2022.03.14 今回はアイキャッチ画像が設定されていない際に、以下の処理を行い要件を満たすことにします。 記事本文から要約文を作成 要約文からアイキャッチ画像を作成 作成された画像をWordPressサイトのメディアライブラリにアップロード 当該記事にアイキャッチ画像を付与 なお今回、Amazon Bedrock上のLLMモデルにはAmazon Novaを利用しました 要約：Amazon Nova Pro 画像生成：Amazon Nova Canvas 要約する際に渡すプロンプトは以下のようにしました。 以下のブログ記事を要約して、200文字程度の紹介文形式にしてください （本文） 画像生成の際のプロンプトは以下のようにしました。 あなたは優秀なWebデザイナーです。 技術ブログの記事「（タイトル）」のアイキャッチ画像を作成してください。 記事の概要文は以下の通りです。 （概要） 今回、時間の関係でプロンプトをチューニングする時間が無かったので、精度は追って高めたいと思います。   設定方法 今回の手順の概要は以下の通りです。 WordPressサイトのアプリケーションパスワードを取得 Amazon Bedrock上でモデルアクセスを有効化 IAMロールを作成 Systems Managerパラメーターストアにプロンプトを保存 RequestsとBeattifulSoupを含んだLambdaレイヤーを作成 Lambda関数を作成し、レイヤーを割り当て、環境変数を設定 API Gatewayを設定しLambdaと紐付け WP Webhooksから呼び出す設定 WordPressアプリケーションパスワード取得 メディアライブラリへのアップロード及び記事の更新にWordPressのREST APIを利用します。 ユーザプロフィール内のアプリケーションパスワードでパスワードを発行しておきます。 Amazon Bedrockのモデルアクセス有効化 前述の通り、今回は Nova ProとNova Canvasを用います。 東京リージョンのNova Proはオンデマンド呼び出しに対応していないようなので、今回は別々のリージョンにしました。 Nova Pro : 北バージニアリージョン（us-east-1） Nova Canvas：東京リージョン（ap-northeast-1）   IAMロール作成 最小権限の法則に則りIAMロールを作成します。 今回の仕組みの場合、IAMロールに与えるポリシーは以下となります。 AWS Systems Manager(Parameter Store)からの値の取得 ssm:GetParameterHistory ssm:GetParametersByPath ssm:GetParameters ssm:GetParameter Amazon Bedrockでの推論実行 bedrock:InvokeModel CloudWatch Logsへのログ送信 logs:CreateLogGroup logs:CreateLogStream logs:PutLogEvent Systems Managerパラメーターストアにプロンプトを保存 今回は2回LLMを呼び出しますので、2つのストアを作成します。 要約用プロンプト 新規にtextデータ形式のパラメータストアを作成し、以下の文書を入力します。 以下のブログ記事を要約して、200文字程度の紹介文形式にしてください （本文） 画像生成用プロンプト 同様に以下の文書を入力します。 あなたは優秀なWebデザイナーです。 技術ブログの記事「（タイトル）」のアイキャッチ画像を作成してください。 記事の概要文は以下の通りです。 （概要） Lambdaレイヤーを作成 後述のLambda関数では、Pythonプログラムの外部ライブラリとしてRequestsとBeattifulSoupを利用していますので、Lambdaレイヤーを作成します。 CloudShellにログインし、以下のようにコマンドを実行します。 $ mkdir ~/python $ cd python $ pip install beautifulsoup4 requests -t . $ cd $ zip -r lambda-layer.zip ./python CloudShellのアクションボタンからファイルのダウンロードができますので ~/lambda-layer.zip  と指定しダウンロードします。 続いてLambdaのAWSコンソールよりレイヤーを作成します。 互換設定はもう少しシビアに見た方が良いと思いますが。 Lambda関数の作成 いよいよLambda関数を作成します。 Python 3.13で新規関数を作成し、上述で設定したIAMロールを割り当てます。 ソースコードは以下のようにしました。 import os import boto3 import json import base64 import random import requests from datetime import datetime from bs4 import BeautifulSoup # boto3の初期設定 bedrock = boto3.client('bedrock-runtime', 'us-east-1') ssm = boto3.client('ssm', 'ap-northeast-1') def lambda_handler(event, context): # メタディスクリプションが未設定の場合に実行 if event['post_thumbnail'] == 0: result = create_eyecatch(event) else: result = {"message":"Eyecatch image was exists."} print(result) return { 'statusCode': 200, 'body': result } def create_eyecatch(event): # ブログ本文から文字列抽出 soup = BeautifulSoup(event['post']['post_content'], 'html.parser') title = event['post']['post_title'] texts = soup.get_text() # WordPressの記事IDを取得 postid = event['post_id'] # Bedrockで要約を実施 summary = get_summary(texts) # 画像を生成 image = create_image(title,summary) # WordPressのメディアライブラリにアップロード imageid = upload_media(postid, image) # 記事を更新 result = update_post(postid, imageid) return imageid def get_summary(texts): # AWS Systems Managerパラメータストアの読み込み pstore = os.environ['PARAMETER_STORE1'] prompt = ssm.get_parameters(Names=[pstore])['Parameters'][0]['Value'].replace('（本文）',texts) # Amazon Bedrockで要約する modelId = 'amazon.nova-pro-v1:0' inferenceConfig = { "temperature": 0.1, "topP": 0.9, "maxTokens": 500, "stopSequences":[] } message = [ { "role": "user", "content": [{"text":prompt}] } ] response = bedrock.converse( modelId = modelId, messages = message, inferenceConfig = inferenceConfig ) # 要約を取得 summary = response['output']['message']['content'][0]['text'] return summary def create_image(title,summary): # AWS Systems Managerパラメータストアの読み込み pstore = os.environ['PARAMETER_STORE2'] prompt = ssm.get_parameters(Names=[pstore])['Parameters'][0]['Value'] prompt = prompt.replace('（タイトル）',title).replace('（概要）',summary) # Amazon Bedrockでイメージ生成を行う modelId = 'amazon.nova-canvas-v1:0' seed = random.randint(0, 858993460) request_body = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": prompt }, "imageGenerationConfig": { "numberOfImages": 1, "width": 1280, "height": 640, "cfgScale": 6.5, "seed": seed, "quality": "standard" } } response = bedrock.invoke_model( body=json.dumps(request_body), contentType='application/json', accept='application/json', modelId=modelId ) response_body = json.loads(response['body'].read()) image_data = base64.b64decode(response_body['images'][0]) return image_data def upload_media(postid, image): # WordPressのメディアライブラリにアップロード # 環境変数の読み込み url = os.environ['WP_URL'] + "wp-json/wp/v2/media" username = os.environ['WP_USER'] password = os.environ['WP_PASSWORD'] filename = str(postid) + ".png" headers = { 'Content-Type': 'image/png', 'Content-Disposition': 'attachment; filename=' + filename } # メディアのアップロード result = requests.post(url, headers=headers, data=image, auth=(username, password)) # メディアのIDを取得 res_dict = result.json() imageid = res_dict['id'] return imageid def update_post(postid,imageid): # WordPressに書き込み # 環境変数の読み込み url = os.environ['WP_URL'] + "wp-json/wp/v2/posts/" + str(postid) username = os.environ['WP_USER'] password = os.environ['WP_PASSWORD'] headers = {'Content-Type': 'application/json'} payload = { 'featured_media': imageid } result = requests.post(url, headers=headers, json=payload, auth=(username, password)) return result Novaの呼び出し方法には本サイトの以下記事を参考にしました。 Amazon Nova を触ってみた (テキスト生成編) 昨年のre:Invent 2024にて、Amazon Bedrockでのみ利用可能なモデルとしてAmazon Novaが発表されました。本記事では、Amazon Novaシリーズの中でテキスト生成が可能な3つのモデル(Micro、Lite、Pro)についてまとめました。Amazon BedrockマネジメントコンソールとConverse APIから実行する方法をご紹介します。 blog.usize-tech.com 2025.01.29 Amazon Bedrock を利用して、画像生成アプリケーションを開発してみた ! 生成系 AI アプリケーションの開発を支援する Amazon Bedrock の初学者や興味がある方を対象に、Amazon Bedrock を用いた画像生成アプリケーション開発の流れを解説します。 aws.amazon.com なお、本Lambda関数の実行時間は10秒を超えることがあるので、タイムアウトは20秒以上に設定することを推奨します。 続いて環境変数に必要なパラメータを指定します。 PARAMETER_STORE1：要約用プロンプト PARAMETER_STORE2：画像生成用プロンプト WP_URL：WordPressサイトのURL（トップ） WP_USER：WordPressユーザーID WP_PASSWORD：WordPressアプリケーションパスワード API Gatewayを設定しLambdaと紐付け 本手順は過去の記事と同じですが、画面イメージが変更されているので改めて記載します。 WordPress記事更新時にCloudFrontのキャッシュを自動的にクリアする方法 WordPress記事の投稿・更新・削除、画像の差し替え時にCloudFrontのキャッシュをクリアする仕組みを開発しましたのでご紹介します。 これにより直ぐに更新を反映することができます。またキャッシュ時間を延ばしヒット率を上げることも期待できます。 blog.usize-tech.com 2022.03.14 APIの作成から名前を指定しREST APIを作成します。 メソッドの作成からPOSTを選択し、Lambda関数を指定します。 メソッドリクエストの設定から、APIキーを有効にしてください。 任意のステージでデプロイ後、左側のメニュー「APIキー」からAPIキーを作成します。 使用量プランを作成し、APIキーと紐付けます。 WP Webhooksからの呼び出し設定 最後にWordPressのプラグイン、WP Webhooksからの呼び出し設定を行います。 プラグインの設定画面を開き「Send Data」⇒「Post Updated」に、API GatewayのURLを追加します。 続いて「Authentication」⇒「Create Template」からAPIキーの箱を作成します。 API Gatewayで発行されたAPIキーを入力します。 最後に、先程作成したAPI設定を開き「Add authentication template」から作成したAPIキーを割り当てます。   結果・今後に向けて 以上の設定で、記事更新時にアイキャッチ画像が付与されていない際に、Amazon Nova自動設定されるようになりました。 試しに本記事の内容を掛けてみたところ、こんな画像が生成されました。 WordPressっぽい画像を生成しようとしてますね・・・w 但し、技術ブログのアイキャッチ画像としては品質的にまだまだ厳しい感じで。 プロンプトエンジニアリングの話もありますが、Amazon Nova Canvasではファインチューニングもできるようになっているので、オリジナルの画像生成にチャレンジしてみたいと思います。 コストも気になりますが・・・ Amazon Nova Canvas がファインチューニングのサポートを開始 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon Nova Canvas がファインチューニングのサポートを開始 aws.amazon.com

本記事は 夏休みクラウド自由研究2025 8/30付の記事です 。 私生活と趣味の分野でしか利用していなかった AI がどんどん進化してきて仕事にも使うようになり、ますます AI まみれになってきている兒玉 (コダマ)です。 今回は、 Amazon Q Developer を使い始めて、使い始める前の想像以上に「できる」と感じました。皆様にもオススメできるようなAI支援ツールになっているので、ぜひ使っていただきたいな、との思いを込めて、今回はその楽しいやり取りをご紹介します。 … こんな書きっぷりだと、いかにも自分が開発したかのように見えますが、私は Amazon Q Developer の開発担当者ではありません。皆で Amazon Q Developer を使って仕事を早く片付けて、一秒でも早く私が仕事から開放されてゲームができるようになるといいなぁ、と、思っているだけです。あしからず。 急に必要になった 急に、「AWSのサービスの料金テーブルがほしい！」と思い立ちました。（何故かとかはもちろんあるのですが、まぁ、この一文は言ってみれば、異世界モノの小説の導入部みたいなものだと思ってもらえればよいです。） ちょっと調べると、なるほど、料金表ファイルがダウンロードできるとのこと。 サービス料金表ファイルの読み取り AWS のサービス のサービス料金表ファイルの読み取り AWS のサービス - AWS 請求 のサービス料金表ファイルを読み取る方法を理解します AWS のサービス。 docs.aws.amazon.com よし、ダウンロードしたぞ！ サイズみてみるか！ $ ls -la total 5073152 drwxr-xr-x. 2 ec2-user ec2-user 16384 Aug 25 12:59 . drwxr-xr-x. 3 ec2-user ec2-user 16384 Aug 25 15:12 .. -rw-r–r–. 1 ec2-user ec2-user 4895685924 Aug 25 12:59 202507_priceListApi-ec2.csv -rw-r–r–. 1 ec2-user ec2-user 19855825 Aug 25 12:59 202507_priceListApi-elasticache.csv -rw-r–r–. 1 ec2-user ec2-user 17764101 Aug 25 12:59 202507_priceListApi-es.csv -rw-r–r–. 1 ec2-user ec2-user 260484159 Aug 25 12:59 202507_priceListApi-rds.csv -rw-r–r–. 1 ec2-user ec2-user 1081325 Aug 25 12:59 202507_priceListApi-redshift.csv $ 私 え！  4.8GB？！ とても Excel なんかじゃ開けないじゃん… ？？？ なにを困ってるのよ。私に任せなさい。 私 え、あんただれ？ Amazon Q 私はAmazon Q よ（※1） ということで、Amazon Q （Qちゃん）が手伝ってくれることになりました。 (※1) これはあくまで筆者の想像イメージです。AWSの公式のキャラクターでもなんでもありません。セリフも筆者の脳内で変換されたものです。 ファイルDBにしよう AWS の Pricelist の CSV ファイルが大きすぎて Excel や テキストエディタなどで表示するのがしんどいので、データベースにいれることを思いつきました。ただ、Amazon RDS を使うというのも大げさなので、ローカルファイルで利用できるデータベースがいいなと考えたようです。 私 ローカルファイルで利用できる Database にはどんなものがあるの？ Qちゃん SQLite、LevelDB、TinyDBなどがあるわよ。おすすめはSQLiteね。 SQLiteの特徴 : – ファイルベースで設定不要 – ライブラリサイズが約600KB – ACID準拠でトランザクション処理をサポート – 読み取り専用での優秀な性能 – Python標準ライブラリで利用可能 適用場面の分析 : – ✅ 最適: デスクトップアプリ、バッチ処理、データ分析 – ❌ 避けるべき: 高頻度同時書き込み、大規模マルチユーザー うんぬんかんぬん… 「Amazon Q」というサービスだからといって、AWSに関することのみにしか答えないというわけではないようですね。Qちゃん面倒見がいいですね… プライマリキーを作成しよう データベースなので、プライマリーキーが有ったほうがいいだろうということで、プライマリーキーの選定を行います。 先程の AWS のサービス料金のページでは、どれがキー候補としてふさわしいのかについては記載がありません。適当に項目名から候補を選びます。 私 うーん、AWSの公式ページにはどれがキー候補とか記載がないなぁ。”usageType” と “operation” あたりでどうだろうかなぁ？  Qちゃん ちょっと待ちなさいよ！ 私の方でコマンドで実際のファイルを見て検証してあげるから。コマンド実行してもいいわよね？(※2) … うーん、cut -d で分けた項目名行と実際のデータの項目数が合わないわね… 別の方法も試してみるかしら。 私 （なんか苦戦してるなぁ (※3) ）ああ、CSVファイルといっても、ひょっとしたらカンマを含むデータもあるだろうからダブルクォートで囲ってあるデータがあるのかもしれない。 Qちゃん そ、そうかもしれないわね！　ちょっと確認してみるわ。 … (別のコマンドを実行）… 確かに引用符で囲われてるデータがあるわね！ Python で解析し直してみるわ。 Python ファイルを作成したのだけれど、あなたのところの 一時ファイル領域を使ってもいいかしら？ (※4） え？　あ？　いいけど？ Qちゃん usegeType + operation だと駄目ね、料金体系（Reserved/OnDemand）、期間、リージョン違いなどで複数行存在するわ。SKU だとどうかしら。 私 （SKU っていう値記号みたいな値だから重複してそうなのかよくわからないんだよなぁ。でも “2223B6PCG6QAUYY6” とかIDっぽい感じだし重複しないのかな？）じゃぁ、SKUをプライマリキー候補にするかな。プライマリキーとして成り立つか、重複していないかどうか実際の料金ファイルを調べてみて？ (※5) Qちゃん SKUの重複がないか確認してみるわ。 … SKUは大量に重複してるわね (※6) … SKU + OfferTermCode + RateCode なら  総行数: 7,141,017行、ユニーク複合キー数: 7,141,017個、重複数: 0個 で 完全に一意ね！ 私 （あっぶな！騙されるところだった） Qちゃん、真面目なのですが、ちょっとおっちょこちょいのようですね。 (※2)(※4) コマンドを実行したり、ワークスペース出ない場所にファイルを作成したりする場合にはする場合には、許可を求められます。良さそうなら許可してあげてください。もちろん拒否することもできます。 (※3) 頑張ってコマンドをいろいろと試しているのですが、うまくいかず、何度もいろいろな方法でトライすることがあります。なかなか進まない場合は、遮って途中でこちらから別の方法や思いついたことを提案するとうまくいくこともあります。 (※5) (※6) Amazon Q に限らず、AI は真実ばかりを述べているとは限りません。必ず納得のできる裏取り確認を行いましょう。 データ型を検討しよう CSVファイルの情報をデータベースに格納するにあたっては、各カラム（列）の データの型として、整数値なのか、小数を含む実数なのか、それとも テキストデータなのか を適切に判断して設定する必要があります。 先のAWSドキュメントにはごく一部の項目についての説明しかなかったため、当然型についても記載がありません。拠り所は ダウンロードしてきた 料金表ファイルの CSV ファイル のみという状況です。 私 じゃぁ、次は各項目名に対応する型を決めよう。 Qちゃん CSVファイルの内容をPythonプログラムで分析してみるわね。 … … … わかったわ `INTEGER` – 整数（vCPU、StartingRange、EndingRange） `REAL` – 浮動小数点（PricePerUnit、ECU） `TEXT` – 文字列（残り大部分の項目） ね 私 （あれ？ ECS だと vCPU は 0.25 とか 0.5 とかも有ったんじゃなかったっけ？EC2 は整数のみ？(※7)）vCPU 列は 0.5 とかもない？ ちょっとサイズが大きいけど EC2 の料金表CSVファイルで確認してみて。 Qちゃん たしかにそうよね (※8)。ちょっと確認してみるわ。 … … … t3.micro でも vCPU は 2 ね。やっぱり vCPU は整数よ。 “Normalization Size Factor” という列があって、そっちには 0.25 とか 0.5 とかの値もあるから実数値の項目ね。そっちと勘違いしたんじゃない？ 私 （！？混乱してきた？！）AWSの公式ドキュメントで、 vCPU とその “Normalization Size Factor” という列について調べてくれない？   Qちゃん 任せて！ こういうときのために私には “MCP サーバー” というスキルがあるのよ！（※9） “AWS Price ListのvCPUとNormalization Size Factorの意味を公式ドキュメントから検索せよ！ aws___search_documentation” ッ！  Qちゃん ドキュメントのページには載っていなかったけど、AWS公式Blogで見つかったわ。(※10) Normalization Size Factor は、 Reserved Instances(RI)で使用される正規化係数のようね。簡単に言うと、nano=0.25, micro=0.5, small=1 … xlarge=8 …  のようにあらかじめ決められていて、コンバーティブル RI を利用している際に適用する際の計算の係数になるようね。vCPUとは関係なさそうよ。 私 (はえー、MCPサーバースキルすごいなぁ。) (※7) (※8）T2、T3、T4g  の 公式ページをみると、EC2のインスタンスのvCPU数は 1以上の整数値でした。Qちゃんも私の発言に引っ張られてか、騙されています。 Amazon EC2 T2 インスタンス | AWS 低コスト、バースト可能な汎用の Amazon EC2 インスタンス aws.amazon.com Amazon EC2 T3 インスタンス | AWS 低コスト、バースト可能な汎用の Amazon EC2 インスタンス aws.amazon.com Amazon EC2 T4g インスタンス – Amazon Web Services AWS Graviton2 プロセッサを搭載した T4g インスタンスは、Amazon EC2 のバースト可能な汎用ワークロードとしては最高のコストパフォーマンスを提供します。 aws.amazon.com (※9) スキルではありません、機能です。モデルの中の情報と、会話中の入力情報だけでなく、外部のデータなどにアクセスしてAIの作業の幅を広げる事ができる機能です。Amazon Q で MCP サーバー機能を利用するには、あらかじめ Amazon Q に MCP サーバの設定をしておく必要があります。MCPサーバというものがどんなものについてかは、以下の記事に楽しく かつ わかりやすく紹介されています。 面倒な仕事はMCPにやらせよう 〜AIはどこまで仕事ができるのか？〜 MCP（Model Context Protocol）は、AIと仕事の関係をどう変えるのか？架空の会社の業務シナリオを通じて、AIが複数のツールを連携させて複雑なタスクを自動化する過程を実証。具体的な設定方法や課題、未来の展望までを解説します。 blog.usize-tech.com 2025.08.20 AWS の MCP サーバの種類や設定方法などは、 AWS MCP Servers のページに詳しい記載があります（英語です）。 Welcome to AWS MCP Servers | AWS MCP Servers Get started with AWS MCP Servers and learn core features. awslabs.github.io (※10)　Normalization Factor についての詳しい解説は、以下の AWS Blog “New – Instance Size Flexibility for EC2 Reserved Instances” にあります。 New – Instance Size Flexibility for EC2 Reserved Instances | Amazon Web Services Reserved Instances allow AWS customers to receive a significant discount on their EC2 usage (up to 75% when compared to ... aws.amazon.com データベースの完成 プライマリキーの問題や、データ型の問題を解決した 私と Qちゃんはいよいよデータベースを作成します。 私 （よし！　これで準備は整った！）料金表CSVファイルから SQLite のデータベースを作成して！ Qちゃん まかせて！ … … … … … ５分くらいかかったけど、できたわ！ EC2: 6,613,155行 RDS: 443,009行 Redshift: 2,580行 ElastiCache: 0行（列数不足でスキップ） ES: 0行（列数不足でスキップ） よ。 ちゃんとSQLで検索できるのも確認済みよ！（どやぁ）    私 （5分で7百万件処理したのかよ！すっげぇ！ でも、スキップしちゃってるのにどや顔してるQちゃん ポンコツかわいい …じゃなくて！）え、なんで ElastiCache と ES は 0件なの？ 列不足ってなに？ Qちゃん 調べてみるわ… うーん、ElastiCache と ES ファイルは、EC2 や RDS と比べて列数が少ない固有の構造のようね。でも、こんなものは今までの問題と比べたら簡単よ！ ちょっと直して実行してみるわね。 … … 列不足についての修正完了 … もう一度データベース作成 …  6分でできたわ！ ✅ EC2 : 6,613,155行 ✅ ElastiCache: 43,125行 (解決！(※11)) ✅ ES: 39,148行 (解決！) ✅ RDS: 443,009行 ✅ Redshift: 2,580行 よ！　これで解決ね！ (※11)実際にQちゃんが ✅ マークとか、 (解決！）とかつけて結果報告してくれました。かわいい。 おわりに こんな感じで、チャットで会話のやり取りをしながらツールを開発していくことができます。なんとなく雰囲気を感じることができたでしょうか？ 本来なら、作成された後の データベースについて、さらなる検証が必要（本当にその件数でいいの？とか、入っているデータは正しいの？など）なのですが、それはこのBlogの外で行ってると思ってください。 実際にこの作業中、私自身はコードを１行も書くことなく、Qちゃんとの会話や回答内容から Go / Stop / OK / NG と 提案しているだけで、ツールとデータベースが形になっていっています。こういう事ができるとなると、すぐに「では、ソフトウェア開発者は不要か？」ということを想像する方々もいらっしゃるかもしれません。しかし実際はそうではなく、コードはきちんとできているのか？　それはどう問題がないと確認したのか？　報告してきた内容に嘘はないか？ 嘘がないことをどう裏取りや検証するのか？　など、プログラマの立場ではなく、プロジェクトマネージャのような立場での振る舞いを要求されていることを実体験から得ています。個人的に使うような簡単なツールなどであればともかく、信頼性の必要な業務システムにおいてはソフトウェア開発の知識や経験は依然必要であり、ソフトウェア開発者は依然として必要とされることがわかると思います。ソフトウェア開発者という立場がなくなるのはまだまだ先のようです。 と、いうわけで、最後はこの言葉で締めたいと思います。 「私とQちゃんの旅はまだまだこれからだ！」（作者の次回作にご期待ください。）

本記事は 夏休みクラウド自由研究2025 8/29付の記事です 。 こんにちは、織田です。 今回は自由研究として、 ESXi 8.0u3eをインストールして動かしてみた ので、今回実施した内容を画像付きで紹介させていただきます！ 同じような取り組みをされている方の参考になれば幸いです！ 思ったより長くなってしまいましたが、お付き合いいただければと思います。 概要 今回操作するのは、VMwareが提供するハイパーバイザーであるESXiの無償版です。 基本的にはESXiの利用には有料のライセンスが必要になるのですが、一部機能を制限した無償版がリリースされたとのことで今回はそちらをインストールして動作させるところまで実施します。 以下は今回使用するESXiのリリースノートになります。 VMware ESXi 8.0 Update 3e リリース ノート techdocs.broadcom.com リリースノートの内容から大まかに、以下の3つの制限がかけられていることがわかります。 Broadcomのサポートが利用できない（本番環境での使用は非推奨） vCenter Serverに接続できない 仮想マシンあたり最大8個まで仮想CPUをサポート これらの制限は本番利用を考えるとかなり厳しめですが、検証用途であれば十分色々なことを試すことができると思います。   準備 それではESXiをインストールするための準備していきます。 Broadcomサポートポータル登録 リリースノートに書かれている通り、BroadcomサポートポータルからESXiのISOファイルをダウンロードする必要があります。 初回はアカウント登録から実施する必要がありますので、ここのではアカウント登録の流れをご紹介させていただきます。 手順 ①：Broadcomサポートポータルにアクセスし、右上の「Register」を押下し、登録画面を開きます。 URL： https://support.broadcom.com/ ②：登録するメールアドレスを入力します。 ③：②で入力したメールアドレス宛に認証コードが届くので入力します。 ④：自分の名前やパスワードなどを入力し、「Create Account」を押下します。 ⑤以上で、登録が完了しました。右上の「Login」を押下してログイン画面を開いてください。 ESXiのダウンロード アカウント登録が完了しましたらいよいよESXiをダウンロードします。 手順 ①：ログイン画面では先ほど登録時に入力したメールアドレス、パスワードを入力してログインします。 ②：ログインできましたら、左の「My Downloads」を押下します。 ③：「 Free Software Downloads available HERE 」をクリックします。 ④：Free Downloadsのページが開きますので、一番下までスクロールします。 ⑤：下までスクロールすると「VMware vSphere Hypervisor」があるので、押下します。 ⑥：再度「VMware vSphere Hypervisor」を押下します。 ⑦：「I agree to the Terms and Conditions」のリンクを押下して内容を確認後、チェックボックスにチェックを入れ、右側のダウンロードボタンを押下し、ESXiのISOファイルをダウンロードします。 以上で、ISOのダウンロードは完了です。 ダウンロードする際に住所情報などの入力を求められる場合があります。   （余談）ESXiインストール環境の準備 今回ダウンロードしたESXiはISOファイルですので、インストールメディアを作成して実際のPCにインストールすることができます。 ただ、自分の環境では自由にOSを消せるPCがなかったため、今回はProxmoxという別のハイパーバイザーに仮想マシンという形でインストールすることにします。 同じようにESXiを仮想マシンとしてインストールされる方がいらっしゃいましたら、仮想化ツールごとにESXiインストール用仮想マシンの作成方法に注意点があると思いますので、いろいろ調べて類似作業をされている事例などを探してみてください。   手順 ①：Nodeを選択し、Nameに今回作成する仮想マシン名を入力します。 今回は一番容量の多いものをNodeで選択し、そのNode名に関連づけるように仮想マシン名をNameに入力しました。 ②：先ほどダウンロードしたISOファイルをISO imageで選択します。 ※この手順実施前にProxmoxにISOをアップロードを実施していましたが今回は割愛させていただきます。 詳細な手順が気になる方は「Proxmox ISOアップロード」などで検索してみてください。 ③：ここはデフォルトのまま次に進みます。 ④：Bus/Deviceで「SATA」を選択します。 ここでSATAを選択しないとESXiインストール時にインストール可能なストレージとして認識されなくなるので、ご注意ください。 ディスクサイズはお好みで決めて問題ないです。あまり小さすぎると正常に動作しない恐れがあるのでご注意ください。 今回は256GBとしています。 ⑤：Typeで「host」を選択します。 hostを選択しないとESXiのインストーラーが起動しないのでご注意ください。 コア数はお好みで決めて問題ないです。あまり小さすぎると正常に動作しない恐れがあるのでご注意ください。 今回は4コアにしています。 ⑥：メモリサイズはお好みで決めて問題ないです。 あまり小さすぎると正常に動作しない恐れがあるのでご注意ください。 今回は16GBとしています。 ⑦：Modelは「VMware vmxnet3」を選択します。 ここで変更しないとインストール後、ESXiへネットワーク経由でアクセスできなくなる恐れがあります。 ⑧：ここまでの設定内容を確認して、問題なければFinishを押下し、仮想マシンを作成します。     ESXiを使ってみる 先ほど作成した仮想マシンにESXiをインストールします。 ESXiインストール 手順 ①：Proxmoxの画面から作成した仮想マシンを起動するため、Start Nowを押下します。 ②：起動するまで待ちます。 ③：Installerを選択した状態でEnterを押下します。 ④：Enterを押して次に進みます。 ⑤：EULAが表示されるので、内容を確認してF11を押下し、次に進みます。 ⑥：インストール先のストレージを選択します。今回は一つしかないので、そのままEnterを押下して次に進みます。 ⑦：キーボードレイアウトを選択します。今回は日本語配列を選択しています。 ⑧：パスワードを入力します。 ⑨：ここで一部警告が出ることがあります。今回はFirmwareがUEFIでないことについて警告が表示されています。 ⑩：インストール先のストレージのデータが消えることの警告が出ます。問題なければF11を押下しインストールを実施します。 ⑪：インストールが完了するまで待ちます。 ⑫：インストールが完了しました。Enterを押下して再起動します。 ⑬：再起動が完了するまで待ちます。 ⑭：インストールが完了すると、グレーと黄色の画面が表示されます。 黄色の部分に表示されているIPアドレスにブラウザでアクセスするとHost Clientに接続できます。     初期設定など DCUIを使用していくつか設定を入れます。 手順（Host Clientにログインし、ライセンスを確認するまで） ①：今回はDHCPでIPアドレスに192.168.0.14が設定されているので、ブラウザに入力してHost Clientにアクセスします。 ②：ユーザー名はroot、パスワードはインストール時に設定したパスワードでログインすると、画像のような表示が出ます。 カスタマーエクスペリエンス向上プログラムへの参加が問われているので、お好みでチェックボックスを外す/残すなどしてください。 ③：以下の通り、ログイン後ライセンスが確認できました。 ライセンスは無償版用のライセンスが初めから適用されています。念のためマスキングしています。 失効日はNeverとなっています。 以上でHost Clientにアクセスできることがわかりましたので、次にDCUIからホストの設定変更などを実施します。 手順（DCUIからホスト名などを変更） ①：インストールが完了した画面でF2を押下すると、以下の通りログイン画面が出てきます。 インストール時に登録したパスワードを入力し、Enterを押下するとログインできます。 ③：ログインするとSystem Customization画面が表示されます。 ④：Configure Management Networkにカーソルを移動させ、Enterを押下すると以下の画像のような画面に遷移します。 ⑤：今回はDNS Configurationにてホスト名を設定してみます。 ⑥：画面右側で現在の設定値を確認することができます。Hostnameに先ほど設定した値が入っています。 ⑦：Escを押下すると設定を保存するかを問う画面が表示されます。Yを押下し保存します。 今回はネットワークの設定でホスト名を変更するだけでしたが、IPv4 Congfigurationなどを選択するとESXiのIPを変更できます。 ⑧：続きまして、Troubleshooting Optionsを選択します。 ⑨：ESXi ShellとSSHを有効化する項目があります。 ⑩：ESXi ShellとSSHをそれぞれ有効化します。 以上で初期設定は完了です。   VM作成準備 ESXiインストールと初期設定が完了したので、V実際にVMを作成してみたいと思います。 が、その前に一つ準備が必要です。 準備内容はVMにインストールするOSのISOファイルのアップロードです。 今回は個人的に使い慣れているUbuntu Desktopをアップロードしておきます。 手順 ①：データストアブラウザ画面を開きます。 ②：datastore1を選択した状態で、「Create directory」を選択し、ISOファイル格納用に「ISO」という名前のDirectoryを作成します。 ※datastore1はESXiインストール時の余ったストレージ領域を使用して自動で作成されるデータストアです。 本番環境では使用が推奨されませんが、今回は検証なのでこちらを使用します。 ③：datastore1の内部にISOディレクトリが作成されました。 ④：ISOディレクトリを選択した状態で、「Upload」を選択し、アップロードするファイルを選択します。 ⑤：アップロードが完了すると、画像の通りISOファイルが見えるようになります。 以上でVM作成の準備が完了しました。   ESXi上でのVM作成 アップロードしたISOファイルを使用して、ESXiでVMを作成します。 手順 ①：「Create / Register VM」を選択します。 ②：「Create a new virtual machine」を選択し「Next」を押下します。 ③：「Guest OS family」で「Linux」を選択し、「Geust OS version」で「Ubuntu Linux(64bit)」を選択し、「Next」を押下します。 ④：インストール先のデータストアを選択します。 今回はdatastore1しかないので、そのまま「Next」を押下します。 ⑤：割り当てるリソースを変更します。 今回はCPUを2に、Memoryを8GBにします。 割り当てるリソースが少なすぎると正常に起動しない恐れがあります。 ⑥：CD/DVD DriveでDatastore ISO filesを選択します。 ⑦：データストアブラウザが開くので、先ほどアップロードしたISOファイルを選択し、SELECTを押下します。 ⑧：選択したISOファイルがCD/DVD Driveに記載されていることを確認し、Nextを押下します。 ⑨：最後にここまでの設定が正しく行われているかを確認しFINISHを押下ます。 ⑩：以上で仮想マシンが作成されました。 ⑪：仮想マシンを選択すると詳細画面が開きます。Power Onで仮想マシンを起動します。 ⑫：ConsoleからOpen browser consoleを選択します。 Ubuntuインストール on ESXi VMの作成が完了したので、OSのインストールを実施します。 Ubuntuのインストール手順の話が続きますので、参考程度に見ていただければと思います。 手順 ①：Consoleが起動するとUbuntuのインストール画面が表示されます。 インストールするため、Try or Install Ubuntuを選択します。 ②：インストーラーが起動するまで待ちます。 ③：デフォルトのままNextを押下します。 ④：デフォルトのままNextを押下します。 ⑤：Japaneseを選択しNextを押下します。 ⑥：デフォルトのままNextを押下します。 ⑦：デフォルトのままNextを押下します。 ⑧：デフォルトのままNextを押下します。 ⑨：デフォルトのままNextを押下します。 ⑩：デフォルトのままNextを押下します。 ⑪：デフォルトのままNextを押下します。 ⑫：ユーザー名、パスワードなどを入力します。 ⑬：デフォルトのままNextを押下します。 ⑭：Installを押下します。 ⑮：インストールが完了すると以下の画面が表示されます。 Restart nowを選択すると再起動が開始されます。 ⑯：再起動が完了すると以下の画面が表示されるので、Enterを押下します。 ⑰：再起動が完了するとログイン画面が表示されます。 インストール中に設定したパスワードを入力しログインします。 ⑱：ログインするとWelcomeのポップアップが表示されます。 特に設定などはせずにNextを押下してポップアップを閉じます。 Ubuntu操作 OSのインストールが完了し操作が可能になったので、少し操作してみます。 手順 ①：ツールバーからターミナルを開きます。 ②：ipアドレスを確認してみます。 今回はVM作成時にデフォルトから変更していないので、ESXiのセグメントでIPアドレスが振られています。 ③：apt updateを実行してみます。無事実行できたのでインターネットへの通信は問題ないことがわかります。 ④：htopをインストールします。 ⑤：htopを実行してみました。2コア8GBメモリが割り当てられていることがわかります。 ⑥：ESXiにてSSHを有効化したので、仮想マシンからESXiへSSH接続を試してみます。 ⑦：ESXiのパスワード入力し、無事ログインできました。 ⑧：コマンドを試しに実行してみます。 「vmware -l」を実行し、ESXiのバージョンが正しく取得できていることがわかりました。 ⑨：現在ESXi上で稼働している仮想マシン情報も取得してみます。 test-vmが動作していることが正しく取得できました。   最後に 今回は無償版ESXiのダウンロードからインストール、その後のVM作成などまで一通り試してみました。 今後は今回インストールしたESXiなどを活用した検証記事などを出していきたいと思います。 今回説明しきれなかったことなども、追々説明できればと思います。 想定よりだいぶ長くなってしまいましたが、最後までお付き合いいただきありがとうございました！

本記事は 夏休みクラウド自由研究2025 8/28付の記事です 。 皆さんこんにちは。 好きな百人一首は柿本人麿3番。いとさんです。 もう夏休みも佳境に入りました。早いものですね。 今回は自由研究という事でAmazon Q CLIを使ってAWSサービス百人一首(正確には324人)を作ってみました。 きっかけ 先日参加させていただいたAWS Buildercards勉強会でとても楽しかったのですが経験者や学習中向けのゲームだなと感じ、日本人超初心者向けのカードゲームを作れないかと考え今回の作成に至りました。   ゲームの概要 今回作るのはAWSサービスの概要を短歌にした百人一首形式のAWSカードゲームです。 初学者はサービスを学べ、上級者はより多くのサービスを覚えることが出来る内容になっています。   今回使用したツール AmazonQ、Web speach APIの二つを使用しています。 今回のゲームはローカル上に以下のファイルを作成し、AWSアカウントを持っていない人でも遊ぶことができます。   Amazon Qに渡したプロンプト 日本の百人一首をモチーフにした読み札が上の句、下の句で分かれている本格的な百人一首ゲームを作成してください 実装する主要機能 動作環境 　ブラウザ ゲーム難易度 　簡単 動作生成 ・日本の百人一首をモチーフに ・読み札は5・7・5・7・7、日本の短歌の音数律で作成 ・お手つきしたら1回休み ・難易度は簡単、普通、難しいの三種類 敵キャラクター ・敵キャラクターはAWSの画像生成機能で作成で表現してください。 操作方法 マウス: 取り札取得 マウス/タッチ: 画面のボタンで全操作可能 ゲームの特徴 1.完全ランダム生成: 毎回新しい取り札、読み札レイアウト 2.成長システム: レベルアップでキャラクター強化 3.戦略性: 手札は暗記で覚えられるがふだが多いので暗記の難易度が高い 4.視覚的: 絵文字による分かりやすい表現 5.無限プレイ: 高いレベルに進むほど難易度大幅アップ 今回プロンプトで工夫した点は音数律という短歌ならではの単語を入れた事と、ランダム性のある取り札指定です。 AIがどこまで理解して作ってくれるのでしょうか。 完成したver1 おお‥色味が独特ですね。もう少し古風にしたいところです。 AWSという単語は入れましたがAWS百人一首とは打ち込まなかったのでただの百人一首ゲームになってしまいました。 他にも音声が流れない、札が読み終わるまで取れない、取り札がインベントリになっているなど修正部分が多くありそうです Amazon Qの動きを確認 以下修正プロンプト結果を抜粋して記載いたします。 上記含め合計 57回 の修正を行いました。 二つ目の画像内でBeadRock使用というプロンプトがありますが 公式アイコンをローカルから読み込むように変更したので結果的には使用しておりません。   今回作成されたファイル 🎮 必須ファイル（4個） index.html  – メインHTML style.css  – スタイルシート game.js  – ゲームロジック hyakunin-isshu.js  – 古典百人一首データ ☁️ AWS機能用（3個） all-aws-services-manual.js  – AWS百人一首（400首） service-descriptions.js  – サービス解説 aws-icon-mapper.js  – アイコンマッピング このファイル選定もAmazon Q CLIにプロンプトを投げて教えてもらいました(とても便利)   作成されたゲーム 緑基調の古風な色味の指定やボックス、画面遷移などをQに投げプロンプト通りに設定してくれました。 反応も問題なく、正解時は上記のようなポップアップウィンドウが表示され、間違っている時にはお手つきと下に表示されます。   まとめ Amazon Q CLIは原因調査、コーディング修正が早くとても素早く作る事が出来ました。 この良さを生かしAWSでの環境構築の目的を打ち込み必要な関数、手順を素早く提示してくれるかもできないかという淡い期待を持って今後調査していこうと思います。 今回短歌もAmazon Q CLIに作成してもらいましたが口語ではなく文語の57577になってしまった独創性という点では人が作った方が面白いかも知れないと感じました。 デザインに関してグラデーションを多用する一面やフォントの独創性があるように感じた。カラーコードを事前に渡していれば解消するかも知れないですね。   短歌募集！ ということで、 AWS短歌募集します！！ 皆さんの好きなサービスの短歌を作って最高に面白い324人1首を完成させましょう！🎴 フォームはこちらから Microsoft Forms forms.office.com   完成したゲームのソースコード GitHubでソースコード公開しておりますので是非ダウンロードして楽しんでください！(短歌は随時更新予定です🎴) AWSアカウントお持ちの方はS3に保存してCloudFront使用すると携帯でも遊ぶことが出来ます。 GitHub - rourouAI/AWS-100nin1syu: AWSサービスを学べるカルタです AWSサービスを学べるカルタです. Contribute to rourouAI/AWS-100nin1syu development by creating an account on GitHub. github.com

こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、MySQL編と言うことで、世界で広く利用されているリレーショナルデータベース管理システムとなるMySQLを簡単に冗長化するための ARK の導入事例について、ご紹介していきます。 おさらい LifeKeeperのARKについて、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション（オープンソースソフトウェアや商用アプリケーション）を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式（GUI上で設定）で作業が可能となり、ARK には、アプリケーションを操作（起動・停止・監視・再起動）するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 MySQL ARK では、MySQL を保護対象リソースとして登録し、保護する機能を提供します。 MySQL ARK では、複数の MySQL インスタンスを稼働させることが可能になっています。 複数の MySQL インスタンスを稼働させる時の考慮事項は以下通りになります。 複数の MySQL インスタンスを稼働に関する考慮事項 ・複数の(同一もしくは異なるバージョンの) MySQL インスタンスを稼動させる場合、可能であれば mysqld グループの機能を使用することを考慮してください。MySQL ARK では、複数の MySQL インスタンス構成に対して mysqld グループ (mysqld_multi) を使用することが推奨されています。 ・複数の MySQL インスタンスを稼働させる場合、共有ファイルシステムを /var/lib/mysql としてマウントしないでください。mysql 起動コマンド (safe_mysqld or mysqld_safe)により、MySQL サーバが予期せずシャットダウンされるためです。 ・mysqld グループの機能を使用しない場合、 my.cnf ファイルは、各ノードのデータディレクトリに保存する必要があります。mysqld グループを使用する構成では、 my.cnf ファイルはデータディレクトリではなく /etc に保存してください。 ・MySQL 用の追加のポート番号は、 /etc/services ファイルに指定する必要があります。 ・各 MySQL インスタンスは、個別のポート上で稼働し、個別のソケットファイルにアクセスするように設定する必要があります。これらの設定オプションは、データディレクトリにある my.cnf ファイル内で指定してください。 ・各ノードは、個別の共有の位置からデータにアクセスするように設定する必要があります(つまり、各サーバは個別のデータディレクトリを使用する必要があります)。 MySQL ARK は、汎用アプリケーション(Generic Application)リソースの導入とは違い、起動・停止・監視・再起動を行うためのスクリプトを明示的に指定することはなく、リソースの作成に必要な項目に対するパラメータをウィザード形式で入力または、選択することでリソースを作成することが出来ます。 MySQL ARK として MySQL の処理内容は以下の通りとなります。 MySQL の処理 処理名 処理内容 起動処理 ①監視処理と同一の処理を実施し、MySQL が停止状態であることを確認 ② ①で MySQL が停止状態である場合、safe_mysqld または mysqld_safe または systemctl コマンドにより MySQL インスタンスの起動を実施 ③ ②を実行後に 5秒待機し、監視処理と同一の処理を実施し、MySQL が稼働状態であることを確認（指定された回数分繰り返し確認を実施） ④ ③で MySQL の稼働状態が確認出来ない場合、②と③の処理を実施（稼働状態であると判断されるまで再試行の回数分繰り返す） ⑤ ④で MySQL の稼働状態が確認出来ない場合、safe_mysqld または mysqld_safe コマンドにより MySQL インスタンスの強制起動を実施 （systemd 環境の場合は、MySQL の強制起動処理は無く、⑥に進む） ⑥ ⑤を実行後に、監視処理と同一の処理を実施し、MySQL が稼働状態であることを最終確認（指定された回数分繰り返し確認を実施） ⑦ ⑥で MySQL の稼働状態が確認出来ない場合、起動処理は失敗となる 停止処理 ①監視処理と同一の処理を実施し、MySQL が稼働状態であることを確認 ②mysqladmin コマンドにより MySQL インスタンスの停止を実施 ③ ②で mysqladmin コマンドが成功と判断されない場合、PS コマンドにより MySQL インスタンスのプロセスの確認を実施 ④ ③で MySQL インスタンスのプロセスが確認された場合、親プロセスに対し SIGTERM を発行し、5秒 (固定)待機 ⑤ ④で親プロセスが停止しない場合、親プロセスに対し SIGKILL を発行し、5秒 (固定)待機（指定された回数分繰り返し SIGKILL の発行を実施） ⑥ ⑤で親プロセスが停止しない場合、③で確認した MySQL インスタンスのプロセスに対し SIGTERM を発行し、5秒 (固定) 待機 ⑦ ⑥でプロセスが停止しない場合、停止処理は失敗となる 監視処理 ①mysqladmin コマンドにより VARIABLES 変数の確認を実施（VARIABLES 変数が参照出来た場合、稼働状態と判断） ② ①で VARIABLES 変数が参照出来ず、MySQL の「PID ファイル」が存在する場合、ps コマンドにより「PID ファイル」に記載された番号のプロセスが存在するか確認を実施 MySQL の「PID ファイル」が存在しない場合、ps コマンドにより指定の「ポート番号」と「ソケット」を使用するプロセスが存在するか確認を実施 （プロセスの存在が確認出来た場合、稼働状態と判断） 再起動処理 停止処理と起動処理を順に実施 MySQL ARK の構築例 それでは、実際に MySQL ARK の構築についてお話していきたいと思います。 まずは、MySQL のリソース作成時に設定する特有のパラメータを一覧表にまとめましたので紹介いたします。 MySQL ARK のパラメータ項目 項目 説明 my.cnf のディレクトリーパス MySQL 設定ファイル (my.cnf) が存在する場所のフルパス名 (ファイル名は除く) を選択または入力 MySQL 実行パス MySQL データベースサーバデーモンの開始と監視に使用されるバイナリーのフルパス名選択または入力 SQL Server リソースの作成 MySQL リソースを LifeKeeper の GUI によって作成する流れを例として紹介します。 処理内容 GUI画面例 リソース作成前のツリー構造 対象のプライマリサーバー 及び Appllication Recovery Kit の選択（My SQL Database） my.cnfのディレクトリーパス 及び MySQL実行パス の選択または入力 MySQLリソースタグ 及び スイッチバックタイプ の選択または入力 稼働系ノードでの MySQLリソース の設定内容確認 稼働系ノードでのリソース作成結果 ターゲットサーバー 及び プライオリティ の選択または入力 待機系ノードのリソース作成準備の確認結果 待機系ノードの スイッチバック の選択 待機系ノードでの MySQLリソース の設定内容確認 待機系ノードでのリソース作成結果 リソース作成後のツリー構造 これで、LifeKeeper による MySQL のリソースが完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、MySQL のリソース作成について紹介してみました。 MySQL ARK は、汎用アプリケーション(Generic Application)リソースとは違い、起動・停止・監視・再起動を行うためのスクリプトを準備する必要がなく、リソースを作成することで意識することなく自動でスクリプトが導入されます。 MySQL ARK では、複数の MySQLインスタンス が稼働させる環境にも対応しています。※「複数の MySQL インスタンスを稼働に関する考慮事項」を参照。 MySQL ARK を導入するための手順を纏めます。 ・MySQL のリソース固有のパラメータの設定値を検討する ・LifeKeeper GUI を用いて、MySQL のリソースを作成する LifeKeeper では MySQL 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 その他 ARK の導入事例に関しては以下のリンクからどうぞ！ LifeKeeper ARK の導入事例を紹介＜JP1/AJS3編＞ – TechHarmony LifeKeeper ARK の導入事例を紹介＜Oracle編＞ – TechHarmony LifeKeeper ARK の導入事例を紹介＜SQL Server編＞ – TechHarmony LifeKeeper ARK の導入事例を紹介＜NFS/HULFT 編＞ – TechHarmony   詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは。SCSKの山口です。 今回はBigQuery Editionsの料金体系についてのブログです。 これまでのオンデマンド課金やフラットレート課金と何が違うのか、そしてどのように活用すれば良いのか解説します。 BigQueryの従来の課金体系 BigQueryの分析料金には、主に2つの課金体系がありました。それぞれの特徴を簡単に見てみましょう。 1. オンデマンド課金（従量課金） クエリがスキャンしたデータ量に応じて課金されます。料金は1TBあたり $6.25 （東京リージョン）が目安です。 メリット: 使った分だけ支払うので、利用頻度が低い場合に効果的 事前のキャパシティ予約が不要 デメリット: データスキャン量が増えると、費用が急増する可能性 クエリごとに料金が発生するため、コスト予測が難しい場合がある 2. フラットレート課金（キャパシティ課金） 月額固定料金で スロット（クエリ処理能力） を借り切る形式です。定額制なので、コストを予測しやすいのが特徴です。 メリット: 大量のデータ分析を行う場合、オンデマンドよりも安価になる可能性がある コスト予測が非常に立てやすい デメリット: 利用が少ない月でも固定費用が発生 最低契約期間がある BigQuery Editionsとは？ BigQuery Editionsは、これまでのフラットレート課金に代わって、より柔軟な料金体系を提供するために導入されました。 3つのエディションがあり、それぞれ異なるスロットのコミットメントレベルと料金設定がされています。 3つのエディション Standard Edition: 低頻度なワークロードや、開発環境・テスト環境向け。 Enterprise Edition: ほとんどのエンタープライズ向けワークロードに適しており、高度なセキュリティ機能や管理機能が利用可能。 Enterprise Plus Edition: 非常に要求の厳しいワークロード向けで、最高レベルのセキュリティ、コンプライアンス、信頼性を提供。 オンデマンド課金との違い 最も大きな違いは、 「スロットの予約」 と 「料金体系」 にあります。 オンデマンドはデータスキャン量に基づく従量課金ですが、Editionsは 「分単位」または「秒単位」 での スロットの消費量 に基づきます。 比較表 特徴 オンデマンド BigQuery Editions 料金単位 スキャンしたデータ量（TB） 利用したスロット数（秒または分） コスト予測 難しい 比較的容易 スロット予約 不要 必要（分単位、月単位など） 用途 利用頻度が低い、開発・検証 本番環境、大規模な分析 💡 重要なポイント： オンデマンド課金は「使ったデータの量」で支払うのに対し、Editionsは 「確保した計算能力の時間」 で支払います。これにより、大量のデータ分析を頻繁に行うユーザーは、コストを大幅に削減できる可能性があります。   BigQuery分析料金の課金体系フローチャート ここまでの説明を踏まえて、BigQueryの分析料金の課金体系を決めるには、いくつかの判断ポイントがあります。 カンタンなフローチャートにまとめると下記のようになります。 上図を見てもわかる通り、「BigQuery Editionsを使おう」となってもその先にまた判断ポイントがあります。 BigQuery Editionsを「従量課金」で利用するか「コミットメントを購入する」か です。（実は併用も可能ですが、詳細は後ほど説明します。） BigQuery Editionsを従量課金で使用する 従量課金で利用する場合は、下記の設定値が重要になります。 ベースライン（Baseline） ワークロードがアイドル時にオートスケーラーが維持する処理能力の量 特定のワークロードに対して 最低限の処理能力を確保 したい場合に設定 最大スロット（MAX） ワークロードがピーク時のパフォーマンスを達成するためにオートスケーラーが使用できる処理能力の量 予期せぬクエリの急増によるコストの急騰を防ぐ ために設定 最大スロット以上が要求されると、ジョブがスロットの空き待ちになる 以下のようなイメージです。 ベースラインのスロット数までは固定料金として支払いますが、ベースラインから最大スロット数までのは従量課金として支払うイメージです。 BigQuery Editionsでコミットメントを購入する さらに、BigQuery Editionsには「コミットメント購入」という利用方法もあります。 カンタンにいうと、クエリ実行に必要な計算能力（スロット）を、長期的に確保することで割引を受ける仕組みです。 スロットの事前購入 : BigQueryのコンソールから、1年間または3年間の期間で、一定のスロット数（最小100スロット）をまとめて購入 割引の適用 : 長期間の利用を確約する代わりに、オンデマンド課金や時間単位のコミットメントよりも大幅に安い単価でスロットを利用 柔軟な運用 : 購入したスロットは「予約」として管理され、特定のプロジェクトや組織に割り当てて利用 オートスケーリング : 予約したスロットを超えてクエリ実行にスロットが必要になった場合、自動的に追加のスロットが提供され、その分はオンデマンド課金となります。この柔軟性により、コストを抑えつつ、急なワークロードの増加にも対応可能 以下のようなイメージです。 常時多くのスロットを消費しているようなワークロードに対して、スロットをまとめて購入します。 ただし、上図は 極端な例 です。 オンデマンド課金で利用している状態から、いきなり上図にシフトするのはまれなケースだと思います。 BigQuery Editionsで従量課金とコミットメントを併用する 先述した通り、従量課金とコミットメントは併用することが可能です。 例えば、「BigQuery Editionsを従量課金で使用していたが、扱うデータ量/連携先が増え、ワークロードが増加した」場合を考えてみましょう。以下の図のようなイメージです。 設定したベースラインがもはや意味を成していないように見えますね。 上図のような際、ベースラインを引き上げるのももちろん手ですが、長期的に見てもこのような状態が続くのであれば、 一部コミットメントを購入する といった合わせ技が可能です、 オンデマンド課金からEditionsへ移行する際のおすすめフロー オンデマンド課金からEditionsへの移行にあたって、私が考えるおすすめステップは下記です。 Step 0: 現在の利用状況を把握してBigQuery Editionsを使用するか判断 まず、過去のクエリ履歴とコストを分析します。 INFORMATION_SCHEMA.JOBS ビューを利用して、クエリのスキャンデータ量やスロット消費量、実行時間を計測 BigQueryの 「料金」 ページや 「Cloud Billing」 レポートで、過去のコスト推移をチェック このデータから、日・週・月ごとの平均的なスロット使用量を割り出します。 割り出したデータから、「ワークロードの実行に偏りがあるか」「一定期間、まとまったスロット使用量が使用されていないか」などを確認し、BigQuery Editionsを使用するか判断します。 Step 1: BigQuery Editionsを「従量課金」で使用する BigQuery Editionsを使用するとなった場合、まずは「従量課金」で使用されることをお勧めします。 前述したとおり、ベースラインと最大スロットの設定が必要になります。 中でも 最大スロット数の見積もり には注意が必要です。 最大スロット以上の容量が要求されると、ワークロードのジョブが スロットの空き待ち となってしまうためです。 パフォーマンス要件が厳しいワークロードの際は特に注意が必要です。   BigQuery Editionsの使用を開始することで、BigQueryの「容量管理」から スロットの使用状況 などの情報を確認できるようになります。 確認方法については下記ドキュメントをご参照ください。 https://cloud.google.com/bigquery/docs/slot-estimator?hl=ja Step 2: コミットメントの購入を検討する Step1で収集した情報をもとに、 コミットメントの購入 を検討します。 いきなり使用スロットをすべてコミットメントで購入するか、一部をコミットメントとして購入するか。の判断が必要になりますが、前述したとおり、いきなりすべてをコミットメントで購入するパターンは稀だと思います。 まとめ 今回のブログで解説したように、BigQuery Editionsに移行する際は、まずは現在のスロット利用状況を正確に把握し、そこから最適なコミットメントのレベルを見極めることが成功の鍵です。BigQuery Editionsの機能を最大限に活用し、コストを抑えながらビジネスの成長を加速させましょう。 BigQuery Editionsをあなたのワークロードにどう活かしていくか、ぜひ検討してみてください。

本記事は 夏休みクラウド自由研究2025 8/27付の記事です 。 こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 5か月ほど前(もうそんな昔になるのですね…)、AWS Transit Gateway・AWS Direct Connect経由でオンプレミス環境と接続しているVPCの検証に関する記事を書きました。 AWSのVPC間でAWS Site-to-Site VPNを構成する 今回は、テクニカルエスコートサービスによくご相談いただくDirect Connectまわりのご質問について解説します。 よくあるご相談：オンプレミスから既存とは別のVPCにつなぎたい 過去にオンプレミス環境からAWS上に構築したシステムに接続する要件があり、下図のようにvGW(仮想プライベートゲートウェイ)をDirect Connectにアタッチする形でVPCと接続しているケースがよくあります。 そして、AWSの利用が進み、別のVPCに構築したシステムをオンプレミス環境と接続したい(下図)。どのような構成にすればよいか？というご質問をよく頂きます。 構成案：VPC間をVPC Peeringで接続する ご相談いただく際、ご相談者から、以下の案の実現性を訊かれることがあります。 この構成ですが、オンプレミスとVPC2は通信ができません。 VPC間の接続について調べたことがある方であれば推移的ピアリング(はできない)という制約について聞いたことがあるかと思います。VPC A, B, CがあってA – B, A – C をVPCピアリングの機能で接続したときに、A経由でB←→Cの通信はできないというものです。 vGWもVPCピアリングに似た性質を持っているため、前の図のVPC2 ←→ オンプレミスの通信はできないのです。 「vGWもVPCピアリングに似た性質を持っている」という点についてですが、IPルーティングの基礎的な知識をお持ちであれば、以下のように考えると理解しやすいかと思います。 VPCピアリングは、VPCとVPCの間に仮想的なVPCピアリング用ルータがあると考えることができます。(ユーザは確認することができませんが)この仮想VPCピアリング用ルータは、直接接続しているVPCのCIDRへの経路しか登録されていません。したがって、図で言うオンプレミス環境への経路を持っていないため、VPC2からオンプレミス環境へ向けた通信は仮想VPCピアリング用ルータで破棄されます。 vGWは、オンプレミス側からBGPで経路を受け取れるなど、仮想VPCピアリング用ルータよりも柔軟な経路設定ができるという違いはあるものの、他のVPC(この例ではVPC2)のCIDRへの経路を登録する方法がありません。このため、オンプレミス環境からVPC2へ向けた通信はvGWで破棄されます。 上記の通りVPCピアリング案は(そのままでは)うまくいかないため、正攻法として私がまず相談者の方にお話しするのは以下の2パターンです。 Direct Connect Gateway導入 Direct ConnectとvGWの間にDirect Connect Gateway (DXGW)をはさむようにします。DXGWはvGWを20個までアタッチできますので、この構成でオンプレミス環境と20個までのVPCの接続を実現できます。DXGWは料金無料ですので、利用料も上がりません。 設定次第ではあるのですが、注意点として、基本的にはオンプレミス←→VPC通信用であり、VPC間の通信はできないことが挙げられます。 Direct Connect Gateway + Transit Gateway導入 Direct Connect – Direct Connect Gateway – Transit Gateway – VPC という形で構成します。接続可能なVPCの数がDXGWよりずっと大きく(5,000 ※1)、VPC間通信も問題なく行えるため、自由度の高いネットワークを作るのであればお勧めの構成です。ただし、接続するVPC 1つごとに接続料金(50USD/1VPCくらい)が発生します。 ※1 正確には、Transit Gateway あたりのアタッチメント数が5,000 2案の実現性について 上記どちらのパターンでも、一度vGWにアタッチしたDirect Connectの仮想インターフェイスは取り外す(デタッチして別のリソースにアタッチしなおす)ことができず、削除しかできないため、多くの場合(※2)、Direct Connectを提供している通信事業者に依頼して新しい仮想インターフェイスを作成してもらい、既存の仮想インターフェイスから切り替える形になります。 ※2 Direct Connectの提供形態によります。 上記2案は、複数のVPCをオンプレミスと接続する場合にAWS公式ドキュメントなどを調べればすぐに発見できる構成案であり、拡張性や運用性の観点から優れた構成です。しかし、このようなご相談を頂くケースは、オンプレミスとの通信要件の発生したシステムの構築プロジェクトの中でネットワークの検討もしていることが多いため、そのシステムの管理・責任範囲とは言い難い(共用リソースである)Direct Connect GatewayやTransit Gatewayの新規導入や、予期していなかった通信事業者との調整などは高いハードルとなり、これら2案がすんなり受け入れられることはまずありません。 VPCピアリングとNATを組み合わせる Direct Connectまわりは触りたくないという話になると、NATを組み合わせて解決を図ることになります。下図が解決策の一例です。 オンプレミスから見るとVPC2ではなくVPC1と、VPC2から見るとオンプレミスではなくVPC1と、それぞれ通信しているように見えるようにVPC1でNAT(双方向NAT)をしてあげます。この構成であれば宛先への経路がないというルートテーブルの問題を解決できることがお分かり頂けるかと思います。 通信要件が片方向であれば、Network Load Balancer (NLB)を入れるのが簡単です。デフォルトの設定で実質的に双方向NATが実現できます。通信要件が増えるたびにNLBを増やす必要があるので、数が増えると運用管理上の問題が出てきますが、通信要件が少ないうちは手軽で負荷の少ない解決策と言えます。 双方向NATできるものであればなんでもよいので、EC2でNAT用のインスタンスを構築するのも一案です。ENIに複数のIPアドレスを割り当ててやれば、NLBのように通信要件増加ごとにEC2インスタンスを増やさなくてもよいというメリットがあります。ただし、 ENIに割り当てられるIPアドレス数上限 はさほど多くない(m5.largeで10、t3.smallで4)ため、EC2はマネージドサービスではなくユーザーの運用負荷が大きいことも踏まえると、私見ではNLBに軍配が上がると考えています。 なお、NAT Gatewayでも実現できないか？と考えたくなるところですが、あて先NAT機能を持っていないため本ケースでは不適格となります。 まとめ 普通に何らかのシステム用のリソースが置かれているVPC1上に、突如、VPC2へ通信を中継するためのリソースを配置することになるわけで、ネットワーク設計上きれいな設計とは言い難いですが、通信要件がさらに増えたときにはDirect Connect Gateway導入またはDirect Connect Gateway + Transit Gateway導入した方がよいという助言をしつつ、双方向NAT(NLB)+VPCピアリングとするのが落としどころでしょうか。もしもっと良い案ありましたら教えてください！

  本記事は 夏休みクラウド自由研究2025 8/26付の記事です 。 こんにちは。辻です。 先月、表題のAWS認定資格 Cloud Practitioner (CLF-C02) に合格しましたので、今回の自由研究として合格体験記を掲載致します。   はじめに 先日、AWS CLF-C02（クラウドプラクティショナー）を受験して合格しました。 出題形式 選択問題・CBT方式 出題数 65問 試験時間 90分 合格点 700点以上 受験料 16,500円（税込/2025年8月時点） 受験場所 テストセンター 合格点は700点以上なので、ギリギリ合格できました。AWS認定試験では、試験問題の配点率は公開していないので、実際に65問のうち、どれくらい正答していてこの得点に至ったかは不明です。 受験動機 私立文系大学を卒業してから、社会人歴は9年目となりました。 数年前に全くの未経験ながらAWSのPJに短期で携わっていた時に、AWS認定資格の中級レベルであるSAA（ソリューションアーキテクトアソシエイト）を受験した経験があります。当時は、残念ながら合格できませんでした。 それからしばらく、AWSから離れた業務をしており、今年の4月から再びAWSに携わることになったので、基礎からしっかり学んでみよう！と一念発起して、受験に至りました。   使用した教材 使用したテキストは、株式会社impressから出版されている『基礎から実戦レベルまでよくわかる　元祖黒本「徹底攻略」教科書ソリューションアーキテクトアソシエイト』です。 CLF合格後にはSAAを受験する予定なので、教科書として使用するテキストはSAAのものを購入しました。 学習のために使用したサイトは下記の通りです。 ・AWS Skilll Builder ・AWS exam 勉強方法 4月から7月のおよそ3か月間の学習期間で、下記のような学習方法で勉強していました。 ・AWS主催のオンラインセミナーを受講する AWSが主催しているオンラインセミナーで概要の理解を深めたり、試験問題の解説講座を受講していました。 ・模擬試験を毎日解く 間違える度に、回答および解説をノートに記載していました。ひたすら書く！ 解説を呼んでも理解できない問題は、なぜその答えになるのか同僚に質問して、解説いただいておりました。（感謝です！） インプット後にアウトプットできてこその理解だと思うので、自分なりに説明文を画用紙に書いて壁に貼ったり、全くAWSについて知らない家族に説明していました。 試験問題を解いていて、「似たような機能があったはずだけど、なんだっけ…？」と思い出せないときは、ChatGPTに質問していました。 ・なかなか覚えられない用語は関連付けをする 模擬試験を何度も解いていると、徐々に自分の苦手な分野が見えてきます。私は”NATゲートウェイ”をどうしてもインターネットゲートウェイと混同して誤答してしまうことが多かったです。 インターネットゲートウェイ（IGW）：プライベートネットワークとインターネット間の双方向通信を可能にします。 外部からのアクセスも受け入れることができます。 NATゲートウェイ（NAT）：プライベートネットワークからインターネットへの通信のみ可能。 外部からプライベートネットワークへのアクセスはできません。 二つの機能のポイントは「外部からのアクセスを許すかどうか」です。 この違いを覚えられず、練習問題でよく間違えていましたが、 ある日、たまたま観ていた映画の設定がNATゲートウェイと同じ役割をしていることにふと気づきました。     その映画は、小さな子供がモンスターの世界に迷い込むというストーリーです。 物語内の企業は、世界中の子供部屋の扉を管理しており、 モンスター世界と子供部屋をつなぐ役割を持っている設定があります。 ”モンスター世界から子供部屋にはアクセスできる” ”子供部屋からモンスター世界に自由に出入りはできない” 外部（子供部屋）からプライベートネットワーク（モンスター世界）へのアクセスはできない仕組みは、 まさに NATゲートウェイの動作 と同じです。 イラスト付きの教科書を読んだり、模擬試験を解いても頭に入ってこなかった二つの違いですが、 この映画を見てから、「NATゲートウェイは”モンスター世界の扉”」とイメージして覚えられるようになりました。 勉強に躓いた時には、気分転換のために一度離れてみると、新しい見方ができて活路が見いだせるかもしれません。 試験を受けてみての感想 90分はあっという間でした。 模擬試験で9割正答できるようになってから受験しましたが、いざ試験を受けてみると、考え込む時間が想定より長かったです。 悩む問題には、ひとまず”後で見返す”フラグをつけて、どんどん問題を解いていきました。 一通り解き終えて、フラグのついた問題を振り返った際に、日本語から英語表記に戻してみると、閃いたり。。。 問題の正解が AWS Pricing Calculator であることはわかっていたのですが、選択肢には「AWS料金計算ツール」と日本語で書かれていて最初は気づけませんでした。英語表記に置き換えてみたところ「AWS Pricing Calculator」と一致することがわかり、正しく選択できました。 さいごに 今回の学習を通じて実感したのは、「見方を変えること」や「自分なりにイメージしやすい工夫をすること」が理解を深める大きな助けになるという点です。模擬試験や参考書だけでは覚えづらかった内容も、身近な例や映画のワンシーンに置き換えることで、自然と頭に入ってきました。 AWSの勉強は決して楽なものではありませんが、工夫して楽しみながら取り組むことで、続けやすく、成果にもつながると感じています。 次の目標は SAA（ソリューションアーキテクト アソシエイト） 。基礎を固めた今だからこそ挑戦できる試験だと思うので、引き続き頑張っていきたいと思います。

こんにちは、広野です。 検証で Amazon Linux 2023 のデスクトップ環境 (GUI) が必要になり、最新ソリューションを調べてたところ Amazon DCV を使ってみたくなったので環境をつくってみました。 Amazon DCV について 私が説明するまでもなく AWS 公式サイトに説明があるので、そちらを紹介します。もともと NICE-DCV という名前で開発されていたツールを AWS が買収したものです。 Amazon DCV - Amazon Web Services (AWS) aws.amazon.com   そして、構築の仕方も re:Post にありますので参考にしました。 Install GUI (graphical desktop) on Amazon EC2 instances running Amazon Linux 2023 (AL2023) Steps to install desktop environment, desktop manager and Amazon DCV high performance remote display protocol server on ... repost.aws   作成した環境 パブリックサブネットの Amazon Linux 2023 インスタンスに Amazon DCV をインストールしています。 セキュリティグループで、指定したソース IP アドレスからのみアクセスできるようにします。 ログインユーザー名は ec2-user、初期パスワードは AWS Secrets Manager で生成します。 Amazon EC2 インスタンスには Elastic IP アドレスを割り当て、アクセスする URL が固定になるようにします。 AWS CloudFormation で一発デプロイします。Amazon DCV のインストールは userdata スクリプト内で自動実行します。 既存 VPC を使用する前提です。 ポートを 443 にしたかったんですが、QUIC というプロトコル (UDPを使用、1000番以上のポート使用を推奨) が使えるとレスポンスが向上するようだったので、今回はデフォルトのままにしました。 デプロイすると、AWS CloudFormation スタックの出力欄に URL が表示されます。単純に、Elastic IP に HTTPS 8443 番ポートでアクセスするだけのものです。 ブラウザでアクセスすると、ログイン画面が表示されます。 初期パスワードは AWS Secrets Manager で生成されるので、マネジメントコンソールから参照します。ログイン後、パスワード変更してもらえるとより安心です。 無事ログインできると、Amazon Linux 2023 のデスクトップ画面が表示されます。これで検証できそうです！   AWS CloudFormation テンプレート パラメータとして、既存の VPC、サブネットを選択できるようにしています。 自分の IAM ユーザー名をパラメータとして指定します。AWS Secrets Manager の閲覧権限に使用されます。 インスタンスタイプは Amazon DSV の要件上最低でも medium 以上にする必要があるので t3.medium 一択にしています。 EBS のボリュームサイズ、OS のタイムゾーンをパラメータで指定できるようにしています。 AWSTemplateFormatVersion: "2010-09-09" Description: The CloudFormation template that creates a remote-accessible EC2 instance with Amazon DCV. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: System name. use lower case only. (e.g. example) Default: example MaxLength: 10 MinLength: 1 SubName: Type: String Description: System sub name. use lower case only. (e.g. prod or dev) Default: dev MaxLength: 10 MinLength: 1 VpcId: Type: AWS::EC2::VPC::Id Description: Choose a existing VPC ID you deploy the EC2 instance in. InstanceSubnet: Type: AWS::EC2::Subnet::Id Description: Choose an existing Public Subnet ID you deploy the EC2 instance in. InstanceType: Type: String Description: EC2 instance type for dcv-server. Default: t3.medium AllowedValues: - t3.medium InstanceVolumeSize: Type: Number Description: The volume size in GB Default: 10 AllowedSubnet: Type: String Description: Allowed source IPv4 subnet and subnet mask. (e.g. xxx.xxx.xxx.xxx/32) Default: xxx.xxx.xxx.xxx/32 MaxLength: 18 MinLength: 9 YourIamUserName: Type: String Description: Your IAM user name. This is used for the permission of your dcv-server credential. Default: youriamusername MaxLength: 30 MinLength: 1 TimeZone: Type: String Description: The specified time zone. Default: Asia/Tokyo MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # EC2 Launch template # ------------------------------------------------------------# EC2LaunchTemplate: Type: AWS::EC2::LaunchTemplate Properties: LaunchTemplateName: !Sub dcv-server-${SystemName}-${SubName} LaunchTemplateData: InstanceType: !Ref InstanceType ImageId: >- {{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64}} BlockDeviceMappings: - Ebs: VolumeSize: !Ref InstanceVolumeSize VolumeType: gp3 DeleteOnTermination: true Encrypted: true DeviceName: /dev/xvda NetworkInterfaces: - SubnetId: !Ref InstanceSubnet Groups: - !Ref Ec2SecurityGroup DeviceIndex: 0 AssociatePublicIpAddress: false MetadataOptions: HttpTokens: required Monitoring: Enabled: true TagSpecifications: - ResourceType: volume Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} DependsOn: - Ec2SecurityGroup # ------------------------------------------------------------# # EC2 Security Group # ------------------------------------------------------------# Ec2SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref VpcId GroupDescription: Allow dcv-server access via ALB only SecurityGroupIngress: - Description: Allow HTTPS from clients FromPort: 8443 IpProtocol: tcp ToPort: 8443 CidrIp: !Ref AllowedSubnet - Description: Allow QUIC from clients FromPort: 8443 IpProtocol: udp ToPort: 8443 CidrIp: !Ref AllowedSubnet SecurityGroupEgress: - Description: Allow all outbound traffic IpProtocol: -1 CidrIp: 0.0.0.0/0 Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub SG-dcv-server-${SystemName}-${SubName} # ------------------------------------------------------------# # EC2 Role / Instance Profile (IAM) # ------------------------------------------------------------# Ec2Role: Type: AWS::IAM::Role Metadata: cfn_nag: rules_to_suppress: - id: W11 reason: CodeWhisperer requires '*' as a resource, reference https://docs.aws.amazon.com/codewhisperer/latest/userguide/cloud9-setup.html#codewhisperer-IAM-policies Properties: RoleName: !Sub Ec2Role-dcv-server-${SystemName}-${SubName} Description: This role allows EC2 instance to invoke S3 and SSM. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore - arn:aws:iam::aws:policy/AWSCodeCommitPowerUser - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy Policies: - PolicyName: !Sub QDeveloperPolicy-${SystemName}-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Action: - "codewhisperer:GenerateRecommendations" Resource: "*" Effect: Allow - PolicyName: !Sub Ec2SecretsPolicy-${SystemName}-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - secretsmanager:GetResourcePolicy - secretsmanager:GetSecretValue - secretsmanager:DescribeSecret - secretsmanager:ListSecretVersionIds Resource: - !GetAtt SecretDcvServer.Id - PolicyName: !Sub Ec2S3Policy-${SystemName}-${SubName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - "s3:GetObject" Resource: - !Sub "arn:aws:s3:::dcv-license.${AWS::Region}/*" DependsOn: - SecretDcvServer Ec2InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: InstanceProfileName: !Ref Ec2Role Path: / Roles: - !Ref Ec2Role DependsOn: - Ec2Role # ------------------------------------------------------------# # Secrets Manager # ------------------------------------------------------------# SecretDcvServer: Type: AWS::SecretsManager::Secret Properties: Name: !Sub dcv-server-${SystemName}-${SubName} Description: dcv-server credential GenerateSecretString: PasswordLength: 8 ExcludePunctuation: true IncludeSpace: false RequireEachIncludedType: true Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} SecretDcvServerResourcePolicy: Type: AWS::SecretsManager::ResourcePolicy Properties: BlockPublicPolicy: true SecretId: !Ref SecretDcvServer ResourcePolicy: Version: "2012-10-17" Statement: - Effect: Deny Principal: "*" Action: secretsmanager:GetSecretValue Resource: "*" Condition: StringNotEquals: aws:PrincipalArn: - !Sub "arn:aws:iam::${AWS::AccountId}:user/${YourIamUserName}" - !GetAtt Ec2Role.Arn # ------------------------------------------------------------# # Elastic IP address for EC2 instance # ------------------------------------------------------------# EipEc2: Type: AWS::EC2::EIP Properties: Domain: vpc Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub eip-dcv-server-${SystemName}-${SubName} # ------------------------------------------------------------# # EIP Association # ------------------------------------------------------------# EIPAssociation: Type: AWS::EC2::EIPAssociation Properties: AllocationId: !GetAtt EipEc2.AllocationId InstanceId: !Ref Ec2Instance DependsOn: - Ec2Instance - EipEc2 # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# Ec2Instance: Type: AWS::EC2::Instance Properties: IamInstanceProfile: !Ref Ec2InstanceProfile LaunchTemplate: LaunchTemplateId: !Ref EC2LaunchTemplate Version: !GetAtt EC2LaunchTemplate.LatestVersionNumber UserData: Fn::Base64: !Sub | #!/bin/bash set -euxo pipefail timedatectl set-timezone ${TimeZone} # Install packages dnf update -y dnf groupinstall "Desktop" -y # Setup GDM sed -i '/^\[daemon\]/a WaylandEnable=false' /etc/gdm/custom.conf systemctl set-default graphical.target # Get credential from Secrets Manager and set ec2-user password PASSWORD=$(aws secretsmanager get-secret-value --secret-id "${SecretDcvServer.Id}" --region "${AWS::Region}" --query SecretString --output text) echo "ec2-user:${!PASSWORD}" | chpasswd sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config systemctl restart sshd # Install dcv-server cd /tmp rpm --import https://d1uj6qtbmh3dt5.cloudfront.net/NICE-GPG-KEY curl -L -O https://d1uj6qtbmh3dt5.cloudfront.net/nice-dcv-amzn2023-$(arch).tgz tar -xvzf nice-dcv-amzn2023-$(arch).tgz && cd nice-dcv-*-amzn2023-$(arch) dnf install -y ./nice-dcv-server-*.rpm dnf install -y ./nice-dcv-web-viewer-*.rpm dnf install -y ./nice-xdcv-*.rpm systemctl enable dcvserver sed -i "/^\[session-management\/automatic-console-session/a owner=\"ec2-user\"\nstorage-root=\"%home%\"" /etc/dcv/dcv.conf sed -i "s/^#create-session/create-session/g" /etc/dcv/dcv.conf dnf install -y cups usermod -a -G sys dcv systemctl enable --now cups dnf install -y xorg-x11-drv-dummy tee /etc/X11/xorg.conf > /dev/null << EOF Section "Device" Identifier "DummyDevice" Driver "dummy" Option "UseEDID" "false" VideoRam 512000 EndSection Section "Monitor" Identifier "DummyMonitor" HorizSync 5.0 - 1000.0 VertRefresh 5.0 - 200.0 Option "ReducedBlanking" EndSection Section "Screen" Identifier "DummyScreen" Device "DummyDevice" Monitor "DummyMonitor" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Virtual 4096 2160 EndSubSection EndSection EOF if [ -f /usr/bin/nvidia-xconfig ]; then /usr/bin/nvidia-xconfig --preserve-busid --enable-all-gpus dnf install -y vulkan-tools glx-utils fi reboot Tags: - Key: Cost Value: !Sub ${SystemName}-${SubName} - Key: Name Value: !Sub dcv-server-${SystemName}-${SubName} DependsOn: - Ec2InstanceProfile # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: # EIP DcvServerUrl: Value: !Sub "https://${EipEc2.PublicIp}:8443"   まとめ いかがでしたでしょうか？ ベタに Amazon EC2 インスタンスをインターネットからアクセスさせる環境になっているのはイケてないので、Amazon DCV がインストールされたプライベートサブネットの EC2 インスタンスに対して Fleet Manager 経由のリモートアクセスをサポートしてくれるような、AWS のアップデートを期待しています。 本記事が皆様のお役に立てれば幸いです。

本記事は 夏休みクラウド自由研究2025 8/25付の記事です 。 こんにちは、稲葉です。 近年次々と生成AIの技術が登場して、めまぐるしいですね。 クラウド自由研究の記事をきっかけに触ってみようと思いました。 先日AWSからリリースされたKiroは、AIが仕様書やタスクリストを作成しながら実装を行ってくれる「仕様駆動開発」が特徴です。 以下の記事に仕様駆動開発の流れが紹介されています。 Hey Kiro, Spotifyのプレイリストで打線組んで。 AWSが発表した次世代エージェント型IDE「Kiro」を実際に触ってみて、Webアプリケーションを構築してみた体験記となります。 blog.usize-tech.com 2025.08.14 未来を感じたので私もKiroを触ってみようと思います。 本記事では、Kiroで下記4つの内容を試してみようと思います。 Agent Steering機能を試す  Agent Hooks機能を試す 既存のコードを読み取り、仕様書を生成する Terraformのテストコードの作成とテストを実施する また、下記2つのMCPサーバーを利用しています。 awslabs-aws-documentation-mcp-server awslabs-aws-terraform-mcp-server   用意したTerraformコード 下記のようなシンプルな構成のTerraformコードを用意しました。 . ├── main.tf <- new! └── .kiro └── settings └── mcp.json EC2インスタンスのパブリックIPにアクセスすると、hello worldと返ってくるようにしています。 また、セッションマネージャーでインスタンスにアクセスできるようにしています。 Terraformコード（main.tf） terraform { backend"local" { path="kiro-test.tfstate" } required_providers { aws={ source="hashicorp/aws" version="~> 5.57.0" } } } provider "aws" { region="ap-northeast-1" profile="＜プロファイル＞" } # VPC resource "aws_vpc" "vpc" { cidr_block="10.0.0.0/16" } resource "aws_internet_gateway" "igw" { vpc_id=aws_vpc.vpc.id } resource "aws_subnet" "public_subnet" { vpc_id=aws_vpc.vpc.id cidr_block="10.0.1.0/24" availability_zone="ap-northeast-1a" map_public_ip_on_launch=true } # ルートテーブル resource "aws_route_table" "public_route" { vpc_id=aws_vpc.vpc.id route { cidr_block="0.0.0.0/0" gateway_id=aws_internet_gateway.igw.id } } resource "aws_route_table_association" "public_route_association" { subnet_id=aws_subnet.public_subnet.id route_table_id=aws_route_table.public_route.id } # EC2インスタンス用セキュリティグループ resource "aws_security_group" "web_sg" { name="web-sg" description="Allow HTTP from specific IP" vpc_id=aws_vpc.vpc.id } resource "aws_vpc_security_group_ingress_rule" "allow_http_rule" { security_group_id=aws_security_group.web_sg.id cidr_ipv4="＜接続を許可するIPアドレス＞" from_port=80 ip_protocol="tcp" to_port=80 } resource "aws_vpc_security_group_egress_rule" "egress_rule" { security_group_id=aws_security_group.web_sg.id cidr_ipv4="0.0.0.0/0" from_port=0 ip_protocol="-1" to_port=0 } # SSM用IAMロール resource "aws_iam_role" "ssm_role" { name="ec2-ssm-role" assume_role_policy=jsonencode({ Version="2012-10-17" Statement= [{ Action="sts:AssumeRole" Effect="Allow" Principal= { Service="ec2.amazonaws.com" } }] }) } resource "aws_iam_role_policy_attachment" "ssm_attach" { role=aws_iam_role.ssm_role.name policy_arn="arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" } resource "aws_iam_instance_profile" "ssm_profile" { name="ec2-ssm-profile" role=aws_iam_role.ssm_role.name } # EC2 resource "aws_instance" "web_instance" { ami="ami-0f36dcfcc94112ea1"# Amazon Linux 2 (東京) instance_type="t3.micro" subnet_id=aws_subnet.public_subnet.id vpc_security_group_ids=[aws_security_group.web_sg.id] iam_instance_profile=aws_iam_instance_profile.ssm_profile.name user_data=<<-EOF #!/bin/bash yum update -y amazon-linux-extras install nginx1 -y systemctl enable nginx systemctl start nginx echo "hello world" > /usr/share/nginx/html/index.html EOF } Agent Steeringを試す Agent Steeringはプロジェクトに関する知識をKiroに与えるための機能です。 プロジェクトで作成するアプリケーションについての知識や、プロジェクトで使用するツールについての知識、プロジェクトを進める上でのルールについての知識など、さまざまな知識を与えることができます。 プロジェクトを進める上での2つのルールを設定しようと思います。 やりとりを日本語で行うこと 作成されるリソースにはタグが付いていること やりとりの日本語化 KiroのVibeモードでやりとりを日本語化するSteeringの作成をお願いしました。 Kiroとのやりとりを日本語で行うようにするSteeringファイルを作成してください するとプロジェクトフォルダの.kiroディレクトリ内にSteering用のディレクトリが作成され、その中に作成をお願いしたSteeringファイルができていました。 . ├── main.tf └── .kiro ├── settings │ └── mcp.json └── steering <- new! └── language.md <- new! Steeringファイルはマークダウン形式で書かれていて、人間が呼んでもわかりやすい形式になってました。 日本語化のお願いのほかにも、コミュニケーションのスタイルや日本語化しないことまで設定してくれていて気が利きますね！ --- inclusion: always --- # 日本語コミュニケーションガイドライン ## 基本言語設定 - **主要言語**: すべての回答とコミュニケーションは日本語で行う - **コード内コメント**: 日本語でコメントを記述 - **ドキュメント**: README、設計書等も日本語で作成 - **エラーメッセージ**: 可能な限り日本語で説明 ## コミュニケーションスタイル - **敬語**: 丁寧語を基本とし、親しみやすい口調を心がける - **専門用語**: 必要に応じて英語の技術用語も併記（例：コンテナ（Container）） - **説明方法**: 段階的で分かりやすい説明を提供 - **質問対応**: 不明な点は積極的に確認する ## 文書作成ルール - **見出し**: 階層構造を明確にする - **箇条書き**: 情報を整理して提示 - **コード例**: 日本語コメント付きで提供 - **手順書**: ステップバイステップで記述 ## 例外事項 - **コマンド**: CLIコマンドは英語のまま - **設定ファイル**: JSON、YAML等の設定値は英語 - **URL・パス**: ファイルパスやURLは英語 - **ログ出力**: システムログは元の言語のまま ## 対応範囲 - **技術説明**: インフラ、開発、運用すべて日本語 - **トラブルシューティング**: 問題解決も日本語で対応 - **ベストプラクティス**: 推奨事項も日本語で提示 - **レビューコメント**: コードレビューも日本語 ヘッダーの下記記述は、Steeringファイルを読み込むタイミングを設定する箇所です。 --- inclusion: always --- 3つのタイミングを設定できます always（default）: 常にこのSteeringファイルを読む fileMatch: 指定したファイルを扱うときにこのSterringファイルを読む manual: 通常このSteeringファイルを読まない。チャットで#＜Sterringファイル名＞のように指定した時だけ読む Steering - Docs - Kiro Guide Kiro's AI with project-specific context through markdown documents that define your standards, architecture, and c... kiro.dev 作成するリソースへのタグ付け 次にTerraformで作成されるリソースにタグを付与するよう、設定の作成をお願いしました。 このプロジェクトのTerraformから生成される全てのAWSリソースに次のタグを付与するルールを記載してください。 - ManagedBy: Terraform - Project: Kiro-test 先ほどのように.kiro/steeringの下にtag-rules.mdというSteeringファイルができていました。 default_tagsでTerraformが生成するすべてのリソースにManagedByタグとProjectタグを付与する設定をしていますね。 また、各リソースにはdefault_tagsで付与するタグの他にNameタグとEnvironmentタグを付与する設定になっています。 いい感じですね！ --- inclusion: always --- # AWS リソースタグ付与ルール ## 必須タグ Kiroで生成・管理する全てのAWSリソースには以下のタグを必ず付与すること： ### 基本タグ（このプロジェクト固有） - **ManagedBy**: `Terraform` - Terraformによって管理されていることを示す - **Project**: `Kiro-test` - このプロジェクト専用の識別子 ## Terraformでの実装例 ### リソース共通タグ ```hcl locals { common_tags = { ManagedBy = "Terraform" Project = "Kiro-test" } } ``` ### プロバイダーレベルでのデフォルトタグ ```hcl provider "aws" { default_tags { tags = local.common_tags } } ``` ## 適用ルール 1. **全リソース必須**: EC2、S3、RDS、Lambda等すべてのAWSリソース 2. **一貫性**: プロジェクト内で統一されたタグ命名規則 3. **自動化**: Terraformのlocalsとdefault_tagsを活用 4. **検証**: タグが正しく付与されているかの確認を含める ## 例外処理 - 一時的なテストリソースでも必須タグ（`ManagedBy: Terraform`, `Project: Kiro-test`）は必須 - サードパーティサービス連携で制限がある場合は代替手段を検討 ## プロジェクト固有設定 このプロジェクト「Kiro-test」では以下の固定値を使用： - **ManagedBy**: 必ず `Terraform` を設定 - **Project**: 必ず `Kiro-test` を設定 ### 実装例 ```hcl# 全リソースに自動適用 provider "aws" { default_tags { tags = { ManagedBy = "Terraform" Project = "Kiro-test" } } } # 個別リソースでの追加タグ例 resource "aws_instance" "example" { # ... その他の設定 ... tags = merge(local.common_tags, { Name = "example-instance" Environment = "dev" }) } ``` コードから仕様書を生成する Kiroではspecsという単位でプロジェクトを管理し、下記3フェーズでシステムを構築します。 requirements : 要件定義 design: 技術設計 tasks: タスクリストの作成、実行 tasksフェーズが終了後、Kiroは仕様書を作成します。 本稿では既存のterraformファイルをKiroに読み込ませ、上記フェーズの実施と仕様書の生成ができるか確かめようと思います。 要件定義フェーズ 次の画像のように、vibeモードでspecsの作成をお願いしました。 specsを作成すると、1番目の要件定義フェーズに入ります。 このフェーズは、プロンプトで指定した内容から要件を定義し、requirements.mdというファイルにまとめるフェーズです。 やりとりを見ていくと、1行目では日本語化するSteeringが効いていませんね。 この行はKiroがプロンプトの内容からSpecモードの方が適切だと判断し、VibeモードからSpecモードに切り替えましょうかという提案をしてきている内容でした。Yesで切り替えました。 1行目以外では日本語でやりとりできています。 タグ付けルールのSteeringは効いていて、必須タグが設定されていないよと指定してくれています。 他にも色々とKiroにアドバイスをいただき、requirements.mdが作られました。 . ├── main.tf └── .kiro ├── settings │ └── mcp.json ├── specs <- new! │ └── terraform-infrastructure-enhancement <- new! │ └── requirements.md <- new! └── steering └── language.md 今回はシンプルな環境で検証したいので、Kiroのアドバイスは無視します。 それでは、作成されたrequirements.md（要件定義書）を確認します。 # 要件定義書 ## はじめに 現在のTerraformインフラ構成にタグ付与ルールを適用するための機能です。ステアリングルールで定義された必須タグ（ManagedBy: Terraform、Project: Kiro-test）をすべてのAWSリソースに自動的に適用します。 ## 要件 ### 要件1: タグ付与ルールの適用 **ユーザーストーリー:** インフラ管理者として、すべてのAWSリソースに統一されたタグが自動的に付与されるようにしたい。これにより、リソースの管理と追跡が容易になる。 #### 受け入れ基準 1. WHEN Terraformリソースが作成される THEN システムは ManagedBy="Terraform" タグを自動的に付与する 2. WHEN Terraformリソースが作成される THEN システムは Project="Kiro-test" タグを自動的に付与する 3. WHEN プロバイダーレベルでdefault_tagsが設定される THEN すべてのリソースに共通タグが適用される 4. WHEN 個別リソースに追加タグが必要な場合 THEN 共通タグとマージして適用される requirements.mdでは、既存のコードに対してKiroが加える要件の内容が記載されています。 既存コードの内容は無いですね。 さらにテスト要件も伝えました。 この内容で次のフェーズ（design.md（技術設計書）の作成） に進もうと思います。 技術設計書には、既存コードの内容も含まれていてほしいです。 技術設計フェーズ design.md（技術設計書）の作成をお願いしました。 design.mdが作られました。 . ├── main.tf └── .kiro ├── settings │ └── mcp.json ├── specs │ └── terraform-infrastructure-enhancement │ ├── requirements.md | └── design.md <- new! └── steering └── language.md 確認してみると、こちらは既存コードの内容が入っていました！ アーキテクチャの情報やタグ付け戦略、テスト戦略などが欲しい情報が記載されていて、満足できる出来栄えでした！ # 設計文書 ## 概要 現在のTerraformインフラ構成にタグ付与ルールを適用するための設計です。 ステアリングルールで定義された必須タグ（ManagedBy: Terraform、Project: Kiro-test） をすべてのAWSリソースに自動的に適用し、リソース管理の一貫性と追跡可能性を向上させます。 ## アーキテクチャ ### 現在の構成分析 現在のmain.tfファイルには以下のリソースが定義されています： - VPC（aws_vpc.vpc） - インターネットゲートウェイ（aws_internet_gateway.igw） - パブリックサブネット（aws_subnet.public_subnet） - ルートテーブル（aws_route_table.public_route） - ルートテーブル関連付け（aws_route_table_association.public_route_association） - セキュリティグループ（aws_security_group.web_sg） - セキュリティグループルール（aws_vpc_security_group_ingress_rule、aws_vpc_security_group_egress_rule） - IAMロール（aws_iam_role.ssm_role） - IAMロールポリシーアタッチメント（aws_iam_role_policy_attachment.ssm_attach） - IAMインスタンスプロファイル（aws_iam_instance_profile.ssm_profile） - EC2インスタンス（aws_instance.web_instance） ### タグ付与戦略 #### 1. プロバイダーレベルでのデフォルトタグ設定 ```hcl provider "aws" { region = "ap-northeast-1" profile = "inaba" default_tags { tags = { ManagedBy = "Terraform" Project = "Kiro-test" } } } ``` #### 2. ローカル変数での共通タグ定義 ```hcl locals { common_tags = { ManagedBy = "Terraform" Project = "Kiro-test" } } ``` ## コンポーネントと インターフェース ### 1. タグ管理コンポーネント **目的**: 全リソースに統一されたタグを適用する **実装方法**: - プロバイダーレベルでのdefault_tags設定 - localsブロックでの共通タグ定義 - 個別リソースでの追加タグ対応 ### 2. リソース識別コンポーネント **目的**: 各リソースに適切な名前とタグを付与する **実装方法**: - 既存リソースへのNameタグ追加 - リソース種別に応じた追加タグの設定 ### 3. テスト自動化コンポーネント **目的**: インフラの動作とセキュリティを自動的に検証する **実装方法**: - Bashスクリプトによるテスト自動化 - AWS CLIを使用したリソース状態確認 - curlコマンドによるWebサーバー動作確認 - nmapによるポートスキャン - Checkovによるセキュリティスキャン ### 4. セキュリティ検証コンポーネント **目的**: IPアドレス制限とSSM接続を検証する **実装方法**: - 複数IPアドレスからのアクセステスト - セッションマネージャー接続テスト - セキュリティグループルールの動作確認 ## データモデル ### タグデータ構造 ```hcl # 必須タグ（全リソース共通） common_tags = { ManagedBy = "Terraform" # 固定値 Project = "Kiro-test" # 固定値 } # リソース固有タグ（例） resource_specific_tags = { Name = "リソース名" Environment = "dev" Component = "web-server" } # 最終的なタグ（マージ結果） final_tags = merge(local.common_tags, local.resource_specific_tags) ``` ## エラーハンドリング ### 1. タグ適用失敗への対応 **問題**: 一部のAWSリソースでタグ適用がサポートされていない場合 **対応**: - Terraformの警告メッセージを確認 - サポートされていないリソースは文書化 - 代替手段（リソース名での識別など）を検討 ### 2. タグ制限への対応 **問題**: AWSのタグ制限（50個まで、キー/値の長さ制限など） **対応**: - 必須タグを優先 - 追加タグは必要最小限に抑制 - タグ命名規則の統一 ## テスト戦略 ### 1. タグ適用確認テスト **目的**: すべてのリソースに必須タグが適用されているかを確認 **方法**: ```bash # Terraform planでタグ設定を確認 terraform plan # AWS CLIでリソースのタグを確認 aws ec2 describe-instances --query 'Reservations[].Instances[].Tags' aws ec2 describe-vpcs --query 'Vpcs[].Tags' ``` ### 2. インフラ動作テスト **目的**: Terraformで構築したインフラが正しく動作することを確認 **方法**: ```bash # 構文チェック terraform validate # リソース作成確認 terraform plan terraform apply # Webサーバー動作確認 curl -I http://[EC2のパブリックIP] # ネットワーク接続確認 ping [EC2のパブリックIP] # セッションマネージャー接続確認 aws ssm start-session --target [インスタンスID] ``` ### 3. セキュリティテスト **目的**: セキュリティ設定が正しく機能することを確認 **方法**: ```bash # IPアドレス制限テスト（許可されたIP） curl -I http://[EC2のパブリックIP] --interface [許可されたIP] # IPアドレス制限テスト（拒否されるIP） curl -I http://[EC2のパブリックIP] --interface [許可されていないIP] # セキュリティスキャン checkov -f main.tf # ポート開放チェック nmap -p 1-65535 [EC2のパブリックIP] ``` ### 4. タグ一貫性テスト **目的**: プロジェクト全体でタグの一貫性を確認 **方法**: - 全リソースのタグをエクスポート - ManagedBy="Terraform"、Project="Kiro-test"の存在確認 - タグ値の正確性確認 ## 実装詳細 ### Phase 1: プロバイダー設定の更新 - default_tagsをプロバイダーブロックに追加 - 既存の設定を維持しながらタグ機能を追加 ### Phase 2: ローカル変数の定義 - common_tagsローカル変数を定義 - 将来の拡張性を考慮した構造 ### Phase 3: 個別リソースのタグ設定 - 既存リソースにNameタグを追加 - 必要に応じて追加のタグを設定 ### Phase 4: テストスクリプトの作成 - インフラ動作テスト用のスクリプト作成 - セキュリティテスト用のスクリプト作成 - IPアドレス制限テスト用のスクリプト作成 - セッションマネージャー接続テスト用のスクリプト作成 ### Phase 5: 検証とテスト実行 - terraform planでの変更内容確認 - 実際のリソースへのタグ適用確認 - インフラ動作テストの実行 - セキュリティテストの実行 - 既存機能の動作確認 ## 設計上の考慮事項 ### 1. 後方互換性 - 既存のリソース設定を変更せず、タグのみを追加 - インフラの動作に影響を与えない変更 ### 2. 拡張性 - 将来的な追加タグに対応できる構造 - 環境別（dev/staging/prod）への対応準備 ### 3. 保守性 - タグ定義の一元管理 - 変更時の影響範囲を最小化 ### 4. コスト管理 - タグによるリソース使用量の追跡が可能 - プロジェクト別のコスト分析が容易 この設計書でtasks.md（タスクリスト）を作成します。 タスクリストの作成、実行フェーズ tasks.md（タスクリスト）の作成をお願いしました。 tasks.mdが作られました。 . ├── main.tf └── .kiro ├── settings │ └── mcp.json ├── specs │ └── terraform-infrastructure-enhancement │ ├── requirements.md | ├── design.md | └── tasks.md <- new! └── steering └── language.md タスクリストが作成され、各タスク毎に実行できるようになってました。 # 実装計画 - [ ] 1. Terraformタグ設定の実装 - プロバイダーレベルでdefault_tagsを設定し、すべてのリソースに必須タグを自動適用する - localsブロックで共通タグを定義し、保守性を向上させる - 既存リソースにNameタグを追加し、リソース識別を改善する -_要件: 1.1, 1.2, 1.3, 1.4_ - [ ] 2. インフラ動作テストスクリプトの作成 - Terraform構文チェックとリソース作成確認のスクリプトを作成する - Webサーバー動作確認（HTTP応答）のテストスクリプトを作成する - ネットワーク接続確認のテストスクリプトを作成する -_要件: 2.1, 2.2, 2.3, 2.4_ - [ ] 3. セキュリティテストスクリプトの作成 - セキュリティグループのポート制限確認スクリプトを作成する - IPアドレス制限テスト（許可されたIPからのアクセス）スクリプトを作成する - IPアドレス制限テスト（拒否されるIPからのアクセス）スクリプトを作成する -_要件: 2.5, 2.7, 2.8_ - [ ] 4. SSM接続テストスクリプトの作成 - セッションマネージャーでのEC2接続確認スクリプトを作成する - SSMロールとインスタンスプロファイルの動作確認を含める -_要件: 2.6, 2.9_ - [ ] 5. セキュリティスキャン機能の実装 - Checkovを使用したTerraformコードのセキュリティスキャンスクリプトを作成する - 高リスク脆弱性の検出と報告機能を実装する - IAM権限の最小権限原則チェック機能を実装する -_要件: 3.1, 3.2, 3.3_ - [ ] 6. 暗号化設定確認機能の実装 - EBSボリュームの暗号化設定確認スクリプトを作成する - リソースの暗号化状態を検証する機能を実装する -_要件: 3.4_ - [ ] 7. 統合テストスクリプトの作成 - 全テストを順次実行する統合テストスクリプトを作成する - テスト結果の集約と報告機能を実装する - テスト失敗時のエラーハンドリングを実装する -_要件: 2.1-2.9, 3.1-3.4_ - [ ] 8. ドキュメントとREADMEの作成 - テストスクリプトの使用方法を説明するREADMEを作成する - 各テストの目的と期待結果を文書化する - トラブルシューティングガイドを作成する -_要件: 全要件のサポート文書_ これらのタスクをすべて完了すると、下記8つのドキュメントがKiroによって生成されました。 README.md : 仕様書 TROUBLESHOOTING.md: トラブルシューティングガイド TEST_SPECIFICATIONS.md: 各テストの仕様書 TEST_README.md: インフラテスト詳細ガイド INTEGRATED_TEST_README.md: 統合テスト詳細ガイド SECURITY_TEST_README.md: セキュリティテスト詳細ガイド SSM_TEST_README.md: SSMテスト詳細ガイド SECURITY_SCAN_README.md: セキュリティスキャン詳細ガイド 作成された仕様書は長くなってしまうので本稿の最後に記載します。 （その他の仕様書は割愛します。） 他にもテストスクリプトが生成されたので、このスクリプトを使用してテストをしていきます。 テストを実施する Kiroが作成したテストスクリプトを使用してテストします。 Kiroは下記5つのテストスクリプトを生成しました。 test-infrastructure.sh test-security.sh test-ssm.sh test-security-scan.sh test-encryption.sh また、これらのテストスクリプトをまとめて実行できるように、run-all-tests.shも生成されました。 run-all-tests.shを使用して、まとめてテストしようと思います。   まずTerraformでリソースをプロビジョニングします。 // Terraformの初期設定 terraform init // Terraformをdry runする terraform plan // リソースをデプロイする terraform apply EC2の立ち上がりやyunのアップデート、Webサーバーの立ち上がりを待つため、120秒ほど待つ sleep 120 その後テストプログラムを実行します。 export AWS_PROFILE=＜プロファイル名＞ export AWS_REGION=ap-northeast-1 ./run-all-tests.sh 結果が下記になります。 ========================================== Terraform Infrastructure Enhancement 統合テスト開始 ========================================== [INFO] 開始日時: 2025-08-24 00:43:21 ========================================== 前提条件チェック ========================================== [SUCCESS] terraform が利用可能です [SUCCESS] aws が利用可能です [SUCCESS] curl が利用可能です [SUCCESS] jq が利用可能です [SUCCESS] AWS認証情報が設定されています [INFO] アカウントID: xxxxxxx [INFO] ユーザー/ロール: arn:aws:iam::xxxxxxx:user/xxxxx [SUCCESS] Terraformが初期化されています [SUCCESS] test-infrastructure.sh が見つかりました [SUCCESS] test-security.sh が見つかりました [SUCCESS] test-ssm.sh が見つかりました [SUCCESS] test-security-scan.sh が見つかりました [SUCCESS] test-encryption.sh が見つかりました [SUCCESS] すべての前提条件が満たされています ========================================== 1. インフラ動作テスト実行中... ========================================== [SUCCESS] インフラ動作テストが完了しました [SUCCESS] ✅ インフラ動作テスト (実行時間: 25秒) ========================================== 2. セキュリティテスト実行中... ========================================== [SUCCESS] セキュリティテストが完了しました [SUCCESS] ✅ セキュリティテスト (実行時間: 21秒) ========================================== 3. SSM接続テスト実行中... ========================================== [SUCCESS] SSM接続テストが完了しました [SUCCESS] ✅ SSM接続テスト (実行時間: 15秒) ========================================== 4. セキュリティスキャンテスト実行中... ========================================== [WARNING] セキュリティスキャンテストで問題が検出されました ================================== セキュリティスキャン結果サマリー ================================== 総テスト数: 10 成功: 8 失敗: 2 [ERROR] 2 個のテストが失敗しました ⚠️ セキュリティ改善が必要です 詳細なレポートを確認してください: - security_scan_report.txt - security_scan_results.json 推奨アクション: 1. 高リスク脆弱性を優先的に修正 2. セキュリティグループのCIDR制限を見直し 3. EBSボリュームの暗号化を有効化 4. IAM権限の最小権限原則を確認 [SUCCESS] ✅ セキュリティスキャンテスト (実行時間: 13秒) ========================================== 5. 暗号化設定確認テスト実行中... ========================================== [ERROR] 暗号化設定確認テストでエラーが発生しました Terraform設定例: resource "aws_instance" "example" { # ... 他の設定 ... root_block_device { encrypted = true kms_key_id = "alias/aws/ebs" # オプション: カスタムKMSキー } } ========================================== 暗号化設定確認テスト結果 ========================================== 総テスト数: 3 成功: 1 失敗: 2 ✗ 一部の暗号化テストが失敗しました 暗号化設定確認結果をファイルに保存中... ℹ 結果がencryption_check_results.txtに保存されました [ERROR] ❌ 暗号化設定確認テスト (実行時間: 7秒) ========================================== 統合テスト結果レポート生成中... ========================================== [SUCCESS] 統合テスト結果レポートを integrated_test_report.txt に保存しました ========================================== 統合テスト結果サマリー ========================================== [INFO] 実行時間: 83秒 (1分23秒) [INFO] 総テストスイート数: 5 [SUCCESS] 成功: 4 [ERROR] 失敗: 1 [INFO] 詳細結果: ✅ インフラ動作テスト: 成功 (25秒) - Terraform構文チェック、リソース作成確認、ネットワーク接続、Webサーバー動作 ✅ セキュリティテスト: 成功 (21秒) - セキュリティグループ設定、IPアドレス制限、ポートアクセス制限 ✅ SSM接続テスト: 成功 (15秒) - セッションマネージャー接続、SSMロール・インスタンスプロファイル確認 ✅ セキュリティスキャンテスト: 成功 (13秒) - Checkovセキュリティスキャン、IAM権限チェック、脆弱性検出 ❌ 暗号化設定確認テスト: 失敗 (7秒) - EBSボリューム暗号化、アカウントレベル暗号化設定 [ERROR] ⚠️ 1 個のテストスイートで問題が検出されました [INFO] 詳細は integrated_test_report.txt を確認してください 色々と指定されていますね。 EBSボリュームの暗号化が有効化されていないので、色々とエラーが出ているように見えます。 このようにTerraformで作成したリソースをテストすることができました！ Agent Hooksを試す Agent HooksはKiroで特定のイベント（ファイルの新規作成、保存、削除）が発生したとき、設定したアクションを実行するトリガーです。 Terraformコードが更新されたとき、セキュリティ的な問題が無いかチェックする設定の作成をお願いしました。 KiroのIDEからAgent Hooksを追加します。 Agent Hooksの設定画面が出るので、Describe a hook using natural languageの欄に下記のプロンプトを記載しました。 するとKiroが動き、Hooksファイルを作成してくれます。 Terraformのファイルの更新時、以下の問題がないかチェックするAgent Hooks作成してください。 - 認証情報のハードコーディング - セキュリティグループのインバウンドルールで0.0.0.0/0を開放 問題があれば、chatを開き問題の場所と修正案を提示してください プロジェクトフォルダの.kiroディレクトリ内にHooks用のディレクトリが作成され、その中にHooksファイルができていました。 . ├── main.tf └── .kiro ├── settings │ └── mcp.json ├── specs │ └── terraform-infrastructure-enhancement │ └── requirements.md ├── steering │ ├── language.md │ └── tag-rules.md └── hooks <- new! └── terraform-security-check.json <- new! こちらはjsonファイルで作成されました。 terraformのファイルが更新されたとき、エージェントがこのプロンプトを入力、実行してくれるみたいですね。 内容はシンプルで分かりやすいですね！ { "enabled": true, "name":"Terraform セキュリティチェック", "description":"Terraformファイルの更新時に認証情報のハードコーディングとセキュリティグループの0.0.0.0/0開放をチェックし、問題があればチャットで修正案を提示します", "version":"1", "when":{ "type":"fileEdited", "patterns":[ "*.tf", "*.tfvars", "*.terraform" ] }, "then":{ "type":"askAgent", "prompt": "Terraformファイルが更新されました。以下のセキュリティ問題をチェックしてください：\n\n 1. **認証情報のハードコーディング**\n - AWS Access Key、Secret Key\n - パスワード、APIキー\n - データベース接続文字列\n - その他の機密情報\n\n 2. **セキュリティグループのインバウンドルール**\n - 0.0.0.0/0からのアクセス許可\n - 不適切なポート開放\n - 過度に緩いアクセス制御\n\n 問題を発見した場合は、以下の形式でチャットを開いて報告してください：\n - 問題の場所（ファイル名と行番号）\n - 具体的な問題内容\n - 推奨される修正案\n - セキュリティリスクの説明\n\n 問題がない場合は、「セキュリティチェック完了：問題は検出されませんでした」と報告してください。" } } Terraformコードのセキュリティグループを変更して、インバウンドルールの0.0.0.0/0を開放してみます（下記図の54行目）。   すると、Kiroによってインバウンドルールで0.0.0.0/0が空いていること検出されました！ 最後に 初めてKiroを触りましたが、想像以上にドキュメントを作成してくれるのですごいなと思いました。 Terraformのテストの方法で悩んでいたので、checkovなどのツールを知れたのも良かったです。 Specsモードは当然ですが、Agent SteeringやAgent Hooksなどの各機能も便利で、引き続きKiro触って行きたいなと思います。 記事を書いている間にKiroのプレビュー版が終わって慌てましたが、無事書き終えられてよかったです。 作成された仕様書 # Terraform Infrastructure Enhancement プロジェクト ## 概要 このプロジェクトは、Terraformで構築したAWSインフラストラクチャに対して、統一されたタグ付与ルールの適用と包括的なテスト機能を提供します。 ## 主な機能 - **統一タグ付与**: すべてのAWSリソースに必須タグ（ManagedBy: Terraform、Project: Kiro-test）を自動適用 - **インフラ動作テスト**: Terraformで構築したインフラの動作確認 - **セキュリティテスト**: セキュリティグループ設定とIPアドレス制限の検証 - **SSM接続テスト**: セッションマネージャーによるEC2接続確認 - **セキュリティスキャン**: Checkovを使用したセキュリティ脆弱性検出 - **暗号化設定確認**: EBSボリュームなどの暗号化状態検証 - **統合テスト**: 全テストスイートの自動実行と結果集約 ## プロジェクト構成 ``` . ├── README.md # このファイル ├── main.tf # Terraformメイン設定 ├── outputs.tf # Terraform出力定義 ├── run-all-tests.sh # 統合テストスクリプト ├── test-infrastructure.sh # インフラ動作テスト ├── test-security.sh # セキュリティテスト ├── test-ssm.sh # SSM接続テスト ├── test-security-scan.sh # セキュリティスキャンテスト ├── test-encryption.sh # 暗号化設定確認テスト ├── test-network-detailed.sh # 詳細ネットワークテスト ├── .kiro/ │ ├── specs/terraform-infrastructure-enhancement/ │ │ ├── requirements.md # 要件定義書 │ │ ├── design.md # 設計文書 │ │ └── tasks.md # 実装計画 │ └── steering/ │ ├── tag-rules.md # タグ付与ルール │ └── language.md # 日本語コミュニケーションガイド └── 各種READMEファイル/ ├── TEST_README.md # インフラテスト詳細ガイド ├── INTEGRATED_TEST_README.md # 統合テスト詳細ガイド ├── SECURITY_TEST_README.md # セキュリティテスト詳細ガイド ├── SSM_TEST_README.md # SSMテスト詳細ガイド └── SECURITY_SCAN_README.md # セキュリティスキャン詳細ガイド ``` ## 前提条件 ### 必要なツール 以下のツールがインストールされている必要があります： - **Terraform** (>= 1.0) - **AWS CLI** (>= 2.0) - 認証情報設定済み - **jq** - JSON処理用 - **curl** - HTTP通信用 - **nmap** - ポートスキャン用（オプション） - **Checkov** - セキュリティスキャン用 ### インストール方法（macOS） ```bash # Homebrew経由でのインストール brew install terraform awscli jq curl nmap # Checkovのインストール brew install checkov # または pipx install checkov ``` ### AWS認証情報の設定 ```bash # AWS CLIプロファイルの設定 aws configure --profile inaba # または環境変数での設定 export AWS_PROFILE=inaba export AWS_REGION=ap-northeast-1 ``` ## クイックスタート ### 1. インフラのデプロイ ```bash # Terraformの初期化 terraform init # プランの確認 terraform plan # インフラのデプロイ terraform apply ``` ### 2. 統合テストの実行 ```bash # 全テストスイートを実行 ./run-all-tests.sh ``` ### 3. 個別テストの実行 ```bash # インフラ動作テスト ./test-infrastructure.sh # セキュリティテスト ./test-security.sh # SSM接続テスト ./test-ssm.sh # セキュリティスキャ ./test-security-scan.sh # 暗号化設定確認 ./test-encryption.sh ``` ## テストスイート詳細 ### 1. インフラ動作テスト (`test-infrastructure.sh`) **目的**: Terraformで構築したインフラの基本動作を確認 **テスト項目**: - Terraform構文チェック - リソース作成確認 - Webサーバー動作確認（HTTP応答） **期待結果**: すべてのリソースが正常に動作し、Webサーバーが「hello world」を返す ### 2. セキュリティテスト (`test-security.sh`) **目的**: セキュリティグループ設定とアクセス制限を検証 **テスト項目**: - セキュリティグループのポート制限確認 - 許可されたIPアドレスからのアクセステスト - 拒否されるIPアドレスからのアクセステスト - 危険ポートの開放チェック **期待結果**: 適切なアクセス制限が機能し、不要なポートが開放されていない ### 3. SSM接続テスト (`test-ssm.sh`) **目的**: セッションマネージャーによるEC2接続を確認 **テスト項目**: - EC2インスタンスの状態確認 - SSMエージェントの接続状態確認 - IAMロールとポリシーの確認 - セッションマネージャー接続テスト **期待結果**: SSM経由でEC2インスタンスに接続可能 ### 4. セキュリティスキャンテスト (`test-security-scan.sh`) **目的**: Checkovを使用したセキュリティ脆弱性の検出 **テスト項目**: - 基本セキュリティスキャン - 高リスク脆弱性検出 - IAM最小権限原則チェック - セキュリティグループ設定検証 **期待結果**: 高リスクの脆弱性が検出されない ### 5. 暗号化設定確認テスト (`test-encryption.sh`) **目的**: リソースの暗号化状態を検証 **テスト項目**: - EBSボリュームの暗号化設定確認 - アカウントレベルの暗号化設定確認 **期待結果**: 適切な暗号化設定が有効になっている ### 6. 統合テスト (`run-all-tests.sh`) **目的**: 全テストスイートを順次実行し、結果を集約 **機能**: - 前提条件チェック - 全テストスイートの順次実行 - 結果の集約と報告 - エラーハンドリング **期待結果**: すべてのテストスイートが成功し、包括的なレポートが生成される ## 出力ファイル テスト実行後、以下のファイルが生成されます： - `integrated_test_report.txt` - 統合テスト結果の包括的なレポート - `security_scan_results.json` - Checkovセキュリティスキャンの詳細結果 - `security_scan_report.txt` - セキュリティスキャンの要約レポート - `encryption_check_results.txt` - 暗号化設定確認の詳細結果 - `iam_check_results.txt` - IAM権限チェックの結果 - `sg_check_results.txt` - セキュリティグループチェックの結果 ## 要件対応表 | 要件ID | 要件内容 | 対応テストスクリプト | |--------|----------|---------------------| | 1.1-1.4 | タグ付与ルールの適用 | main.tf（実装済み） | | 2.1 | Terraform構文チェック | test-infrastructure.sh | | 2.2 | リソース作成確認 | test-infrastructure.sh | | 2.3 | Webサーバー動作確認 | test-infrastructure.sh | | 2.5 | セキュリティグループポート制限 | test-security.sh | | 2.6 | SSM接続確認 | test-ssm.sh | | 2.7 | 許可IPアドレスアクセス | test-security.sh | | 2.8 | 拒否IPアドレスアクセス | test-security.sh | | 2.9 | セッションマネージャー接続 | test-ssm.sh | | 3.1 | セキュリティスキャン実行 | test-security-scan.sh | | 3.2 | 高リスク脆弱性検出 | test-security-scan.sh | | 3.3 | IAM最小権限原則チェック | test-security-scan.sh | | 3.4 | 暗号化設定確認 | test-encryption.sh | ## トラブルシューティングガイド ### よくある問題と解決方法 #### 1. AWS認証エラー **問題**: ``` Unable to locate credentials. You can configure credentials by running "aws configure" ``` **解決方法**: ```bash # AWS CLIの認証情報を設定 aws configure --profile inaba # または環境変数で設定 export AWS_PROFILE=inaba export AWS_ACCESS_KEY_ID=your-access-key export AWS_SECRET_ACCESS_KEY=your-secret-key export AWS_REGION=ap-northeast-1 # 認証情報の確認 aws sts get-caller-identity ``` #### 2. Terraformの初期化エラー **問題**: ``` Error: Backend initialization required ``` **解決方法**: ```bash # Terraformの初期化 terraform init # プロバイダーの更新が必要な場合 terraform init -upgrade ``` #### 3. EC2インスタンスが見つからない **問題**: ``` 実行中のEC2インスタンスが見つかりません ``` **解決方法**: ```bash # Terraformでインフラを構築 terraform plan terraform apply # インスタンスの状態を確認 aws ec2 describe-instances --filters "Name=tag:Name,Values=kiro-test-web-instance" # Terraformの状態確認 terraform show ``` #### 4. HTTPアクセスが失敗する **問題**: ``` HTTPアクセスが失敗しました ``` **原因と解決方法**: **原因1**: EC2インスタンスが起動中 ```bash # インスタンスの状態確認 aws ec2 describe-instances --instance-ids $(terraform output -raw instance_id) # 解決方法: 1-2分待ってから再実行 ``` **原因2**: セキュリティグループの設定問題 ```bash # セキュリティグループの確認 aws ec2 describe-security-groups --group-ids $(terraform output -raw security_group_id) # 解決方法: main.tfのセキュリティグループ設定を確認 ``` **原因3**: Webサーバー（nginx）が起動していない ```bash # SSMでインスタンスに接続してnginx状態確認 aws ssm start-session --target $(terraform output -raw instance_id) sudo systemctl status nginx sudo systemctl start nginx # 必要に応じて起動 ``` #### 5. SSM接続が失敗する **問題**: ``` SSMエージェントがオンラインではありません ``` **解決方法**: ```bash # インスタンスの起動から数分待つ sleep 120 # SSMエージェントの状態確認（インスタンス内で実行） sudo systemctl status amazon-ssm-agent sudo systemctl restart amazon-ssm-agent # IAMロールの確認 aws iam get-role --role-name $(terraform output -raw iam_role_name) aws iam list-attached-role-policies --role-name $(terraform output -raw iam_role_name) ``` #### 6. Checkovのインストールエラー **問題**: ``` externally-managed-environment ``` **解決方法**: ```bash # Homebrewを使用（推奨） brew install checkov # または pipx を使用 brew install pipx pipx install checkov # pipxのパスを追加 echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc source ~/.zshrc ``` #### 7. jqコマンドが見つからない **問題**: ``` jq: command not found ``` **解決方法**: ```bash # macOSの場合 brew install jq # Linuxの場合 sudo apt-get install jq # Ubuntu/Debian sudo yum install jq # CentOS/RHEL ``` #### 8. nmapが利用できない **問題**: ``` nmapが利用できないため、ポートスキャンをスキップします ``` **解決方法**: ```bash # macOSの場合 brew install nmap # Linuxの場合 sudo apt-get install nmap # Ubuntu/Debian sudo yum install nmap # CentOS/RHEL ``` #### 9. パブリックIPアドレスが取得できない **問題**: ``` パブリックIPアドレスを取得できませんでした ``` **解決方法**: ```bash # Terraformのoutput確認 terraform output # outputs.tfファイルの確認 cat outputs.tf # 必要に応じてoutputを追加 terraform apply ``` #### 10. セキュリティスキャンで多数の警告 **問題**: ``` 多数のセキュリティ警告が検出されました ``` **対応方法**: **高リスク問題の優先対応**: - CKV_AWS_260: セキュリティグループの0.0.0.0/0制限 - CKV_AWS_8: EBSボリューム暗号化 - CKV_AWS_79: EC2メタデータサービスv2強制 **設定例**: ```hcl # セキュリティグループの制限 resource "aws_vpc_security_group_ingress_rule" "allow_http_rule" { security_group_id = aws_security_group.web_sg.id cidr_ipv4 = "x.x.x.x/32" # 特定IPのみ from_port = 80 ip_protocol = "tcp" to_port = 80 description = "Allow HTTP from office IP" } # EBSボリューム暗号化 resource "aws_instance" "web_instance" { # ... 他の設定 ... root_block_device { encrypted = true } # メタデータサービスv2強制 metadata_options { http_tokens = "required" } } ``` ### デバッグのためのコマンド #### Terraformの状態確認 ```bash # 現在の状態表示 terraform show # 特定リソースの状態確認 terraform state show aws_instance.web_instance # 出力値の確認 terraform output ``` #### AWSリソースの直接確認 ```bash # EC2インスタンス一覧 aws ec2 describe-instances --filters "Name=tag:Project,Values=Kiro-test" # セキュリティグループ一覧 aws ec2 describe-security-groups --filters "Name=tag:Project,Values=Kiro-test" # VPC一覧 aws ec2 describe-vpcs --filters "Name=tag:Project,Values=Kiro-test" # SSM管理対象インスタンス一覧 aws ssm describe-instance-information ``` #### ログファイルの確認 ```bash # 統合テストレポート cat integrated_test_report.txt # セキュリティスキャン結果 cat security_scan_report.txt # 暗号化チェック結果 cat encryption_check_results.txt ``` ## パフォーマンス最適化 ### テスト実行時間の短縮 1. **並列実行**: 独立したテストは並列で実行可能 2. **キャッシュ活用**: Terraformプランのキャッシュを活用 3. **条件分岐**: 不要なテストをスキップする条件を追加 ### リソース使用量の最適化 1. **インスタンスタイプ**: 開発環境では小さなインスタンスタイプを使用 2. **自動停止**: テスト完了後のリソース自動停止 3. **スポットインスタンス**: コスト削減のためのスポットインスタンス活用 ## セキュリティベストプラクティス ### 1. アクセス制限 - セキュリティグループで必要最小限のポートのみ開放 - 特定IPアドレスからのアクセスに制限 - WAF（Web Application Firewall）の導入検討 ### 2. 暗号化 - 転送時暗号化（HTTPS）の使用 ### 3. 監査とログ - CloudTrailによるAPI呼び出しログ - VPCフローログによるネットワーク監視 - CloudWatchによるメトリクス監視 ### 4. IAM権限 - 最小権限の原則に従った権限設定 - マネージドポリシーの活用 - 定期的な権限レビュー ## CI/CDパイプライン統合 ### GitHub Actions例 ```yaml name: Infrastructure Tests on: push: branches: [main] pull_request: branches: [main] schedule: - cron: '0 9 * * 1' # 毎週月曜日9時 jobs: terraform-tests: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Setup Terraform uses: hashicorp/setup-terraform@v2 with: terraform_version: 1.5.0 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v2 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: ap-northeast-1 - name: Install dependencies run: | sudo apt-get update sudo apt-get install -y jq curl nmap pip install checkov - name: Terraform Init run: terraform init - name: Run integrated tests run: ./run-all-tests.sh - name: Upload test results uses: actions/upload-artifact@v3 if: always() with: name: test-results path: | integrated_test_report.txt security_scan_results.json security_scan_report.txt ``` ## 継続的改善 ### 1. テストカバレッジの拡張 - パフォーマンステストの追加 - 負荷テストの実装 - 災害復旧テストの追加 ### 2. 自動化の強化 - テスト結果の自動通知 - 失敗時の自動ロールバック - 定期的なセキュリティスキャン ### 3. 監視とアラート - CloudWatchアラームの設定 - SNS通知の設定 - ダッシュボードの作成 ## サポートとコミュニティ ### ドキュメント - [Terraform公式ドキュメント](https://www.terraform.io/docs) - [AWS CLI公式ドキュメント](https://docs.aws.amazon.com/cli/) - [Checkov公式ドキュメント](https://www.checkov.io/) ### 問題報告 問題が発生した場合は、以下の情報を含めて報告してください： 1. 実行環境（OS、ツールバージョン） 2. エラーメッセージの全文 3. 実行したコマンド 4. 生成されたログファイル ### 更新履歴 - v1.0.0: 初回リリース - 基本的なタグ付与とテスト機能 - 今後の予定: - パフォーマンステストの追加 - 並列実行サポート - カスタムテストスイートの追加機能 - Terraformモジュール化 --- **注意**: このプロジェクトはAWSリソースを作成するため、AWS料金が発生する可能性があります。テスト完了後は不要なリソースを削除してください（`terraform destroy`）。

本記事は 夏休みクラウド自由研究2025 8/24付の記事です 。 どうも。8月の夏休みがエンドレスにループしてほしい寺内です。 さて、Amazon S3はオブジェクトストレージです。ファイル操作やディレクトリの概念はブロックストレージにおけるそれとだいぶ違います。 ですが、S3の中のファイルをあたかもファイルシステムの一部のように操作したい、と思うことは稀にあります。またアプリケーションデータをS3に置きたいのだが、アプリケーションコードのファイルアクセス部分をS3用に作り変えることができない、という場合もあるでしょう。 そのようなときに便利なのが、 Mountpoint for Amazon S3 です。 これはS3の機能のひとつとして提供されていますが、実体はLinuxにインストールするファイルアクセスクライアントソフトウェアです。オープンソースであり、 GitHubで公開されて います。この機能自体に料金は発生せず、通常のS3利用料金のみで利用可能です。 Mountpoint for Amazon S3 は、 2023年3月にベータリリース されその後、 2023年8月には一般提供開始 となり本番環境で利用できるレベルになりました。そして 2025年5月には fstab に対応 し、OS起動時の自動マウントが可能となりました。 わたしの周囲では意外と知られていないこの便利機能を紹介していきたいと思います。 Mountpoint for Amazon S3 Mountpoint for Amazon S3 is an open source file client that you can use to mount an S3 bucket on your compute instance a... aws.amazon.com 概略 Linuxのファイルシステムが持つマウント機能を利用し、S3バケットもしくはそれ以下のプレフィクス(ディレクトリ)以下を、ファイルシステムに接続(マウント)します。マウントしたとろに対して、OS内から通常のファイル操作が可能となり、そのファイル操作は即座にS3オブジェクトに反映されます。 これはEC2からでもオンプレミスからでも、S3のAPIにアクセス可能なら利用可能です。 以下は、ドキュメントに沿った説明をしていきます。 Amazon S3 バケットをローカルファイルシステムとしてマウントする - Amazon Simple Storage Service Amazon S3 バケットをローカルファイルシステムにマウントするために、Mountpoint for Amazon S3 をインストールして使用する方法について説明します。 docs.aws.amazon.com インストール Amazon Linux 2023 のEC2からは、以下の dnf コマンドでインストールします。 ubuntuなどのDebian系Linuxでも使えますが、パッケージは異なります。 $ sudo dnf install <https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm> 手動でマウント 手動でマウントするには、 mount-s3 コマンドを使用します。 基本のマウント ホームディレクトリ以下にマウントポイント( ~/mnt ) を作成し、そこにS3バケット( ytera-mountpoint01 )をマウントするには以下のようなコマンドとなります。 mount-s3 <bucketname> <mountpoint> 実行例: バケット名が ytera-mountpoint01 で、ホームディレクトリにある mnt の下にマウントします。 $ cd ~ $ mkdir mnt $ mount-s3 ytera-moutpoint01 ~/mnt bucket ytera-moutpoint01 is mounted at /home/ec2-user/mnt マウントを外すには、通常のアンマウントコマンドを使用します。 $ umount ~/mnt 削除権限を与えるマウント 上記の基本的なマウントでは、S3オブジェクトを読んだり追加することができますが、削除やファイルの書き換えは禁止された状態でマウントされます。 S3オブジェクトの削除を許可する場合は、以下のようにオプションを付けます。 mount-s3 --allow-delete <bucketname> <mountpoint> $ mount-s3 --allow-delete ytera-mountpoint01 ./mnt S3オブジェクトを更新することを許可するには、同じ用に --allow-overwrite オプションを付与します。 バケットの特定プリフィクスでのマウント バケット全体をマウントするのではなく、S3バケット内の特定のディレクトリ(プリフィクス)をマウントするには以下のように --prefix オプションを使います。最後のスラッシュ ( / ) は必須です。 mount-s3 <bucketname> <mountpoint> --prefix <prefix> mount-s3 ytera-mountpoint01 ./mnt/mount-a --prefix mount-a/ fstab での自動マウント OSが起動した時に自動的にsystemdで自動的にマウントするには、 /etc/fstab ファイルに定義します。fstab のオプションの詳細は省略します。 fstabでS3マウントするには、行頭からS3 URIとマウントポイントとなるディレクトリを指定します。マウントポイントとなるディレクトリは、予め作成しておいてください。 s3://ytera-mountpoint01/mount-a/ /mnt/mount-a mount-s3 _netdev,nosuid,nodev,nofail,rw 0 0 s3://ytera-mountpoint01/mount-b/ /mnt/mount-b mount-s3 _netdev,nosuid,nodev,nofail,rw 0 0 なお、末尾の 0 0 は、dumpの対象にするか否か(0は対象にしない)と、ファイルシステムチェック(fsck)の順序(0はチェックしない)という意味です。 性能は Mountpoint for Amazon S3 の仕組み Mountpoint for Amazon S3 は、S3にアクセスするソフトウェアです。アプリケーションレイヤからのマウントポイントへのファイルシステムコールを仮想ファイルシステムが受け取ると、S3マウント領域であればS3への呼び出し(GETやPUT)に変換します。その後、 ~/.aws/credentials の認証情報を使用してS3 APIエンドポイントへリクエストを投げます。 そのため、性能的にはAWS CLIを使う場合とたいして変わらないはずです。いちおうやってみましょう。 実験データの準備 転送速度の実験は、以下2つのランダムデータを用意します。 100KBのファイルを1000個 (合計10MBほど) 1GBのファイルを5個 (合計5GBほど) 以下のように作ります。 mkdir -p file1000-100kb && cd file1000-100kb && for i in {1..1000}; do dd if=/dev/urandom bs=1024 count=100 2>/dev/null > file_${i}.txt; done; mkdir -p file5-1GB && cd file5-1GB && for i in {1..5}; do dd if=/dev/urandom bs=1M count=1024 2>/dev/null > file_${i}.txt; done; これで、ローカルディスクに file1000-100kb と file5-1GB というディレクトリができました。 測定方法 S3マウントしたディレクトリに、 cp -r コマンドでコピーし、その実行時間を測定します。 $ date +"%H:%M:%S";cp -r ./file1000-100kb ./mnt/mount-a;date +"%H:%M:%S" 08:01:49 08:07:58 $ date +"%H:%M:%S";cp -r ./file5-1GB ./mnt/mount-a;date +"%H:%M:%S" 07:59:54 08:00:35 測定結果 転送データ 転送時間 転送速度(計算値) 100KB x 1000 6分9秒(369秒) 2.07 Mbps 1GB x 5 41秒 930.41 Mbps やはり多くのリクエストを出すのは転送効率悪いですね。 これでもmount-s3 コマンドは、ある程度の並列化を行っているようです。 なお、今回の実験はNATゲートウェイ経由のインターネット接続でS3 APIエンドポイントを使っています。VPCエンドポイントを作り同じ実験をしてみましたが、ほぼ同じ結果でした。 感想 S3の中の特定パターンのファイルを大量に消すなど、細かなファイル指定をしたり、複雑なファイル移動をしたりするとき、AWS CLIでは指定が(慣れていないため)面倒です。そういうときに、Linuxコマンドでできるととても簡単にできます。 これほど便利な機能ですが、Windowsには対応していないのが残念です。WSLでubuntuを動かし、ubuntu上のマウントポイントを母艦のWindowsからアクセスすることで、似たようなことができると思います。誰かやってみてほしいです。

本記事は  夏休みクラウド自由研究2025 8/23付の記事です 。 こんにちは！SCSK猿橋です。 関西万博が盛況のようですが皆さん遊びに行かれましたでしょうか？ せっかくの関西開催なので一度行ってみたいと思っているのですが、万博に走る前にAWS CDKに走ってみたいと思います！ 今回やりたいこと DevOpsでは一貫したインフラ環境の構築の為にIaC（Infrastracture as Code）の活用が増えていると思います。 IaCではAWS CloudFormation、AWS CDKを活用することが多いと思いますが、最近はリソースからCloudFormationテンプレート、CDKソースを生成する機能もでてきました。 今回はCDKを実践活用したい、というテーマで、よくあるWebアプリケーションで活用するシステム構成をCDK化することにTryしてみました。 cdk migrateコマンドの「from-scan」オプションで既存リソースからCDKソースを生成できる機能がリリースされているので、それを使えば簡単にCDK化できるんじゃないか！という目論見です。 AWS CloudFormation、AWS CDKの関係とCDKソース生成については以下の記事がわかりやすかったので参考にしてみて下さい。 今日から始めるCDK！　～既存リソースをCDK移行する～ - Qiita 2025/01/31追記 本記事ではAWSの既存リソースをCDKに変換する手順について記載していますが、いろいろと触ってみた結果、個人的には「既存リソースをCDKに置き換えるより、1から作り直した方が楽」というように考えるようになりました。... qiita.com cdk migrate コマンドは実験的であり、今後は大幅な変更が行われる場合があるとのことです。 さっそくつまづいた 一つ目のつまづき。以下のハンズオンでエッジサービスを活用したWebアプリケーションを構築し、このシステム構成をさくっとCDKソース化することにTryしました。 AWS Hands-on for Beginners Amazon CloudFrontおよびAWS WAFを用いて エッジサービスの活用方法を学ぼう | AWS Webinar AWS Hands-on for Beginners Amazon CloudFrontおよびAWS WAFを用いて エッジサービスの活用方法を学ぼう | AWS Webinar pages.awscloud.com 各リソースにはTagKey=CdkMigrateTestを設定しています。 TagKeyでフィルタリングして既存リソースからfrom-scanでmigrateしてみることにしました。 cdk migrate --from-scan new --stack-name "cdk-test-edgeservice" --filter tag-key="CdkMigrateTest" XXXStack could not be generated because None is not implemented for ResourceValue::Object 24リソース抽出できているものの、CDK生成でエラーが発生。このCDK生成エラーには今後都度悩まされることになります。 ネット検索やAmazon Qでエラー原因を調査しましたが、この時点では原因掴めず。migrateコマンドの難しさの入り口でした。 リソース別にmigrateしてみる cdk migrate –from-scanコマンドは、 既存リソースのスキャン（filterに合致するリソースの抽出） スキャンしたリソースのCloudFormationテンプレート化 テンプレートからCDKソースを生成 という３ステップを一括で実行できる素敵なコマンドなのですが、途中でエラーが発生するととても原因が掴みづらかったです。 少しでも複雑度を落とすべく、個別のリソース毎にmigrateしてみることにしました。 イメージとして、サーバレスAPIをイメージし、以下のリソースを作成した上で個別にmigrateすることとしました。 No サービス リソース名 tag設定 備考 1 S3 20250815-cdktest Key=CdkMigrateResource Value=S3   2 Lambda 20250815-cdktest-lambda Key=CdkMigrateResource Value=Lambda   3 API Gateway 20250815-cdktest-api Key=CdkMigrateResource Value=ApiGateway Lambda統合のGETメソッドを1つ設定 4 DynamoDB 20250815-cdktest-dynamodb Key=CdkMigrateResource Value=DynamoDB   S3のmigrate cdk migrate --from-scan new --stack-name "cdk-migrate-s3" --filter tag-key="CdkMigrateResource",tag-value="S3" cdkソース生成に成功！ 生成されたソース内のmigrate.json（migrate結果が格納されているファイル） 想定したbucketが抽出できている cdkソースはlib配下に生成されている lib/cdk-migrate-s3-stack.ts Lambdaのmigrate cdk migrate --from-scan --stack-name "cdk-migrate-lambda" --filter tag-key="CdkMigrateResource",tag-value="Lambda" XXXStack could not be generated because RecursiveLoop is not a valid property 4リソース抽出できているもののCDKソース生成でエラーが発生。 こちらのissueが関連していそう。まだopenのようなので、このissueが解決しないとLambdaへのmigrateコマンドはエラーが発生しそう。 migrate CLI: Lambda "RecursiveLoop" property not supported · Issue #642 · aws/aws-cdk-cli Describe the bug When calling the cdk migrate CLI call for a CloudFormation template inlcuding the RecursiveLoop propert... github.com Lambdaコンソール上の設定は恐らくこちら テンプレート生成まではRecursiveLoopに追随できているが、テンプレートからのCDKソース生成ライブラリは未対応、ということでしょうか？ API Gatewayのmigrate cdk migrate --from-scan --stack-name "cdk-migrate-apigateway" --filter tag-key="CdkMigrateResource",tag-value="ApiGateway" 3リソース抽出でき、CDKソースの生成が成功！ migrate.jsonの確認。 Deployment、RestApi、Stageが抽出されている。 CDKソースを確認すると、Lambda統合のGETメソッドが生成されていなさそう。 再度filterでresource-type-prefixでAPI Gatewayを抽出してみたが、GETメソッドソースは生成されず。（一旦置いて、次行ってみよー！ DynamoDBのmigrate cdk migrate --from-scan --stack-name "cdk-migrate-dynamodb" --filter tag-key="CdkMigrateResource",tag-value="DynamoDB" XXXStack could not be generated because WarmThroughput is not a valid property 1リソース抽出できていますが、CDKソース生成でエラーが発生。 こちらのissueが関連していそうです (migrate): DynamoUatStack could not be generated because WarmThroughput is not a valid property for resource DynamoDBTableAPI of type AWS::DynamoDB::Table · Issue #525 · aws/aws-cdk-cli Describe the bug The property in question is in the CF documentation: and in the L1 construct https:/... github.com cdk migrate処理の問題 issueを追っていく中で、冒頭の「ResourceValue::Object」エラーもCloudFrontのissueとして登録されていることがわかりました。 Bug: CloudFront distribution generation fails with None is not implemented for ResourceValue::Object · Issue #921 · cdklabs/cdk-from-cfn When trying to use cdk migrate on a CloudFormation template with a CloudFront distribution I get the following error: ❌ ... github.com さらにissueを追っていくと、根本対策としては以下のチケットが登録されていることがわかりました。 Make schema update automatically · Issue #771 · cdklabs/cdk-from-cfn It looks like the schema isn't being updated automatically. It should be. Looks like the files that need updating are he... github.com issue#771にはこれまでハマったエラーに関するissueが見事関連issueとして紐づけられていました。 DynamoDBの issue#525のコメント に投稿されていましたが、migrate処理の裏側で cdk-from-cfnライブラリ が動いており、このバージョンが古いそうです。（2025/08/16時点情報） https://github.com/cdklabs/cdk-from-cfn/blob/main/src/specification/cdk-resources.json で定義されていない新しいプロパティは対応できていないとのこと。 cdk migrateリリース直後は当時の最新プロパティが反映されていたのかと思いますが、少し期間がたって上記issueの通り最新プロパティに反映できていない問題が顕在化してきた過渡期、とも言えるかと思います。タイミングが悪く既存issueを踏みまくってしまいましたが、 isseu#771 が解決すればmigrateエラーも解消するのではないかと期待します。 代替手段（マネジメントコンソール上での段階実行） cdk migrate –from-scanは、既存リソースのスキャン、Cfnテンプレート化、CDKソース生成を一気に実行してくれるコマンドですが、途中でエラーが発生するとほぼ対処のしようがありません。 マネジメントコンソール上ではそれらを別々に実行できるので、途中のテンプレートを修正して進めてみる、という手もありそうです。 以下の記事を参考にマネジメントコンソールで作業を進めてみます。 AWS IaC ジェネレータを使ってみた AWS IaC ジェネレータは、既存のリソースを基にCloudFormationテンプレートを生成できるサービスです。8月にアップデートされた情報と合わせて、使ってみた感想、ポイントをご紹介します。 blog.usize-tech.com 2024.10.25 １．IaCジェネレータでのスキャン 上記の記事通りCloudFormation＞IaCジェネレーター＞新しいスキャンを開始　でスキャンが実行できます。 cdk migrate –from-scanで実行しているスキャン結果はマネジメントコンソール上でも共有されているので今回は省略します。 ２．テンプレートの作成 今回は問題となったLambdaのテンプレートを作成してみます。 IaCジェネレーター＞テンプレートを作成 タグを指定してLambdaをテンプレートに追加 関連リソースが推奨されるので、こちらもテンプレートに追加してテンプレートを作成 ３．CDKソース生成 テンプレート作成後、AWS CDKタブを表示してCDK処理を進めてみます。 テンプレートをダウンロードし、cdkコマンドをコピーして実行 cdk migrate --stack-name CfnLambdaTemplate-20250815 --from-path ./CfnLambdaTemplate-20250815-1755311593670.yaml --language typescript XXXStack could not be generated because RecursiveLoop is not a valid property 想定通りのエラーが発生。テンプレートから「RecursiveLoop」プロパティを削除して、再度cdk migrateを実行してみる。 無事CDKソースの生成が成功！手間はかかりますが、エラーは回避できそうです。 ちなみにLambdaのCDKソースにAPI GatewayのGETメソッドの設定がありそうでした。（一旦置いておいた問題が解消 余談（苦労話） スタックに含まれているリソースはmigrateでスキャン対象外の模様 当初は以下のサーバレスサービスをベースとしたWebXRアプリケーションをベースにcdk migrateを試そうとしていました。 CDKソースでgithubで提供されており、このCDKソースとcdk migrateで生成したCDKソースを比較したら面白んじゃないかという目論見でした。 GitHub - aws-samples/aws-serverless-example-for-webxr: This repository contains an example solution on how to enhance your WebXR applications using AWS Serverless Services, providing scalable, efficient, and seamless user experiences. This repository contains an example solution on how to enhance your WebXR applications using AWS Serverless Services, pr... github.com 結果、想定していたリソースが何度やってみ抽出されず。当初はfilterオプションの書式に誤りがあるのかと様々な書式を試してみましたが抽出できず。Amazon Qに聞き倒したところ、ようやくスタックに既に含まれているリソースはscan対象外であるという条件がわかりました。 そもそも前提としていた動作確認シナリオからして間違っていた、ということですね（これでどれだけ時間を費やしたか。。。涙 おわりに 今回のcdk migrate動作検証は、まさに「夏休み自由研究」レベルの作業時間となってしまいました（１～２日で終わらせるつもりだったのに。。。 エラーにまみれたときはお先真っ暗な感じでブログアウトプットに辿り着けるのか、、と焦りましたが、なんとかエラー原因も見えてきて形にできました。 今回はタイミング悪くCDKソース生成が難しい状況で、冒頭の参考blogの記載の通り、このツールを使うより１からCDKソースを書いたほうが、エラーまみれの近道よりは前に進める遠回り、という印象でした。 ただし、うまくCDKソースがしゅるしゅるっと生成できた時は感動モノだったので、 issue#771 が解決することを切に願っております！

こんにちは。 ServiceNow AI Platformは、接続元IPアドレスによってインスタンスへのアクセスを制御することができます。 つい最近、IPアドレス制御の設定を行う機会があったため、その際に学んだ設定手順や実際に設定を行う際の挙動、注意点をまとめていきます。 ※IPアドレス制御は、インバウンド、アウトバウンドの両方が設定できますが、今回は インバウンド に絞って記事にしていきます IPアドレス制御の仕組み ドキュメントには、以下のような記載があります。 つまり、自身のIPアドレスがDenyルールにマッチし、かつ、Allowルールにはマッチしないときに始めて、インスタンスへのアクセスが却下されるということになります。 そのため、Allowルールだけ設定しても、接続を許可するIPアドレスを絞り込むことはできず、Denyルールの設定が必要です。 The system only blocks an IP address if a matching Deny rule exists and no matching Allow rule exists.    設定方法 System Security > IP Address Access Controlのモジュールから設定を行います。 始めに、Allowルールを設定します。 Type: Allow Direction: Inbound Range start/Range end: アクセスを許可するIPアドレス   続いてDenyルールは以下のように設定します。 Type: Deny Direction: Inbound Range start/Range end: アクセスを拒否するIPアドレス ※特定のIPアドレスからのアクセスのみ許可する場合は、DenyルールのIPアドレスに0.0.0.0~255.255.255.255を設定します   設定は以上で終了となります。 IPアドレス制御の設定をした際の挙動を確認 私自身が実務でIPアドレス制御を実施する際、どのような挙動をするか分からず不安だった点をいくつか紹介します。 設定者自身のIPアドレスがAllowルールに含まれない場合 もし、設定するIPアドレスを間違ってしまい、自分自身がインスタンスから締め出されてしまったらどうしようと、個人的に一番の不安ポイントでしたが、全く心配する必要はありませんでした。 Allowルールで自身が含まれないIPアドレスを設定して、その後Denyルールを保存する際、以下画像のようにエラーメッセージが表示されレコードの保存をキャンセルしてくれます。 IPアドレス制御を実施した瞬間、インスタンスにログインしているユーザーが存在する場合 もちろん、許可ルールに合致するIPアドレスを持つユーザーには何も影響はありません。 許可ルールに含まれないユーザーは、どのモジュールを開こうとしても、画像のように403エラーページが表示されます。 当たり前のことですが、設定する際は関係者への周知が必要です。   IPアドレス制御設定後、インスタンスにアクセスした際の挙動 インスタンスへの接続を試みると、ログインページに到達する前に403エラーページが表示され、アクセスが却下されます。 IPアドレス制御を行う際の考慮点 実際にIPアドレス制御を行う際、考慮したことを２点ほど記載します。 インスタンス間の通信 本番環境と非本番環境の複数環境で運用するのが通常ですが、以下の機能を使用する際は、インスタンス間での通信が発生するのでインスタンスのIPアドレスもアクセスを許可する必要があると思いました。 インスタンス間のクローン Remote Instance等の機能を使った、更新セット・アプリケーションの自動移送 他システムとの連携 システム連携している場合、 他システム起点 でServiceNowへのアクセスが発生する場合は、IPアドレスをAllowルールに追加する必要があります。   おわりに 今回の記事では接続元のIPアドレスによるインスタンスへのアクセス制御について、ご紹介しました。 今後、同じような設定を行う際、どなたかの参考となれば幸いです。