こんにちは。SCSKの吉田です。 初めてのブログ投稿となります。今後、ServiceNowに関する様々な情報をアウトプットしていきたいと思いますのでよろしくお願いします！ 2か月前のことになりますが、5月にServiceNowの年次ビッグイベント 「Knowledge 2024」 に参加してきました。 イベントの概要は以下の通りです。 日程：5月7日～5月9日の3日間 階催場所：米国ラスベガスのThe Venetian Convention & Expo Center 参加人数：グローバルで20,000人弱（うち日本からは300名以上が参加） 内容：KeyNote(基調講演)、Expo(展示会)、Session、オンサイトミーティングなど 今回は現地での体験談をお伝えします！ ラスベガスで認定資格取得にチャレンジ！ まずは自己紹介もかねて個人のお話から。 こちらはKnowledge 2024で実施された、イベント会場でServiceNowメインライン認定資格の受験にチャレンジする取り組みです。 今回、人事領域アプリケーションの導入者向け資格である「Certified Implementation Specialist – Human Resources」を受験し、見事合格することができました！ さらに本イベントには 日本から唯一の参加者 ということもあり、最終日のJapan Closing Sessionで紹介していただけました。 （自称：初代ラスベガスでServiceNow認定資格を取得した人） 試験後に合格したことをスタッフに伝えると記念のピンバッジを頂けました。 試験開始前に他の受験者と「緊張するね」と会話したり、イベント会場でバッジを見た人から「これは何？」と聞かれて立ち話が始まったりと、思いがけず海外の方とも交流できて非常に良い経験となりました。   KeyNote KeyNoteでは、Bill Mcdermott氏による講演や、製品ロードマップ、ライブデモなどが行われました。 特に生成AIに関する発表が多く、ServiceNowがビジネス変革のためのAIプラットフォームへと進化している点が強調されていました。 会場へは入りきれないほどの参加者が集まり、講演中は都度、歓声が上がるなどすごい盛り上がりでした。 KeyNoteを通じて、参加者全員のServiceNow、生成AIに対する熱気を改めて感じることができました。   Session・Expo イベント期間中は、多数のセッションが同時に開催され、各自が興味のあるセッションを予約して参加する形となります。 私は主に以下のセッションに参加してきました。 ServiceNowの活用事例 生成AIを活用する上でのTipsや機能紹介 製品ロードマップ ServiceNowの生成AI機能がリリースされてから数カ月にも関わらず、開催されたセッションのうち、生成AIに関するセッションが多くを占めていたのがとても印象的でした。   また、Expo会場では各企業の展示ブースがあり、ServiceNowを活用しているデモを見たり、企業の担当者と会話することができます。 IoTやAIとServiceNowを組み合わせた体験型のブースも数多くあり、会場全体で非常に盛り上がっていました。   最後に 以上、Knowledge 2024の現地体験レポートでした。 今回、初めての参加でしたが、個人として感じたことは主に以下3点となります。 ServiceNowに関わる全ての人の熱気がすごい ビジネスにおいてAIの活用が前提となっている時代となりつつある 個人としてAIを活用しきれていないことに対する危機感 また、ServiceNowに関わる者としてServiceNowをさらに盛り上げていこうというモチベーションをより上げることができたのが、一番の収穫でした。 今後もServiceNowに関する情報をアウトプットしていきたいと思います！  

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 AWSサービスに接続するためのVPCエンドポイント(ssm.ap-northeast-1.amazonaws.com など)がVPCごとに作られていくのは管理上よろしくないと考える方はいらっしゃるようでして、VPCエンドポイントを1か所に集中させたいというご要望を頂くことがございます。 これを実現するうえで重要なのは、DNS名前解決をどのように行うか、です。本稿では、マルチアカウント環境において、AWSサービス用のVPCエンドポイント(ssm.ap-northeast-1.amazonaws.com など)を一つのVPCに集約した場合のDNS名前解決パターンについて考察します。 ※VPC間の接続にTransit Gatewayを何の説明もなく使用していますが、Transit Gatewayをよく知らないという方でも、VPC間を接続するサービスということだけ理解していれば本稿を読み進めるのに支障ありません。 プライベートホストゾーンを使う案 対象ドメイン(例：ap-northeast-1.amazonaws.com)のプライベートホストゾーンを作成し、各アカウント・各VPCに関連付けることで、ハブVPC上のVPCエンドポイントの名前が返るようにします。 アーキテクチャ図は以下の通りです。 プライベートホストゾーンではハブVPC上のDNS名とIPアドレスを対応付けるAレコードを作成しておきます。スポークVPCでAmazon Provided DNS(デフォルトで設定されるDNS)にDNSクエリを発行すると、プライベートホストゾーンに登録されたハブVPC上のIPアドレスが返ってきます。 こちらの構成は、クラスメソッドさんの下記記事で既に解説されていますので、本稿では気づいた点を何点か述べるに留めます。 複数VPCで名前解決を集約・共有する方法を試してみた | DevelopersIO 複数のVPCで名前解決をいい感じに共有または集約する方法を試してみました。今回シングルアカウント内のVPCで試していますが、大枠の考え方はマルチアカウントでも利用できると思います。 dev.classmethod.jp ap-northeast-1.amazonaws.com や amazonaws.com でプライベートホストゾーンを作成しようとすると、既にAWSに予約されているという理由でエラーになるので、bedrock.ap-northeast-1.amazonaws.com や kendra.ap-northeast-1.amazonaws.com のようにサービス名ごとにプライベートホストゾーンを作成する必要がある。 プライベートホストゾーンを他アカウントのVPCに関連付ける作業はマネジメントコンソールからは実行できず、CLI等から実施する必要がある。 名前解決したいホスト名の数 × 関連付けたいVPCの数 だけ関連付け作業を実施する必要があるので、規模が多くなってきたらスクリプト化・IaC化必須である。 ドメイン名 ap-northeast-1.amazonaws.com のゾーン作成はエラーになる プライベートホストゾーン設定例(kendra.ap-northeast-1.amazonaws.comゾーンのレコード作成) 他のアカウントのVPCにプライベートホストゾーンを関連付ける手順についても以下のクラスメソッドさんの記事で解説されていますので、そちらをご参照ください。 [Route 53]他のAWSアカウントのVPCにプライベートホストゾーンを関連付ける | DevelopersIO Route 53で作成したプライベートホストゾーンを他のAWSアカウントのVPCに関連付ける方法をご紹介します。 dev.classmethod.jp なお、この手順で関連付けられたホストゾーンは、マネジメントコンソールから確認することができず、CLIの route53 list-hosted-zones-by-vpc などで確認する必要があるようです。 DHCPオプションセットを使う案 スポークVPCにDHCPオプションセットを適用して、(EC2などが)参照するDNSサーバのIPアドレスにハブVPC上のRoute 53 Resolverインバウンドエンドポイントを指定する方法です。 アーキテクチャ図を描くと以下の通りです。 こちらも先ほどご紹介したクラスメソッドさんの記事で既に解説されていますので、本稿では詳しい説明を割愛します。 複数VPCで名前解決を集約・共有する方法を試してみた | DevelopersIO 複数のVPCで名前解決をいい感じに共有または集約する方法を試してみました。今回シングルアカウント内のVPCで試していますが、大枠の考え方はマルチアカウントでも利用できると思います。 dev.classmethod.jp ハブVPC内のRoute 53 Resolverインバウンドエンドポイントは、同じVPC内にあるVPCエンドポイント(この例の場合は bedrock.ap-northeast-1.amazonaws.com)の名前解決時にプライベートIPアドレスを返しますので、プライベートホストゾーンを作成する必要はありません。 スポークVPC(内のEC2等)が参照するDNSサーバがハブVPC上にあるため、スポークVPC独自の名前解決をさせたいときに難易度が上がります。例えばできる限りSession Managerがネットワーク障害の影響を受けないようにする目的で、Session Manager用のVPCエンドポイントだけはスポークVPC内に作成したい(他のVPCエンドポイントはハブVPC内に置きたい)となった場合に、対応ができません。 スポークVPCにRoute 53リゾルバ アウトバウンドエンドポイントを置く案 私が無い知恵をふりしぼって最初に考えた構成です。ハブVPCにRoute 53リゾルバ インバウンドエンドポイントを作成し、スポークVPCにはRoute 53リゾルバ アウトバウンドエンドポイントを作成します。スポークVPCで発行されたap-northeast-1.amazonaws.comドメインのDNSクエリは、リゾルバ転送ルールを使用してハブVPCのインバウンドエンドポイント(のIPアドレス)に向けてやります。 図にするとこのようになります。   この構成は動作します。しかし、VPCごとにRoute 53リゾルバ アウトバウンドエンドポイントが必要になり、冗長構成が必須であることも考慮するとそれだけで月180ドルの料金がかかってしまいますので、今回の目的に照らし合わせると没案と言わざるを得ません…。 Resource Access Managerでリゾルバルールを共有する案 私が費用対効果の悪い案をひねり出すより前に、AWSからとっくに以下のようなアーキテクチャが公開されていました。 複数の VPC から中央のAWS のサービスエンドポイントにプライベートにアクセスする - AWS 規範ガイダンス docs.aws.amazon.com リンク先にも示されていますが図にすると以下のようになります。(リンク先とは図が若干異なりますが、私なりに同じものをより分かりやすく示そうとした結果です) 構成を細かく分解して説明すると以下の通りです。 ハブVPCに、Route 53リゾルバ インバウンドエンドポイントだけではなく、Route 53リゾルバ アウトバウンドエンドポイントも作成する リゾルバ転送ルールを作成し、ap-northeast-1.amazonaws.comドメインの名前解決をRoute 53リゾルバ インバウンドエンドポイント(のIPアドレス)に転送するように設定する リゾルバ転送ルールをResource Access Manager (RAM)を使ってスポークアカウントと共有する スポークアカウント側で、リゾルバ転送ルールをスポークVPCに関連付ける 上記の通り構成することで、スポークVPC側にRoute 53リゾルバ アウトバウンドエンドポイントがなくても、Amazon Provided DNSは、ap-northeast-1.amazonaws.comドメインの名前解決DNSクエリを ハブVPCのRoute 53リゾルバ インバウンドエンドポイントへと転送してくれます。 構築時のポイント ハブアカウント側、リゾルバ転送ルールの作成 今回の目的は、ap-northeast-1.amazonaws.comドメイン(AWSサービスのVPCエンドポイント)の名前解決をハブVPCに転送することなので、ルールの作成画面でドメイン名にap-northeast-1.amazonaws.comを指定します。 VPCは指定する必要がありません。 ターゲットIPアドレスに、Route 53リゾルバ インバウンドエンドポイントのIPアドレスを指定します。 ルール作成画面 Resource Access Manager (RAM)を使用した転送ルールの共有 Resource Access Manager (RAM)メニューの「自分が共有: リソース共有」から「リソース共有を作成」ボタンを押します。 そこから先の設定は、以下にスクリーンショットを載せました。 「リソース – オプション」のところで「リゾルバルール」を選び、対象のルールをチェックします。 マネージド型アクセス許可は、デフォルトのまま変更しませんでした。 プリンシパルタイプは、「AWSアカウント」を選択し、スポークアカウントのアカウントIDを入力します。 また、スクリーンショットは載せていませんが、スポークアカウント側でResource Access Manager (RAM)メニューの「自分と共有: リソース共有」から「リソース共有を承認」する必要があります。 リゾルバ転送ルールをスポークVPCに関連付け 共有された転送ルールは、Route 53 > リゾルバー > ルール のルール詳細から、「VPCを関連付ける」をクリックし、スポークVPCを関連付けます。 VPC関連付け後の転送ルール(スポークアカウント側) 名前解決確認 以上で設定は完了です。スポークVPCのEC2からdigコマンドでssm.ap-northeast-1.amazonaws.comの名前解決を実行すると、ハブVPCのssmエンドポイントのIPアドレスが返ってきました。 DNSクエリの通信経路はどうなっている？ この構成で、DNSクエリ(UDP 53番ポートの通信)は実際にどのように行われているのでしょうか。調べてみることにします。 アーキテクチャ図再掲 この構成なら、スポークVPCのAmazon Provided DNS(10.1.0.2)からRoute 53リゾルバ インバウンドエンドポイント(10.0.33.153, 10.0.34.129)へのIP通信が発生しているのではないか？と推測しました。 しかし、DNSクエリログと照らし合わせながらVPCフローログを調べて行きますが、スポークアカウント側に該当するログはありません。それどころか該当の時間帯に、UDP 53番ポートの通信は一切発生していませんでした。 スポークアカウント側のDNSクエリログ スポークアカウント側のVPCフローログ。srcPortでDNSクエリログと照らし合わせを試みるが、該当ログなし 次に、ハブアカウントを見ていきます。 ハブアカウント側のDNSクエリログを見ると、上記と同時刻に同内容のDNSクエリが確認できるので、スポークVPCで発生したDNSクエリが、ハブVPCまで到達し、ハブVPC側で応答を返したと考えられます。以下がそのログです。 ハブアカウントのDNSクエリログ ハブアカウント側のVPCフローログも調べて行きます。スポークVPCからのUDP 53番ポート通信は発見できませんでしたが、該当時間帯に以下のログを発見しました。 ハブアカウントのVPCフローログ DNSクエリログのタイムスタンプと若干ずれがありますが、srcPortが一致(46161)していることから、同じ通信のことを指しているとみて間違いないでしょう。 srcAddrの10.0.34.254は、Route 53リゾルバ アウトバウンドエンドポイントのIPアドレス(のひとつ)です。スポークVPCで発生したDNSクエリは、Route 53リゾルバ アウトバウンドエンドポイントで一種のNATのようなものが行われてハブVPCにやって来たと推測できます。 dstAddrの10.0.34.129は、Route 53リゾルバ インバウンドエンドポイントのIPアドレス(のひとつ)です。ここまで到達して、Route 53による名前解決が行われたと考えられます。 以上の情報をまとめると、下図青色実線矢印の通信が確認できたことになります。 青色破線矢印の部分がどのように行われたか、ですが、VPC側のフローログを確認しても該当するログは発見できませんでしたので、AWSインフラ側を通る通信であり、ユーザ側(VPC)からは見えないようになっているのだと考えられます。 まとめ 本稿では、AWSサービス用VPCエンドポイントをひとつのVPCに集約したい場合のDNS名前解決アーキテクチャとして以下の4つを概観しました。 プライベートホストゾーンを使う案 DHCPオプションセットを使う案 スポークVPCにRoute 53リゾルバ アウトバウンドエンドポイントを置く案 Resource Access Managerでリゾルバルールを共有する案 また、第4案について、構築時のポイントを解説するとともに、DNSクエリの通信を追ってみた結果、通信の一部がAWSインフラ側を通っていると考えられることを示しました。 本稿の内容がDNS設計のお役に立てば幸いです。

本記事では、Catoクラウドを運用するにあたって、特に知っておくべきIT用語をピックアップして解説していきます。 Catoクラウドの運用においては、多くのネットワーク・セキュリティに関する専門用語が登場します。 これらの用語を知識として持っている方も多いかと思いますが、具体的にCatoでどのように扱われているか、実例を交えながらご説明します。 今回は【ネットワーク編】と題して、ネットワーク用語を取り上げてご説明していきます。 今後【セキュリティ編】【応用編】を随時公開予定です。 そもそもSASEとは、Catoクラウドとは何か、が知りたい方は以下の記事をご覧いただければと思います。 ・ 世界初のSASEプラットフォーム Catoクラウドとは？ – TechHarmony (usize-tech.com) それでは早速、用語解説を始めていきます。 パケット パケット(Packet)とは、データ転送において、効率よくデータを送るために小分けした単位のことです。 Catoでは、パケットがネットワーク上できちんと転送できているか、パケットロス率としてモニタリングできます。 ネットワーク運用で起こりうるケースとして、通常はスループットに比例してパケット数も増えるものですが、スループットは低いがパケット数が多いケースがあります。 小さなパケットを大量に送信している状態です。 この状態のとき、ルータやスイッチなどの性能制限によって、一定時間に処理できるパケット数に上限があり、期待した性能が出ないことがあります。 パケットロスと似た用語に、Catoではディスカードがあります。 ディスカードは、拠点の最大帯域を超えた通信が発生し、Socketがパケットを破棄したときに発生します。 ディスカードが多い時には、後程解説するスループットと合わせて最大帯域の増速をご検討いただければと思います。 トラブル時など性能グラフを見るときは、スループットだけでなくパケット数やディスカードも確認ポイントとなります。 フロー フロー(Flow)とは、ある特定のデータ通信の流れを指します。 これは、特定の送信元と受信先の間でやり取りされる一連のパケットを意味します。フローの具体的な要素としては、IPアドレス / ポート番号 / プロトコルの情報で構成されています。 Catoでは、フロー数のモニタリングも可能になっています。 また、ホストごとにもフロー数を見ることができ、特定のホストだけが異常な値を検出している場合にはセキュリティインシデントが発生している可能性も考えられます。 そういった調査観点でもフロー数をモニタリングすることは重要と言えます。 従来のネットワーク機器では、フロー数に比例してメモリを利用しています。ネットワーク機器上で、フローごとにNATや動的なFWルールの管理をしているため、機器のメモリ量に依存して同時に通信可能なフロー数に上限があります。 ただし、Catoではソフトウェアによってこれらの機能を実現しスケールアウトしています。Catoでは実質的なフロー数の上限は存在していないとも言えます。 トラフィック・スループット トラフィック(Traffic)とは、回線・ケーブルを流れるデータやその総量のことを言います。 また、トラフィックと近しい言葉に、スループット(=帯域)があります。 トラフィックがデータ総量であるのに対して、スループットは単位時間あたりに流れるデータ量のことを言います。 一般的なモバイル通信におけるトラッフィクの平日の一日の推移としては、お昼時間帯や帰宅時間帯がピークになり、深夜から早朝にかけた時間帯が少ない傾向にあります。 また、企業においては、勤務開始の午前9時前後がピークになった後なだらかになり、お昼時間帯には再度Youtubeなどへのアクセスが増えるためやや上昇、勤務終了以降の18時ごろから段々と少なくなるという傾向にあります。 さらに、回線・ケーブルごとに利用可能な最大帯域が決められています。 これは、ISPとの契約時に回線ごとに決めるもので、最大帯域を大きくするほど費用もそれに応じて高くなります。 最大帯域を超えると、パケットの破棄や通信遅延が発生してしまうため、想定される帯域と予算を天秤にかけながら、ネットワーク設計者は契約帯域を決定する必要があります。 Catoクラウドでは、スループットをモニタリングできます。 通信が不安定になった際には、こちらのグラフで最大帯域を超過していないか確認いただくのも1つの切り分け方法と言えます。 スループットが最大帯域に張り付いているような状況の際には、契約帯域の増速をご検討いただければと思います。 QoS QoS（キューオーエス）とは、「Quality of Service」の略称で、日本語では「サービス品質」と訳されます。 インターネットや社内ネットワークなどで、データを送受信する際の品質を確保するための仕組みです。 QoSは、重要なデータが遅延したり止まったりしないように、どのデータを優先して送るかを決めて品質を確保します。 通常、回線の最大帯域を超えるトラフィックが発生すると、通信機器で遅延やパケットの破棄が発生します。 このような問題を解決する仕組みがQoSです。QoSには優先制御や帯域制御といった制御の種類があります。 優先制御であれば、例えばWeb会議のような即時性が求められる通信に対して優先度を高く設定することが多いです。 一方で、メールのような急がない通信では、優先度を低く設定することがあります。 この制御によって、Web会議の快適な通信を実現できます。 CatoクラウドでもQoSの仕組みが導入されています。詳細を知りたい方は、以下の記事をご覧ください。 ・ CatoクラウドのQoSについて – TechHarmony (usize-tech.com) ルーティングテーブル ルーティングテーブルとは、主にルータやL3スイッチなどのネットワーク機器がデータをどこに送るかを決定するために使用するテーブルのことです。 また、ネットワーク機器に限らずPCやサーバのようなIPアドレスで通信する、ほぼ全ての機器がルーティングテーブルを持って通信しています。 例えば皆さんお使いのPC上で、Windowsであれば、コマンドプロンプトで route print というコマンドを打てばルーティングテーブルを見られます。 ルーティングテーブルは、基本的には次の要素で構成されています。 • 宛先IPアドレスもしくはサブネット：最終的なデータ転送先のIPアドレスもしくはサブネット。 • ゲートウェイ：データが次に送られる中間地点のIPアドレス。 • 出力インターフェース：データが送信されるネットワーク機器のポート • メトリック：ルートの優先順位を示す値。小さいほど優先度は高くなる。 Catoに限らず、ルーティングテーブルはネットワーク構成を考えるうえで、まず最初に検討を始める部分と言えます。 DHCP DHCPは、「Dynamic Host Configuration Protocol」の略称で、ネットワーク管理プロトコルの一つです。 ネットワーク内の機器に自動的にIPアドレスを割り当てる際に主に使用されます。 DHCPはIPアドレスの他、IPアドレスのサブネットマスク、ネットワーク内で利用可能なDNSサーバのIPアドレス、外部ネットワークとの出入り口であるデフォルトゲートウェイのIPアドレス、割り当てられたアドレスのリース期間（使用期限）などの情報を通知します。 DHCPの利点は、機器利用者が手動で設定することなく、ネットワーク管理者が適切な設定を自動で適用できることです。 DHCPは、ネットワーク管理者にとって、IPアドレスの管理負担軽減のため有効なプロトコルとなっています。 ドメイン名・FQDN ドメイン名とは、ネットワーク上に存在するコンピュータやネットワークを識別するための名前のことです。 コンピュータやネットワークを識別する際、IPアドレスが利用されますが、単なる数字の羅列のため人間が覚えづらく識別しづらいです。 そのため、識別しやすいように、文字・記号を組み合わせたドメイン名をつけることができます。 例えばGoogleであれば、「www.google.co.jp」にアクセスします。 上図のように、ドメインは実世界の住所表示のように広い領域を指す名前から順に範囲を狭めていく階層構造になっています。 各階層の識別名を「.」で区切って表記されています。 一番右が最上位階層で、左に向かって階層が下がっていきます。 それぞれ右からトップレベルドメイン(jp)、セカンドレベルドメイン(co)、サードレベルドメイン(google)呼ばれます。 また、特に実際にアクセス先となる「www.google.co.jp」は「FQDN」（完全修飾ドメイン名）とも呼ばれます。 なお、Catoでは、FWルールを設定する際、ドメイン名とFQDNを区別して設定する仕様になっています。 仮にgoogle.co.jp配下のサブドメインをすべて制御したい場合はDomainを選択、www.google.co.jpを完全一致で個別に制御したい場合にはFQDNを選択します。 このように、Catoに限らず用語ごとの設定仕様をよく確認することも実際の設定作業において重要になります。 DNS DNSとは、「Domain Name System」の略称で、上記で説明したドメイン名とIPアドレスの対応関係をネットワーク上で管理しているシステムのことです。 外部からのドメイン名の問い合わせ解決するサーバをDNSサーバと呼びます。 反対にDNSサーバへ問い合わせするコンピュータをDNSクライアントもしくはDNSリゾルバと言います。 また、ドメイン名とIPアドレスの対応関係をサーバへの問い合わせによって明らかにすることを「名前解決」と呼びます。 ドメイン名から対応するIPアドレスを求めることを「正引き」、逆にIPアドレスからドメイン名を割り出すことを「逆引き」と呼ばれます。 ネットワーク設計において、特に社内ネットワークなどでFQDNを使った通信がある場合には、どのDNSサーバへ問い合わせするかを意識して設計することが必要です。 まとめ いかがでしたでしょうか。 すでに理解できていた用語もあれば、人によってはあいまいに理解して誤用していた用語もあったのではないでしょうか。 本記事では、ネットワーク設計・運用において特に重要な用語を取り上げています。 Catoクラウドの初期設定や障害調査で用語の意味が理解できない場面で、ぜひ本記事に立ち戻ってご活用いただければ幸いです。 今後続編として、【セキュリティ編】【応用編】の投稿も予定しています。

こんにちは、SCSKの齋藤です。 今回はAWSサービスのモックを作成し、プログラムをテストする方法の簡単な例をブログにしました。   モックとは？ ソフトウェアテストを行う際に、代用する下位モジュールスタブの一種です。 プログラムを作成した際に、作成したプログラムから別のモジュールを呼び出したりする際に、別のモジュールの代用品として理想的な値を返すようなオブジェクトです。 例えば、AWSリソースを操作するようなLambdaのソースコードをテストする場合、AWSリソースの部分を代用品としてモックを使うことで、ソースコードが正しく動作するかをテストできます。   AWSのモックツール 代表的なものとして、motoがあります。 Moto: Mock AWS Services — Moto 5.0.12.dev documentation docs.getmoto.org これを用いると、開発環境のPC上などで擬似的にAWSリソースを作成することができます。 全てのAWSリソースは網羅されていないらしいのですが、Lambdaと連携されるような代表的なサービス（S3、SQS、DynamoDB、STSなど）は、含まれております。   motoを使ってPythonのテストをしてみた！ 今回は実際にmotoを使ったモックによるテストを行ってみます。 今回私が検証した環境は下記になります。 マシン：Mac Book Pro IDE：Visual Studio Code 仮想環境構築 今回は、プログラムを実行するための仮想環境から構築していきたいと思います。 仮想環境構築の前に、プロジェクトフォルダの作成を行います。 PC上のどこでも良いので、空のプロジェクトフォルダをまず作成します。中身は何も作成しません。   その次に、ターミナルを開いて、下記コマンドを入力し、仮想環境をPython３代で作成します。 仮想環境名は各自で命名してください。（今回は、myvenvで作成しました。） $ cd プロジェクトフォルダ名 $ python3 -m venv 仮想環境名   仮想環境を構築後、下記コマンドで仮想環境をアクティベートします。 ・Linux・Mac $ source 仮想環境名/bin/activate もしくは、 $ . 仮想環境名/bin/activate ・Windows $ .\仮想環境名\Scripts\activate 仮想環境に切り替わったため、Pythonのバージョン確認をします。 (仮想環境名)$ python -V 先頭に仮想環境名が付与され、Python３代がインストールされているのを確認できます。 そのまま、仮想環境にパッケージのインストールを行います。 今回インストールするのは、AWS SDK for Pythonであるboto3、モックツールのmoto、Pythonのテストツールのpytestの３点です。 pip install boto3 pip install moto pip install pytest あくまで仮想環境上でのインストールなので、仮想環境を閉じれば、これらのツールは使えません。 VSCodeでのフォルダ・ファイル作成 VSCode上で、先ほどのプロジェクトフォルダを開きます。 まだ空のフォルダしか作成されていないので、その中にさらにフォルダとファイルを作成していきます。 今回は、下記画像のようなフォルダ構成とすることを目標とします。 このフォルダを実現するために、新たに作成するフォルダは「 src 」フォルダと「 tests 」フォルダです。 それ以外のフォルダについては自動で作成されます。 srcフォルダとtestsフォルダ内で作成するファイルをそれぞれ解説いたします。   srcフォルダ app.py メインのソースコードをこのファイルに書きます。 boto3を用いて、S3のバケットの情報を取得して、返却する処理を実行します。 今回は簡略的に、取得したバケットの1つ目の情報のみを返却します。 boto3でのS3へのリクエストやレスポンスの形は、boto3のドキュメントを参照してください。 https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/list_buckets.html import boto3 def list_bucket(): s3=boto3.client('s3') response=s3.list_buckets() bucket_info=response['Buckets'][0] return bucket_info   testsフォルダ 本フォルダはテストに必要なファイル類を定義します。 __init__.py テスト対象のファイルがsrcフォルダにありますが、これをtestsフォルダのファイルが読み込めるようにしなければなりません。 そのため、testフォルダのファイルにパス情報を渡す必要があります。 その処理を、下記のコードで実現します。 import os import sys sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'src'))) 上記コードで何をしているか内訳を見てみると、 1. os.path.dirname(__file__)・・・開いているファイル（__init__.py）のディレクトリ名を取得します。 （/Users/usename/Desktop/sample-project/tests） 2. os.path.join()関数により、1で取得したディレクトリに、”..”と”src”という文字列を連結します。 （/Users/usename/Desktop/sample-project/tests/../src） 3. os.path.abspath()関数により、2で連結したパスを正規化します。 （/Users/usename/Desktop/sample-project/src） 4. sys.path.append()関数により、3で正規化されたパスをpytestに渡しています。   conftest.py このファイルが本記事の要である、モックをしている箇所になります。 環境構築の際にインストールしたmotoから、mock_awsというツールをインポートしています。 このmock_awsというツールが、ローカル上で、仮想的なAWS環境を実現してくれます。 この仮想的な環境に、「test_bucket」という名前のS3バケットを作成します。 import pytest from moto import mock_aws import boto3 @mock_aws @pytest.fixture def setup_s3(): with mock_aws(): s3=boto3.client('s3') s3.create_bucket( Bucket='test_bucket', CreateBucketConfiguration={ 'LocationConstraint': 'ap-northeast-1', },) yield s3 test_app.py これまで作成したファイルを元に、実際にテストを行うファイルです。 テストの関数に、conftest.pyのsetup_s3関数を継承させます。 これにより、このテストコードはsetup_s3関数内のモックしたS3を使うことができます。 この状態で、テスト対象である、srcフォルダのapp.pyのlist_bucket関数を実行します。 そして、モック化した際に「test_bucket」という名前でS3を作成しているので、その名前が取得できているのかをassert文で評価します。 import app def test_list_bucket(setup_s3): response=app.list_bucket() assert response['Name']=='test_bucket' テストの実行 VSCodeのターミナルを立ち上げて、下記コマンドを入力します。 python -m pytest テストが合格してます！ これによりモック化して作成したS3バケット「test_bucket」の情報を、正しく取得できたことを確認できました。 モックしないとどうなるか？ 今回conftest.pyでモックを作成しました。 しかし、それを作らずにテストした場合は、環境上にセットされているAWS CLIの情報を元に、実際にAWS環境にアクセスされてしまいます。 大規模な開発などの場合、まだAWS環境が用意されていないが、Pythonのソースコードを開発しなければならない場合などはあり得ます。 そうした場合、AWS環境に接続せずとも、正しく動作されていることをテストするには、モックというのがどうしても不可欠になりますね。 そもそも、単体テストというのは、作成したプログラム自身が正しいかどうかを確認するプロセスのため、それ以外のものについては正しい値が返却されるという想定で、モックを作って実施するのは当然かと考えられます。 実際にAWSリソースへのアクセスをしてプログラムが正しく動くかどうかは、機能テストなどの段階で検証するため、単体テストでは適切にモックを使うことを意識すると良いと思います。 まとめ 今回はPython上で、AWSリソースのモックのやり方を簡単に紹介しました。 motoは、大変便利なツールですので、単体テストを行う際はぜひ使うようにしましょう！

はじめに Cato クラウドを利用のお客様から、ときどき次のようなお問い合わせが来ることがあります。 Web ページ内の動画を再生できない Web ページは開けるが正常に表示されない Cato クラウドに接続しなければ正常に Web ページが表示されるのであれば、上記のような問題は Cato クラウドによって引き起こされていると考えられます。 このような場合、ブラウザのデベロッパーツールを利用すればお客様自身で素早く解決できる可能性がありますので、そのトラブルシューティング方法をご紹介します。 トラブルの原因 Cato クラウドに接続しなければ正常に Web ページが表示されるのに、Cato クラウドに接続するとおかしくなるという問題が起きた場合、お客様自身で Web ページへのアクセスに関するイベントを確認し、Internet Firewall で許可したり TLS Inspection をバイパスしたり、他にもいろいろと試されるのですが、解決できずにお問い合わせいただくことがあります。 表示がおかしくても Web ページ自体は開けているのであれば、その Web ページへのアクセスは Cato クラウドによって制限されることなく行えていることを意味します。しかし、表示がおかしくなるということは、その Web ページから参照されている他の Web サイトへのアクセスがブロックされている可能性があります。 世の中の多くの Web ページでは、そこにアクセスしたとき、ブラウザのURL欄に表示される FQDN (ドメイン名) 以外の Web サイトへのアクセスも行われ、JavaScript、CSS、画像や動画、その他リソースの読み込みが行われます。それらの読み込みがブロックされると、結果として Web ページ内の一部が表示されない、レイアウトが崩れる、一部機能が動作しないといった事象に繋がります。 例として、弊社の Web ページ (https://www.scsk.jp/) を挙げてみます。この Web ページでは、サイト内検索機能を実現するために “c.marsflag.com” というドメインにアクセスして JavaScript などを読み込むようになっています。試しに Cato クラウドの Internet Firewall を用いてこのドメインをわざとブロックするようにしてみると、次の図のように検索機能が利用できなくなってしまいました。 ドメインをブロックしていない場合（正常な表示） 一部ドメインをブロックした場合（検索ボックスが無くなって使えなくなっている） こういった問題の原因は Web ページを見るだけではわかりづらく、お客様に通信のキャプチャを取得していただいたうえで弊社や Cato のサポートにて解析・調査しているのですが、ブラウザのデベロッパーツールを利用すればお客様自身で素早く解決できる可能性があります。 トラブルシューティング方法 ここでは一般的によく利用される PC 用ブラウザで、デベロッパーツールを利用してトラブルシューティングする方法を説明します。先ほどの例のまま “c.marsflag.com” ドメインをブロックしている状態で試しています。 Google Chrome の場合 Google Chrome では、キーボードの「Ctrl + Shift + I キー」を押すとデベロッパーツールが表示されます。あるいは、メニューの「その他のツール」の中から「デベロッパーツール」を選択して表示することもできます。 上図のブラウザ画面の右のほうの領域を占めているのがデベロッパーツールです。このうち「Network」タブがトラブルシューティングの肝です。デベロッパーツールを表示してから Web ページを表示 (F5 キーで再読み込み) すると、ブラウザと Web サーバとの間で行われる多数の HTTP 通信の内容が全て表示されます。 一覧では HTTP 通信の Name, Status, Type などが表示されていますが、Cato クラウドをお使いの場合は通信先のドメイン名が重要ですので、一覧のヘッダ部分を右クリックして「Domain」も選択して表示させるようにするのがお勧めです。 すると、”c.marsflag.com” というドメインへのアクセスで HTTP ステータスコード 403 のエラーとなっていることが一目でわかります。 この 403 エラーとなっている行を選択し、右クリックして “Open in new tab” を選択してその URL を別のタブで開いてみると、たしかに Cato クラウドのブロック画面が表示されました。 これにより、”c.marsflag.com” というドメインの URL へのアクセスが Cato クラウドによってブロックされていることがわかりましたので、あとはイベントログを確認しつつ、実際にブロックしている機能 (Internet Firewall など) のルールを変更すればアクセスできるようになります。Cato クラウドのブロック画面以外が表示されるようであれば、おそらく Web サイト側の問題の可能性が高いです。 また、Web ページが表示されるのが遅いという場合、デベロッパーツールの各行の「Time」を見ると、どのリソースへのアクセスでどれだけ時間がかかったのかわかります。Cato クラウドを使わない場合は素早く表示されるのに Cato クラウド経由だと遅くなるような場合には、時間がかかっているアクセスの URL を特定できれば、原因特定や改善にも役立ちます。 Microsoft Edge の場合 Microsoft Edge も Google Chrome と同様に、キーボードの「Ctrl + Shift + I キー」を押すか、メニューの「その他のツール」の中から「開発者ツール」を選択すれば、デベロッパーツールを表示できます。 表示が日本語化されていたり、ツールの名称が「Microsoft Edge DevTools」や「開発者ツール」となっていたりしますが、デベロッパーツールの利用方法や機能は Google Chrome とほぼ同じです。 Mozzila Firefox の場合 Mozzila Firefox もキーボードの「Ctrl + Shift + I キー」を押すか、メニューの「その他のツール」の中から「ウェブ開発ツール」を選択すれば、デベロッパーツールを表示できます。 見た目は Google Chrome などと異なりますが、同様に利用してトラブルシューティングを行えます。 まとめ 本記事では、ブラウザのデベロッパーツールを用いたトラブルシューティング方法の一例を説明しました。 Web ページの一部の表示がおかしいときのトラブルシューティングとして記載していますが、他の問題が起きたときもデベロッパーツールが役立ちますので、ぜひご活用ください！

Catoの運用支援をしていると「WEBサイトへ アクセスできなくて困っている 」という問い合わせをいただくことが多いです。 今回は、上記のようなトラブルが発生した際に CMAのEvents機能から切り分けを行う方法  をご紹介します。 画⾯は2024年7⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 Eventsとは 「Events」は、Catoクラウド利用時のログが一元的に確認できる機能です。 基本的な操作方法は、以下の記事をご参照ください。 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22   注意！！Eventsに表示されない通信 Eventsの確認をする前に、以下の設定をしている通信はEventsに表示されませんのでご注意です。 トラブルが発生している通信が当てはまっていないかをまず確認ください。 １）Internet/WAN Firewall等のセキュリティルールの設定の際に[Event]の項目をTrackにしていない Trackにすることで、設定したルールにより許可もしくはBlockされた通信をEventsで確認できるようになります。 ２）BypassやSplit Tunnelを利用している通信 ３）Off-Cloudを利用した拠点間の通信 BypassやSplit Tunnel、Off-CloudでCatoを経由させていない場合に発生するトラブルは、Catoを経由していないためCato起因である可能性が低いです。利用しているネットワーク環境等の確認をまず実施ください。   トラブルシューティングの際によく使うField Eventsでのトラブルシュートは、主にフィルタリングを利用して問題に関連する通信を絞り出すことから始まります。 しかし、Eventsには多くのFieldが存在するため、問題が起きた際はどれを見ればよいの？という事態に陥ってしまうかもしれません。 以下に私がトラブルシューティングの際によく確認するFieldについて紹介します。 ※トラブルの内容にもよりますが、以下はWebサイトが見れない事象が起きた場合によく見ているFieldです。 Field名 内容 Action Catoの機能により実行された動作がわかる 例）Monitor、Allow、Block、Alertなど Sub-type Catoの機能。上記の[Action]がどの機能で実施されているのかがわかる 例）Internet/WAN Firewall、TLS、IPS、App Security Rule [Sub-type]のどのルールにマッチしているのかがわかる Category 通信がどのカテゴリに分類されているのかがわかる PoP Name 通信を行う際に入り口となるPoP名がわかる Source IP 送信元IPアドレス Source is Site or SDP User 送信元がSocket配下か、SDPユーザかがわかる Domain Name 通信先のドメイン名 Full Path URL 通信先のフルパスURL Destination IP 宛先IPアドレス Network Rule どのNetwork Ruleにマッチしているかがわかる Public Source IP トラフィックの送信元であるPoP によって割り当てられたグローバルIPアドレス Network RuleによりEgress IPにNATされている場合も表示される Source Site Socket配下の場合はSite名、SDPユーザの場合はユーザ名が表示される User Email 送信元ユーザのメールアドレス TLS Inspection TLS Inspectionで検査を行っているかがわかる 「1」の場合は検査済み、「0」の場合は検査なし 上記は、ざっくりとした説明ですが、すべてのFieldの意味については以下のCatoのKnowledgeサイトを参照ください。 https://support.catonetworks.com/hc/en-us/articles/5131416221085-Explaining-the-Event-Fields   Eventsを利用したトラブルシューティング手順 次に、実際にお問合せの多い「Webサイトにアクセスできない問題」を例に、Eventsでの切り分け手順について説明します。 問題が発生したらまず以下の手順で実際にトラブルシューティングを実施してみましょう。   手順①　Eventsでログを確認する前に以下の情報を事前に確認しておきましょう。 ・いつ：問題が発生した日時 ・どこで：Socket配下からのアクセス、もしくはリモートからのアクセスか ・誰が：送信元のIPアドレス、もしくはユーザ情報(メールアドレス) ・宛先情報：宛先IPアドレスやWebサイトのURL ・何の通信：プロトコルやポート番号、アプリケーション 上記を確認出来たらEventsを使ってトラブルシューティングを実施してみましょう。   手順②　どこから通信を行ったかを絞る Socket配下からのアクセスか、リモート(SDPユーザ)からのアクセスかがわかる場合は、初めに絞ってしまいましょう。 ・Socket配下からのアクセスの場合 [Network]>[Sites]から拠点を選択し、[Site Monitoring]>[Events]をクリック ・SDPユーザからのアクセスの場合 [Access]>[Users]からユーザを選択し、[User Monitoring]>[Events]をクリック ・上記が特に決まっていない場合 [Monitoring]>[Events] 上記のようにEventsはユーザ単位、Site単位で確認することが可能です。   手順③　問題が発生した時刻に絞る Eventsの右上にあるカレンダーボタンをクリックし、問題が発生した日時を絞り込みましょう。   手順④　宛先を絞る アクセス先をドメインもしくは宛先IPアドレスで絞りましょう。   手順⑤　Actionを確認 [Fields]からActionを選択し、対象の通信がBlockされていないか確認しましょう。 Actionの中にBlock以外の項目が複数ある場合があります。 今回はBlockのEventsを確認したいので、以下○枠の「⊕」をクリックしてさらに絞り込みましょう。   手順⑥　Sub-Typeを確認 手順⑤でBlockされていた場合、次にSub-typeからCatoのどの機能でBlockされているのかを確認しましょう。 上記の画像でいうと、通信をBlockしているのは、Internet Firewallだということがわかります。   手順⑦　Ruleを確認 手順⑥で、Blockを実行している機能が分かりましたら、どのルールでBlockされてしまったのかを確認しましょう。 これでBlockを実行しているルールが判明しました。 原因であるCatoの機能、ルールが確認できたらCMA側で設定変更を行い問題を解消しましょう。 原因別の対応例 EventsでBlockが確認できた場合 上記の手順でEventsからCatoの機能によるBlockが確認できましたら、アクセスができるように設定変更を行いましょう。 例として以下パターン別の対応例をご紹介します。 パターン１　Internet/WAN FirewallでBlockされていた よくあるのが、Internet Firewallで意図せずBlockされていたパターンです。 「通信が間違ったカテゴリに分類されていた」や「そもそも上位のルールでBlockされていた」といった事例が多いです。 解決方法としては上記の手順⑦にてBlockしているルールを確認し、それに合わせて設定の変更を行いましょう。 ▼ 上位のルールにブロックされていた 上記手順の⑦番で、どのルールによりBlockされていたのかを確認できたとします。 確認ができたら、上位に許可ルールを作成することで問題が解消します。 ▼間違ったカテゴリに分類されていた 上記手順の⑦番で、Blockしているルールの内容を確認し、通信が間違ったカテゴリに分類されていることがわかった場合。 対象のドメインのカテゴリを変更することで問題が解決します。 カテゴリ変更の方法につきましては、以下の技術ブログを参考ください。 Catoで業務通信がブロックされてしまう事象の解決策！～SWGで誤分類されたサイトを管理者で修正する機能～ Catoを使っていると、業務でアクセスするドメイン（URL）が誤ったカテゴリに分類され、通信できない！ということがあります。今回は、そんな問題が発生した場合の新しい回避策「カテゴリの手動修正」を紹介します。 blog.usize-tech.com 2024.02.22 上記のようにカテゴリの変更で解決する場合もありますが、Internet FirewallもしくはWAN Firewallで該当の通信を許可してしまった方が早くて確実です。 アクセスができなくて困っている場合は、まずはFirewallルールでの許可設定を行いましょう。   パターン２　IPSやAnti-MalwareでBlockされていた CatoのIPSやAnti-Malware機能によってBlockされていたというケースもあります。 Blockされていた通信が問題ないと判断できる場合は、Allow Listを作成することで問題を回避できます。 なお、Allow Listは[Security]>[IPS]の[Allow List]タブから作成できますが、Eventsの画面からでも作成が可能です。 例として、IPSでBlockされていた際にEvents画面からAllow Listを作成する方法について記載します。 手順①：「4.Eventsを利用したトラブルシューティング手順」で、IPSによるBlockを確認 手順②：表示されたEventsの「＋」をクリックして詳細を展開 手順③：詳細が展開されたら[Signature ID]をクリック 手順④：Allow Listの作成画面が画面右から展開されるので、環境に合わせて設定し、[Apply]をクリック Allow Listの作成手順は以上です。 ※Anti-Malwareの場合も同様の手順でAllow Listを作成できます。 Signature IDによっては、CMAからAllow Listを作成しても許可されない場合があります。 その場合はCatoのバックエンド側でホワイトリストに登録してもらわなくてはいけないため、Catoのサポートチームへ依頼してください。 EventsでBlockではなくMonitorと表示されていた場合 これまではEventsでBlockされていた(Catoの機能でBlockされていた)ケースについてご紹介しました。 しかし、Webサイトにアクセスできない状況なのに、Eventsで見ると通信はBlockされずにMonitorと表示されているケースもあります。 これは、宛先への通信はCatoを通過していることを表しており、宛先側で何かしらのアクセス制限がされている可能性があります。 そういった場合は、TLSインスペクションのBypass設定やCatoを迂回させる設定などをお試しください。 設定方法などの詳細につきましては以下の技術ブログを参照ください。 Cato経由でのWebサイト接続のトラブル例とその対処法 Cato経由でのWebサイトの接続トラブルについて、事例とその対処法についてご紹介します。 blog.usize-tech.com 2024.04.19   例外事例 上記のように、通信がMonitorと表示されているとEventsから原因を特定することは難しいですが、例外事例もあるのでご紹介します。   事例：Webサイトにアクセスすると「プライバシーが保護されません」ページが表示される どのWebサイトへアクセスをしても以下画像のように「プライバシーが保護されません」と表示されてしまうといった事例があります。 原因の一つとして、TLS Inspection機能を有効にしているにも関わらず、端末にCatoのルート証明書を導入していないことが挙げられます。 上記の事象が証明書のインストール有無が原因かどうかは、Eventsから特定することができますのでご紹介します。 TLS Inspection機能の詳細につきましては、以下の技術ブログをご参照ください。 CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 ▼確認手順 手順①：日時やドメイン情報などで絞り、アクセスしたWebサイトへの通信をEventsで表示させる 手順②：Actionを確認する ここでは、Block表示はありませんでしたが、Monitorの他にAlertがあるので「⊕」を押して絞ります。 手順③：Eventsの詳細を展開する Sub-typeがTLSであることがわかります。 Sub-typeがTLSの場合は、「TLS Error Description」からAlertとなった理由が確認できます。 実際に検証も行ってみましたが、端末にCatoのルート証明書が入っていない場合は「certificate unknown」と表示されます。 同様のEventsが確認できた場合は、Catoのルート証明書がインストールされていないことが原因の可能性があります。   まとめ 本投稿では、トラブル時のEventsの見方や対処法について一例をご紹介しました。 トラブルでお困りの方のお役に立てれば幸いです。 なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！

こんにちは、広野です。 最近、AWS Lambda 関数から AWS Elemental MediaConvert の API を呼び出そうとしたときに気付いたことを話します。API エンドポイントが変わっていました。いつから変わっていたのかわからないのですが。 そもそも MediaConvert って？ ひとことで言うと、動画をエンコードしてくれるサービスです。動画処理ソフトウェアができることに近いです。私は MP4 のデータをストリーミング可能な形式 HLS に変換する目的で使用しています。ユーザがアプリ UI からアップロードした動画データを自動的にエンコードするのに便利です。 What is AWS Elemental MediaConvert? - MediaConvert AWS Elemental MediaConvert is a file-based video processing service that provides scalable video processing for content ... docs.aws.amazon.com 変更点 本題です。 今現在の AWS Elemental MediaConvert のマネジメントコンソール画面です。左側のメニュー、矢印の位置に「アカウント」という設定があったのですが、無くなっていました。 実はこのアカウントの設定には、アカウントかつリージョン固有の MediaConvert API エンドポイントの URL が表示されており、API を呼び出すときにはその URL を使用しなければならない、という仕様がありました。 例えば AWS Lambda 関数 (Python) では、以下のようにエンドポイントを打ち込んでいました。 client = boto3.client('mediaconvert', region_name='ap-northeast-1', endpoint_url='https://xxxxxxxx.mediaconvert.ap-northeast-1.amazonaws.com' ) マネジメントコンソールからアカウントの設定が無くなったことを受けて AWS ドキュメントを確認したところ、以下のように DescribeEndpoints は不要になったと書いてありました。これがアカウントかつリージョン固有の API エンドポイントだったはず。 Note that DescribeEndpoints is no longer required. We recommend that you send your requests directly to the regional endpoint instead. Endpoints - AWS Elemental MediaConvert API Reference /2017-08-29/endpoints Operation ID: DescribeEndpoints 200 response The service can't process your request because of a p... docs.aws.amazon.com 結論 試してみたら、AWS Lambda 関数からの MediaConvert API 呼出は API エンドポイント指定 なし で動きました。 client = boto3.client('mediaconvert') 従来の方法で作成済みの AWS Lambda 関数が動くかは未確認です。過去に作成していたリソースを削除してしまったため。ですが互換性維持のため、動くのではないかと想像します。 まとめ いかがでしたでしょうか？ この変更についてアナウンスがあったのかわからず、変更に気付いたときは戸惑いました。 短いですが、本記事が皆様のお役に立てれば幸いです。

どうも、Catoクラウドを担当している佐々木です。 今回は Catoクラウドの「Header Injection」   について紹介します。   最近、Microsoft365やGoogleアカウントについて、許可していないアカウントを利用させないようにしたい、といった いわゆる「 テナント制御 」に関する問い合わせを多くいただきます。 Catoクラウド経由でテナント制御する際に利用する機能の一つ、それが「Header Injection」です。   画⾯は2024年7⽉時点のものです。 機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 「Header Injection」を利用するためには、セキュリティオプションのCASBが必須になります。   テナント制御とは テナント制限とは、会社や管理者が許可したアカウントのみWEBサービスを利用できるようにすることです。 ※MicrosoftやGoogleで、会社のアカウントによるアクセスはOKだけど、個人アカウントでのアクセスはNG、を実現する機能です。   どうやってやってるの？ クライアントとインターネットの間にあるプロキシなどで、通信ヘッダーや認証プロセスを操作することで実現しています。 例： Microsoft365の場合 クライアント端末からAzure ADに対する認証の通信をプロキシ経由させます。 そのプロキシから送信されるパケットに許可対象の Azure AD テナントの情報を付与します（HTTPヘッダーとして付与）。 Microsoft365側での上記で挿入したヘッダーの値を参照することで、許可したテナントへのアクセスのみ許可され、 それ以外はブロックされるといった動作をします。      ※Catoクラウド利用者は、上記のプロキシ＝Catoクラウドと置き換えてください。 ※Microsoftの仕様については、以下の公式サイトを参照ください。   テナント制限を使用して SaaS アプリへのアクセスを管理する - Microsoft Entra ID 自社の Microsoft Entra テナントに基づいて、テナント制限を使用しアプリにアクセスできるユーザーを管理する方法。 learn.microsoft.com   つまり、プロキシ（＝Catoクラウド）で実施しているのは、ヘッダーを挿入することです。 ブロックする/しないなどの「アクセス制御」は、 Microsoft365など WEBサービスがやっています。 Catoクラウドがブロックしている、と誤解される方が多いのですが、 Header Injection機能では一切アクセス制御はしていません！！！   Catoクラウドでの実現方法 Catoクラウドを経由してテナント制御する場合、以下の機能を利用します。   Header Injection機能 設定した条件（アプリケーションやアカウント等）にマッチする通信が発生した際、パケットのヘッダーに任意の文字列を挿入します。 アクセス先のWEBサービス側で、任意の文字列がヘッダーに含まれるパケットのみ許可し、それ以外をブロックするなど、 といった制御をさせることで、テナント制御を実現します。   TLSインスペクション トラフィックを検査するためTLSインスペクションを有効にする必要があります。 TLSインスペクションが有効でも、Bypassしている通信に対して「Header Injection機能」は動作しません。   その他 過去のブログ記事「 Catoクラウドでアプリケーションを制御するには 」でも紹介があった通り、 Catoクラウドの「Application Control」機能でもテナント制御は可能です。 気になる方は上記記事をご確認ください。   動作イメージ 例えば、Microsoft365へのテナント制御を実施する場合、以下のような動作をします。 ① ユーザーがMicrosoft365にアクセスし、サインインを試みます。 ② トラフィックは「Catoクラウド」に送られ、CMAで設定したヘッダー（ Microsoft 365が指定したもの） を挿入します ⇒これがHeader Injectionの機能です。 ③ Catoクラウド経由でトラフィックをMicrosoft365に転送します。 ④ Microsoft365で、ヘッダー値を検索します。 ⑤ 正しいヘッダー値を持っている場合、アクセスが許可され、正しくない場合、アクセスに失敗します。   Microsoft365へのテナント制御をやってみた 今回は、問い合わせが多い「Microsoft365へのテナント制御」をテストしてみました。   注意事項 ここから読み始めた方もいるかもしれないので再掲します。 Catoクラウドで実施しているのは、ヘッダーを挿入することです。 ブロックする/しないなどの「アクセス制御」は、 Microsoft365など WEBサービスがやっています。 Catoクラウドがブロックしている、と誤解される方が多いのですが、 Header Injection機能では一切アクセス制御はしていません！！！   テスト条件 テスト内容：Microsoft365について、アカウントAのアクセスはOKで、アカウントA以外はアクセスさせない 端末：Windows 11 Catoクライアント：5.10.34.2284   Catoの設定 CMAで「 Security 」＞「 Application Control 」＞「 Header Injection 」から以下のように設定します。 ▼「Header Injections」の有効化 左上のHeader Injections Enabledをクリックして、バーが緑色になるようにしてください。   ▼ルール1（Microsoft365_テナント制御1） ログインを許可したいアカウントを定義 しています アプリケーションは「 Azure Active Directory 」を選択してください 「Injected Headers」で以下の設定をしてください Header Name： Restrict-Access-To-Tenants 　／　Header Value： Microsoftアカウントのprimary domainを入力 Header Name： Restrict-Access-Context 　／　Header Value： Microsoftアカウントのテナント IDを入力   MicrosoftアカウントのテナントIDなどがわからない方は、以下を参考に調べてみてください。 ※管理者権限がないと確認できません。 Microsoft 365 テナント ID を見つける   ▼ルール2（Microsoft365_テナント制御2_コンシューマーアカウントをブロックする設定） コンシューマー向けのアカウントをブロックするための設定です。 アプリケーションは「 Microsoft Live 」を選択してください 「Injected Headers」で以下の設定をしてください Header Name： sec-Restrict-Tenant-Access-Policy 　／　Header Value： restrict-msa   最後に設定を保存して完了です。 ※TLSインスペクションを有効にしていない場合、有効化してください。   Catoのバージョンアップに伴い、アプリケーション名などが変わる可能性がございますのでご注意ください。 ヘッダー値や動作は、Microsoftの仕様に依存しますので、思うように動作しない場合、Microsoftの仕様をご確認ください。   テスト結果 許可しているアカウントでのアクセスは許可されましたが、許可していないアカウントでのアクセスは以下のようにブロックされました。   ▼許可していないアカウントでアクセスした結果   ▼コンシューマー向けアカウントでアクセスした結果 　※ちょっと画面が違ったので一応共有します。 まとめ 意外と簡単な設定でテナント制御ができました。 挿入するヘッダー値は変わりますが、GoogleやSlackなど他のアプリケーションでも同じように設定することで制御可能です。   ・Catoクラウドでもテナント制御が可能 ・Microsoft365、Gmail、Slcakなど多くのアプリケーションに対応 ・Catoクラウドではヘッダーを挿入しているだけで「実際の振る舞い」はWEBサービス側に依存 ・Header Injectionだけではなく、TLSインスペクションも有効しないとダメ   上記以外の情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

AWS JAPAN APNブログ にて 2024 Japan AWS Ambassadors / 2024 Japan AWS Top Engineers / 2024 Japan AWS Jr. Champions の受賞者が発表されました。 今年度は、SCSKより過去最多の表彰者が選出されました！SCSKから選出された計10名の社員を今回はご紹介します！ 2024 Japan AWS Ambassadors 「 2024 Japan AWS Ambassadors 」は、2024 Japan AWS Top Engineers のうち、卓越した技術力を持ち、社内外への情報発信やその深い専門知識を基に、アマゾン ウェブ サービス（AWS）のソリューションアーキテクトと協力してお客様のAWS導入・活用にあたり大きく貢献・支援したメンバーが選出されます。（各社最大2名まで） SCSKからは広野と木澤の2名が選出されました。 広野 祐司 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 ソリューション事業グループ ソリューション事業グループ統括本部 統括部 タレントマネジメント第二課 Ambassador 3 年目となりました。 私は社内クラウド技術者育成や、社外のお客様または社内のエンジニア向けの AWS 技術支援を担当しております。AWS サーバーレスサービス、React によるモダン Web アプリケーション開発が得意領域です。 社員向けクラウド学習用 e-Learning サイトの開発、コンテンツ作成をしながら、その e-Learning サイトを学習教材に仕立て、DevOps、CI/CD、アジャイルソフトウェア開発を体験できる研修も提供しております。 当社 AWS 認定資格数はちょうど 2,500 を超えたところです。知識的な育成だけでなく、人材育成施策の過程で得た実戦経験を社内外への技術支援に活用するサイクルも徐々にできるようになってきたと感じています。 今年度当社 Top Engineer は増えましたが、今後継続的に Top Engineer や次期 Ambassador の育成サイクルを回していけるようになれたらと思っています。 引き続き、どうぞよろしくお願いいたします。 ★ 広野のTechHarmony記事一覧は こちら 木澤 朋隆 ソリューション事業グループ クラウドサービス事業本部 事業推進部 事業企画課 ソリューション事業グループ クラウドサービス事業本部 クラウドサービス第二部 第二課 2021年からJapan AWS Ambassadorsを拝命しております。 自身の活動方針として「クラウドに強いSCSKの実現」と「それをアピールすることによる当社のプレゼンス向上」を挙げ活動してまいりました。それに伴い立ちあげた本エンジニアブログTechHarmonyも記事数が500を超え、認知度が高まってきていることを嬉しく思います。 私は新卒で入社以来、お客様先での常駐やWebシステム開発のインフラ構築で幅広い経験を積んでまいりました。2013年にAWS上での大規模構築案件を担当したことでクラウドサービスの将来性を感じ、2016年よりクラウド提供部署に異動して現在に至ります。 現在の業務は、クラウドアーキテクトとしての案件支援やマーケティングのリーダーとして各種イベントの企画や運営・登壇、社内外向けの情報発信などを担当しております。 なお表彰制度は活かしてこそと思っておりコミュニティイベントにも参加や発表を行い積極的に交流するようにしておりますが、そこでの交流は人生の糧になっていると感じております。皆様ありがとうございます。 そうした活動を通じ、今後も「クラウドに強いSCSK」の実現に邁進していく所存です。 よろしくお願いします。 ★ 木澤のTechHarmony記事一覧は こちら   2024 Japan AWS Top Engineers 「 2024 Japan AWS Top Engineers 」は、AWSパートナーネットワーク(APN) 加入のAWSパートナー企業に所属し、AWSに関する高い技術力を発揮した活動を行ったメンバーが選出されます。 8つのカテゴリ（Services、Software、Networking、Security、Analytics、Database、Machine Learning、SAP on AWS）が用意されており、 SCSKからはServicesで広野/木澤/寺内の3名（※）、Databaseで丸山/潮の2名、Analyticsで安彦/三上の2名、Nerworkingで貝塚の1名が選出されました。 ※広野/木澤は前項で紹介済みのため本項では割愛 （2024 Japan AWS Top Engineers　SCSKメンバー8名）   ★ 2024 Japan AWS Top Engineers (Services) 寺内 康之 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第二課 四半世紀以上前にネットワークエンジニアとして社会人になり、サーバエンジニアを経由して現在AWSを専業でやっております。 2007年、EC2が発表され、あまりに簡単にLinuxマシンが手に入ることに感動して以来、AWSのファンです! 現在は、お客様の内製を技術面、教育面で総合的に支援する「テクニカルエスコートサービス」を提供しています。こちらはアプリケーションから基盤およびネットワークなど幅広く、AWSの範疇にとどまらなず幅広く相談を受け付ける総合IT支援サービスとなっておりますので、是非お気軽にお問い合わせください。 今回、AWS Top Engineersとしてご評価いただいたことは、長年”AWS愛”を育んできた私としてとても嬉しく光栄に思います。チームのみなさまと協力し得られた成果ですので、引き続きチーム力で貢献したいきます。 さて、個人的にはSF小説やアニメが大好きで、わりと妄想したり夢見がちです。VUCAの時代、SFプロトタイピングなどもやってみたいと常々思っております。関係の方々、よろしくお願いします。 ★ 寺内 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Database) 丸山 祐佳 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第三課 SCSKに入社以来、MySQLを中心としたDB技術者として、設計・構築をはじめ、サポートやチューニングサービス、研修講師などを担当していました。 その後、当社ERPパッケージであるProActiveのデータベースをOracle DBからMySQLへ移行するプロジェクトをきっかけとし、AWS環境への異種DBマイグレーションサービスを立ち上げ、PostgreSQLやAmazon Auroraへの移行案件に携わり、現在に至ります。 この度、昨年に続き2024 Japan AWS Top Engineers (Database)にも選出いただき大変光栄です。異種DB移行は、技術難易度やその複雑性から決して一人でできるものではなく、チームとして協力しあってこそ成功するサービスです。今回の選出についても、これまで異種DB移行に携わってきた方々のおかげです。大変感謝申し上げます。 おかげさまでお客様からの相談も多く少しずつ実績も増え、また移行後も快適にDBを利用できるようチューニングなどのサービス拡大を行っております。 AWS環境におけるDB分野のサービスを継続的に進化・拡大することで、今後もよりAWSの普及に寄与できるよう努めて参りたいと思います。 ★ 丸山 のTechHarmony記事一覧は こちら 潮　雅人 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第三課 新卒でSCSKに入社して以来、5年ほどMySQL関連の設計構築や性能問題対策を担当していました。その後、ニューヨークに1年半、ジャカルタに8か月ほどの駐在を経て、現在はお客様の異種データベースマイグレーションプロジェクトをご支援し、Oracle DatabaseからAmazon Auroraへの移行案件等に携わってきました。 異種データベース移行は、移行する際の規模の予測が難しく、かつ移行前後のデータベース両方の知識が必要とされるため、ハードルが高いと考えられ、実際ハードルは高い傾向にあるのですが、運用費用節減やクラウド活用による柔軟性の確保等、得られるメリットも大きい活動です。 今回Top Engineersの選出に際しては、この異種データベース移行の活動によるお客様のビジネスへの貢献、また、海外でのAWS利用拡大に向けた活動がご評価頂けたものと考えております。 今回のTop Engineers選出をきっかけとして、より高いレベルでのAWS上DBの理解と利用普及に貢献して参ります。 ★ 潮 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Analytics) 安彦 洋樹 ソリューション事業グループ　クラウドサービス事業本部　データ＆ＡＩソリューション部　第一課 SCSKに入社以来、アプリケーション開発する部署と基盤を構築する部署を渡り歩き、主にDA/DBAとして様々な大規模プロジェクトを経験してきました。 その中でオンプレ環境でDWHシステムを構築するプロジェクトも何度か経験しており、面白い領域だなぁと思っていたところ、2018年にAmazon Redshiftを中心とした顧客情報基盤構築プロジェクトでアーキテクトリーダを担当したことをきっかけに、AWSのAnalytics系のサービス(Amazon Redshift、Amazon QuickSight、AWS Glue等)を使ったデータ活用システム構築のプロジェクトを主に担当することになりました。 そこで培った経験を活かし、2023年には「クラウドデータ活用サービス」を開発し、そのサービスを使って現在はAWS様主催のセミナーに登壇させて頂いたり、データ活用システムの構築プロジェクトを数多く推進しております。 このような活動をAWS様に評価頂き、2024 Japan AWS Top Engineers (Analytics) に選出して頂きました。 これからも、AWSのAnalytics系のサービスを活用して、お客様のDX推進やデータドリブン経営の支援に努めていきたいと思います。 ★ 安彦 のTechHarmony記事一覧は こちら 三上 晶子 産業事業グループ　産業ソリューション第二事業本部　エンタープライズソリューション第二部　第二課 新卒でSCSKに入社し、今年で入社6年目になります。 入社当初はデータベース専門部隊としてOracleやMySQLのデータベース構築案件を担当しており、その後はデータ活用案件と並行して、SCSKクラウドデータ活用サービスの企画からプロモーションを担当しました。現在はInformaticaの主管部署として、引き続きデータ活用案件やサービス開発に従事しております。 この度、2024 Japan AWS Top Engineers (Analytics)に選出いただきました！これまでのYouTubeを利用したプロモーション活動やセミナーでの登壇が選出に繋がったと考えております。YouTubeやセミナーなど表に見えているのは私一人ですが、その裏には多くの優秀な技術者がおり皆様にたくさんの支援をいただいております。大変感謝申し上げます。 現在はInformatica部隊ではありますが、AWSとの親和性を活かしAWS部隊との懸け橋となりビジネス拡大に貢献してまいります。 ★2024/7/26に大阪でデータ活用に関するセミナーを実施します！ぜひ興味のある方はご参加ください★ トヨタ紡織様事例から学ぶ、社員を幸せにするDXの第一歩 現在、DX（デジタルトランスフォーメーション）やデータ活用という言葉をよく目にしますが、多くの企業が「どのようにDXに取り組めば良いか分からない」「データ活用を進めたいが、何をしたら良いか分からない」といったお悩みを抱えています。 こうした... www.scsk.jp ★ 三上 のTechHarmony記事一覧は こちら   ★ 2024 Japan AWS Top Engineers (Networking) 貝塚 広行 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第二課 新卒でSCSKに入社後、数年間は自社データセンターをはじめとする各種ネットワークの設計・構築・運用を担当していました。その後、Linuxやサーバ仮想化技術の調査・開発、自社クラウド基盤（IaaS）の設計・構築・運用を経て、AWS関連の開発にも携わるようになりました。 さらにその後の約4年間は他業務を経験し、1年ほど前からはAWSの内製化・技術支援を提供するテクニカルエスコートサービスに従事しています。 AWSに関わること自体に数年のブランクがあった上、ネットワークについてもさらに長いブランクがあったため、今回のJapan AWS Top Engineers (Networking)受賞には驚いています。 手探りの中で、AWSのアーキテクチャ関連ドキュメントを読み込み、明確には分からないことを細かい部分まで検証し試行錯誤したこと、それらを社内外に発信できたことが選出につながったのだと思います。 今後も経験と実績を積み重ね、社内外へのAWSの普及に努めてまいります。 ★ 貝塚 のTechHarmony記事一覧は こちら   2024 Japan AWS Jr. Champions 「 2024 Japan AWS Jr. Champions 」は、APN加入のAWSパートナー企業に所属する社会人歴 1～3 年目で、AWSについて突出した活動実績がある若手エンジニアを対象とした、今年度より新設された日本独自の表彰制度です。 AWSを積極的に学び、アクションを起こし、周囲に影響を与えている若手エンジニアが選出されます。 SCSKからは福地 と蛭田の2名が選出されました。 2024 Japan AWS Jr. Champions　SCSKメンバー2名（左右） ※AWSでJr.Championsを主管するYukki(髙橋 敏行)さんと一緒に 福地 孝哉 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第一課 2021年にSCSKに入社しました。 業務経歴は、オンプレミスからAWSへのマイグレーション支援、データ利活用のためのデータ連携基盤の設計・構築業務をしています。 2024 Japan AWS Jr. Champions選出にあたり、3つのContributionカテゴリに対してAWSエンジニアとして水準を満たしているか評価されます。 私の場合は以下の活動を評価いただきました。 Challenge：サーバレス技術を組み合わせたシステム設計、案件リード Influence：Techharmonyでの発信活動 Output：社内エンジニア向けの研修プログラムの企画・運営・講師 また、2023-2024 Japan AWS All Certifications Engineersとして認定資格を継続的に取得し、積極的にインプットに取り組んできました。 今回の選出について、協力いただいた皆様には感謝申し上げます。 このブログを読んでいるあなた！SCSKで次世代のJr. Championsを目指しませんか？？ SCSKの代表としてAWSビジネスの発展に貢献できるよう精一杯頑張りますのでどうぞよろしくお願いします！ ★ 福地 のTechHarmony記事一覧は こちら 蛭田 悠介 ソリューション事業グループ　クラウドサービス事業本部　クラウドサービス第二部　第一課 2023年に新卒で入社しました。 半年間の研修を経て昨年10月よりAWSの主管部署に配属されております。 業務内容としては、福地さんと同じチームにてAPI基盤構築プロジェクトに配属後から現在まで参画しています。 入社してからは一年余り、AWSに触れ始めてからはまだ一年が経過していないため、最初は周囲の方々の知識のすごさに圧倒されておりました。 そのため、少しでもそのような方々に追いつく・追い越すべく、業務以外の場面においても「これってAWSで構築できるかなぁ…」と思ったことは自分で調べながら構築してみて、その取り組みをTechHarmonyにて発信するという活動をしてまいりました。 この活動によって社内で声を掛けていただき、この度2024 Japan AWS Jr. Championsに選出いただきました。 今まで以上にインプット、そしてアウトプットをし、社内外の若手に刺激を与えられる存在になれるよう努めてまいります。 （ちなみに写真の手は「S3」の「3」です。） ★ 蛭田 のTechHarmony記事一覧は こちら   最後に 2024 Japan AWS Ambassadors / 2024 Japan AWS Top Engineers / 2024 Japan AWS Jr. Champions に選出されたSCSK社員10名をご紹介しました。今回ご紹介した10名以外にもSCSKにはAWS認定資格取得者が多数在籍しております。 AWS導入・DX推進をお考えの方は、 ぜひSCSKにお気軽に お問い合わせ ください。 弊社の SCSKクラウドサービス（AWS） では AWS の導入から運用改善まで、お客様のAWS活用をご支援するサービスをご提供しております。 今後もお客様のAWS案件を強力にご支援出来るよう、技術力の向上や情報発信などの活動に努めてまいります。

こんにちは、SCSK株式会社の小寺崇仁です。 先日、安藤さんから バージョンアップ方法の紹介 がありました。 補足情報として、バージョンアップの注意点をご紹介したいと思います。 関連モジュールの依存関係について OSについて ZabbixOSは公式HPのダウンロードメニューより対応しているか確認します。 Zabbix7.0で対応していますが、OSのサポート終了（EOL）にご注意ください ■Zabbix Download https://www.zabbix.com/download OS バージョン EOL（AI調べ） Red Hat Enterprise Linux 9 2032年5月（メンテナンスサポート終了） 8 2029年5月（メンテナンスサポート終了） 7 2024年6月（メンテナンスサポート終了） 6 2017年5月（メンテナンスサポート終了） Alma Linux 9 2032年5月 8 2029年5月 Rocky Linux 9 2032年5月 8 2029年5月 Ubuntu 24.04 (Noble) 情報未定 22.04 (Jammy) 2027年4月（標準サポート終了）、2032年4月（ESM終了） 20.04 (Focal) 2025年4月（標準サポート終了）、2030年4月（ESM終了） 18.04 (Bionic) 2023年4月（標準サポート終了）、2028年4月（ESM終了） 16.04 (Xenial) 2021年4月（標準サポート終了）、2026年4月（ESM終了） ミドルウェアについて Zabbix7.0のミドルウェア要件として公式マニュアルに以下の記載があります ■Zabbix7.0 Requirements https://www.zabbix.com/documentation/current/en/manual/installation/requirements Apache 2.4 or later Nginx 1.20 or later PHP 8.0.0 – 8.3.X MySQL 8.0.30-8.4.X MariaDB 10.5.00-11.4.X PostgreSQL 13.0-16.X OSのリポジトリに対応のミドルウェアがあるか？ 各MWの導入にdnf,aptコマンドを使用してインストールすると思います。 OSの種類ごとに2024年7月7日時点の最新のバージョンをまとめました。   Zabbix7.0 （要件） RHEL 9.4 RHEL 8.10 Ubuntu 24.04 Ubuntu 22.04 Ubuntu 20.04 Apache 2.4 or later httpd-2.4.57 2.4.37-65 2.4.58 2.4.52 2.4.41 Nginx 1.20 or later 1.20 1.14 1.24.0 1.18.0 1.17.10 PHP 8.0.0 – 8.3.X 8.0.30 7.2.24 8.3 8.1 7.4 MySQL 8.0.30-8.4.X 8.0.36 8.0.36 8.0.36 8.0.28 8.0.19 MariaDB 10.5.00-11.4.X 10.5.22 10.3.39 10.11.7 10.6.7 10.3.22 PostgreSQL 13.0-16.X 13.14 10.23 16+257 14+238 12+214 まとめ RHEL系もUbuntu(Debian)系もOSも合わせてアップグレードが必要になりそうです   バージョンアップの時間について Zabbixのバージョンアップはdnfやaptコマンドを使用して、プログラム（パッケージ）の更新を行います。 Zabbix-serverのサービスを起動する際に、データベースの更新処理が行われます。 データ量の多い、ヒストリー、イベントテーブルに更新があると、更新に時間がかかり、監視の停止時間が長くなります。 バージョン5からバージョンアップした際に、テーブル構造の変更があるか調査しました。 history系テーブルのIndexからPRIMARY KEY への変更 Zabbix5.0 CREATE TABLE `history` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT 0, `value` double NOT NULL DEFAULT 0, `ns` int(11) NOT NULL DEFAULT 0, KEY `history_1` (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin Zabbix7.0 CREATE TABLE `history` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT 0, `value` double NOT NULL DEFAULT 0, `ns` int(11) NOT NULL DEFAULT 0, PRIMARY KEY (`itemid`,`clock`,`ns`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin まとめ history、history_uint、history_str、history_log、history_textでプライマリキーに変更されていました。 データ容量やディスクの速度によって、時間が変わりますが、感覚的に時間がかかりに思います。 ヒストリデータを破棄してから更新するのもアリかもしれないです。   ZabbixProxyを利用している場合について ZabbixProxyを使用している場合、Zabbix7.0では下位互換があります。バージョンアップの際に活用できるか、別途検証してブログ記事にしたいと思います。   仕様の変更について Zabbixの5.0からバージョンアップをすると機能が大きく変わっています。 大きな変更点をご紹介します。 ダッシュボードの変更 メニューが左側になりました。 バージョンが上がる度に改良されていきます。 トリガー条件式 条件式の記述方法が大きく変わっています。 バージョンアップの際に自動で更新されます。 監視プロセスの最適化 Pollerプロセスが分割されます。 別途チューニングが必要となります。 ユーザ役割 ユーザの役割にて、権限が詳細設定可能になります。 監視対象のサーバ管理者にユーザを払い出している場合、注意が必要です。 監査ログ バージョンアップ時に既存の監査ログのレコードは削除されます。 サポートされるDBバージョンの確認 起動前にデータベースのバージョンを確認し、サポート範囲外のバージョンの場合は起動しないようになりました。 参考 https://www.zabbix.com/documentation/6.0/jp/manual/introduction/whatsnew600 https://www.zabbix.com/documentation/current/en/manual/introduction/whatsnew700   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com  

こんにちは、広野です。 Amazon GuardDuty の設定は機能ごとに有効/無効にできるのですが、それを AWS CloudFormation で設定しようと試みたときにハマりました。 もし同じエラーが出た方には役立つかもしれません。そもそも AWS CloudFormation で Amazon GuardDuty の設定をする人ってあまりいないかもですが・・・。 ハマったこと 始まりは、AWS CloudFormation IaC ジェネレーターを使用したこと IaC ジェネレーターは、既存のデプロイ済みリソースをスキャンして、CloudFormation テンプレートにしたいリソースを選択すると、そのテンプレートを出力してくれるというスゴイやつです。 IaC ジェネレーターを使用して既存のリソースのテンプレートを生成する - AWS CloudFormation Infrastructure as Code (IaC) テンプレートを、CloudFormation で管理されていないアカウントにデプロイされた AWS リソースタイプから生成します。 docs.aws.amazon.com 今回、Amazon GuardDuty を AWS マネジメントコンソールからボタンぽちっとな、で有効にしたものを IaC ジェネレーターでテンプレート化して、他のアカウントにデプロイしようとしました。 IaC ジェネレーターが出力したテンプレートはこちら。↓ ここに、ハマり要素が潜んでいました。 注意！動きません。 --- Metadata: TemplateId: "arn:aws:cloudformation:ap-northeast-2:xxxxxxxxxxxxx:generatedTemplate/a4c6ba10-b002-47b3-bee2-587defc7921a" Resources: GuardDutyDetector0082c84d2d1e796541ecd974b782ea181600qtDWT: UpdateReplacePolicy: "Delete" Type: "AWS::GuardDuty::Detector" DeletionPolicy: "Delete" Properties: FindingPublishingFrequency: "SIX_HOURS" Enable: true DataSources: MalwareProtection: ScanEc2InstanceWithFindings: EbsVolumes: true S3Logs: Enable: true Kubernetes: AuditLogs: Enable: true Features: - Status: "ENABLED" Name: "CLOUD_TRAIL" - Status: "ENABLED" Name: "DNS_LOGS" - Status: "ENABLED" Name: "FLOW_LOGS" - Status: "ENABLED" Name: "S3_DATA_EVENTS" - Status: "ENABLED" Name: "EKS_AUDIT_LOGS" - Status: "ENABLED" Name: "EBS_MALWARE_PROTECTION" - Status: "ENABLED" Name: "RDS_LOGIN_EVENTS" - Status: "DISABLED" AdditionalConfiguration: - Status: "DISABLED" Name: "EKS_ADDON_MANAGEMENT" Name: "EKS_RUNTIME_MONITORING" - Status: "ENABLED" Name: "LAMBDA_NETWORK_LOGS" - Status: "DISABLED" AdditionalConfiguration: - Status: "DISABLED" Name: "EKS_ADDON_MANAGEMENT" - Status: "DISABLED" Name: "ECS_FARGATE_AGENT_MANAGEMENT" - Status: "DISABLED" Name: "EC2_AGENT_MANAGEMENT" Name: "RUNTIME_MONITORING" Tags: [] IaC ジェネレーターの出力を参考にして作成したテンプレート ※注意！動きません Amazon GuardDuty は機能ごとに有効/無効を設定できるものがあるので、私が必要な機能だけ有効にするように設定したつもりでした。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that enables GuardDuty per region. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# TagValue: Type: String Description: Tag value for Cost key. Default: GuardDuty MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # GuardDuty # ------------------------------------------------------------# GuardDutyDetector: Type: AWS::GuardDuty::Detector Properties: FindingPublishingFrequency: SIX_HOURS Enable: true DataSources: MalwareProtection: ScanEc2InstanceWithFindings: EbsVolumes: true S3Logs: Enable: true Kubernetes: AuditLogs: Enable: false Features: - Status: ENABLED Name: CLOUD_TRAIL - Status: ENABLED Name: DNS_LOGS - Status: ENABLED Name: FLOW_LOGS - Status: ENABLED Name: S3_DATA_EVENTS - Status: DISABLED Name: EKS_AUDIT_LOGS - Status: ENABLED Name: EBS_MALWARE_PROTECTION - Status: DISABLED Name: RDS_LOGIN_EVENTS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT Name: EKS_RUNTIME_MONITORING - Status: ENABLED Name: LAMBDA_NETWORK_LOGS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT - Status: DISABLED Name: ECS_FARGATE_AGENT_MANAGEMENT - Status: DISABLED Name: EC2_AGENT_MANAGEMENT Name: RUNTIME_MONITORING Tags: - Key: Cost Value: !Ref TagValue ハマり その1 DataSources と Features の設定を両方入れるとエラーになる IaC ジェネレーターが出力したテンプレートを全面的に信じてテンプレートを作成したわけですが、実際にテンプレートを流すと以下のエラーメッセージでスタック作成が失敗しました。 Resource handler returned message: “Invalid request provided: AWS::GuardDuty::Detector” まず最初に気付いたのは以下のドキュメントでした。 GuardDuty API changes in March 2023 - Amazon GuardDuty The GuardDuty APIs configure protection features that don't belong to the list of . A feature object contains feature de... docs.aws.amazon.com どうも、GuardDuty の機能ごとに有効/無効を設定するには DataSources ではなく Features の設定を使用することを推奨していました。そして、両方記述するとエラーになるようです。 解決: DataSources の設定は削除しました。 ハマリ その2 EKS_RUNTIME_MONITORING と RUNTIME_MONITORING の設定も その1 の修正をしただけでは状況が変わりませんでした。エラーメッセージも その1 と同じです。テンプレートのどこに問題があるかわからず、AWS CloudTrail の API ログを確認したところ、以下のメッセージを発見しました。 The request was rejected because EKS_RUNTIME_MONITORING and RUNTIME_MONITORING cannot be provided in the same request.  EKS_RUNTIME_MONITORING と RUNTIME_MONITORING の設定を両方記述するとエラーになる ようです。 これについては、以下のドキュメントの冒頭に書いてありました。後から気付きました。 DetectorFeatureConfiguration - Amazon GuardDuty Contains information about a GuardDuty feature. docs.aws.amazon.com 解決: EKS_RUNTIME_MONITORING の設定は RUNTIME_MONITORING に含まれるようなので、EKS_RUNTIME_MONITORING の方を削除しました。 ハマり その3 指定した機能の名前が正しくない その2 の修正をしても状況は変わりませんでした。エラーメッセージも その1 と同じです。テンプレートのどこに問題があるかわからず、AWS CloudTrail の API ログを確認したところ、以下のメッセージを発見しました。 The request failed because the provided feature names are invalid: [FLOW_LOGS, DNS_LOGS, CLOUD_TRAIL]. テンプレートの中に記述している、これら 3つの機能の名前が正しくないと言っています。 後から気が付いたのですが、 設定変更可能な機能としてこれらは含まれていませんでした。 その2 で紹介した公式ドキュメントにしっかり書いてありました。 DetectorFeatureConfiguration - Amazon GuardDuty Contains information about a GuardDuty feature. docs.aws.amazon.com 解決: これら 3つの機能の設定は削除しました。 完成した AWS CloudFormation テンプレート ※動きます いろいろとハマりましたが、動作したテンプレートはこれです。有効にしたい機能は ENABLED にする必要があります。 IaC ジェネレーターを使用せずに最初から公式リファレンス読んで作成した方が早かったかも・・・。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that enables GuardDuty per region. Parameters: # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# TagValue: Type: String Description: Tag value for Cost key. Default: GuardDuty MaxLength: 30 MinLength: 1 Resources: # ------------------------------------------------------------# # GuardDuty # ------------------------------------------------------------# GuardDutyDetector: Type: AWS::GuardDuty::Detector Properties: FindingPublishingFrequency: SIX_HOURS Enable: true Features: - Status: ENABLED Name: S3_DATA_EVENTS - Status: DISABLED Name: EKS_AUDIT_LOGS - Status: ENABLED Name: EBS_MALWARE_PROTECTION - Status: DISABLED Name: RDS_LOGIN_EVENTS - Status: ENABLED Name: LAMBDA_NETWORK_LOGS - Status: DISABLED AdditionalConfiguration: - Status: DISABLED Name: EKS_ADDON_MANAGEMENT - Status: DISABLED Name: ECS_FARGATE_AGENT_MANAGEMENT - Status: DISABLED Name: EC2_AGENT_MANAGEMENT Name: RUNTIME_MONITORING Tags: - Key: Cost Value: !Ref TagValue AWS CloudTrail のログが有用だった AWS CloudFormation テンプレートのスタック作成時エラーはメッセージから原因がわかることが多いのですが、GuardDuty に関しては Resource handler returned message: “Invalid request provided: AWS::GuardDuty::Detector” このメッセージ一辺倒だったので困りました。以下のドキュメントにあるように、AWS CloudTrail のイベント履歴から AWS CloudFormation のエラーメッセージを探すことで、原因を突き止められました。 コンソールで最近の管理イベントを表示する - AWS CloudTrail CloudTrail コンソールを使用して、アカウントで過去 90 日間の管理イベントを表示、フィルタリング、ダウンロードします。管理イベントは、単一の属性と時間範囲でフィルタリングできます。 docs.aws.amazon.com まとめ いかがでしたでしょうか？ AWS CloudFormation テンプレートを IaC ジェネレーターで作成し始めたことからハマってしまいましたが、これに懲りずに他のリソースのテンプレート作成も引き続き試してみたいと思います。きちんと検証することの重要さや、AWS CloudTrail の有用性にも改めて気づかされました。 本記事が皆様のお役に立てれば幸いです。

こんにちは、広野です。 以下の記事と同じ理由で、AWS Summit Japan 2024 のセッションを聞いてインスピーレーションを受けまして、Amazon API Gateway と Amazon DynamoDB を AWS Lambda 関数抜きで直接連携しました。似たような記事は世の中に多いのですが、本記事では AWS CloudFormation でデプロイしています。 Amazon API Gateway から Amazon SES API を直接叩いてメール送信する (AWS Lambda 不使用) AWS Summit Japan 2024 でとあるセッションを聞いてインスピレーションを受けまして、Amazon API Gateway と Amazon SES を直接連携させてみました。 blog.usize-tech.com 2024.07.04 やりたいこと 以下の Amazon DynamoDB テーブルから、GetItem API を使用して指定のデータを 1件取得します。パーティションキーは pkey、ソートキーは skey です。属性として attr があります。 Amazon API Gateway REST API を使用します。AWS Lambda 関数は使用しません。 AWS Lambda 関数で行っていた Amazon DynamoDB API の呼び出しは、Amazon API Gateway の統合リクエストマッピングテンプレートで代用します。Amazon API Gateway の統合タイプは、AWS になります。 Amazon API Gateway の認証はありません。CORS 設定はあります。本記事では簡略化のため “*” を使用して設定します。 テストでは、”pkey”: “test1”, “skey”: 1 のパラメータを指定してデータ取得してみます。 マッピングテンプレートをどう書くか AWS Lambda 関数でやっていたことを Amazon API Gateway のマッピングテンプレートに肩代わりさせるので、そこが肝になります。イメージしてもらいやすくするため、AWS Lambda 関数と対比して紹介します。 AWS Lambda 関数 書き方はいくつかありますが、以下のような AWS Lambda 関数 (Python) で Amazon DynamoDB GetItem API を呼び出すと思います。 import json import boto3 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('extable-xxxxxxxxxx-hirono') def lambda_handler(event, context): input = json.loads(event['body']) res = table.get_item( Key={ 'pkey': input['pkey'], 'skey': input['skey'] } ) return { "isBase64Encoded": False, "statusCode": 200, "body": json.dumps(res) } マッピングテンプレート マッピングテンプレートだと、以下のように VTL を使用して書きます。統合リクエストマッピングテンプレートに定義します。 ## API Gateway が受け取った引数を $inputRoot に格納する #set($inputRoot = $input.path('$')) { "TableName": "extable-xxxxxxxxxx-hirono", "Key": { "pkey":{ "S": "$inputRoot.pkey" }, "skey":{ "N": "$inputRoot.skey" } }, "ConsistentRead" : false } Amazon DynamoDB GetItem API に渡すフォーマットは同じだと思いました。 冒頭で、Amazon API Gateway が受け取ったパラメータを $inputRoot という変数に格納しています。面倒なのは項目ごとに “N” や “S” などデータ型を明示的に書かないといけないことです。 Amazon DynamoDB テーブルに渡すパラメータの仕様は以下の公式リファレンス通りだったので、Amazon DynamoDB の他の API でも同様に応用できるものと想像します。 GetItem - Amazon DynamoDB The GetItem operation returns a set of attributes for the item with the given primary key. If there is no matching item,... docs.aws.amazon.com 実際の動作 実際に API へのリクエストを AWS CloudShell からコマンドを打って試してみます。以下のコマンドを打ちます。 curl -X POST 'https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/Dynamodb' -H 'Content-Type: application/json' -d '{"pkey": "test1", "skey": "1"}' 以下の結果が返ってきます。 {"Item":{"attr":{"S":"attr1"},"pkey":{"S":"test1"},"skey":{"N":"1"}}} ↓整形すると { "Item": { "attr": { "S":"attr1" }, "pkey": { "S":"test1" }, "skey": { "N":"1" } } } 今回、Amazon API Gateway REST API の統合レスポンスマッピングテンプレートをパススルーにしたので、Amazon DynamoDB から返ってきたデータがそのまま表示されました。 レスポンスから余計な “N” や “S” を消そうと思ったら、統合レスポンスマッピングテンプレートで戻りを加工する必要がありますが、属性が固定ではない場合は難しいかもしれません。 本記事の例ではソートキーのデータ型が Number になっています。このケースでは、API に数値を文字列として渡さないとエラーになります。Amazon DynamoDB API の仕様です。”skey”:{“N”:”1″} となっている部分のことです。また、戻ってくる値も数値は文字列として返されます。 他にも Amazon API Gateway の設定はあるのですが、メインはマッピングテンプレートでしたので、AWS CloudFormation テンプレートから読み取るか、それを実行してデプロイされた現物をご確認頂けたらと思います。 AWS CloudFormation テンプレート 本記事で紹介した Amazon DynamoDB テーブルと Amazon API Gateway REST API を一式デプロイする AWS CloudFormation を貼り付けます。執筆時点で動いたことは確認済みです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a DynamoDB table and an API Gateway. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name. (e.g. example) Default: example MaxLength: 10 MinLength: 1 Resources: # ------------------------------------------------------------# # DynamoDB # ------------------------------------------------------------# DynamodbExample: Type: AWS::DynamoDB::Table Properties: TableName: !Sub extable-${AWS::AccountId}-${SubName} AttributeDefinitions: - AttributeName: pkey AttributeType: S - AttributeName: skey AttributeType: N BillingMode: PAY_PER_REQUEST KeySchema: - AttributeName: pkey KeyType: HASH - AttributeName: skey KeyType: RANGE PointInTimeRecoverySpecification: PointInTimeRecoveryEnabled: false Tags: - Key: Cost Value: !Ref SubName # ------------------------------------------------------------# # API Gateway # ------------------------------------------------------------# RestApiDynamodb: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub dynamodb-${SubName} Description: !Sub REST API to call DynamoDB GetItem API for ${SubName} EndpointConfiguration: Types: - REGIONAL Tags: - Key: Cost Value: !Ref SubName RestApiDeploymentDynamodb: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApiDynamodb DependsOn: - RestApiMethodDynamodbPost - RestApiMethodDynamodbOptions RestApiStageDynamodb: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApiDynamodb DeploymentId: !Ref RestApiDeploymentDynamodb MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Ref SubName RestApiResourceDynamodb: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApiDynamodb ParentId: !GetAtt RestApiDynamodb.RootResourceId PathPart: Dynamodb RestApiMethodDynamodbPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiDynamodb ResourceId: !Ref RestApiResourceDynamodb HttpMethod: POST AuthorizationType: NONE Integration: Type: AWS IntegrationHttpMethod: POST Credentials: !GetAtt ApigDynamodbInvocationRole.Arn Uri: !Sub "arn:aws:apigateway:${AWS::Region}:dynamodb:action/GetItem" PassthroughBehavior: WHEN_NO_TEMPLATES RequestTemplates: application/json: !Sub | #set($inputRoot = $input.path('$')) { "TableName": "${DynamodbExample}", "Key": { "pkey":{ "S": "$inputRoot.pkey" }, "skey":{ "N": "$inputRoot.skey" } }, "ConsistentRead" : false } IntegrationResponses: - StatusCode: 200 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 400 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 403 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 404 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 500 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" - StatusCode: 503 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" MethodResponses: - StatusCode: 200 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 400 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 403 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 404 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 500 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 503 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true DependsOn: - ApigDynamodbInvocationRole RestApiRequestModelDynamodb: Type: AWS::ApiGateway::Model Properties: ContentType: application/json RestApiId: !Ref RestApiDynamodb Schema: |- { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Dynamodb", "type": "object", "properties": { "pkey": { "type": "string" }, "skey": { "type": "integer" } }, "required": ["pkey", "skey"] } RestApiMethodDynamodbOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiDynamodb ResourceId: !Ref RestApiResourceDynamodb HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigDynamodbInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: "'*'" ResponseTemplates: application/json: '' StatusCode: 200 PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: 200 # ------------------------------------------------------------# # API Gateway DynamoDB Invocation Role (IAM) # ------------------------------------------------------------# ApigDynamodbInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigDynamodbInvocationRole-${SubName} Description: This role allows API Gateways to invoke DynamoDB GetItem API. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess Policies: - PolicyName: !Sub ApigDynamodbInvocationPolicy-${SubName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "dynamodb:GetItem" Resource: - !GetAtt DynamodbExample.Arn DependsOn: - DynamodbExample # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: APIGatewayEndpointDynamodb: Value: !Sub https://${RestApiDynamodb}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStageDynamodb}/Dynamodb 本テンプレートは、Amazon API Gateway のログを Amazon CloudWatch Logs に push するために必要な IAM ロールがアカウントに登録済みでないとエラーになります。それについては以下の記事をご確認ください。 Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロールはアカウント単位の設定です Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロール設定を紹介します。 blog.usize-tech.com 2024.07.01 まとめ いかがでしたでしょうか？ Amazon DynamoDB の API をそのまま使うだけの要件であれば、十分実用的であると思いました。VTL では対応しきれない文字列加工やビジネスロジックが必要になる場合は、やはり AWS Lambda 関数を間に挟む必要があります。 AWS AppSync のマッピングテンプレートでは便利な独自関数が用意されているのですが、Amazon API Gateway では標準 VTL が用意しているものしか使えないようなので (公式ドキュメントを見た限りでは) 、AWS AppSync の方がやや融通は利きやすいという印象でした。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK 木澤です。 SCSKでは、生成AIがより高精度の回答を出力できるRAG環境を、お客様AWSアカウントに構築できるテンプレートを提供する S-Cred+ InfoWeaveオプションを5月より提供開始 しました。 生成AI RAGソリューション InfoWeave｜SCSK株式会社 生成AI RAGソリューション（InfoWeave（インフォウィーヴ））は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp 本記事では AWS Summit Japan 2024の当社ブース内で講演した内容をベースに、本サービスの特徴等などについて解説します。 なお本サービスについては7/23にウェビナーを開催しますので奮ってご参加下さい。 [AI活用紹介セミナー] AWSとRAG構築テンプレで社内チャットボットを始めよう 本セミナーでは、AWSとRAG構築テンプレート「InfoWeave」を活用して社内チャットボットを簡単に始められる方法をご紹介いたします。 さらに、今年6月に開催されるAWS Summit Japan 2024のアップデート情報とあわせてA... www.scsk.jp AWS Summit Japan 2024ミニシアター資料 ミニシアターにて講演した内容はこちらです。 私は 6/20に1回と、(急遽)6/21の午前中に2回、合計3回発表いたしました。聴講頂いた皆様、ありがとうございました。   InfoWeaveの概要 InfoWeaveは当社のAWS複合基盤サービス、S-Cred+のオプションとして提供されています。 S-Cred+についてはこちらをご覧下さい S-Cred+プラットフォーム S-Cred+プラットフォームとはアプリケーション開発やサービス提供を最適な形で実現する複合基盤サービスです www.scsk.jp S-Cred+では、単なる運用基盤(MSP)に留まらず、環境構築テンプレートや、SCSK自社開発のローコード開発ツール等を組み合わせることによって、AWS上でのシステム／サービス開発をより迅速に行えるよう構成されています。 今回提供を開始したInfoWeaveは、この「システム環境構築テンプレート」の一種として提供を始めたものとなります。 生成AIがより高精度の回答を出力できるRAG環境を構築できるテンプレートを提供しますので、お客様は速やかに(※)独自ナレッジを含んだチャットボットを利用できるようになります。 利用料金は以下の通りです。 初期料金：600,000円（AWSアカウント単位） 環境構築代行：60,000/回（当社側でテンプレート展開を代行する場合のみ） ※申込（契約）後、利用開始まで3営業日。テンプレートのデプロイは概ね1時間程度 RAGについて さて、ご存じの方も多いと思いますが、RAGについて簡単におさらいしたいと思います。 生成AIのチャットボットを利用したことがある方も多いと思いますが、思ったよりも回答精度が良くないと感じることがあるでしょう。 大規模言語モデル(LLM)は、過去のある時点の情報を基に学習しているため、最新の情報は回答できません。 また、より専門的な情報や組織内の情報を基にした回答をして欲しい場合もあるでしょう。 そうした場合に回答精度を高める手段の一つして利用できるのが、RAG(Retrieval-Augmented Generation)となります。 LLMへのインプットとして関連情報を付加することで、より高精度な回答を得ることができるようになります。 InfoWeaveの特徴 さて環境構築テンプレートを利用し速やかにRAG環境を立ちあげることができるInfoWeaveですが、特徴として以下が挙げられます。 既存ドキュメントの活用 環境構築後、学習用ドキュメント格納用のS3バケットが1つ用意されます。 お客様はここにドキュメントを放り込むだけ独自ナレッジを利用したチャットボットを立ちあげることができます。 （テキストやMS-Office系、PDFなど一般的なドキュメント形式に対応。画像等マルチモーダルは現時点で非対応） 速やかにRAG環境を立ちあげることができる 利用開始（契約）後、3営業日にて環境構築テンプレートが提供されます。 テンプレートをデプロイすることで概ね1時間程度でチャットボットのUIも含めて提供されますので、  ① テンプレートをデプロイ  ② ユーザーを追加  ③ 既存ドキュメントを放り込む この一連の流れだけですぐにRAG環境を利用することができます。 またチャットボットだけでなくAPI機能も提供されるので、既存システムとの連携も容易に行うことができます。 無制限に環境作成が可能 環境構築テンプレートはAWSアカウント単位で提供されます。 よって当該AWSアカウント内では追加料金なくRAG環境を立て放題となります（AWSリソース料金は発生します） これにより、業務ごと・部署毎に独自の専門的なRAG環境を立ちあげることができます。 要件に応じて選択可能 大規模言語モデル(LLM)は、Amazon Bedrock上のAnthropic Claude(各種)および、OpenAI GPT-4から選択可能です。 RAG用のベクトルデータベースについては、Amazon Kendraあるいは外部サービスのPineconeを選択可能です。 セキュリティ重視でAWS内に閉じたい場合やコスト重視の場合など、要件に応じて構成を選択できる特徴があります。 利用者の権限に応じて回答が変化 これがRAGを選択する最大の特徴かもしれません。 RAGでは関連情報を付加してLLMに問い合わせるといった仕組みであることから、利用者の権限によって回答内容を変えることができます。これによって以下のような仕組みが可能になります。      社内 からの問い合わせ：社外秘の資料を用いて詳細な回答を行う 社外 からの問い合わせ：社内ナレッジを利用しない回答を行う Knowledge bases for Amazon Bedrockとの違い AWSでは同様に簡単にRAG環境を構築できる Knowledge bases for Amazon Bedrockが提供されていますが、違いは以下となります。 ① 標準でWeb ChatbotのWeb UIが提供されすぐに利用できる ② 選択できるLLMや検索用DBの幅が広い ③ 権限による回答の制御ができる InfoWeaveのユースケース 先述の特徴を持つInfoWeaveですが、以下のようなユースケースに活用可能です。 ヘルプデスクの業務効率化 専門分野・業務向けのチャットボット 社内ロール（権限）に応じた回答   アーキテクチャ 少しだけで恐縮ですが、アーキテクチャの話に触れたいと思います。 InfoWeaveの構築テンプレートは当社側のサービス提供環境よりAWS Service Catalogを通じて提供されます。 デプロイされるサービスは主なものとして以下があります。 Amazon S3（ドキュメント格納用） Amazon ECS , AWS Fargate（APIサーバー、Chatbot UI コンテナ、管理機能 各コンテナ） Amazon Bedrock（※LLM） Amazon Kendra（※RAG用データベース） DynamoDB（データストア） Application Load Balancer ※利用を選択した場合 コンテナイメージも弊社側管理のECRリポジトリから提供され、適宜更新される予定です。   注意点 本サービスはSCSKの複合基盤サービス、S-Cred+のオプションとして提供されており、S-Cred+の契約が必須となります。 AWS Service Catalogによるテンプレートやコンテナイメージの展開にあたり、AWSアカウントを弊社の管理基盤の管理下にする必要があり、このような仕様としております。 このような制約は有るものの、InfoWeaveは独特の特徴があるサービスとなりますので   最後に：AWS Summit Japan 2024を終えて AWS Summit Japan 2024が終わりましたね。 私は当社出展のリードとしてここ数ヶ月注力してきました。 細かい反省点は多いのですが、今はとにかく大きなトラブル無く終了できてホッとしています。 当社の出展内容は、川原さんのレポートをご覧下さい。 AWS Summit Japan 2024に出展しました！ 6月20日～21日の2日間にわたり、幕張メッセで開催されたAWS Summit Japan 2024に出展しました。SCSKはプラチナスポンサーとして、スポンサーセッションとブースを出展し、大変多くの方々にご来場いただきました！ blog.usize-tech.com 2024.06.27 私は2日間、概ねブース周辺におりました。たくさんの方に来訪いただき本当に感謝しております。 また夜はHUB周辺に出没し、いろいろな方との交流を深めることができました。 こちらでお会いした方々にも感謝したいと思います。 なお、お陰様で今年の表彰も継続して頂戴することができました。 AWS Ambassadors Japan AWS Top Engineers Japan AWS All Certfications Engineers 今回のイベントを成功させるにあたっては、社内外の皆様の協力無くしてなし得ませんでした。 この点においても感謝ですし、一個人としてはこの経験を糧に、今後も邁進して行ければと思います。 全ての皆様に御礼まで。ありがとうございました。

こんにちは。SCSK株式会社の上田です。 2024年6月4日に最新バージョンであるZabbix 7.0 LTSがリリースされ、様々な新機能が追加されました。 今回は、追加された新機能の中から、便利な機能をピックアップしてご紹介します。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 新機能の紹介 ここからは、新機能をカテゴリごとに紹介していきます。 Zabbixプロキシの新機能 大規模な環境で使われているZabbixプロキシについて、2つの新機能がリリースされました。 プロキシの負荷分散と高可用性 Zabbix 6.0ではサーバのHAが可能でしたが、7.0では プロキシもHAと負荷分散に対応 しました。 プロキシグループ という新たな概念が登場し、監視対象ホストをグループ内で自動的に分散して監視できるようになりました。 一つのプロキシがダウンした場合でも、残りのプロキシに監視を振り分けることが可能です。 プロキシのメモリバッファ 従来は必須だったヒストリデータのDB書き込みが、 プロキシメモリ内から直接Zabbixサーバに送信できる ようになりました。 保持方式は以下の3種類から選択可能です。 方式 機能 hybrid 正常時はメモリから送信、バッファフル時やプロキシ停止時はDBに書き込み memory DBへの書き込みは一切行わず、停止時のデータ保証はなし disk メモリを使用せず、従来通りDBで管理 WEB機能の追加 ZabbixのWEBインターフェース関連で、いくつかの新機能がリリースされています。 新ウィジェットの追加 新しいウィジェット が利用可能になりました。その中からいくつかを実際の画面付きでご紹介します。 ウィジェット 機能 Gauge（ゲージ） 単一アイテムの値をスピードメータ形式で表示 Pie Chart（円グラフ） 単一/複数アイテムの値を円グラフで表示 ハニカム（ハチの巣） アイテムの値を色分け可能な六角形セルで表示 新機能①：ゲージ 新機能②：円グラフ   新機能③：ハニカム 定期レポート機能の拡張 6.0で試験的に導入されていた定期レポート機能が、7.0で正式リリースとなりました。 1ページだけでなく、 複数ページのPDF出力が可能 になっています。 ブラウザ監視の追加 新しいアイテムタイプ「 ブラウザ 」が追加されました。こちらは別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 新機能検証 (ブラウザモニタリング編) Zabbix 7.0 の新機能について検証しています。今回はブラウザモニタリングでZabbixの「キュー概要」画面を監視しています。 blog.usize-tech.com 2024.06.28 多要素認証（MFA）機能の追加 Zabbixへのログインに MFA認証 が利用可能になりました。ワンタイムパスワードとDuo認証に対応しています。 こちらも別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 LTS 新機能：多要素認証機能 (Duo認証) を利用してみた 2024年6月に最新バージョンであるZabbix 7.0 LTSがリリースされました。Zabbix 7.0の新機能である、多要素認証機能（Duo認証）の利用方法をご紹介いたします。 blog.usize-tech.com 2024.06.17 パフォーマンス改善 Zabbixのパフォーマンスを向上させる改善も行われています。 ポーリングの高速化 Pollerプロセスが並列実行できるようになり、 ポーリング処理が高速化 されました。 こちらも別記事で検証しておりますので、是非ご覧ください。 Zabbix 7.0 新機能検証 (ポーリングの高速化編) Zabbix 7.0 の新機能について検証しています。今回はデータ収集処理の改善について検証しています。 blog.usize-tech.com 2024.06.18 ネットワークディスカバリの動作改善 ネットワークディスカバリの処理も並列実行できるようになり、 ネットワークディスカバリが高速化 されました。 従来と比べておよそ10倍～100倍のパフォーマンスと謳われています。 その他の追加機能 Zabbix API 経由で Zabbix サーバにデータ送信可能 history.pushメソッドを使うことで、 API経由でZabbixサーバにデータ送信可能 です。 これにより、 Zabbix agentが入っていないホスト （例えばIoTデバイスなど） でも監視を行うことが可能 になりました。 アイテム名のユーザーマクロサポート機能復活 アイテム名、アイテム プロトタイプ名で、ユーザーマクロが使える ようになりました。 こちらは、Zabbix 6.0で廃止された機能でしたが、Zabbix 7.0になって復活しました。   その他にも、いくつかの新機能が搭載しています。 詳しくは以下の公式サイトをご参照ください。 What's new in Zabbix 7.0 LTS www.zabbix.com まとめ Zabbix 7.0の新機能を紹介しました。様々な機能が追加されていますので、是非Zabbix 7.0を試してみてください。 「 Zabbix 7.0を新規にインストールしてみたい 」「 既存のZabbixからバージョンアップしたい 」という方は、こちらの記事も参考にしてみてください。 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12 Zabbix 5.0 LTS から 7.0 LTS へ簡単にバージョンアップしてみた Zabbix 5.0 LTS から 7.0 LTS へバージョンアップしてみました blog.usize-tech.com 2024.07.04 今回は概要だけでしたが、新機能を検証した記事を順次投稿していく予定です！ 最後まで読んでいただき、ありがとうございました。   最後に・・・ 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com X.com

こんにちは。SCSK株式会社の安藤です。 2024年6月4日にリリースされた最新バージョンであるZabbix 7.0 LTSへ、5.0 LTSから簡単にバージョンアップしてみたいと思います。 ※新規インストールの場合は、以下の記事を参照ください。 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、以下をご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com   バージョンアップ手順 早速、Zabbix5.0から7.0へバージョンアップしていきたいと思います。 今回の構成 今回の構成は以下のとおりです。 ZABBIX VERSION: 5.0.42 OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 8.2 DATABASE: MySQL 8.0.36 WEB/AP SERVER: Apache 2.4.37 / PHP-fpm 7.2.24 SELinux: 無効 Firewalld: 無効   関連ミドルウェアのバージョンアップ 各ミドルウェアの対応バージョンは以下の通りです。事前に、Zabbix 7.0の動作が可能なバージョンまで、バージョンアップしておく必要があります。   5.0 LTS 7.0 LTS Apache 1.3.12 or later 2.4 or later PHP 7.2.0 or later 8.0.0 – 8.3.X MySQL 5.7.X – 8.4.X 8.0.30 – 8.4.X Zabbix 7.0リポジトリの設定とZabbixのバージョンアップ Zabbix 7.0 のリポジトリを設定します。 # Zabbix 7.0 リポジトリの設定 rpm -Fvh https://repo.zabbix.com/zabbix/7.0/rhel/8/x86_64//zabbix-release-7.0-1.el8.noarch.rpm dnf clean all 次に、Zabbix関連のパッケージをバージョンアップします。 # Zabbix関連パッケージのバージョンアップ dnf update zabbix-agent zabbix-apache-conf zabbix-server-mysql zabbix-web zabbix-web-japanese zabbix-web-mysql インストールされているZabbixパッケージのバージョンを確認します。 # インストールされているZabbixパッケージのバージョンの確認 dnf list --installed |grep zabbix これだけで完了です。とっても簡単です！ Zabbix Serverのサービス再起動とデータベースのアップグレード Zabbix Serverのバージョンアップ後、Zabbix Serverのサービスを再起動すると、自動的にZabbixのデータベースのアップグレードが開始されます。データベースのアップグレード時には、ログに以下のような出力があります。 2623:YYYYMMDD:194015.890 using configuration file: /etc/zabbix/zabbix_server.conf 2623:YYYYMMDD:194015.941 current database version (mandatory/optional): 05000000/05000007 2623:YYYYMMDD:194015.942 required mandatory version: 07000000 2623:YYYYMMDD:194015.942 mandatory patches were found 2623:YYYYMMDD:194015.943 starting automatic database upgrade 2623:YYYYMMDD:194016.159 completed 0% of database upgrade 2623:YYYYMMDD:194017.273 completed 1% of database upgrade 2623:YYYYMMDD:194019.414 completed 2% of database upgrade 2623:YYYYMMDD:194021.865 completed 3% of database upgrade ・・・ 5.0 LTSのデータベースバージョン「05000000」であるのに対し、7.0 LTSの「07000000」が必要であると、出力があります。 その後、自動的にデータベースのアップグレードが開始されていることがわかります。   バージョンアップ中の挙動 バージョンアップ中に、以下のような挙動をすることがあります。 データベースのアップグレード中にWeb管理画面を表示 データベースのアップグレード中にWeb管理画面にアクセスすると、Zabbixデータベースのバージョンが要件を満たしていない旨のエラーメッセージが表示されます。 データベースのアップグレードを中断 データベースのアップグレードが中断した場合は、Zabbix Serverのサービスを再起動することで、中断した箇所からアップグレード処理が再開されます。   まとめ Zabbix5.0から7.0へのバージョンアップは、5.0→6.0→7.0と段階を踏むことなく、5.0から7.0へ、一度で簡単にバージョンアップすることができました。 最後まで読んでいただき、ありがとうございました。   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp   ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント： www.youtube.com   ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com x.com

こんにちは。SCSK 稲葉・川原・間世田です。 6月20日と21日に幕張メッセで開催された「 AWS Summit Japan 2024 」に参加してきました！本イベントは、日本最大のAWSに関する学びの場であり、2日間にわたってさまざまなセッションや展示が行われました。 私たち3名で各セッションやブースを回りましたので、その感想やレポートを共有したいと思います。 イベント概要 AWS Summit Japan 2024は、日本最大の“AWS を学ぶイベント”として、多彩なプログラムが用意されていました。 主に以下のような内容で構成されております。 基調講演 150を超えるセッション 250を超えるEXPOコンテンツ DeepRacerリーグや開発者向けワークショップ、さまざまな AWS の質問をすることができる「Ask an Expert/Ask an Speaker」   基調講演やセッションなどには、AWSを導入しているパートナー企業やユーザー企業なども参画しています。自社で導入してきたAWSの知見などを発表し、他のAWS利用者がそれを見て学ぶことができるイベントになっております。 基調講演 1日目：AWSと創る次の時代 1日目の基調講演では「AWSと創る次の時代」という題で、既に活用されているAIの活用事例について発表され、後半にはAWSの新サービスの発表も行われました。 AIの活用事例では、画像認識を使用して養殖している魚の病原体を検知したり、データの傾向から病気の予兆を検知するなどさまざまな活用事例が紹介されており、非常に興味深かったです。 また善のためのAIが強調されていて、持続可能な社会の実現に向けた人類の課題に対して、AIでどのように課題を解決するかといった内容が多かった印象です。 後半のAWSの新サービス発表では、AI系のサービスが多く発表されました。 特にClaude3の東京リージョン対応やAmazon Q Businessの日本語版対応が、会場を大きく盛りあげていました。 2日目：ビルダーとテクノロジーが加速する次のイノベーション 生成AI および AI/ML マーケット戦略担当のラフール パサック氏が登壇され、生成AIによる新しい時代を、それらの実現に向けての AWS の戦略や支援を、これまで日本のお客様と創出してきたイノベーション事例とともに紹介されました。 セッションでは、複数の業界におけるクラウドテクノロジーの革新が焦点となりました。金融業界では、SBIがインフラストラクチャをコード化し、効率化を図っています。自動車業界では、TIER 4が大量のテスト資料から開発シミュレーションを作成し、エッジコンピューティングへの展開を推進しています。通信業界では、docomoが5Gの商用展開でAWSを選定し、消費電力を大幅に削減する取り組みを行っています。 また、プロジェクトKuiperによる衛星群の運用や、ANAがAWSにデータ分析基盤を移行し、グループ全体のデータを集約・分析することで競争力を高めています。これらの事例は、データの活用が企業の競争力を飛躍的に向上させ、AIがビジネスの差別化に重要な役割を果たしていると感じました。 さらに、AWSのLLM開発支援プログラムや新しい推論コンポーネントの導入が、デジタル革命が多岐にわたる産業で進行していることが強調されました。これにより、企業は柔軟に業務を変革し、進化を続けることが可能になっています。 電通とJR東海の事例も取り上げられ、電通はAIを活用したマーケティング戦略の展開や、顧客のデータドリブンな分析を通じたサービスの最適化を進めています。一方、JR東海はリニア中央新幹線の運行管理において、地上設備からのリアルタイムデータを活用し、運行計画の最適化と運行監視の効率化を図っています。これらの取り組みは、AWSのテクノロジーを駆使してデータ中心の革新を実現し、それぞれの業界において革新的な成果をもたらしています。 セッションの締めくくりでは、ラフール氏から「あなたが作り上げるのはどんな魔法ですか？」と問いかけられました。これからもAWSを活用した革新がさらに進展し、ビジネスにおける魔法のような変革をもたらすことが期待される素晴らしいセッションでした。   セッション 1日目 Amazon Bedrockの活用によるデジタル教育サービスの生成AI機能拡張 パートナーセッション 【スピーカー】中村 寿志 氏　株式会社 学研メソッド 取締役 学研様の生成AI活用事例についてお話しされていました。 学研様では生徒が学習するためのWebシステムを運用しており、学習情報の取得や独自にチューニングした分析システムで学習情報を分析していました。 このWebシステムに対し、生成AIを活用するアイデアがお話しされていました。 学習情報を分析した結果を生成AIが生徒一人に合わせてフィードバックしたり、生徒の質問に生成AIアシスタントが対応し生徒一人ひとりに合わせたヒントを出したり、生徒に合わせた類題を提示したりとたくさんのアイデアがお話しされていました。 このセッションで機械と人間のインタフェースとして生成AIは特に有用だなと感じました。 自社データを用いた生成AIの活用事例 AWSセッション 【スピーカー】中島 佑樹氏　アマゾン ウェブ サービス ジャパン合同会社　技術統括本部 エンタープライズ技術本部 本セッションでは、生成AIの導入におけるデータの重要性と活用戦略について事例を用いて詳細に解説していました。 まず、生成AIを効果的に活用するためには、良質なデータが不可欠であり、データ適用方式として、検索拡張⽣成 (RAG)、Fine-turning、継続的事前学習の3つの方法が紹介され、それぞれのメリットや具体的な事例が示されました。 具体的な事例としては、RIZAPテクノロジーズ様が社内問い合わせ検索システムを生成AIで構築したケースが紹介されました。このシステム導入により、従業員の問い合わせ対応工数が大幅に削減され、業務効率が向上しました。また、カラクリ株式会社様がカスタマーサポート向けに誠実かつ自然な返答を提供する生成AIを3日で学習させた事例も取り上げられ、生成AIの実用性が強調されていました。 また、データ戦略の重要性について、生成AIを活用するための3つの観点が示されました。 独⾃のカスタムデータを使⽤して AI アプリケーションをする 独自データを活用して他社との差別化を図る。 既存のデータ基盤上で⽣成 AI を活⽤する 既存のデータ基盤を活用して生成AIワークロードに適用。 生成AIアプリケーションを監査する 生成AIアプリケーションの監査機能をONにして責任あるAIを実践。 特に、責任あるAIの実践には生成AIアプリケーションの監査機能をONにすることが第一歩として重要であると強調されました。AWSのリソースを活用し、透明性や公平性を確保するための具体的な方法も提供されています。 このセッションを通じて、生成AIの導入にはデータの質と戦略が非常に重要であることを再認識しました。特に、実際の事例を通じて、生成AIがどのように業務効率を向上させるかが具体的に理解できました。今後のビジネスにおいて、生成AIの活用がどのように進化し、どのように実用化されるのか非常に楽しみです。AWSの提供する多様なツールとサポートを活用することで、企業はより効率的に生成AIを導入し、競争力を高めることができるのだと思いました。 生成AIが変える、データアナリティクス AWSセッション 【スピーカー】西澤 祐介氏　アマゾン ウェブ サービス ジャパン合同会社 プロフェッショナルサービス本部 ビッグデータコンサルト 生成AIがデータアナリティクスと連携することで何ができるようになったのかお話しされていました。 生成AIとAmazonDataZoneの連携では、データの説明やデータの分析例などを出力でき、AWS Glueとの連携では、自然言語でETLジョブを作成できるとお話しされていました。 また、生成AIとAmazon Redshift クエリエディタが連携することで、自然言語からSQLを生成してデータ分析可能だとお話しされていました。 Quicksightは生成AIと連携することで多くの恩恵を受けられるとお話しされていました。 自然言語でダッシュボードや計算フィールドを作成できたり、ダッシュボードに対してQ&Aインタフェースを提供し質問できるようになると紹介されていました。他にはデータからストーリーテリングを生成できるようになると紹介されていました。 このセッションでは特にQuicksightと生成AIの連携のお話しが興味深く、今後グラフを使用して発表するときはQuicksightと生成AIをぜひとも使用したいと思いました。 AWS 環境におけるセキュリティ調査の高度化と生成 AI 活用 AWSセッション 【スピーカー】 勝原 達也氏　アマゾン ウェブ サービス ジャパン合同会社 セキュリティソリューションアーキテクト AWS環境でのセキュリティインシデント対応をどのように高度化するかについてのセッションでした。 セッションのポイントを以下にまとめました。 AWSの特性がセキュリティ分析を支える 高い可視性 ：AWSのサービスは詳細なログを提供し、システムの状態を把握しやすくしています。 柔軟な自動化機能 ：自動化により、迅速かつ効率的なインシデント対応が可能です。 Amazon GuardDuty ：脅威検知に特化したサービスで、インシデントの初期検知を担います。 Amazon Detective ：詳細なログ分析を行うサービスで、脅威の根本原因を特定します。 セッションでは、仮想的なセキュリティインシデントを通じて、どのように脅威が検知されるかを具体的に説明されていて、GuardDutyが検知する脅威の種類や、Amazon Detectiveを用いた詳細なログ分析の方法が紹介されました。具体的な脅威検知の流れとしては、次のようなプロセスが示されていました。 GuardDutyの検知 ：偵察活動、インスタンス侵害、アカウント侵害などの脅威を検知。 Detectiveでの詳細なログ分析 ：検知された脅威を基に、詳細なログ分析を実施。 生成AIの活用 ：自然言語でのクエリ生成により、分析作業が効率化。 生成AIはセキュリティ専門家を即座に置き換えるものではないですが、その活用により専⾨家は優れた成果を得ることができると述べられました。AWSのナレッジと自社固有の構成情報を基に、生成AIが優れたインサイトを提供し、セキュリティチームを強力にサポートしてくれます。 AWSのセキュリティサービスと生成AIの組み合わせにより、セキュリティ分析がより効率的かつ効果的に行える未来が見えてきたと思います。今後もAWSのセキュリティサービスの進化に注目していきたいです。 2日目 なぜ、AWS 活用のメリットを実感できないのか？ ～内製化・運用改善の考え方～ パートナーセッション 【スピーカー】浅野 佑貴氏　株式会社ＢｅｅＸ　事業開発室 AWS Partnerから見た内製化支援の活用方法のナレッジを共有するセッションでした。 まず、内製化支援の活用方法を考える前に、AWSのメリットを実感できない理由として以下が挙げられていました。 継続的な変更・改善を行うためのコスト・プロセスを確保していない 「どの様な課題を解決することに使えるアップデートか？」を考えていない 前提として、AWSを活用して実現したいことは「ビジネス環境の変化に追随し、最新IT技術を取り込む」ことです。 しかし現状は、AWSサービスのアップデートが想像以上に速く・多く、自分たちに必要なアップデートが何か見極められなかったり、継続的な構成変更を計画せず、移行初期からのメリット享受を優先してしまったりすることが多いようです。 そこから考えると、内製化を進めるためのポイントは以下となります。 改善のための専任リソース(Teams)を確保する 通常業務を行ったまま改善業務を行うことは負担が大きいです。そのため専任Teamが必要とのことですが、会社の”理解”を得ることが個人的には一番難関だと感じました。セッションでも、Teamが機能するために必要なカルチャー/会社の仕組みの整備には時間がかかるため、3つめのポイントの実践が推奨されていました。 不足する役割・スキルをサポートするパートナーとの協業 必ずしもAWSサービス固有の深い知識が必要な訳では無いです。より重要なのは、担当システムの課題がどの様な技術課題なのかを把握し、どの様な課題を解決することに使えるかを考えることです。CCoEによるナレッジ収集・共有は組織的なソリューションの一つですが、ここは専門家(AWSパートナー)のナレッジを活用することで補うことができます。 取り組みレベルは段階的に成熟させる 内製化とは自社リソースですべて実施するものではなく、どこまでを自社で行うかを見極めることが必要です。例として3段階のアプローチが挙げられており、自社で行う範囲として、Lv1：企画の一部⇒Lv2：企画+開発の一部⇒Lv3：企画から運用まで また、どのレベルが正解といったわけではなく、内製化を行うシステム・領域によってレベルを使い分けることが重要とのことでした。 弊社も内製化支援を行っており、私も支援を行った経験があったため、非常に参考となるセッションでした。 AWS技術支援 テクニカルエスコートサービス｜SCSK株式会社 テクニカルエスコートサービスはAWSの導入に関して課題に直面されているお客様にAWS認定資格保有者が参画いたします。 www.scsk.jp NTT の生成AI「tsuzumi」とともに挑む新たなチャレンジ（AWS LLM 開発支援プログラムを 用いた技術検証等） パートナーセッション 【スピーカー】爪長 美菜子氏　日本電信電話株式会社 研究開発マーケティング本部 執行役員　マーケティング部門長 NTT版LLM「tsuzumi」の紹介と活用領域、案件対応から浮き出たLLM利活用時の主な課題が伝えられたセッションでした。 「tsuzumi」の特徴として、軽量・高い言語性能・高カスタマイズ性・マルチモーダル性を挙げていました。特にパラメタサイズは、GPT-3の1/25である7Bサイズと非常に軽量のようです。驚くべきことに、「図表・イラストの読解（infoVQA）」と「複数画像の複合読解（SlideVQA）」ではGPT-3.5、GPT-4を凌ぐ精度となっていました。 LLM利活用時の主な課題として「精度」・「精度のゴール設定」・「データ整備」の三本を挙げていました。 精度 精度40%〜70％から出発すること チャンキング、検索手法の精査、pre-retrieval等で精度向上が必要であること 精度のゴール設定 PJ開始時に精度の定義合わせが重要であること データ整備 フォーマットの違い等でのデータ整備にコストがかかる PoCを行っている方も多いですが、データ整備に課題を感じている方も多いのではないでしょうか。 私もデータ整備を行ってくれる生成AIないかなぁ〜と日々感じています… 余談ですが、セッション冒頭で名前の由来も話されており、「雅楽で用いられる鼓が演奏の流れを統率する役割を担っていることになぞらえ、これからの自然言語処理技術の発展をリードしていく存在をめざす」とのことでした。日本らしく、素敵な名前です。 AIアプリ開発プロジェクトの始め方 AWSセッション 【スピーカー】⼤渕 ⿇莉氏　アマゾン ウェブ サービス ジャパン合同会社　サービス&テクノロジー事業統括本部 セッションの冒頭では、AIの基本的な概念とそれらの違いについてお話されていて、特に生成AIについては、テラバイト規模のデータで学習し、追加学習なしに人間と同等のコンテンツ生成能力を持つことが強調されました。AIの最大の特徴として「AIは間違えることがある（精度100%にはならない）」という点が挙げられ、入力が決まれば出力の「予測値」が決まるため、単純なロジックでは計算できない現象を予測する際に使われることが多く、必ず誤差が生じることが説明されました。 また、生成AIは、プロンプトエンジニアリングを通じて多様な表現形式や応答の微調整が可能です。しかし、プロンプトが肥大化する場合にはファインチューニングの検討が必要となります。 AIを自社アプリに組み込む具体的なステップは以下になります。 課題のフレーミング データ処理 モデル開発 モデルのデプロイ モデル性能監視 ビジネスゴールがないと、評価指標や評価データを作れず、AIが正しく機能しているかを評価できないため、ビジネスゴールの設定が非常に重要になります。 安全で信頼性の高い生成AIソリューションの実現には、生成AIを利用する際の入出力データの適切性を確保するためのガードレールやモデレーション機能が重要です。Amazon Bedrock や Amazon Rekognition などのAWSサービスを活用することで、より安全で信頼性の高い生成AIソリューションを構築することが可能となります。 このセッションを通じて、AIアプリ開発プロジェクトの始め方と、従来のAIと生成AIの違い、AWSが提供する豊富なAIサービスについて深く理解することができました。特に、ビジネスゴールの設定の重要性や、適切なAIサービスの選択が成功の鍵であると感じました。AWSのAIサービスを活用することで、AIアプリ開発がより身近で現実的なものになると感じました。 チームのつながりをInfrastructure as Codeでデザインする AWSセッション 【スピーカー】高野 賢司氏　アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジック製造グループ チームがDevOpsできるようになるにはどのような障壁を乗り越えないといけないのかというお話でした。 従来の分断されたチームでは、それぞれのチームがタスクの完了だけに注目し、フィードバック受け取って改善しなくなるという問題点がありました。 目標とするDevOpsできるチームは、コードをコミュニケーションの中心に置くことでフィードバックに基づいた継続的な改善を行うことができるチームとお話しされていました。 目標達成するためにはインフラストラクチャをコードで管理すること、バージョン管理ツールでコードを管理すること、チーム全員がコードを理解できることなどが挙げられていました。 DevOpsをできるようになるまでの手順を段階的に紹介されていたので非常に勉強になりました。 Amazon CodeCatalyst と Amazon Q で開発者の生産性を向上！ – AI アシスタントの活用方法 – AWSセッション 【スピーカー】柳久保 友貴氏　アマゾン ウェブ サービス ジャパン合同会社 デジタルサービス技術本部 ISV/SaaSソリューション部 昨年11月のアップデートにて、Amazon CodeCatlyst での Amazon Q によるソフトウェア開発タスク支援が発表されており、本セッションではそのデモンストレーションが行われました。 Amazon CodeCatalyst、Amazon Q の機能開発 (プレビュー版) を発表 aws.amazon.com 具体的にはAmazon Q によって、単体テストの作成やPull Requestのコメント作成・レビューコメントの要約等です。驚くべきこと「Title」欄に一文記入するだけで、前述の処理の作成を行ってくれていました。エンジニア初心者でも簡単にアプリケーション作成を行えるでしょう。（生成AIのコードの正確性の理解は必要ですが。） また、「レビューコメント」の作成によって、大規模変更の際に大きくエンジニアの負担を減らすことができます。今までは大きな変更の際、差分が多くなってしまい、そのすべてを確認し、理解する必要がありました。この機能により、エンジニアの負担を大幅に削減することができます。 データセンターのラックぜんぶ抜く！SCSKだからできる脱オンプレの秘策とは？ パートナーセッション 【スピーカー】岸岡 学氏　ＳＣＳＫ株式会社　クラウドサービス事業本部 事業推進部 クラウド営業課長 髙島 豊徳氏　沖電気工業株式会社 常務理事 情報責任者 本セッションでは、沖電気工業株式会社（OKI）のCIOである高島様と共に、実際のクラウド移行プロジェクトの具体的な取り組みと成功の秘訣について語られました。クラウドのメリットを理解し活用を進めようとする企業は多いものの、さまざまな理由で踏みとどまっている企業が多く存在するのが現実です。2日目の最後のセッションにもかかわらず、多くの方々が来場していて、クラウド移行に関する関心の高さを感じました。 沖電気工業株式会社様は広範な事業領域と高いセキュリティ要件を持つため、膨大な業務システムのクラウド移行には多くの課題がありました。特に、事業ごとに異なるシステム要件や古いシステムのモダナイズ、クラウド移行が難しいシステムが存在していました。さらに、2026年までに約800台のサーバ（100ラック相当）を含む現行データセンターの移転・移行が必要で、クラウド利用促進とシステム刷新を同時に進める必要がありました。 この課題に対し、ハード面、ソフト面、マネジメント面の三位一体のアプローチが成功の鍵となりました。 ハード面（設備/体制） 最新データセンター、自社プライベートクラウドとAWSへの直接コネクティビティを提供し、営業・技術一体となったデリバリ体制を整備したこと ソフト面（技術/サービス） オンプレミスも把握しているAWSスペシャリストによる全体計画、プロジェクト推進、最新技術への追随とAWS社と共同で立ち上げた移行アセスメント、移行仕分け、移行作業パッケージを利用した迅速で安心安全な移行 マネジメント面 当初の目的を定期的に経営レベルで見直し、共通ゴールをぶらさずに、現場メンバーがプロジェクトに専念できることを最優先したこと 今後は、クラウドシフト/サーバレス化、そしてアプリケーションのモダナイゼーションを目指しています。 今回のセッションを通じて、SCSKとOKI様がどのようにしてデータセンターの完全移行を実現したか、その具体的な施策と成功の秘訣を深く理解することができました。特に、SCSKのAWSに対する深い理解と高い技術力が、脱オンプレミスを実現する上で不可欠な要素であると強く感じました。 SCSKは、AWS戦略協業パートナーとして、トータルサポートを提供していて、豊富なサービスメニューと延べ2000を超えるAWS認定技術者が、お客様のクラウドジャーニーを最適なルートで案内しています。Lift & Shiftフェーズでの課題に対して、これまで培ったノウハウを活かし、ビジネスに必要なITサービスをフルラインナップで提供することができます。 クラウド移行を考えている企業にとって、今回のセッションは非常に参考になる内容でした。SCSKの技術力とサポート体制により、多くの企業が安心してクラウドへの移行を進めることができると確信しました。   EXPO AWS DeepRacer 白熱の戦いが繰り広げられていました。私が観戦したときは8秒台が決勝ラインでしたが、最終結果はどうなったのでしょう…？   AWS Village 生成AI・Developer・Industry・セキュリティのテーマごとに4つのエリアに分かれて、様々なソリューションの個々の基本的な機能から選定や組み合わせまで、実際に動くデモを見ながら学ぶことができました。 個人的に一番テンションがあがったのが、「 AWS Snowball Edge 」の展示でした。 他の方のレポートを見ると、触ったり持つこともできたようです。（持ち上げたかった！！！） 認定者ラウンジ AWS 認定ごとにシールがもらえました。品切れのため1枚しか貰えなかったので、来年は早めにラウンジへ行こうと思います。 その他の思い出 基調講演前に、田中知之（FPM）氏がウエルカムDJパフォーマンスを披露されており、厳かでありながら魅惑的かつ高揚感高まるステージでした。 （氏のRemix作品である、三日月サンセット -FPM EVERLUST Mix- を聞きながらこのレポートを書いていますが、最高です。） 先着でお弁当とクッションがもらえました。AWS Summitを通じて、クッションにはお世話になりました。 感想 疲れを忘れるぐらい、刺激的で素晴らしい体験でした。生成AIという技術革新の時代に生まれたことに改めて高揚感が高まっています。また、多くの企業がAWSを活用して次々と革新的なソリューションを生み出している様子を目の当たりにし、そのエネルギーを肌で感じることができました。 AWS Summit Japanは、素晴らしい学びを提供し、多くの人々にインスピレーションと知見を与える有意義な場でした。これからもAWSへの学びを深めていきたいです！ 来年のAWS Summit開催を楽しみに待ちたいと思います！

こんにちは、広野です。 本題だけ挨拶抜きで冒頭に話します。本記事では、Amazon API Gateway と Amazon SES を Lambda 抜きで 連携する方法を紹介します。 はじめに 先月、AWS Summit Japan 2024 が開催されました。その中で、印象に残った AWS さんのセッションがありました。 「サーバーレス開発のベストプラクティス～より効果的に、より賢く使いこなすために～」 このセッションでは、サーバーレス開発のアーキテクチャ事例を数多く紹介してくれて非常に有用だったのですが、特に印象に残ったのは 「 AWS サービス間をプロキシするだけの Lambda 使用はやめましょう 」 というようなメッセージでした。 常々、私はサーバーレス開発において、コードやランタイムのメンテが必要になる AWS Lambda 関数が乱立することを負担に感じていました。また、昨今のアーキテクチャ時流では AWS Step Functions が AWS サービスの API を直接叩けるようになったり、Amazon EventBridge を活用したサービス間連携アーキテクチャの台頭があったりして、「とりあえず Lambda」から「脱 Lambda」に変わってきています。 そういう意味で、このメッセージには非常に共感を持つことができました。セッションでは Amazon API Gateway から 他の AWS サービスの連携も Lambda 関数抜きで行うアーキテクチャを紹介しており、やってみたくなりました。 私が題材に選んだのは、 Amazon API Gateway と Amazon SES の直接連携 です。現在主流のアーキテクチャでは、メールを送信する AWS Lambda 関数がメールのコンテンツを加工し、Amazon SES の API を叩く役割を持っています。しかしながら、加工と言っても文字列をちょこっといじるだけのようなもので、何らビジネスロジックがないケースが多いのではないかと思います。であれば、AWS Lambda 関数はいらんだろう！ということでチャレンジしたくなりました。 やりたいこと 本記事で紹介するアーキテクチャは、以前 jQuery でメール送信 API を叩くアーキテクチャを紹介した記事をベースにしています。その記事ではメール送信 API を Amazon API Gateway + AWS Lambda + Amazon SES で作成していたので、そこから Lambda を抜く！部分にフォーカスして執筆いたします。 ベースとなるアーキテクチャ、技術情報は以下リンクをご覧下さい。 フリーの HTML テンプレートと AWS を使って問い合わせフォーム付きサーバーレス WEB サイトをつくってみよう 本記事では、静的WEBサイトに jQuery で動的な機能を付加する例を紹介します。 blog.usize-tech.com 2022.07.14 前回記事の構成から Amazon API Gateway REST API は Amazon SES との直接連携をサポートしている。統合タイプの設定は AWS を選択する。 公開 WEB サイトの問い合わせフォームで使用するため、ユーザ認証はない。CORS はある。 CORS でハマるのが嫌なので、AWS CloudFormation でデプロイする。 WEB サイトから送信するデータは以下の JSON フォーマットとなっている。 { "subj": "件名", "name": "名前", "email": "xxx@xxxxxxx.com", "body": "問い合わせメッセージ本文" } 従来、このデータを AWS Lambda 関数にパススルーして、文字列加工したデータを Amazon SES に渡していた。AWS Lambda 関数がやっていたことは Amazon API Gateway REST API の「統合リクエスト」内、「マッピングテンプレート」で肩代わりさせる。 マッピングテンプレートは VTL (Velocity Template Language) で定義する。(AWS AppSync では多用するので AppSync 信者にはお馴染み) Amazon SES の API は SendEmail を使用する。 マッピングテンプレートをどう書くか AWS Lambda 関数でやっていたことを Amazon API Gateway のマッピングテンプレートに肩代わりさせるので、そこが肝になります。イメージしてもらいやすくするため、AWS Lambda 関数と対比して紹介します。 AWS Lambda 関数 細かい違いはあれど、だいたい以下のような AWS Lambda 関数 (Python) で Amazon SES を呼び出すと思います。 import json import datetime import boto3 def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: # Define Variables ses = boto3.client('ses',region_name='ap-northeast-1') d = json.loads(event['body']) print({"ReceivedData": d}) RECEIVERS = [] RECEIVERS.append('xxxxx@xxxxxxx.xxxx') SENDER = 'xxxxxx@xxxxx.xxxxxx' # Send Email res = ses.send_email( Destination={ 'ToAddresses': RECEIVERS }, Message={ 'Body': { 'Text': { 'Charset': 'UTF-8', 'Data': 'NAME: ' + d['name'] + '\nMAILADDRESS: ' + d['email'] + '\n\nMESSAGE:\n' + d['body'] } }, 'Subject': { 'Charset': 'UTF-8', 'Data': d['subj'] } }, Source=SENDER, ReplyToAddresses=[d['email']] ) except Exception as e: print(e) return { 'isBase64Encoded': False, 'statusCode': 200, 'body': str(e) } else: return { 'isBase64Encoded': False, 'statusCode': 200, 'body': json.dumps(res, indent=4, default=datetimeconverter) } マッピングテンプレート マッピングテンプレートだと、以下のようになります。 ## API Gateway が受け取った引数を $inputRoot に格納する #set($inputRoot = $input.path('$')) ## メール本文の文字列加工 改行を入れたければここでリアルに改行すればよい(かなり違和感を感じるw) #set($tempbodya = "NAME: $inputRoot.name MAILADDRESS: $inputRoot.email MESSAGE: $inputRoot.body") ## Windows 環境からだと改行コードが CRLF で来ることがあるので、LF に置換しておく #set($tempbodyb = $tempbodya.replaceAll("\r\n", "\n")) ## メール本文は URL エンコードすること #set($body = $util.urlEncode($tempbodyb)) ## メールアドレスは URL エンコードすること #set($destination = $util.urlEncode("xxxxx@xxxxx.xxx")) #set($replyto = $util.urlEncode($inputRoot.email)) #set($source = $util.urlEncode("xxxxx@xxxxxx.xxxx")) ## 件名はエンコードしなくてよい、なぜか。エンコードするとエラーになる。改行が入っても通った。謎。 #set($subject = $inputRoot.subj) ## SES API 呼出はこのフォーマットで書く URL の続きに?付きでパラメータ指定するのと同じ形式 Action=SendEmail&Destination.ToAddresses.member.1=$destination&Message.Body.Text.Data=$body&Message.Subject.Data=$subject&ReplyToAddresses.member.1=$replyto&Source=$source AWS Lambda 関数では、URL エンコードなんて一切意識していなかったと思います。AWS が提供してくれる SDK がいい感じにデータを加工してくれていたものと思います。VTL は低級言語？なのか SDK をロードできないですし、組み込み関数も少ないです。ただ URL エンコードする関数 ($util.urlEncode) は用意してくれているので助かりました。 URL エンコードが必要な理由は、マッピングテンプレートから Amazon SES SendEmail API を呼び出すときに API の URL に続けてパラメータを書いて渡すためです。(想像) URL には使用してはいけない文字列、記号があり、UTF-8 の文字コードの文字列を URL で使用できる文字列、記号の範囲内におさまるようにエンコードする必要があります。それが URL エンコードです。 例えば、メールアドレスの @ は使えませんし、改行、日本語なんてもってのほかです。@ は %40 に、改行(\n) は %3A に置き換えられます。 メールの To だけでなく、Cc、Bcc ももちろん設定可能です。これらは複数指定できますが、仕様でそれぞれ 50 個までしか指定できません。To を複数指定するときは、Destination.ToAddress.member.1= のような記述を1始まりで50まで羅列させます。配列が使用できないので、このような書き方になります。AWS Lambda 関数では配列で SDK に渡していたので意識しなかった部分です。 VTL ではダブルクォーテーションとシングルクォーテーションで動きが異なるので、このサンプルコードにあるクォーテーションのまま使用することをお勧めします。 ここまで動く状態に到達するのに、情報が少なくて結構苦労しました。 他にも Amazon API Gateway の設定はあるのですが、メインはマッピングテンプレートでしたので、AWS CloudFormation テンプレートのところで補足いたします。 実際の動作 WEB サイトの問い合わせフォームから、問い合わせを送信します。 こんなメールが予め設定しておいた送信先メールアドレスに届きます。 AWS CloudFormation テンプレート 前回記事で紹介した AWS CloudFormation を修正したものを貼り付けます。一式、Amazon CloudFront や Amazon S3 なども含まれています。一応執筆時点で動いたことは確認済みです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a static website hosting environment with a backend API for receiving emails from feedback form. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SiteName: Type: String Description: Your Site name. (Not any upper case characters) Default: xxxxx MaxLength: 40 MinLength: 1 DomainName: Type: String Description: Domain name for URL. Default: example.com MaxLength: 100 MinLength: 5 AllowedPattern: "([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" SubDomainName: Type: String Description: Sub domain name for URL. Default: xxxxx MaxLength: 20 MinLength: 1 FeedbackSenderEmail: Type: String Description: E-mail address that sends feedback emails. Default: sender@example.com MaxLength: 100 MinLength: 5 AllowedPattern: "[a-zA-Z0-9_+-]+(.[a-zA-Z0-9_+-]+)*@([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" FeedbackReceiverEmail: Type: String Description: E-mail address that receives feedback emails. Default: receiver@example.com MaxLength: 100 MinLength: 5 AllowedPattern: "[a-zA-Z0-9_+-]+(.[a-zA-Z0-9_+-]+)*@([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" CertificateId: Type: String Description: ACM certificate ID. CloudFront only supports ACM certificates in us-east-1 region. Default: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx MaxLength: 36 MinLength: 36 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub website-${SiteName} PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub website-${SiteName} S3BucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3Bucket PolicyDocument: Version: "2012-10-17" Statement: - Action: - "s3:GetObject" Effect: Allow Resource: !Sub "arn:aws:s3:::${S3Bucket}/*" Principal: Service: cloudfront.amazonaws.com Condition: StringEquals: AWS:SourceArn: !Sub arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution} DependsOn: - S3Bucket - CloudFrontDistribution # ------------------------------------------------------------# # CloudFront # ------------------------------------------------------------# CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true Comment: !Sub CloudFront distribution for website-${SiteName} Aliases: - !Sub ${SubDomainName}.${DomainName} HttpVersion: http2 IPV6Enabled: true PriceClass: PriceClass_200 DefaultCacheBehavior: TargetOriginId: !Sub S3Origin-website-${SiteName} ViewerProtocolPolicy: redirect-to-https AllowedMethods: - GET - HEAD - OPTIONS CachedMethods: - GET - HEAD CachePolicyId: !Ref CloudFrontCachePolicy OriginRequestPolicyId: !Ref CloudFrontOriginRequestPolicy ResponseHeadersPolicyId: !Ref CloudFrontResponseHeadersPolicy Compress: true SmoothStreaming: false DefaultRootObject: index.html CustomErrorResponses: - ErrorCachingMinTTL: 10 ErrorCode: 403 ResponseCode: 404 ResponsePagePath: /404.html Origins: - Id: !Sub S3Origin-website-${SiteName} DomainName: !Sub ${S3Bucket}.s3.${AWS::Region}.amazonaws.com OriginAccessControlId: !GetAtt CloudFrontOriginAccessControl.Id S3OriginConfig: OriginAccessIdentity: "" ConnectionAttempts: 3 ConnectionTimeout: 10 ViewerCertificate: AcmCertificateArn: !Sub "arn:aws:acm:us-east-1:${AWS::AccountId}:certificate/${CertificateId}" MinimumProtocolVersion: TLSv1.2_2021 SslSupportMethod: sni-only Tags: - Key: Cost Value: !Sub website-${SiteName} DependsOn: - CloudFrontCachePolicy - CloudFrontOriginRequestPolicy - CloudFrontResponseHeadersPolicy - CloudFrontOriginAccessControl - S3Bucket CloudFrontOriginAccessControl: Type: AWS::CloudFront::OriginAccessControl Properties: OriginAccessControlConfig: Description: !Sub CloudFront OAC for website-${SiteName} Name: !Sub OriginAccessControl-website-${SiteName} OriginAccessControlOriginType: s3 SigningBehavior: always SigningProtocol: sigv4 CloudFrontCachePolicy: Type: AWS::CloudFront::CachePolicy Properties: CachePolicyConfig: Name: !Sub CachePolicy-website-${SiteName} Comment: !Sub CloudFront Cache Policy for website-${SiteName} DefaultTTL: 3600 MaxTTL: 86400 MinTTL: 60 ParametersInCacheKeyAndForwardedToOrigin: CookiesConfig: CookieBehavior: none EnableAcceptEncodingBrotli: true EnableAcceptEncodingGzip: true HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryStringsConfig: QueryStringBehavior: none CloudFrontOriginRequestPolicy: Type: AWS::CloudFront::OriginRequestPolicy Properties: OriginRequestPolicyConfig: Name: !Sub OriginRequestPolicy-website-${SiteName} Comment: !Sub CloudFront Origin Request Policy for website-${SiteName} CookiesConfig: CookieBehavior: none HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryStringsConfig: QueryStringBehavior: none CloudFrontResponseHeadersPolicy: Type: AWS::CloudFront::ResponseHeadersPolicy Properties: ResponseHeadersPolicyConfig: Name: !Sub ResponseHeadersPolicy-website-${SiteName} Comment: !Sub CloudFront Response Headers Policy for website-${SiteName} SecurityHeadersConfig: ContentSecurityPolicy: ContentSecurityPolicy: !Sub >- default-src 'self' *.${DomainName}; img-src 'self' *.${DomainName} data: blob:; style-src 'self' *.${DomainName} fonts.googleapis.com; font-src 'self' *.${DomainName} fonts.gstatic.com; script-src 'self' *.${DomainName} 'unsafe-inline'; script-src-elem 'self' *.${DomainName}; connect-src 'self' *.${DomainName} *.amazonaws.com; Override: true ContentTypeOptions: Override: true FrameOptions: FrameOption: DENY Override: true ReferrerPolicy: Override: true ReferrerPolicy: strict-origin-when-cross-origin StrictTransportSecurity: AccessControlMaxAgeSec: 31536000 IncludeSubdomains: true Override: true Preload: true XSSProtection: ModeBlock: true Override: true Protection: true CustomHeadersConfig: Items: - Header: Cache-Control Value: no-store Override: true # ------------------------------------------------------------# # Route 53 # ------------------------------------------------------------# Route53RecordIpv4: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub ${SubDomainName}.${DomainName}. Type: A AliasTarget: HostedZoneId: Z2FDTNDATAQYW2 DNSName: !GetAtt CloudFrontDistribution.DomainName DependsOn: - CloudFrontDistribution Route53RecordIpv6: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub ${SubDomainName}.${DomainName}. Type: AAAA AliasTarget: HostedZoneId: Z2FDTNDATAQYW2 DNSName: !GetAtt CloudFrontDistribution.DomainName DependsOn: - CloudFrontDistribution # ------------------------------------------------------------# # API Gateway # ------------------------------------------------------------# RestApiSendEmail: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub SendEmail-website-${SiteName} Description: !Sub REST API to send user's feedback email for website-${SiteName} EndpointConfiguration: Types: - REGIONAL Tags: - Key: Cost Value: !Sub website-${SiteName} RestApiDeploymentSendEmail: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApiSendEmail DependsOn: - RestApiMethodSendEmailPost - RestApiMethodSendEmailOptions RestApiStageSendEmail: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApiSendEmail DeploymentId: !Ref RestApiDeploymentSendEmail MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Sub website-${SiteName} RestApiResourceSendEmail: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApiSendEmail ParentId: !GetAtt RestApiSendEmail.RootResourceId PathPart: sendemail RestApiMethodSendEmailPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiSendEmail ResourceId: !Ref RestApiResourceSendEmail HttpMethod: POST AuthorizationType: NONE Integration: Type: AWS IntegrationHttpMethod: POST Credentials: !GetAtt ApigSesInvocationRole.Arn Uri: !Sub arn:aws:apigateway:${AWS::Region}:email:action/SendEmail PassthroughBehavior: WHEN_NO_TEMPLATES RequestParameters: integration.request.header.Content-Type: "'application/x-www-form-urlencoded'" RequestTemplates: application/json: !Sub - |- #set($inputRoot = $input.path('$')) #set($tempbodya = "NAME: $inputRoot.name MAILADDRESS: $inputRoot.email MESSAGE: $inputRoot.body") #set($tempbodyb = $tempbodya.replaceAll("\r\n", "\n")) #set($body = $util.urlEncode($tempbodyb)) #set($destination = $util.urlEncode("${FeedbackReceiverEmail}")) #set($replyto = $util.urlEncode($inputRoot.email)) #set($subject = $inputRoot.subj+"(${SubDomainName}.${DomainName})") #set($source = $util.urlEncode("${FeedbackSenderEmail}")) Action=SendEmail&Destination.ToAddresses.member.1=$destination&Message.Body.Text.Data=$body&Message.Subject.Data=$subject&ReplyToAddresses.member.1=$replyto&Source=$source - {} IntegrationResponses: - StatusCode: 200 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 400 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 403 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 404 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 500 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 503 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" MethodResponses: - StatusCode: 200 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 400 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 403 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 404 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 500 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 503 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true RestApiRequestModelSendEmail: Type: AWS::ApiGateway::Model Properties: ContentType: application/json RestApiId: !Ref RestApiSendEmail Schema: |- { "$schema": "http://json-schema.org/draft-04/schema#", "title": "SendEmail", "type": "object", "properties": { "subj": { "type": "string" }, "name": { "type": "string" }, "email": { "type": "string" }, "body": { "type": "string" } }, "required": ["subj", "name", "email", "body"] } RestApiMethodSendEmailOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiSendEmail ResourceId: !Ref RestApiResourceSendEmail HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigSesInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" ResponseTemplates: application/json: '' StatusCode: 200 PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: 200 # ------------------------------------------------------------# # API Gateway SES Invocation Role (IAM) # ------------------------------------------------------------# ApigSesInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigSesInvocationRole-website-${SiteName} Description: This role allows API Gateways to invoke SES. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess Policies: - PolicyName: !Sub ApigSesInvocationPolicy-website-${SiteName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "ses:SendEmail" Resource: - "*" # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: APIGatewayEndpointSendEmail: Value: !Sub https://${RestApiSendEmail}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStageSendEmail}/sendemail SiteURL: Value: !Sub https://${SubDomainName}.${DomainName} Amazon API Gateway を CORS 対応にしているので、レスポンスのところで CORS 関連の設定が多くなっています。ヘッダー関連の設定はあまりいじらない方がよいと思います。 統合リクエストの設定で、HTTP ヘッダーに Content-Type: ‘application/x-www-form-urlencoded’ を設定しています。こうしないと動きませんでした。 このテンプレートが動作する前提はいろいろあるのですが (すいません) 前回記事から追加していることだけ。Amazon API Gateway のログを Amazon CloudWatch Logs に push するために必要な IAM ロールがアカウントに登録済みでないとエラーになります。それについては以下の記事をご確認ください。 Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロールはアカウント単位の設定です Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロール設定を紹介します。 blog.usize-tech.com 2024.07.01 まとめ いかがでしたでしょうか？ 正直に申しますと、意気込んでやってはみたものの、 AWS Lambda 関数抜きの Amazon SES SendEmail API 呼出は絶対に流行らない と確信しました。VTL の使い勝手が Python に比べて悪すぎるのと、SendEmail 呼出だと文字列のエンコードというデリケートな部分があるためです。気を遣わなくて済む AWS Lambda の方が楽です。でも、せっかく作ったので私はこの方法を使おうと思います。他人にはお勧めしませんが。w ですがこの例は、Amazon API Gateway から Amazon SES でない、他の AWS サービスへの直接連携の参考になるかもしれません。 本記事が皆様のお役に立てれば幸いです。 最後に補足です。Amazon SES からメール送信するときは、Gmail と Yahoo Mail が実装した送信者要件を満たさないとそれらにはメールが届かない恐れがあります。Amazon SES 側で必要な設定があるので、要注意です。私も実装しました。 Yahoo/Gmail におけるメールの一括送信者に求められる要件の変更について | Amazon Web Services Gmail と Yahoo Mail は、ユーザーの受信トレイを保護するための取り組みとして、2024 年 2 月から送信者に関する新たな要件を発表しました。これらの要件を満たすために Amazon Simple Email Service... aws.amazon.com

こんにちは。SCSK渡辺(大)です。 AWS初心者なので、AWS Summit Japan 2024 は異世界に転生したような気持ちで楽しむことが出来ました。 今回は、 Amazon EC2 のコスト効率化に関する推奨事項を提供するサービス   を整理してみました。 そろそろ夏なので、熱中症にならないように暑苦しいコストは削っていきましょう。 ※当記事では、Amazon EC2 インスタンス ＝ EC2 としています。 EC2のコストを削減する方法 まずはじめに、EC2のコストを削減する方法を考えてみます。 無駄な待機課金をなくすために、稼働スケジュールを見直す。 コストを抑えて利用するために、Reserved Instances/Savings Plans（RI/SP）を購入する。 最適な使用率にするために、インスタンスサイズを小さくする。   推奨事項を確認できるサービスとコスト削減方法の関係性 推奨事項を確認できるサービスとコスト削減方法の関係性は次の通りです。 推奨事項を確認できるサービス 関連するコスト削減方法 Trusted adviser a,b Compute Optimizer c Billing and Cost Management サイズ適正化に関する推奨事項 c Cost Optimization Hub a,b,c Reserved Instances b Savings Plans b   注意点 すべての推奨事項を実施したとしても、すべての恩恵を受けることが出来るわけではありません。 勘違いしたままだと「思ってた効果が得られなかった！」と悲しい思いをします。 なぜそのようなことになるのか？ 理由は２つあります。 各サービスの推奨事項は競合します。 理由は言葉にすると難しいので、イメージ図を参照ください。 なお、Cost Optimization Hubは敢えて図に入れていません。   確認する日によって推奨事項の内容は変わります。 理由は単純で、ルックバック期間がズレるためです。 ルックバック期間とは”過去のデータを何日前まで遡って推奨事項を出すかを決める期間”です。 イメージ図はルックバック期間が60日間の場合です。   おすすめのロードマップ では、どうしたら良いか？ 次のように段階を踏んでいくことで効率良くコスト削減できるかと思います。 （あくまで自論です。コスト削減に答えはありません！） RI/SP購入 まずは推定削減額の大きいものから実施します。 ただし、RI/SPの購入しすぎは効果が不明瞭になったり、 アカウントを解約したいのに有効期限前のRI/SPが大量に残ったりするリスクがありますので、 1年後や3年後の利用状況を見据えて計画することが重要です。 Trusted adviseやCompute Optimizerの設定見直し ルックバック期間などの設定を見直し、推奨事項の精度を向上させます。 推奨事項の再確認 見直した設定が反映され、競合が収まる頃（RI/SP購入から3か月ほど経過した後）に再確認します。 その中から簡単に実施出来る推奨事項を実施します。 継続的なコスト削減の運用化 1と3を繰り返し継続的なコスト削減を図ります。 また、必要に応じて、2の設定見直しも実施します。   EC2のコスト効率化に関する推奨事項を提供するサービス 続いて、EC2のコスト効率化に関する推奨事項を提供するサービスを見てみましょう。 なお、当記事ではサービスの概要と確認画面にフォーカスし、推奨事項の細かい説明は煩雑になるため割愛します。 Trusted adviser 各種リソースのベストプラクティスを支援してくれるサービスです。 AWS自体の知見と利用状況を組み合わせて分析してコスト最適化の推奨事項を提案してくれます。 コスト最適化の他にも、パフォーマンスやセキュリティなどの最適化の観点で推奨事項を提案してくれます。 推奨事項は次の画面から確認することができます。 Trusted adviser　＞　コスト最適化　＞　「即時の対応が推奨されるアクション」または「調査が推奨されます」を選択 Compute Optimizer 各種リソースの最適化に関する推奨事項を提案してくれるサービスです。 CPU使用率などのメトリクスを分析してコスト最適化の推奨事項を提案してくれます。 推奨事項は次の画面から確認することができます。 Compute Optimizer　＞　ダッシュボード 下にスクロールします。 EC2 インスタンス　＞　過剰なプロビジョニング Billing and Cost Management Billing and Cost Management は請求とコストの最適化に役立つ機能を提供するサービスです。 利用状況を分析してコスト最適化の推奨事項を提案してくれます。 サイズ適正化に関する推奨事項 こちらはレガシーページのためAWS推奨ではありませんが、2024年7月時点でまだ確認できるためご紹介します。 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　レガシーページ　＞　規模の適正化　＞　サイズの適正化に関する推奨事項   Cost Optimization Hub Cost Optimization HubはAWS推奨です。 Compute Optimizerなどの推奨事項を一元化してくれます。 つまり、「各サービスの推奨事項は競合します。」という注意点は、このサービスが解消してくれます。 「じゃあ、これだけ見れば良くないか？」と思うかもしれませんが、全てのリソースをサポートしているわけではありません。 ですので、他のサービスと併せて確認するのが良いかと思います。 なお、”サポートされているリソース”については、 ユーザーガイド をご確認ください。 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　コスト最適化ハブ Reserved Instances 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　予約　＞　推奨事項 Savings Plans 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　Savings Plans　＞　推奨事項 まとめ お手軽にコスト削減の推奨事項を確認したい場合は、Cost Optimization Hubだけを確認することをオススメします。 全ての無駄コストを根絶やしにしたい場合は、その他のサービスの推奨事項も確認する必要があります。 当記事では推奨事項の細かい説明は割愛してしまったので、物足りない方は「AWS EC2 コスト最適化」で検索してみてください！ AWS EC2 コスト最適化 検索

こんにちは。SCSKの田中です。 本記事では、ランサムウェア対策の最後の砦ともいえるバックアップの重要性やポイントについてご紹介します。 なお本投稿の前段にあたる投稿は以下のリンクよりご覧いただけます。 「ランサムウェアに気をつけろ！基礎知識と安全対策のポイント」 また、USiZEでは新たにオプションサービス：ランサムウェア対応サービスをリリースいたしました。 USiZE、ランサムウェア対応サービスにご興味を持っていただけた方は、以下ページをご参照ください。 USiZEについて ランサムウェア対応サービスに関するプレスリリース ランサムウェアの脅威 最近、人気動画サイトが被害を受けたことで話題となったように、ランサムウェアによる脅威が企業を脅かしています。 VPN機器の脆弱性やRDP通信の認証情報を悪用して、システム全体に攻撃が広がり、甚大な被害を及ぼしています。 以下はシステム全体に被害が拡大した事例です。 どちらもシステムが停止し、事業継続に大きな影響を与えました。 事例1：名古屋港のコンテナターミナルシステムの事例 　 ・ 感染経路 　 　　VPN 機器からの侵入が行われたと考えられている ​ 　・被害 　　　・ 物理サーバ8台、および全仮想サーバ45台が暗号化されました。 　　　・ システムが停止し、約3日間コンテナ搬出・搬入業務が停止しました。 事例2： ​ 大阪急性期・総合医療センター 　・ 感染経路 　　　給食事業者が設置するシステムにVPN機器から侵入が行われ、窃取された認証情報によりRDP通信を用いて、 　　　病院給食サーバに侵入しました。そして病院給食サーバを踏み台に、他サーバへも被害が拡大 　・ 被害 　　　・ 基幹システムサーバの大部分が暗号化、電子カルテシステムが暗号化された影響で長期間診療制限​ 　　　・ 基幹システムが再稼働するまで43日間、部門システムを含めた全体の診療システム復旧は73日間 また「Ransomeware as a Service(RaaS)」というランサムウェアの機能を提供するサービスが 名古屋港へのサイバー攻撃者として報道が多く出回っている「LockBit」も、その一例です。 LockBitが攻撃者から支持を受けている理由は「ユーザーフレンドリーなインターフェイス」により、 簡単に攻撃プログラムを組み立てることができる点にあると言われています。 これにより、高度な知識や専門的な技術を持たない人間でもランサムウェア攻撃が可能となっています。 このような背景から、ランサムウェアによる被害は今後ますます増加すると考えられます。                  バックアップデータが最後の砦に!! ランサムウェアからの攻撃を100%防御することは非常に困難です。 境界型防御やセキュリティ対策ソフトをすり抜ける事例も報告されています。​ 万が一攻撃を受けた際も、バックアップデータが無事であればデータを復旧することが可能です。 そのため、バックアップは最後の砦といえる対策となっています。                       バックアップが攻撃の対象に! ただバックアップを取っておくだけでは安全とはいえません。​ 攻撃者も容易に復旧されないようにバックアップデータを標的とします。 例えば、以下のような手法で攻撃が行われることがあります。 ・ バックアップデータ自体が暗号化される。 ・ バックアップデータが削除される。 ・バックアップソフトウェアがアンインストールされる そのため、バックアップデータを保護するための仕組みが必要となります。 仕組み①：侵入されにくいOS バックアップ製品に対してOSレイヤーで侵入される危険性があります。 WindowsやLinuxといったシェア率の高いOSは、情報が広く流布しているため、 攻撃者にとっても攻撃のための情報が集めやすいです。 それに比べ、独自OSは攻撃のための情報が限られているため、攻撃の難易度が高くなっています 仕組み②：書き換え不可なバックアップデータ バックアップデータ自体が上書きされることを防止するために、バックアップデータを書き換え不可にする機能が必要です。 イミュータブルバックアップ機能やWORM機能と呼ばれています。 他にもアクセス不可な領域に保管するエアギャップ、管理ツールの多要素認証などがあげられます。 またバックアップ製品の機能だけでなく、自社で気を付ける方法として「3-2-1ルール」に則るなどの対策も有効です。 3-2-1ルール ルール① ： データは少なくとも「3つ」のバックアップコピーを持つ ルール② ： バックアップデータを「2種類」以上の異なる媒体に保存する ルール③ ： データ保管先のうち「1つ」は物理的所在地が遠隔地にあるものを選定   復旧時にバックアップデータを利用可能か? データのバックアップを取っているだけでは、破壊されたデータやマルウェアが潜むデータは復旧に利用できません。 そのため、復旧する際にはランサムウェアによる攻撃を受けていない安全なバックアップデータを特定する必要があります。 しかし、保持しているバックアップの世代数が多いほど、安全なバックアップデータを特定するのに時間がかかることがあります。 以下の図では8日分のバックアップしか保持していないため、5世代分のバックアップデータを調査することで 安全なバックアップデータの特定が可能ですが、場合によっては数か月前のデータにさかのぼっての確認が必要となります。                     そのため、バックアップデータが安全であることを確認するための機能が重要です。 最近のバックアップ製品にはAIなどを活用し、異常を検知する機能が搭載されています。 検知機能を利用することで調査対象を絞り込むことができ、特定までにかかる時間を短縮することが可能です。 USiZE バックアップ・ランサムウェア対応サービスのご紹介 最後にUSiZE バックアップ・ランサムウェア対応サービスのご紹介です。 USiZEではランサムウェア攻撃に備えたバックアップ・オプションサービスのランサムウェア対応サービスがございます。 バックアップデータ保護の仕組み USiZE 標準バックアップは独自OSや上書きや削除が不可能なイミュータブルファイルシステムという仕組みがあります。 他にも管理ツールは多要素認証によるなりすまし防止やSMB/NFSといった汎用的なアクセス方式の 制限など様々な仕組みによりバックアップデータを保護しています。 事業復旧対応を支援するランサムウェア対応サービス ランサムウェア対応サービスでは、ランサムウェアにより攻撃された疑いを機械学習により検知します。 「バックアップ侵害検知」では、ランサムウェアによる攻撃された疑いを検知すると自動で電話およびメールにて通知します。 「バックアップ保持・仮想マシン隔離」では、ランサムウェアによる攻撃された疑いを検知した際に自動で以下の2つの対応をいたします。 バックアップ保持： 　以降のバックアップジョブが実行されないように自動で一時停止を行い、破壊されたデータのバックアップ取得や 世代管理のため、バックアップデータが削除されることを防止します。 仮想マシン隔離： 　仮想マシンの仮想NICを自動で遮断し、感染拡大を防止します。 バックアップ侵害検知は5月にリリースしています。 バックアップ保持・仮想マシン隔離は近日中にリリースいたします。 USiZEやランサムウェア対応サービスについてご興味をお持ちになりましたら、気軽にお問合せください。 　宛先： SCSK 株式会社 USiZE サービス部 ​ 　メールアドレス： usize-info@scsk.jp バックアップシステムの導入等にお困りの方はぜひ以下の記事についてもご参照ください。 バックアップ導入の勘所 参考資料 国土交通省 「コンテナターミナルにおける情報セキュリティ対策等検討委員会中間取りまとめ①名古屋港のコンテナターミナルにおけるシステム障害を踏まえ緊急に実施すべき対応策について（案） 」 大阪急性期・総合医療センター 「大阪急性期・総合医療センター 情報セキュリティインシデント調査報告書 概要」 トレンドマイクロ株式会社 RaaS (Ransomware as a Service)とは

本記事はBackhaulingの 「 Internet Breakout 」についてのご紹介です。 Local gateway IPについては、前編をご参照ください。 【前編】CatoクラウドのBackhaulingについて～Local gateway IP～ Catoクラウドの「Backhauling」をご紹介します！Backhaulingには2種類ありますが、今回は「Local gateway IP」のご紹介です。 blog.usize-tech.com 2024.06.26 「Internet Breakout」の ユースケース ※本記事では「Internet Breakout」のユースケースの一例をご紹介します。 Backhaulingの「Internet Breakout」は主に「一部トラフィックのみ、CatoのPoPのアドレスでアクセスさせたくない」場合に利用します。 具体的にユースケースを2つ挙げてご説明していきます。 SaaSサービス側で固定されている送信元アドレスを CatoのPoPのアドレスに 変更できない場合 SaaSサービスを各社専用のグローバルアドレスでアクセス制限をかけて利用している場合を考えてみます。 この場合、 Catoクラウド経由でアクセスさせるためには SaaSサービス側で送信元アドレスをCatoクラウドのPoPのアドレスに変更する必要がありますが、何らかの理由で変更ができないケースもあるかと思います。 そんな時、Backhaulingを使えば Catoクラウドを経由しながら現行 の グローバルアドレスを使ってアクセスさせることができます。 ＝  特定のWebサイトに、 CatoのPoPのアドレス でアクセスできない場合 Cato PoPのIPアドレスは、JPNICでなく上位のAPNICからIPアドレスを取得しています。 そのためアクセス先のWebサイトが日本からのアクセスのみに制限をかけている場合、Catoクラウド経由でアクセスできないケースがあります。 こんな時も、Backhaulingを使えば Catoクラウドを経由しながらISPの グローバルアドレスを使ってアクセスさせることができます。 “Catoクラウドを経由しながら”とはどういうことか構成図を使って補足します。 (前編を見たので説明不要という方は飛ばしてください） 例えば下図の構成の場合、 支店のユーザやモバイルユーザから宛先へのトラフィックは赤線経路で一度Catoクラウドを経由します。 その後、 トラフィックは 本社 内のSocketに転送され本社のインターネット回線経由でアクセスさせるといった通信経路です。 ここで注目いただきたいのは、 宛先が ドメイン・アプリケーションに加え、 IPアドレス・FQDN等の様々な形で指定することができる という点です。 Catoクラウドのその他機能には宛先をアプリケーションでしか指定できないものもあります。 それらの機能と比較すると設定方法においては便利であると言えるんです！（例えば、Split TunnelやBypass等の場合、宛先はアプリケーション指定のみです。※2024年6月現在） 「Internet Breakout」の設定例 前編でもお伝えした通り、 Backhaulさせたトラフィックは一度、Catoクラウドを経由 します 。 そのため、Catoクラウドのセキュリティチェックが適用され、ログにも記録されます。 ということで、以下3点を確認するためテストを行ってみました。 Backhaulさせる前後でのグローバルアドレスの変化 ログの残り方 Backhaulさせた場合、セキュリティ機能はどうなるか 構成例 構成は下図の通りです。 支店のユーザから、アドレス確認サイト(www.cman.jp)へのトラフィックのみをBackhaulさせ、検証環境のSocketから検証環境のインターネット回線経由でアクセスさせるというシナリオです。 まず、Backhaulingの設定を入れる前の状態で、アドレス確認サイト(www.cman.jp)へアクセスをしてみます。 この状態で自身のアドレスの確認を行うと、この通り150.195.219.0/24のアドレスが払い出されていることがわかりました。 このアドレスはCatoクラウドの東京PoPのアドレスとなっており、CatoクラウドのPoPから宛先のアドレス確認サイト(www.cman.jp)に接続していることがわかります。 ちなみに、CatoクラウドのPoPのアドレスはこちらから確認可能です。 Production PoP Guide – Cato Learning Center (catonetworks.com) 設定手順 次に、Backhaulingの設定を行っていきます。 Backhaulingは下記の順番で設定をします。 Step１： Gatewayサイトの定義 →出口として設定したい拠点をGatewayサイトと定義します。 → 今回は、”検証環境”というサイトをGatewayサイトとして定義します。 Step２：Network Ruleの作成 →対象トラフィックをGatewayサイトに向けるためのルーティングの設定を行います。 → 今回は、支店のユーザからアドレス確認サイト(www.cman.jp)へのトラフィックのみを”検証環境”にルーティングさせます。 Gatewayサイトの定義 設定箇所：Network＞Site＞Site Configuration＞Backhauling 「Use this site as a backhauling gateway」のチェックボックスにチェックを入れます。 「Select the destination for the traffic」の設定項目が出力されます。 ここで 「Internet breakout」か「Local gateway IP」のどちらかを選択しますが、今回は「Internet breakout」を選択します。 上の手順で「Internet breakout」を選択すると「Preferred Socket Port」の設定項目が出力されます。 ここではSocketのどのポートから出力させるかを指定することができます。 今回はWAN1ポートから出力させたいので、「WAN1」を選択しました。 SocketのWANポートを冗長している場合は、「Automatic」を選択することで、自動で出力ポートを選択させることも可能です。 ここまででStep1のGatewayサイトの定義は完了です。 次にStep2のNetwork Ruleの作成に進みます。 Network Ruleの作成 中国のユーザからの接続の場合や、中国の拠点をGatewayサイトとする場合は、中国のインターネット規制に違反していないことを事前に確認し、設定を行う必要があります。 設定箇所：Network＞Network Rules 「New」からルールを作成していきます。 本記事ではNetwork Rulesの詳細な説明は省略いたしますが、今回は以下の通り設定をしています。   ・Name：Backhauling test ・Rule Type：Internet ・Source：Site(支店) ・App/Category：Domain( www.cman.jp ) ・Configuration    – Bandwidth priority：P255    – Priority Transport：CATO(Automatic)    – Secondary Transport：None ConfigurationのRouting Methodでは「Backhaul via」を選択します。 「Backhauling Gateway Site」の設定項目が出力されるので、+ボタンからStep1で設定したGatewayサイトを選択します。 最後に「Save」ボタンで設定保存をします。 以上で設定は完了です。 結果 それでは、確認項目を１つずつ確認していきます。 Backhaulさせる前後でのグローバルアドレスの変化  まず確認項目1つ目のグローバルアドレスを確認してみます。 Backhaulingの設定を入れる前の状態では、Catoクラウドの東京PoPのアドレスでした。  Backhaulingの設定が完了した後に接続をしてみると… グローバルアドレスは以下の通りISPから付与されたアドレスへと変更され、CatoクラウドのPoPからではなく検証環境のインターネット回線経由で接続されていることがわかります。 ログの残り方 この時のログを確認してみると残念ながら最終的にどのグローバルアドレスでアクセスされているかまでは確認ができませんでした。 ですが、このログから設定手順のStep2で設定したNetwork Ruleにヒットして”検証環境”というサイトから接続していることがわかります。 また、「Sub-type」と「Rule」からCatoクラウドのInternet Firewall（ルール名：Any Allow）を突破していることもわかります。 Backhaulさせた場合、Catoクラウドのセキュリティ機能はどうなるか 2つ目の確認から、Internet Firewallが機能していることが確認できましたが、念のためInternet Firewallで アドレス確認サイト(www.cman.jp)へのトラフィックをBlockするルールを作成してみました。 この状態で同じようにアドレス確認サイト(www.cman.jp)へアクセスをしてみると、下図の通りBlockされました。 よって、Backhaulされた通信もCatoクラウドを経由するため、Catoクラウドのセキュリティ機能が機能するということがわかります。 さいごに 今回はBackhaulingについて解説しました。 このBackhaulingですが、実はトラブルシューティングで利用されるケースもございます。 詳細はこちらの記事をご参照ください。 Cato経由でのWebサイト接続のトラブル例とその対処法 Cato経由でのWebサイトの接続トラブルについて、事例とその対処法についてご紹介します。 blog.usize-tech.com 2024.04.19