こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync とは AWS AppSync はサーバーレスアプリケーションのバックエンドを作成するときに使用するサービスです。GraphQL というクエリ言語を使用してアプリケーションからリクエストします。AWS AppSync が受けたリクエストを処理するためにリゾルバという設定があり、その中で VTL (Apache Velocity Template Language) という言語でコードを書きます。同じ目的で Amazon API Gateway と AWS Lambda を使用する構成の方がメジャーですよね。ここでは、AWS AppSync = Amazon API Gateway、リゾルバ = AWS Lambda と置き換えてもらえたらわかりやすいと思います。 AWS AppSync には Amazon API Gateway + AWS Lambda の構成と比較して、以下の利点があります。(ChatGPT に聞いてみた) パフォーマンス VTL は AWS AppSync 内で実行されるため、AWS Lambda 関数を呼び出すよりもレイテンシーが低い。サブスクリプションの機能をデフォルトで備えていることも含め、リアルタイム性が高いアプリケーションにおいて優位性がある。 コスト効率 VTL は AWS AppSync の一部として実行されるため、追加のコストがかからない。 スケーラビリティ AWS AppSync と VTL は自動的にスケーリングされる。AWS Lambda 関数は同時実行数の制約がある。 ただし、AWS AppSync のデメリットもあります。 VTL は低機能なため、AWS Lambda 関数で書いていたこと全てを実現できるわけではない。 → JavaScript で書けるようにもなっているので、それにより解決していると思われる。(本記事では紹介しない) また、本記事では本末転倒ではあるが、AWS AppSync と AWS Lambda を統合することも一般的に行われている。 AWS AppSync を使用するために必要な GraphQL が難解で、そもそも AWS AppSync に手を出せない。w 私の実感を加味してまとめると ・AWS AppSync のレスポンスは高速。 ・しかし裏で使われるリゾルバ (VTL) でできることが少ない。簡易な CRUD 処理であれば実装可。 ・GraphQL も勉強しないといけない。学習コスト高い。 リゾルバとは リゾルバは、AWS AppSync がアプリケーションから受け取った GraphQL クエリによるリクエストから、引数を取得してバックエンドにあるデータソース（データベース等）とのやり取りを仲介する役割を持ちます。Amazon API Gateway と Amazon DynamoDB の構成と比較すると以下のようになると思えばよいでしょう。 Amazon API Gateway → AWS Lambda → Amazon DynamoDB AWS AppSync → リゾルバ → Amazon DynamoDB 1つの Amazon API Gateway が複数の AWS Lambda と統合できるのと同じように、1つの AWS AppSync は複数のリゾルバを持つことができます。 しかし、注意しないといけないのは、基本、1つのリゾルバは 1つのデータソースしか統合できません。AWS Lambda 関数であれば、関数コード内で自由に複数のデータソースとのやり取りを書くことができると思いますが、そのような自由度はリゾルバにはありません。 ※リゾルバの書き方によっては一部例外はあります。後ほど紹介します。 リゾルバでは VTL という言語で以下 2つの処理を定義します。 リクエストマッピングテンプレート レスポンスマッピングテンプレート 役割としては リクエストマッピングテンプレートは、AWS AppSync が受けたリクエストの引数を受け取り、バックエンドに処理をさせるコードに置き換える。（マッピングする） バックエンドが Amazon DynamoDB であればそれ用の記述を、Amazon Aurora であればまたそれ用の記述になる。アプリケーション側ではバックエンドの違いを気にせず同じクエリでデータを取得することができる。(これは GraphQL のメリット) レスポンスマッピングテンプレートは、バックエンドが返してきたレスポンスを加工し、アプリケーションが期待するフォーマットに置き換える。（マッピングする） 以降、 Amazon DynamoDB から 1つのアイテムだけを取得する VTL のサンプルを紹介します。今後、シリーズものとしていくつか他のサンプルも用意するつもりです。 Amazon DynamoDB に GetItem する VTL 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定で行います。 引数となるパラメータ：　パーティションキー pkey、ソートキー skey 必要なレスポンス：　data1, data2 という属性の値 マッピングテンプレートは JSON 形式で記述します。その中に VTL が混在する感じです。わかりにくい。 リクエストマッピングテンプレート { "version": "2018-05-29", "operation" : "GetItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey": $util.dynamodb.toDynamoDBJson($context.arguments.skey) }, "consistentRead" : false, "projection": { "expression": "#data1, #data2", "expressionNames": { "#data1": "data1", "#data2": "data2" } } } operation には、GetItem を書きます。これは Amazon DynamoDB に GetItem をするぞ、という意思表示です。 key には、受け取った引数を書きます。ここでは、pkey, skey というキーに対して受け取った引数 $context.arguments.pkey と $context.arguments.skey を指定していると思って下さい。受け取った引数はマッピングテンプレート内では $context.arguments 内に格納されるので、この記述のように取り出すことができます。 $util.dynamodb.toDynamoDBJson で囲んでいる理由ですが、Amazon DynamoDB にキーを渡すときに特有の JSON フォーマットにする必要があるため、それをいちいち手書きしなくてもよいようにしてくれます。手書きだと、例ですが “pkey” : { “S” : $util.toJson($context.arguments.pkey) } と書かないといけないことになります。 consistentRead は、結果整合性でよいか、強整合性が必要かを指定します。 projection は、Amazon DynamoDB から受け取りたい属性を指定します。expressionNames では、例えば data1 という属性名を内部的に #data1 という名前に置き換えて、expression で指定しています。これは、Amazon DynamoDB の予約語や AWS AppSync の禁止文字列などが属性名に使われているときにエラーを回避するお作法です。ちなみに projection の項目を書かなければそのアイテムの全属性を取得します。 これで Amazon DynamoDB に GetItem をかけることができます。 ドキュメントによっては $context.arguments を $ctx.args と書いてあるサンプルもあります。私の経験上ですが、どちらでも同じ動きをするようです。 レスポンスマッピングテンプレート #if(!$context.result || $context.result.isEmpty()) $util.toJson({ "data1": "no data", "data2": "no data" }) #else $util.toJson($context.result) #end 超基本は、$util.toJson($context.result) を 1行書くだけで成り立ちます。$context.result に Amazon DynamoDB から返ってきたデータが格納されます。気を付けないといけないのは、$util.toJson で囲まないといけないことです。実はマッピングテンプレート内部では、$context.result が JSON フォーマットで書かれていないからです。それを JSON に Parse してくれるのが $util.toJson なのです。 このサンプルで少々手を入れているのは、データが無かったときは data1 と data2 に no data というテキストを入れて返すようにしていることです。$context.result と同じ JSON フォーマットに合わせており、受け取るアプリ側はデータがあろうが無かろうが同じフォーマットでレスポンスを受け取れるようにしています。※すみません、エラーのときの処理は入れていません。 レスポンスマッピングテンプレートでは、受け取ったレスポンス $context.result の内容に応じて、if 文でデータを加工することができます。if 構文を書くときには、その構文の先頭に必ず # を入れます。最後には #end で閉じます。if 文のネストも可能です。 任意の JSON データをレスポンスとして返すときも、必ず $util.toJson で囲むようにしましょう。ドキュメントによっては $util を $utils と書いているサンプルがありますが、私の経験上はどちらでも同じように動いています。 VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 Amazon DynamoDB への CRUD 処理の基本中の基本とも言える GetItem ですが、すでにおなかいっぱいなのではないかと思います。ですが、一度 VTL がどんなものか理解できれば、そうでもなく感じてしまうので不思議です。今後他の VTL パターンも紹介しますね。お楽しみに。 本記事が皆様のお役に立てれば幸いです。

AWS CodebuildでAndroid OSのビルドを試す機会がありましたので、ナレッジを紹介します。本記事を読むことで下記が分かります。ご参考にしていただければ幸いです。 Codebuildにおける、ビルド環境のメモリとストレージの拡張方法 ⇒ただし、Android OSのビルドに関しては、本記事の リソース拡張の方法では失敗 することが判明 ビルド仕様のファイル(buildspec.yaml) 内で、以前のコマンドに依存するコマンドを実行する方法 本記事では細かい操作方法は記載しておりません。上記2点のみを記載しています。細かい操作方法は、公式手順をご確認いただければと思います。 Android OSとは Android OSは、モバイルデバイス向けのオープンソースのOSであり、Googleが主導するプロジェクトです。ソースは下記からダウンロードできます。 ソースのダウンロード  |  Android オープンソース プロジェクト  |  Android Open Source Project source.android.com ちなみにオープンソースにした理由としては、特定のプレーヤーが独占して他の誰かのイノベーションを阻害することがないように、誰もがメリットを享受できるようにとの理念があるそうです。 Android オープンソース プロジェクト  |  Android Open Source Project Android が世界を一つにします。オープンソースの Android オペレーティング システムでデバイスを活用しましょう。コピー source.android.com   Android OSのビルド要件 下記の通りです。 64 ビット環境のUbuntu Long Term Support（LTS） ※ ストレージ400GB以上 16 GB 以上の使用可能な RAM（64 GB を推奨） ※Googleでは、Ubuntuで開発とテストが行われているので、ビルドにはUbuntuを使うのが無難。 要件  |  Android オープンソース プロジェクト  |  Android Open Source Project source.android.com   Codebuildのスペック 2024/1現在、東京リージョンのCodebuildで用意されているUbu ntu、環境タイプ値：LINUX_CONTAINERのタイプとその費用は下 記の通りです。 コンピューティングタイプ 環境タイプ値 メモリ vCPU ディスク容量 費用/1分あたり※ Linux Small  LINUX_CONTAINER 3 GB 2 64 GB 0.005USD (0.75円) Linux Medium  LINUX_CONTAINER 7 GB 4 128 GB 0.01USD   (1.5円) Linux Large  LINUX_CONTAINER 15 GB 8 128 GB 0.02USD   (3円) Linux 2xlarge LINUX_CONTAINER 145 GB 72 824 GB (SSD) 0.25USD   (37.5円)  ※1USD=150円換算 参照URL: ビルド環境のコンピューティングモードおよびタイプ - AWS CodeBuild CodeBuild では、CodeBuild がビルドの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 コンピューティング とは、CodeBuild によって管理および保守されるコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 ランタイム環境イメージ... docs.aws.amazon.com ビルド環境のコンピューティングモードおよびタイプ - AWS CodeBuild CodeBuild では、CodeBuild がビルドの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 コンピューティング とは、CodeBuild によって管理および保守されるコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 ランタイム環境イメージ... docs.aws.amazon.com   ビルド要件との比較 Android OSのビルド要件と、Codebuildが用意するコンピューティングマシンの比較は下記の通りです。 項目 要件 Linux Large  Linux 2xlarge メモリ 16GB 15GB 145GB ストレージ 400GB以上 128GB 824GB コア数 ー 8コア 72コア 費用単価(分) ー 3円 37.5円 ビルド時間/回 ー ？ ？ ビルド費用/回 ー ？ ？ 公式によるとメモリが64GBの場合、72コアでビルド40分、6コアで3時間を要しています。 要件  |  Android オープンソース プロジェクト  |  Android Open Source Project source.android.com 要件を満たすコンピューティングタイプはLinux 2xlargeのみ ですが、単価が次点のLinux Large の10倍以上あります。ビルド時間が1/10になってくれればよいのですが、実際に試してみないとわかりません。 今回は費用面の理由によりLinux Largeを選択し、要件を満たしていない点に関しては、後述のリソース拡張方法で乗り切ることにしました。   Codebuildプロジェクトの作成 ストレージの不足：Amazon EFS のマウントで対処 不足するストレージについては、Codebuildに Amazon EFS をマウントさせることで対処します。ここでEFSをマウントする理由は２つあります。 前述の通り、ビルド要件から不足しているストレージ分を補うため Android ソースツリーを事前にダウンロードしたEFSをマウントさせることで、ダウンロード時間をスキップするため ２つ目のポチに関して.. Codebuildを開始すると新規のEC2が起動します。Androidの公式手順に従い、 ソースツリーのダウンロードから初めてしまうとダウンロードの時間(約2~3時間)を要してしまいます。CodebuildのタイムアウトはMAX８時間と制限があります。そのため、事前にEFSにソースツリーをダウンロードし、それをCodebuildから利用することで、時間短縮を図ります。 EFSのマウント方法は公式手順をご確認ください。 AWS CodeBuild の Amazon Elastic File System サンプル - AWS CodeBuild ビルドコンテナで Amazon EFS を使用する方法について説明します。 docs.aws.amazon.com   メモリの不足：SWAPの設定で対処 ビルド仕様のファイル(buildspec.yaml)にて、SWAPの設定を追加します。ここでは16GBを追加しています。 version: 0.2   phases:   pre_build:     commands:       – sudo fallocate -l 16G /swapfile       – sudo chmod 600 /swapfile       – sudo mkswap /swapfile       – sudo swapon /swapfile (略)   補足：buildspec.yamlで、以前のコマンドに依存するコマンドを実行する方法 buildspec.yamlの記載に際し、一つ補足があります。 Android OSのビルドに際し、公式手順では、ダウンロードしたソースツリーにある環境設定のスクリプトを実行することで、ビルドに必要な lunchやmコマンドを実行できるようになります。 $ . build/envsetup.sh #後続のlunchやmコマンドが実行できるようになる $ lunch product_name-build_variant #ビルドターゲット product_name-build_variant を指定 $ m #ビルド開始 公式手順： Android のビルド  |  Android オープンソース プロジェクト  |  Android Open Source Project   下記のようにbuildspec.yamlを記載すると、lunchやmコマンド実行時に”command not found”と怒られ、ビルドが失敗することになります。 version: 0.2 phases:   (略)   build:     commands:       – . build/envsetup.sh       – lunch “product_name-build_variant”       – m   正しくは、c ommands フェーズで – | と指定し、 YAML のリテラルブロック構文を使用する必要があります。 version: 0.2 phases:   (略)   build:     commands:       – |          . build/envsetup.sh          lunch “product_name-build_variant”          m   公式のドキュメントを見たところ、ビルド仕様バージョン 0.1 では以前のコマンド (ディレクトリの変更や環境変数の設定など) の状態に依存する単一のコマンドを実行することはできないとのこと。 ビルド環境のシェルとコマンド - AWS CodeBuild ビルドのライフサイクル中にビルド環境で実行するための AWS CodeBuild の一連のコマンドを提供します (たとえば、ビルドの依存関係のインストール、ソースコードのテストおよびコンパイルなど)。これらのコマンドを指定する方法はいくつかあります。 docs.aws.amazon.com 今回は、上記の通りビルド仕様バージョン 0.2を指定しましたが、以前のコマンドに依存するlunchやmコマンドは実行できず、ビルドが失敗しましたので、上記YAML構文を利用して回避しました。   結果 Codebuild上で、上記のようにリソースを拡張したコンピューティングタイプでは、 ビルドが一向に進まずに失敗する形となりました。 SWAPを設定しない場合は、メモリ不足で失敗するまでは途中までビルドは順調に進みました。 SWAPの利用によりビルドが進まなかったと考えていますが、原因究明中となります.. ひとまず高額ですがビルド要件を満たすコンピューティングタイプ “Linux 2xlarge”を素直に選んだほうがよさそうです。実際に試したかったのですが、費用的観点から別の機会で考えています。 項目 要件 Linux Large  Linux 2xlarge メモリ 16GB 15GB 145GB ストレージ 400GB以上 128GB 824GB コア数 ー 8コア 72コア 費用単価(分) ー 3円 37.5円 ビルド時間/回 ー 8時間(タイムアウトでビルド終了) ？ ビルド費用/回 ー 1,440円 ？   終わりに Android OSのビルドに際し、Codebuildで利用できるコンピューティングタイプのメモリについて、15 GBの上位が145 GBと開きがあり、ちょうど良いスペックのものがありませんでした。 加えて、2023年11月にCodebuildで AWS Lambdaによるサポート開始が発表されました。AWS Lambda はほぼ瞬時に起動するため、より高速なビルドが可能とうたっています。 AWS CodeBuild で AWS Lambda によるコンピューティングのサポートを開始 aws.amazon.com ただし、AWS Lambdaのメモリが最大10GBであり、Android OSのビルド要件である16GB(推奨64GB)を満たしていません。 ビルド環境のコンピューティングモードおよびタイプ - AWS CodeBuild CodeBuild では、CodeBuild がビルドの実行に使用するコンピューティングとランタイム環境イメージを指定できます。 コンピューティング とは、CodeBuild によって管理および保守されるコンピューティングエンジン (CPU、メモリ、およびオペレーティングシステム) を指します。 ランタイム環境イメージ... docs.aws.amazon.com そのため、高額であることを承知した上でCodebuildのEC2のオーバースペックのものを利用するか、Codebuildを使わず、要件を満たすEC2を利用してビルドする方法が望ましいと考えます。

新年あけましておめでとうございます。本年もどうぞよろしくお願いします。 早速ですが、Catoクラウドの担当として、 独断と偏見で選出した ゼロトラストネットワーキング（Zero Trust Networking） 、特に SASE 、 SSE に関連する 2023年の10大ニュース を、今後の注目ポイントと合わせてご紹介します。 SASE （サッシー、サーシ）は「Secure Access Service Edge」、 SSE （エス・エス・イー）は「Security Service Edge」の略称で、ともにアメリカ調査会社であるガートナー社が提唱しており、SASEは2019年、SSEは2年後の2021年に提唱されました。 SASEは、ネットワークとセキュリティと統合（融合）し、ユーザが場所を問わず企業のシステム、アプリケーション、クラウドサービス、データにアクセスできるよう、安全で信頼性が高く、最適化されたネットワーク接続を提供することがコンセプトとなっており、一方でSSEは、SASEのサブセット（一部分）で、SWG、ZTNA/SDP、CASB/DLP機能のみを指します。 1. 国内SASE導入は、海外に遅れを取るものの普及期へ 昨年（2023年）からSASEの普及期に入るとされていました。SCSKでは2021 年より SASE の主要なソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称S4：エスフォー）」をこれまで13回開催しており、2023年の6月および10月の開催では、それぞれ200名以上、これまでに延べ1,300 名以上の方々にご参加頂いております。※次回は2024年2月開催予定です。 これらのセミナーを通じて、多くの参加者からの声を集めると、SASEに関して世間で類似のアンケート調査（例えば、SASE導入済み企業が4割、導入着手企業が6割など）よりも、実際の国内の認知度や導入率が低いのではないか、実態と大きく乖離しているのではないかという仮説が上がりました。 そこで、2023年6月に外部調査企業を利用し、国内企業（n=339社）への実態調査を実施したところ、約7割の企業が、SASEについて認知していないことが判明し、SASE導入済み企業は1割であることが分かりました。 一方、SASEを認知している3割の企業の内、1割（10%）の企業は、すでにSASEを導入済みで、5%が現在導入中、15%が導入計画中であることも判明しており、キャズム理論においては 、日本国内においてもキャズム（普及に向けた深い溝）を超え、メインストリーム市場へ進んでいることが判明 し、2023年から今年（2024年）が普及期であるということが分かりました。 https://www.scsk.jp/news/2023/pdf/20230809i.pdf コロナ禍でのリモートワークや境界型防御の喫緊の課題解決で、いち早くSASEへ移行をしたお客様は一段落し、現在は、WANやリモートアクセスのライフサイクルのタイミングでの検討が多いように思えます。 2. ゼロトラストに続き、SASE、SSEがバズワードへ ガートナーが2023年7月18日に「 ゼロトラストネットワーキングのハイプサイクル （Hype Cycle for Zero Trust Networking）」公開しました。 公開理由には「ゼロトラストをめぐる顧客の関心、混乱、誇大広告を考慮して、新しいハイプ・サイクルを発表」、「測定可能なゼロトラスト・プログラムを導入することは、ノイズや誇大広告に満ちた困難な旅になる可能性がある」、「ゼロトラストは、クラウドや、Software-Defined（SD～）のような言葉に似ており、私たちが目にすることのひとつは、本当にゼロトラストの特徴を示すものと、純粋なベンダーのマーケティングとを区別するのに苦労する」とあり、「ゼロトラスト」に続いて、「SASE」「SSE」が多くの誇大広告に溢れ返ったバズワードと化し、本来の定義は無視され、曖昧な定義のまま広く世間で使われてしまっています。 今後も「ゼロトラスト～」「～SASE」「～SSE」など様々なバズワードが出現することになると思いますが、「SASE」「SSE」の正しい定義と、皆さんが求めている「ゼロトラスト」が、どのようなステップで検討・導入を進めるべきか、また、最終的ゴール（あるべき姿）はどこか？を、きちんと検討されることが重要かと思います。 3. ゼットスケーラー（Zscaler）が、SASEマジック・クアドラントから外れる ご存知の通り、ガートナーの シングルベンダーSASE （Single-Vendor SASE）の マジック・クアドラント （Magic Quadrant：MQ）から、ゼットスケーラーが外されました。 その後のフォレスターの ゼロトラストエッジ （Zero Trust Edge Solutions）の Waveレポート からも外されています。 前述の当社のSASEセミナーS4（エスフォー)でも、2021年の開始当初からゼットスケーラーの紹介を行っておりましたが、2022年度以降（2023年度）からは、ゼットスケーラーを外さざるを得ない状況となりました。 ゼットスケーラーは、このことに対し「このMQは、我々の成長速度を落とすものではない。SASEは幅広い総称です。ガートナーがこれを始めたとき、それは我々が持っているゲートウェイ製品であるSD-WANとSSEの統合でした。そして、私たちはそこにある重要なSD-WANベンダー全てとの統合を行ってきました。ゼットスケーラーは、CASB、DLP、SWG、ZTNAを統合したSSEソリューションと共に、主要なSD-WANベンダーの殆どと提携し、マルチベンダーのベストオブブリードSASEセキュリティスタックを提供しています。」 「今回のMQは、SD-WANを含む単一ベンダーのSASEのためのものです。我々はしばしばSD-WANはゼロトラストであると言ってきたが、我々はゼロトラストのSASEを提供しているが、SD-WAN SASEは提供していません。だから、我々はそのMQに入っていません。」 ゼットスケーラーは、SD-WANベンダーを中心に、様々パートナーとの協業モデル（ゼットスケーラー曰く「マルチベンダーSASE」）で成功してきていますが、利用者はマルチベンダーのベストオブブリード（マルチベンダーSASE）ではなく、よりシンプルなシングルベンダーSASEを希望する方向へ変わってきています。 ゼットスケーラーは、今後ネットワークハードウェアを展開し、SD-WANサービスの提供へ戦略転換を図るとの記事もありますが、それは同時にこれまでのSD-WANベンダーとの関係が悪化することを意味します（ゼットスケーラーの売上のかなりの部分がネットワークパートナーを介したものである）ゼットスケーラーがこれまで一緒にビジネスを牽引してきたパートナーと決別し、シングルベンダーSASEへ舵を取るのかどうかが今後注目です。 また、日本国内では長引く円安の状況もあり、契約更新の度に大幅な値上げがあるのでリプレースを検討する利用者が増えています。最初の3年契約の初回更新はなんとかクリアしても、次の契約更新を行わない（行えない）利用者も多いので、その対応についても今後注目です。 4. AI、AI、AI・・・ 最近のIT関連のニュースは、ChatGPT、Microsoft Copilot、Google BardなどAI一色です。 ゼロトラスト、SASE、SSE界隈も同じくAIの話題がつきません。 一例ですが、パロアルトネットワークス（Palo Alto Networks）は、 Strata Cloud Manager と呼ばれる人工知能（AI）を活用した管理ツールを開発しました。 このAIを活用すると「SASE全体だけでなく、ハードウェア・ファイアウォールとソフトウェア・ファイアウォール全体でも単一の統合ダッシュボードで情報を得ることができ、ネットワーク・セキュリティを 1 つの画面で確認でき、完全な可視性を得ることができます。」とのこと。 その他のベンダーも同じように次々にAIを謳っていますが、多くは管理ポータルでのセキュリティインシデントについての詳細な説明（追加の関連情報）やアドバイスが多いように思います。どの部分にAIがどのように活用されているのか？そのAIによって利用者はどのようなメリットを享受できるのか？などは、実際に利用して見ないと分かりません。 今後もAIの話題はつきないと思いますが、ゼロトラスト、SASE、SSEでの実際のメリットに注目していきたいと思います。 5. シスコ（Cisco）がSASEに本腰をいれるが、現時点では難解 シスコは、シングルベンダーSASEに選出されていますが、これまで買収した「Meraki」、「Umbrella」などが組み合わされたSASE、シスコ曰く「統合型（Unified）SASE」で、管理コンソールは全く別々のままでした。 “組み合わせされたSASE”は、「Cisco+ Secure Connect」と呼ばれ、SD-WANはMeraki、セキュリティ機能はUmbrellaにて機能が提供されていましたが、さらに”組み合わせされたSSE”として、「Cisco Secure Access」もリリースしています。 ちなみに、Umbrellaには「Umbrella DNS」「Umbrella Secure Internet Gateway（SIG）」があります。 正直なところ複雑過ぎて分かりません。 Meraki（SD-WAN）、Umbrellaに、ZTNA（VPNaaS）を付加して（言葉自体がおかしいが）「統合型SASE」として、Cisco+ Secure Connectが位置づけられています。 一方で、SSE、SD-WANについては（これも言葉自体がおかしいが）「組み立て型SASE」として”適宜”組み合わせたものをソリューションとして提供するようで、バラ売りも行うようです。 また、管理コンソールは、Umbrellaを捨てて、Merakiへ統合する方針のようです。 いずれにせよ、シスコは、統合型（Unified）SASEの名の下、 Cisco+ Secure Connect へ統合を図るようです。 シスコは、バラバラのパーツを如何にしてうまく統合できるか、また、この複雑なソリューション・ポートフォリオを利用者が理解し、支持されるかどうかに注目です。 6. マイクロソフト（Microsoft）が、SSEから本格参入 マイクロソフトが、これまでの CASBに加えて、Entra SuiteにSWG、ZTNA、FWaaSを加え、SSEへの本格参入を表明 しました。 これまでのAzure Active Directory（Azure AD）のブランド名も捨て、Entra IDへ変更するなど、かなりの本気度が垣間見えます。 マイクロソフトはすでに全世界中にAzureリージョンを保有しており、61のデータセンターと185のPoPを有し、世界最大のグローバルバックボーンネットワークを保有していることが最も大きな特徴になります。 まずは、SSE-but-the-SASE市場に参入したため、SSE市場の競争が激化することは間違いないですが、近い将来グローバルバックボーンを活用したSASE市場への参画することも間違いないと思います。 シスコと同じく、大規模な顧客基盤と、様々なパートナーとのエコシステム、強力なアイデンティ基盤であるAzure AD（Entra ID）、オペレーションシステム基盤（Windows OS）など、SASE、SSEでは最も強力なベンダーになる可能性が高いです。 一方、国内ではマイクロソフトファンの利用者も多い反面、マイクロソフト嫌いの利用者も多いため、SASE、SSEまでマイクロソフトに支配されたくないと言う方も一定数は存在すると思います。SSEからSASEへサービス範囲を広げ、利用者に支持されるかに注目です。 7. フォーティネット（Fortinet）が、Google Cloudとパートナーシップ 2023年10月に フォーティネットは、SASE PoPの拡大のためにGoogle Cloud と提携 したことを発表しました。 Google Cloudのグローバル ロケーションの広範なネットワークを利用するとのこと。Google Cloudは 、39の地域、200以上の国と地域に187のネットワークエッジロケーションがあります。 つまり、フォーティネットは、パロアルトネットワークス（Prisma Access）と同じくGoogle Cloud と提携し、全世界にPoPを持つことになりましたが、その反面、Googleが進出していない中国へのアクセスは行わない（≒行えない）ことを選択したようです。 アメリカ企業は、とかく中国を軽視しがちですが、日本国内、特に製造業を中心に、中国接続は必須の要件であるため、利用者が中国接続なしでフォーティネット（FortiSASE）を支持するか、またはフォーティネットがGoogle CloudがPoPを展開していない中国等へ独自にPoPを展開するかどうかが注目です。 8. ブロードコム（Broadcom）のヴイエムウェア（VMware）買収が完了 2023年11月にブロードコムのヴイエムウェアの買収が完了しました。 ヴイエムウェア本来の仮想サーバ（vShere）以外でこれまで買収したVeloCloud、Ananda Networks、Nyansa、Carbon Black、Air Watchなどがどうなるかが今後注目すべき事項です。 シマンテック（Symantec）と、VMware SD-WANを組み合わせてSASEを強化するのか、それともすでに話がでているように、それぞれバラバラで売却されるのか？シングルベンダーSASEで有り続けられるのか？がポイントです。 過去ブロードコムにより買収された企業、シーエー（CA Technologies）、シマンテックの動きを見る限りは、従業員のレイオフ、個々の事業売却、そして利用者に対しては、価格高騰（抱き合わせ販売）、サポートの減少、イノベーションの停滞へと進む可能性が高いのではないかと推測します。 ブロードコムがどう動くのか、各調査会社がSASE、SSEからブロードコム（ヴイエムウェア）をどう評価するのか注目です。 特に、旧ヴイエムウェアが買収したSD-WANのVeloCloudは、前述のゼットスケーラーとの協業モデルの事例が多かったため、ブロードコムが VeloCloudを、ゼットスケーラーへ売却することになれば、ゼットスケーラーがいっきにシングルベンダーSASEとなる可能性もあります。 9. 世界初SASEソリューションベンダー、ケイトネットワークス（Cato Networks） Cato Networksは、2023年9月に2億3,800 万ドル(約340億円）の資金を株式調達し、評価額が30 億ドル（約4,300億円）を超えました。 「 SASE のゴッドファーザー 」とも呼ばれる Cato Networks の CEO である シュロモ・クレイマー（Shlomo Kramer）は、「私たちは、2015年にSASEを発明しました。最初の4年間は、多くの人が私たちを”何をしているの？”という目で見ていたが、2019年ガートナーの”ネットワーク セキュリティの未来”で、新たなSASEとしてカテゴリ定義されたことで流れが変わりました。SASE エクスペリエンスを提供するソリューションとして、このプラットフォームをゼロから構築した唯一の企業になりました。」とのこと。 全世界中に85箇所以上に設置されているCato社独自のPoP（中国を含む）、ネットワーク接続性を拠点まで保証するSocketのサービス提供（責任分界点が異なる）、クラウドネイティブで実装されたアーキテクチャ（圧倒的な使いやすさ、シンプルさ）は、他のソリューションと異なる大きな差別化ポイントで、唯一のSASEソリューションとも言えます。 ちなみに、シュロモ氏は、他の競合他社に対しては「SASEが登場した後、パロアルトネットワークスのように、グーグルを活用した急ごしらえのつなぎ合わせソリューションは、持続可能性や費用対効果に問題があり、将来的にその代償は顧客が支払うことになるだろう。」「ゼットスケーラーの言う”マルチベンダーSASE”カテゴリは、本質的にはすでに消滅している。」「フォーティネットは、最近クラウドについて意識し始めたところ、まさにこれから」と、ゴッドファーザーらしいコメントをあげています。 Catoクラウドの注目すべきポイントは、ガートナーのSASE定義をすでに超え始めていること です。 2023年には「 SaaS Security API 」のセキュリティオプションをリリースし、SaaSサービスに対して、ウィルスチェックや、機密情報漏えい対策（DLP）をカバーしました。つまり、企業内のユーザは、Catoクラウドを経由するので問題はないが、社外ユーザとのデータ共有はCatoクラウドによるセキュリティ検査が行えないため、SaaSを直接検査を行うことで、カバー範囲を広げました。 「 XDR Security 」をリリースし、 EDR製品とのログ連携 もすでに開始されています。現時点では Microsoft Defender for Endpoint のみですが、主要なEDR製品との連携が予定されており、これまで「EDRはEDRのSOC、SASEはSASEのSOC」と、SOCが別々になる事が多かったのですが、SASE（Catoクラウド）へログおよびSOCを統合する動きが開始されています。 さらに、来月（2024年2月）からは、 EPP製品をリリース し、ガートナーのSASEの定義を超えて、ネットワーク層を超えエンドポイントまでカバー範囲を広げます。 10. Cato Networks社の最優秀パートナーアワードをSCSKが受賞 最後のニュースはSCSKの宣伝を兼ねていますが、2023年7月 Cato Networksが日本で初めて開催した「Partner Summit in Tokyo 2023」において、SCSKは「ビジネス貢献度」、「案件創出数」、「デジタルコンテンツ拡充」ならびに「Cato 認定技術者数」の項目で最も高いポイントを獲得し、 最優秀パートナーアワードである「Top Performing Partner」を受賞 しました。 https://www.scsk.jp/news/2023/pdf/20230726i.pdf 「ビジネス貢献度」、「案件創出数」はもちろんのことながら、SCSKのCatoクラウド認定技術者数と、特に、Catoクラウドのお客様導入事例の制作や、CatoクラウドのFAQシステム等の「デジタルコンテンツ拡充」が認められたことは、非常にありがたいことです。 2023年8月からは、さらにこのSCSK技術ブログ「TechHarmony」への記事投稿も開始しており、さらにCatoクラウドのデジタルコンテンツの拡充を図って行きたいと考えておりますので、引き続きご活用ください。 最後に 「SASE のゴッドファーザー」であるシュロモ・クレイマーが率いるSASE、Cato Networks社、Catoクラウド（Cato Cloud/Cato SASE Cloud）ですが、 知名度が圧倒的に低いのが一番の課題 です。 特に、日本国内においては「革新的なもの」「便利なもの」「費用対効果が高いもの（安いもの）」よりも、「認知度が高い（誰もが知っていている）もの」「同業（または自社と比較対象の企業）が採用しているもの」「誰もが利用していてるもの」を選択する傾向にあります。 つまり、日本では莫大なマーケティング（特に広告）コストを掛けて、認知度（知名度）をあげ、誰もが知っている有名企業が採用し、さらに導入事例化されたソリューション”のみ”が売れるのが現状です。 そのため、SCSKでは Cato Networks、Catoクラウドの知名度向上に向けた活動を推進しています。 昨年末2023年12月25日（月）から12月31日（日）の一週間、JR東日本品川駅の自由通路（品川コンコース）のデジタルサイネージでOOH（Out Of Home：屋外広告）を実施しました。また、今月2024年1月15日（月）から1月21日（日）の一週間も再度OOHを掲示する予定ですので、もし品川駅をお通りの際は、ご確認いただけると幸いです。

Catoクラウドでは、許可した端末からしかリモートアクセスをさせたくないというご要件に対応する機能として、 デバイス認証(Device Authentication)機能 があります。 これは、 指定した電子証明書(デバイス証明書、別名クライアント証明書)がインストールされている端末からのみ、Catoクラウドへの接続を許可する 機能で、Catoクライアントが対応するすべてのOS(※)にて利用可能です。 ※ Windows, macOS, iOS(iPhone/iPad), Android, Linux デバイス認証機能の詳細や活用方法については後日別記事にてご紹介予定ですが、今回は特によくお問い合わせをいただく iPhoneへの証明書導入方法 について解説します。iPhoneへの導入は他OSよりStepが多く分かりづらいため、参考にしていただけますと幸いです。 前提条件 前提として、 iPhoneでデバイス証明書認証を利用する場合は、iOSの仕様上、MDM等による構成プロファイルの作成が必須 となります。構成プロファイルを用いない設定には対応していないため、ご注意ください。 ※なお、デバイス証明書認証を利用しない場合には、構成プロファイルは必須ではありません。 また、 使用するデバイス証明書およびCA証明書を用意 する必要があります。証明書の用意方法としては、外部の電子証明書発行サービスを利用する方法や、Active DirectoryのADCS機能で発行する方法、OpenSSLを利用しプライベート認証局を構築して発行する方法などがあります。Catoクラウドではどの方法で発行したデバイス証明書でも利用可能です。 接続までの流れは以下となります。 CMAにCA証明書をアップロード MDM等を利用し構成プロファイルを作成 作成した構成プロファイルをiPhoneへ配信 iPhoneに構成プロファイルをインストール CMAで接続テスト設定 iPhoneにCatoクライアントをインストールし接続 本記事では、MDMとしてApple Configuratorを使用し、以下の環境にてテストしています。ご利用のMDMにより画面は異なりますが、設定項目はおおよそ同じですので、参考としていただければと思います。 端末: iPhone SE(第2世代) iOS 16.6.1 MDM: Apple Configurator 2.16 (macOS Ventura 13.6.3) デバイス証明書: 検証用のプライベート認証局で発行 (CMA)CA証明書をアップロード Catoの管理画面(CMA)に、デバイス証明書を検証(Verify)するCA証明書をアップロードします。 ここでは、 デバイス証明書を署名したCAの証明書 をアップロードする必要があります。つまり、デバイス証明書が中間CAから発行されている場合には中間CA証明書、そうでない場合にはルート証明書になります。ご利用の証明書の構成をご確認ください。 アップロードは、CMA の Access > Client Access > Device Authentication の箇所で行います。 「New」ボタンを押し、任意の名前を指定の上、CA証明書をアップロードします。 認証の際は、端末内のデバイス証明書がこのCA証明書で正しく検証できる必要があります。 (MDM)構成プロファイルの作成 Apple Configuratorを開き、ファイル > 新規プロファイルを選択し、構成プロファイルの作成画面を開きます。任意のプロファイル名をつけてください。 各種設定項目がありますが、Catoクライアントで利用するのは、左メニューの「証明書」と「VPN」の2つのみです。 証明書の設定 証明書を2つ設定します。 1. Catoのルート証明書 CatoでTLS Inspectionを行うために必須となる、Catoのルート証明書です。 WindowsやMacOSでは、Catoクライアントのインストール時に自動でインポートされるため特に意識しないのですが、iPhoneではクライアントとセットになっていないため、クライアントとは別にインポートが必要です。このため、この構成プロファイルであわせて配布してしまうのがおすすめです。 このCatoのルート証明書は、下記サイトの「Cato Certificate」より入手ください。 Cato Downloads Easily download the newest Client version from this portal without authenticating clientdownload.catonetworks.com 2. デバイス証明書 デバイス証明書認証で使用する証明書です。 インポートパスワードを設定した .p12形式 でご用意ください。 パスワード欄に、証明書のインポートパスワードを入力します。 VPNの設定 続いて「VPN」に移動し、各設定項目を入力します。詳細はCato Knowledge Baseに公開されていますので、あわせてご確認ください。 Distributing Certificates for Device Authentication and Device Checks 接続名 任意の名前 接続のタイプ カスタムSSL 識別子 CatoNetworks.CatoVPN サーバ vpn.catonetworks.net アカウント Catoテナント名 ※モバイルユーザアカウントではありません プロバイダバンドル識別子 CatoNetworks.CatoVPN.CatoVPNNEExtenstion プロバイダの指定要件 空欄 カスタムデータ 空欄 ユーザ認証 証明書 さらに下にスクロールします。 プロバイダタイプ パケットトンネル 資格情報 プルダウンし、証明書のところで設定した デバイス証明書の名前を選択 ※ここが間違いがちです これ以外の項目はすべてデフォルトとします。 以上で構成プロファイルの作成は完了です。プロファイルを保存します。 (MDM)構成プロファイルをiPhoneへ配信 作成した構成プロファイルを、対象のiPhoneに配信します。配信方法は、MDMからの配信、Eメール添付など、なんでも問題ありません。 今回はiPhoneをUSBケーブルでMacに接続し、Apple Configuratorから直接配信しました。 (iPhone)構成プロファイルをインストール iPhone側で、受け取った構成プロファイルをインストールします。 ※MDM等の設定で、プロファイルが自動インストールされる場合には、以下は不要です 「設定」>「ダウンロード済みのプロファイル」を選択します。 先ほど配信したプロファイルであることを確認し、「インストール」します。 完了画面が出たら、「完了」を押します。 インストールの確認 構成プロファイルが正しくインストールされたかを確認します。 「設定」>「一般」>「VPNとデバイス管理」を開き、「構成プロファイル」の欄に、先ほどインストールした構成プロファイルがあることを確認します。 次に「VPN」を開き、構成プロファイルの中で設定したVPN設定が入っていることを確認します。 これが表示されていない場合、構成プロファイルに何らかの設定誤りがあって、VPN設定が 認識されていないため、プロファイルを見直します。 続いて、配信したCatoのルート証明書を通信に利用できるようにするため、信頼設定します。 「設定」>「一般」>「情報」を最下部までスクロールし、「証明書信頼設定」を開きます。「Cato Networks CA」の横のスライダをON(緑の状態)にしてください。 (CMA)接続テスト設定 接続テストを行うにあたり、デバイス証明書認証の設定を全体に適用すると影響が大きいため、 まずは接続テストを実施するユーザのみに適用する ことをおすすめします。 CMA の Access > Users で、テストを行うユーザを選択します。 User Configuration > Device Authentication で、「Override account Device Authentication settings」にチェックを入れ、証明書認証したいOS(今回はiOS)を選択し「Save」します。 こうすることで、このユーザのみにデバイス証明書認証を有効化できます。 (iPhone)Catoクライアントをインストールし接続 Catoクライアントをインストールします。App Storeからのダウンロードでも、MDMからの配信でも問題ありません。 インストール完了後、アプリを起動し、中央のボタンを押して接続します。 認証画面に遷移します。通常どおりCatoモバイルユーザのアカウント(メールアドレス)とパスワードを入力し、「Continue」を押します。 Connectedの表示となれば成功です! CMAのEventsにも証明書認証が成功した旨のログがでます。 トラブルシュート エラーメッセージが出て接続できない例をご紹介します。 Catoクライアントの認証画面で「Device Certificate is needed」と表示され接続できない デバイス証明書が認識されていません。 以下2点をご確認ください。 配信した構成プロファイルに正しくクライアント証明書が含まれているか。 「設定」>「一般」>「VPNとデバイス管理」>「VPN」の箇所で、 VPNプロファイルが2つできていないか 。 2つできてしまっている場合、構成プロファイルに設定したVPNのパラメータのいずれかに誤りがあり、Catoクライアントがそのプロファイルを参照できていない状態です。パラメータを見直します。 Catoクライアントの認証画面で「Failed to authenticate with Certificate」と表示され接続できない デバイス証明書は認識されていますが、CMAにアップロードされたCA証明書で検証できません。 以下をご確認ください。 デバイス証明書とCA証明書の紐づきが正しいか (異なるCAをアップロードしていないか) 。 よくある例として、デバイス証明書に署名しているのは中間CAなのに、中間CA証明書ではなくルートCA証明書をアップロードしてしまっていないか。 デバイス証明書、CA証明書ともに有効期限内か。 まとめ iPhoneでのデバイス証明書認証は、MDMの利用が必須であることから、他OSより少し手間がかかります。 MDMでうまくいかない場合には、切り分けとして、シンプルなApple Configuratorでの構成プロファイル作成をお試しください。

新年明けましておめでとうございます。SCSKの池田です。 新年早々、能登での大地震があり、今この時点においても余震が続いております。 亡くなられた方々に心からお悔やみを申し上げるとともに、被災された皆様、ならびにそのご家族の皆様に心よりお見舞い申し上げます。 皆様の安全と被災地の一日も早い復興を心よりお祈り申し上げます。  さて前回は、スプリットブレインを防ぐために「Quorum/Witness」機能が有効であることをお伝えしました。2台のサーバで構成するが故に、どちらのサーバがActiveであるかを判断する機能が必要だったというお話しでした。 7回目の今回は、なんと たった1台で可用性を向上 させることができるLifeKeeperの姉妹製品 Single Server Protection をご紹介します。 Single Server Protectionとは Single Server Protection（略してSSPとも呼びます） とは、（くどいようですが） 1台のサーバで可用性を高めることができる 製品なのですが、どのようにして実現しているのでしょうか。 構成と動作の流れはこんな感じです。 前提：1台のサーバにSSPと冗長化したいミドルウェアを実装しておく (1)SSPが冗長化対象のミドルウェアの状態を定期的に監視 (2)ミドルウェアの異常を検知すると、ミドルウェアを再起動し、正常状態に戻るかを確認 (3)正常状態に戻った場合は、処理はここで終了。まだ異常事態が続いている場合はOSを再起動 (4)OS再起動後はSSPの機能により、対象のミドルウェアなど、自動起動し、正常状態に戻ったことを確認   動きとしては、とてもシンプルですね。 以前「 なぜAWS(パブリッククラウド)でLifeKeeperが有効なのか！ 」の回でもお伝えしましたが、AWSですと「責任共有モデル」の考え方により、ミドルウェアレイヤーはユーザー側の責任範囲となります。SSPはLifeKeeper同様に、見落としがちなミドルウェアの可用性をシンプルな仕組みで安価に高めることのできる製品なのです。 SSPはコスパが良い！ 直前で「安価」とお伝えしましたが、SSPはコスパがすごく良い製品なんです。 サイオステクノロジーが公開している定価をご覧いただきますね。 製品名 定価 Single Server Protection for Linux \200,000 Single Server Protection for Linux サポート1年 \50,000 Single Server Protection for Windows \200,000 Single Server Protection for Windows サポート1年 \50,000 桁が間違っているのではないかというレベルのお安さですよね！ 1台構成ですので、 サーバの初期費用もランニングコストも1台分で済みます し、 導入する ミドルウェアのライセンス費や保守費も1台分で済みます 。 さらにこの製品には、LifeKeeperでは有償オプション製品となるARKも一部無償で同梱されているというサービスっぷり！ ただしLinuxとWindowsでは同梱されているARKが異なりますのでご注意くださいね。 製品名 Red Hat Enterprise Linux Windows Apache Web Server Recovery Kit 〇 ー Microsoft IIS Recovery Kit ー 〇 DB2 Recovery Kit 〇 ー Oracle Recovery Kit 〇 〇 MySQL Recovery Kit 〇 ー PostgreSQL Recovery Kit 〇 〇 SQL Server Recovery Kit 〇 〇 Sybase ASE Recovery Kit 〇 ー NFS Server Recovery Kit 〇 ー Network Attached Storage Recovery Ki 〇 ー WebSphere MQ Recovery Kit 〇 ー それと保守についても注意が必要です。LifeKeeperの場合は、重大障害発生時に24時間365日のサポートを受けることができますが、 SSPの場合は平日日中サポートのみとなってしまいます。 GUIはLifeKeeperとほぼ同じで判りやすい LifeKeeperの管理GUIはとても判りやすいことで有名（？）ですが、SSPは、LifeKeeperの姉妹製品だけあって、GUIの判りやすさも受け継いでいます。以下の様にリソースの依存関係もツリー構造で表現されているので、視認性が高く、これまでLifeKeeperの運用をされていた方はもちろんのこと、初めてお使いになる方でも、すぐに使いこなせる様になると言っても過言ではありません。 まとめ 今回は、LifeKeeperの姉妹製品であるSingle Server Protectionについてご紹介しました。コスパがものすごく良い製品ですので、LifeKeeperほどしっかりした可用性は必要ないけど、AWSなどパブリッククラウドではカバーしないミドルウェア領域までの可用性を高めたいとお考えのシステム担当者様にはうってつけな製品ではないでしょうか？ まとめますと SSPは ・たった１台で可用性を高められる ・ライセンス、保守費も安く、一部のARKも同梱されているのでコスパがとても良い ・サーバ自体の費用やミドルウェアのライセンス、保守費も1台分でOK ・LifeKeepeの管理GUIとほぼ同じなので、導入や運用移行の敷居が低い ・保守は平日日中のみなので注意が必要 次回は、第６回でお伝えした Quorum/Witness の詳細について、もう少し掘り下げてお伝えしようと思います。 乞うご期待！！ SCSK　LifeKeeper公式サイトはこちら

こんにちは、自称ネットワークエンジニアの貝塚です。 AWS環境において、会社間でVPC同士を接続したいということはないでしょうか？ 多くの場合、以下の記事で解説されているVPCエンドポイント(PrivateLink)を用いるのが最適な手段ではないかと思います。 Amazon VPC エンドポイントについて整理してみる VPC エンドポイントの役割について説明したいと思います。 blog.usize-tech.com 2023.12.10 PrivateLinkを使用すれば互いに相手側のIPアドレスは隠蔽されるので、IPアドレス被りを心配する必要もなく、私のようにネットワーク設計を考える立場の人間からするととてもありがたいサービスです。 PrivateLinkが使えない場合どうするか？ しかし、PrivateLinkはTCP通信にしか対応していないため、UDPを通したい場合には使用できません。 また、通信対象サーバが複数ある場合は、原則、サーバごとにPrivateLinkの作成が必要になりますし、逆方向の通信が発生する(A社からB社方向へコネクションを開始するだけではなく、B社からA社方向へコネクションを開始する)場合、逆方向のPrivateLinkも必要です。このように通信要件が多くなるとPrivateLinkの管理が逆に大きな負担になってきます。(PrivateLinkのエンドポイントサービス側にはELBが必要なので、料金面の負担も大きくなるかもしれません) NATして互いのIPアドレスを隠蔽できる。(ソースNATとデスティネーションNATが両方できる) UDPを通せる。 双方向通信に対応できる。(1対1NATができる) インターネットは通らないようにする。 上記条件を満たすソリューションとして 接続したいVPCの間にNAT用EC2インスタンスをデプロイした中間VPCを設け、VPC Peeringで接続する方式 を考えてみました。(下図) 今さらNATインスタンス ……非常に泥臭いですね。 EC2を1台管理する手間が増えますし、(直接聞いたことはないですが)AWSはEC2インスタンスで1対1NATすることをあまり推奨していないような感じがします。 が、必要とあらば仕方ありません。 以下、NATインスタンス以外(VPC、サブネット、ルートテーブル、VPC Peering、NATインスタンス以外のEC2インスタンス、EC2に適用するセキュリティグループ、など)は既に構築済みという前提で、NATインスタンスの構築手順を解説します。 VPC Peeringの構築やVPC Peeringした際のルートテーブルの設定などは、インターネット上にブログ記事が多数存在しますので、それらを調べてみてください。 また、インスタンスへのアクセス手段も本記事では解説しておりませんが、VPC内にエンドポイントを作成してセッションマネージャーで接続する、インターネットゲートウェイをアタッチしてインターネットからsshするなどでアクセスできるようにしてください。 EC2インスタンス作成 Linux (Amazon Linux 2023)のAMIからEC2インスタンスを作成します。 作成時に「高度なネットワーク設定」を開き、セカンダリIPを「自動で割り当てる」、IP数は今回2を指定します。 その他は特に注意事項ありません(インスタンスにアクセスできるように適切にセキュリティグループやIAMインスタンスプロファイルの指定はしてください)。 割り当てられたセカンダリIPは、EC2インスタンスの「ネットワーキング」タブから確認することができます。今回の検証では、10.33.1.145と10.33.1.151が割り当てられました。 iptablesの設定 NATインスタンスにログインしてNAT設定を行います。 今回は、NAT機能を実現するためにiptablesを使用しますが、Amazon Linux 2023にはデフォルトでインストールされていないので、yumを使用してインストールします。 sudo yum install -y iptables-services iptablesを起動します。 sudo systemctl start iptables IPパケットを中継する必要があるので、IPフォワーディングを有効にします。 sysctl コマンドで有効にしただけでは再起動で設定が消えてしまうので、/etc/sysctl.conf にも書き込んでおきます。 sudo sysctl -w net.ipv4.ip_forward=1 | sudo tee -a /etc/sysctl.conf 次に、NATの設定を入れます。 A社のIP 10.32.1.157を中間VPCの10.33.1.145にアドレス変換するようにします。 10.32.1.157が送信元の時に10.33.1.145に変換する設定(ソースNAT)と、10.33.1.145が宛先の時に10.32.1.157に変換する設定(デスティネーションNAT)の2行必要です。 sudo /sbin/iptables -t nat -A POSTROUTING -s 10.32.1.157 -j SNAT --to-source 10.33.1.145 sudo /sbin/iptables -t nat -A PREROUTING -d 10.33.1.145 -j DNAT --to-destination 10.32.1.157 同様に、B社のIP 10.34.1.125を中間VPCの10.33.1.151にアドレス変換するようにします。 sudo /sbin/iptables -t nat -A POSTROUTING -s 10.34.1.125 -j SNAT --to-source 10.33.1.151 sudo /sbin/iptables -t nat -A PREROUTING -d 10.33.1.151 -j DNAT --to-destination 10.34.1.125 念のためここまでに入れたNAT設定を確認してみます。以下のようになっているはずです。 [ec2-user@ip-10-33-1-124 ~]$ sudo iptables -vL -t nat Chain PREROUTING (policy ACCEPT 2 packets, 702 bytes)  pkts bytes target     prot opt in     out     source               destination     0     0 DNAT       all  --  any    any     anywhere             ip-10-33-1-145.ap-northeast-1.compute.internal  to:10.32.1.157     0     0 DNAT       all  --  any    any     anywhere             ip-10-33-1-151.ap-northeast-1.compute.internal  to:10.34.1.125 Chain INPUT (policy ACCEPT 0 packets, 0 bytes)  pkts bytes target     prot opt in     out     source               destination Chain OUTPUT (policy ACCEPT 422 packets, 29626 bytes)  pkts bytes target     prot opt in     out     source               destination Chain POSTROUTING (policy ACCEPT 422 packets, 29626 bytes)  pkts bytes target     prot opt in     out     source               destination     0     0 SNAT       all  --  any    any     ip-10-32-1-157.ap-northeast-1.compute.internal  anywhere             to:10.33.1.145     0     0 SNAT       all  --  any    any     ip-10-34-1-125.ap-northeast-1.compute.internal  anywhere             to:10.33.1.151 OS再起動後もiptablesを自動起動しNAT設定が反映されるようにします。 sudo systemctl enable iptables sudo service iptables save 疎通確認 A社EC2から10.33.1.151にpingを実行してみます。 B社EC2でtcpdumpを実行してみると、10.33.1.145からpingが来ているので、意図通りのNATができていることが分かります。 B社EC2から10.33.1.145にpingを実行してA社EC2でtcpdumpを実行してみると、逆方向も確かに10.33.1.151からpingが来ており、意図通りのNATができていることが分かります。 まとめ 以上、NATインスタンスの構築手順でした。 なお、ここで示したソリューションは検証用のものであり、実際にビジネスで使用する場合にはNAT以外にも例えば以下のような考慮点があります。ご注意ください。 中間VPCのIPアドレスは両社で合意しておく必要がある。 VPC間通信のセキュリティ。 NATインスタンスは誰が管理するのか。(NATインスタンスを管理している側は容易にセキュリティ侵害できてしまう点に注意)

こんにちは。SCSKの清水です。 Google Cloud のカンファレンスイベント Google Cloud Next Tokyo’23 が国内4年ぶりに東京ビックサイトにて開催されました。 Platinumスポンサーとして当社も出展をした本イベントですが、当社登壇のパートナーセッション「製造業 DX 関係者必見！Google AI を組み込み、生産プロセスを変革するまでの七転び八起き」では CSAT（顧客満足度）にて最高評価をいただくことができました。 製造業向けの内容としてご紹介をしましたが、 AIの活用に悩まれる全企業の皆様 に向けて是非知っていただきたい内容になります為、 改めて本ブログを通して多くの皆様へ有益な情報をお届けできればと思います！ Google Cloud Next Tokyo ’23　セッションについて Google Cloud Next Tokyo ’23は、基調講演、セッション、ブレイクアウトセッション、ハンズオンセッション、Expoブース、Innovators Hiveと盛りだくさんの内容で構成されていました。各セッションではテーマは様々でしたが、やはりAIに関する内容が多い印象を持ちました。そんな中、SCSKもパートナーセッションでやはりAIというテーマで40分間登壇をしております。 勿論リハーサルもあったのですが、やはりその時に前に立つのと本番で前に立つのでは視界も緊張感も大違いですね…!!! 圧巻の景色を前に、お集まりいただいた観客の皆様へ一つでも情報を持ち帰りいただきたい一心で当日ご説明いたしました。 当社はExpoブースへの出展も行いました。AIサービスのデモ展示は当日非常に好評でしたのでこちらも是非ご確認ください！ 【GCP】【AIML】Google Cloud Next Tokyo ’23に出展しました!!!!! Google Cloud のカンファレンスイベントGoogle Cloud Next Tokyo'23が東京ビックサイトにて開催されました。 2日間に及んだGoogle Cloud Next Tokyo'23での当社の出展内容をご紹介します。 blog.usize-tech.com 2023.11.24   SCSKセッションの中身をご紹介 製造業の某社様に向けて行った実際の導入事例を通して、 Google AIを組み込み生産プロセスを変革するために考えるべきポイントや、リアルな躓きや起き上がりを語りました。 大きく5つの章立てに分かれており、全量を文字ベースで見るのは大変だと思いますのでそれぞれ簡潔にご紹介いたします。 なお、当日の内容はオンデマンド配信としてGoogle Cloud Next Tokyo ’23の公式HPに掲載されておりますので、 フルバージョンはこちらからDay2のパートナーセッションをご確認ください。 Google Cloud Next Tokyo ’23 【Google Cloud Next Tokyo ’23】2023 年 11 月 15 - 16 日に東京ビッグサイトで開催 cloudonair.withgoogle.com ※登録がお済でない方は、招待コード：FY23nx_P030　をご入力の上ご登録ください。 本セッションでお伝えしたかった事 当社セッションで何をお伝えしたかったのか、ずばり結論から申し上げます。 「生産プロセスが抱える課題に対して、省人化・コスト削減・生産性向上を当社と共に実現する方法 」 です。 はい、ピンと来ていない方も大丈夫です。順を追って紐解いていきましょう！ 私たちが考える製造業の課題 まずは、製造業界を取り巻いている課題を整理していきます。製造業様向けのセッションでしたので、「製造業の課題」と書いてありますが、内容はその他業界の皆様にも通ずる課題と思っています。 上図はGoogleのGenAI「Bard」にも聞いた結果となっています。 少子化の影響で労働力人口の減少は不可避（総務省のデータでは2020年~2040年にかけて20％減少）である事、労働力人口減少に拍車をかけるように熟練工や技能人材が退職する等の影響で技術継承が難しくなってきている、さらにその熟練工や技能人材を抱えるために人件費がかかる　といった、労働力に関わる問題が顕在化してきています。これらの課題にさらされている企業では、 労働力人口減少に対しての対策を考え続けなければならない 属人化する業務の置き換わりを検討する余地が残っている 本当に人がやるべきことか業務の仕分けを行う必要がある という状態になっていると思っています。 では、どう解決していくか。弊社では一例として下記のような業界動向も踏まえて、AIの活用にヒントがあると考えています。 DX推進というキーワードでIT投資が進んできた ⇒ クラウドに投資をしている企業も多数存在 ⇒ クラウドではAIに必要なデータを蓄積する基盤も用意しやすい ⇒ 昨今のGenAI登場によりクラウドAIサービスの拡充も進んできた ⇒ 今まで高かったAIへの参入障壁が下がって上記の課題解決を図りやすくなった！   労働力に関わる問題はクラウド利用が進んできた今こそ、AIによる解決を図ることができそう   AIサービスによる自動化の可能性 AIで解決を図れそうだと言っても実際、「AIで具体的にどんなことができるの？？」と思われる方が大半かと思います。GoogleのAIでは幅広いタスクに対して、それぞれ処理を行ってくれるAIサービスは既にかなり出てきている状態です。ここではそのうちの一つ、製造業の外観検査工程を手助けする精度の高いAIを紹介いたします。 製造業のお客様に多い、「不良品を保管していないので、AIに使う画像も用意できない…」、「工場環境はインターネットに繋がっていないのでクラウドAIサービスを使うことができない」等の課題を解決しながら高い性能を誇るという、これだけあれば良いじゃん！となりかねない優れものになります。弊社も自信をもって数々の検証を実施して参りました。 しかし、実際は本番化まで至らないパターンが多かったということでたくさん転んできました。 AI処理以外に画像をアップロードする手間が残ってしまう 検査対象が細かいので、画像処理が必要 目検よりも費用対効果が見込めない etc… これらは一例にすぎませんが、なぜ本番化につながらないのか弊社なりに学んできました。 結局優れたAIだけでは、課題解決ができない AI単体で課題解決できるケースはかなり少なく、実際にAIを業務に活用する際には３つのポイントが重要です。 AIがどの工程のどの作業を担うのかを決めないといけない（AI処理） AIに使用するインプットデータを整えることが必要（AI処理の前工程） インプットデータや処理したデータを蓄積して活用する（AI処理の後工程） これらを全て見据えることで、予算化も含めてAIの導入検討ができるようになると学んできました。 AIによる課題解決を図る場合は、AI処理・AI処理の前工程・後工程　これらすべてを見据えて進めることが重要   導入事例のご紹介 ご紹介した事例は「某製造業様へ行った外観検査ソリューション導入プロジェクト」となります。 お客様は製品の外観検査工程において、こんな背景と課題を抱えていらっしゃいました。 製造パーツのワレ検査を目検で実施している 技能人材、個人の検査スキルに頼って検査している 上記に伴い製品を撮影・データを蓄積する環境は無い状態 これらの背景・課題に対して実施した内容はシンプルです。 外観検査工程にAIを組み込み省人化 データドリブンな工場運営の実現 これにより原価削減・品質向上・AIを利用したマネタイズまで見据え、課題解決を図ることができそうという事で進めて参りました。 では実際どのような解決策となったのか。下図をご覧ください。 前章の学びをしっかりと活かして、「外観検査のクラウドAI部分に留まらない、Input/Outputデータを意識した製造工程の確立」を図ることで成功へと繋げました。弊社としてもこれまで持っていなかった知見の獲得につながった部分もあり、「製造現場へのAI導入」のケイパビリティを獲得することに成功しました。これからもより一層、皆様へAI導入のご支援をして参ります。 AI処理前後も検討/導入する事で課題解決に成功。SCSKはAI導入の新たな知見を獲得し全体の企画立案と推進を行うことが可能に！ ただ、 この図もいきなりポンと出てきたわけではありません 。 お客様のご協力はもちろん、Google Cloud サービスの活用や協業企業とも協力しながら 文字通り七転び八起き、「転んで起き上がる」を繰り返して この全体像に辿りつきました。 ここで詳細はお伝えしませんが、セッション当日は一つ一つどうやって実現に至り、 最終的にお客様へどのような結果をもたらすことに成功したか紹介しています。是非オンデマンド配信にてご覧ください。 Google Cloud Next Tokyo ’23 検索 SCSKを選ぶ理由 前章で、SCSKはAI導入に関するケイパビリティを獲得したという内容をお伝えしました。 ここで一つ、こんな疑問が浮かぶ方もいらっしゃるかもしれません。 「導入を支援してくれるのは分かったけど、結局どこまで支援してくれるのSCSK？」 ご安心ください！！弊社ではクラウドAI体験から、運用保守までサポートさせていただく事が可能です。 使い始めから使いこなすまで、サポートいたします！ 勿論ですが、既に取り組まれている範囲もお伺いした上で、お客様毎に必要なものを必要なだけご提案させていただきます。 AIというのはビジネスへの活用、業務への組み込み・適用が難しいサービスの一つだと弊社では考えておりますし、実際悩まれている企業の方々も多くいると存じます。課題解決を図ることができそうなベンダー様、あるいは弊社へご相談いただくことで、今お抱えのお悩みが解決されることを願っております。 USiZEパブリッククラウドモデル(Google Cloud)│SCSK株式会社｜サービス｜クラウド移行だけでは描けない、理想のDXを実現する Google Cloud の導入支援から保守運用・最適化まで、ワンストップでご提供するサービスです。 SCSKのノウハウや体制を有効活用してお客様のビジネスに合わせてお届けし、お客様と一緒にDX推進を行います。 www.scsk.jp   おわりに いかがでしたしょうか？ 製造業の企業の皆様だけでなく、 AIを活用したいと考えているすべての企業様にお伝えしたい内容 でした。 当日ご参加いただいた企業の皆様には満足をいただけた結果となり、非常に嬉しく思います。 オンデマンド配信が公開されたことをきっかけに、より多くの方々に情報が届けばと思いこのブログを執筆いたしましたので、 是非、同様のお悩みをお抱えの方々にご紹介いただくと共に、この内容が皆様のAI活用の成功への一助となれば幸いです。 最後まで読んでいただきありがとうございました！

こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。よろしくお願いします。 東京リージョンのNetwork Firewallでアウトバウンド(Egress) TLS インスペクションが使えるようになりましたね。 AWS Network Firewall egress TLS inspection is now available in all regions aws.amazon.com TLSインスペクションとは SSL/TLSで暗号化された通信内容をチェックする機能です。 HTTPSなどのSSL/TLSで保護された通信は、クライアント-サーバ間で通信内容が暗号化されているため、通常、中継するネットワークデバイスで通信内容をチェックすることができません。SSLサーバ証明書をうまく使って中継デバイスで通信内容をチェックできるようにしたのがTLSインスペクションです。   インバウンド(Ingress) TLSインスペクション これまで、AWS Network Firewallは、インバウンド(AWSのドキュメントではIngressと呼ばれる)のTLSインスペクションにのみ対応していました。Ingress TLSインスペクションは、自サイトのウェブサーバ等を保護するために使用されます。たとえば自サイトでwww.example.comというサーバ証明書をインストールしたサイトを運営しているとしたら、Network Firewallにも同じwww.example.comの証明書をインストールしてやります。Network Firewallはウェブサーバに向かう通信を、そのサーバ証明書を用いて復号化し、検査した後に再びサーバ証明書を用いて暗号化して、何食わぬ顔でウェブサーバに転送します。 検査したい対象サーバのサーバ証明書を入手しなければ検査ができないので、必然的に自身の管理下にあるサーバしか検査対象にできませんでした。   アウトバウンド(Egress) TLSインスペクション 今回、新たに対応したのは、アウトバウンド(AWSのドキュメントではEgressと呼ばれる)方向、つまり、自分たちの管理下にあるクライアントPCが、自分たちの管理下にないSSLサーバ証明書をインストールした外部のウェブサーバと通信するときに通信内容を検査できるようになりました。 方式としては、Network FirewallがクライアントPCに代わって外部のウェブサーバwww.example.comとTLS接続を行い、Network Firewallは自身でwww.example.comのサーバ証明書を発行してクライアントPCとの間にTLS接続を確立します。Network FirewallがクライアントPCとのTLS接続、サーバとのTLS接続、両方を終端するため、Network Firewallで通信内容が検査できるということになります。 動的にサーバ証明書を発行するためにNetwork Firewallには認証局(CA)証明書をインストールする必要があります。 以下、Egress TLS インスペクション機能を検証したときの設定手順と動作確認について説明しますが、Network Firewall自体は既に作成したことがあるか、他のドキュメントを参考にして新規作成できることを前提に、キモとなる部分のみを解説します。 AWS Network Firewallについて学んでみた！ AWS Network Firewallについて、学んだことをアウトプットしたいと思います。 blog.usize-tech.com 2023.12.24   Egress TLSインスペクション設定の流れ Egress TLSインスペクション機能検証のために実施した設定は以下の通りです。Network Firewall自体は既にデプロイされている前提で、TLSインスペクションの設定手順のみを記載しています。 プライベート認証局のルート証明書を作成する ACMに、作成したルート証明書をインポートする Network FirewallのTLS検査設定を作成する Network Firewallのファイアウォールポリシーを作成する Network Firewallにファイアウォールポリシーを関連付ける   動作確認の流れ Egress TLSインスペクションの動作確認で実施した内容は以下の通りです。 クライアントPCにルート証明書をインストールする クライアントPCからHTTPSアクセスして証明書を確認する Network FirewallのルールグループにHTTPの内容をチェックするルールを追加する HTTPの内容をチェックできていることを確認する   Egress TLSインスペクション設定 プライベート認証局のルート証明書を作成する Egress TLS インスペクションには、プライベート認証局(CA)のルート証明書が必要になります。 作成は、こちらの記事を参考にさせていただきました。 プライベート認証局によるサーバー証明書の発行 プライベート認証局を構築して、Webサーバー向けのサーバー証明書を発行する手順について紹介します。認証局の証明書をWebブラウザやOSの証明書ストアに読み込むことで、自己署名証明書を使ったサーバーに、警告なしにアクセスすることができます。 pvision.jp 「4.2 認証局の証明書の作成」まで実行し、証明書と秘密鍵を作成します。 ACMに、作成したルート証明書をインポートする AWSマネジメントコンソールからACM(AWS Certificate Manager)を起動して「インポート」をクリック、「証明書本文」と「証明書のプライベートキー」に作成した証明書、秘密鍵を張り付けてインポートを完了させます。   インポートした証明書は以下のようになりました。 Network FirewallのTLS検査設定を作成する AWSマネジメントコンソール、ネットワークファイアウォールのTLS検査設定から「TLS検査設定を作成」をクリックします。 「アウトバウンド SSL/TLS インスペクション用の CA 証明書」で、インポートしたCA証明書を選択します。 「TLS 検査設定の詳細」を埋めた後、スコープ設定で検査対象とする送信元/送信先IPとポートを指定します。検査対象としたいトラフィックの範囲をきっちり定義してあげましょう。ここでTLS以外のトラフィックも含めてしまうと、それらは正常に通信できなくなってしまいます。基本的には送信先ポートを443番のみに限定しておくのがよいでしょう。 以降の設定項目も適切に入力して、TLS検査設定を作成します。 Network Firewallのファイアウォールポリシーを作成する ファイアウォールポリシー作成時にTLS検査設定を指定します。既に作成済みのファイアウォールポリシーにTLS検査設定を追加することはできないので、使用中のファイアウォールポリシーがある場合はあきらめてファイアウォールポリシーを作り直します。 作成途中で「TLS検査設定を追加」というステップがありますので、先ほど作成したTLS検査設定を指定します。それ以外は通常のファイアウォールポリシー作成と同様の手順で、ファイアウォールポリシーの作成を完了させます。 Network Firewallにファイアウォールポリシーを関連付ける 作成したファイアウォールポリシーをNetwork Firewallにひもづけます。 手順はNetwork Firewallのドキュメントなどをご参照ください。   動作確認 クライアントPCにルート証明書をインストールする プライベートCAの発行したサーバ証明書が提示されると、クライアントPCのウェブブラウザで警告が出てしまうので、クライアントPCにはルート証明書をインストールします。 下記サイトを参考にして、「プライベート認証局のルート証明書を作成する」のところで作成したルート証明書を、動作確認に使用するクライアントPCにインストールしました。 Windows環境にルート証明書をインストールする方法 knowledge.digicert.com クライアントPCからHTTPSアクセスして証明書を確認する クライアントPCからウェブサーバにHTTPSアクセスします。 今回は、自前で立てたウェブサーバの前にELBを置き、ACMで発行した証明書をELBにインストールしてHTTPS化しています。 まずはTLSインスペクション設定前の状態を確認しておきます。クライアントPCのウェブブラウザからこのウェブサーバにアクセスして証明書を確認してみると、たしかにAmazon(ACM)が発行した証明書です。 次に、TLSインスペクション設定後にアクセスし証明書を確認します。発行者(Issued By)が先ほど作成したCAになっているのが分かります。うまくいっているようですね。クライアントPCにCAのルート証明書をインストールしているので、証明書の警告も表示されません。 Network FirewallのルールグループにHTTPの内容をチェックするルールを追加する Network FirewallのHTTPチェックのルールで、HTTPSの通信をチェックできるようになっているはずです。今回の検証では、URIをチェックしてindex.htmlへのアクセスはドロップし、scsk.htmlへのアクセスは許可するルールにしてみます。 ルールグループのルールに、以下のSuricata互換ルールを追加しました。TLSは終端しているのでプロトコルにはtlsではなくhttpを、ポート番号はhttps通信のデフォルトでTCP 443を使っているので443を指定しています。 drop http $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Detected access to tcp port 443 /index.html"; http.uri; content:"index.html"; sid:1000102; rev:1;) alert http $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Detected access to tcp port 443 /scsk.html"; http.uri; content:"scsk.html"; sid:1000111; rev:1;) pass http $HOME_NET any -> $EXTERNAL_NET 443 (http.uri; content:"scsk.html"; sid:1000112; rev:1;) HTTPの内容をチェックできていることを確認する /index.htmlにアクセスしてみます。以下の通りコンテンツは表示されません。 /scsk.htmlにアクセスしてみます。こちらは問題なくコンテンツを表示できました。 Network Firewallのアラートログを確認したところ、以下のログが確認できました。意図通りにHTTPの内容をチェックし、URIに基づいて通信を制御できていることが分かります。   まとめ Network FirewallのEgress TLS Inspectionについて、簡単な検証の結果をまとめてみました。 AWSのマネージドサービスを使って高度なネットワークセキュリティを確保したいというニーズはわりとあるのではないかと感じているので、Network Firewallが今後さらに機能を充実させていくことを期待しています。

こんにちは、SCSK　池田です。 早いもので2023年も終わりを告げようとしています。皆さんにとってはどのような１年でしたか？ 私は、このTech HarmonyでLifeKeeperに関するブログを投稿し始めた思い出深い１年となりました。 さて前回は、前田さんより、AWS環境におけるLifeKeeperで対応可能ないくつかの接続方法についてお伝えしました。 ６回目の今回は、HAクラスター構成の敵とも言える「 スプリットブレイン 」についてLifeKeeperでどのよぅな対策がなされているのかについてお伝えします。 スプリットブレインとは？ 「スプリットブレイン？」「脳が分かれる？」。またまた聞きなれない用語が出てきました。「 スプリットブレイン 」とはどのような状態なのでしょうか？ HA クラスターシステムは、多くの場合において、2台のサーバでアクティブ-スタンバイの構成となり、2台のうちのどちらか一方だけのサービスが起動している状態です。ところがある条件下において、2台ともがサービスを起動しようとしてしまい、正しくサービスが提供できなくなることがあります。 この状態のことを「 スプリットブレイン 」もしくは「 スプリットブレイン シンドローム 」と呼びます。 本来1台だけでサービス提供するところ、 誤って2台が提供しようとして障害になってしまうのは問題だね ではどんな時にスプリットブレインが起きてしまうのでしょうか？ まず2台のサーバでクラスタを構成している前提とします。2台はお互いの死活状態を確認しています。 この動作をハートビートと言いますが、ネットワークの障害など何らかの原因によって、お互いの死活状態を確認できなくなった場合に、それぞれのサーバは、相手のサーバが停止しサービス提供ができなくなったと判断し、自らが稼働系になろうとします。これによってスプリットブレイン状態になってしまうのです。 スプリットブレイン状態となった時に一番怖いのが、両方のサーバから共有ディスクに書き込んだ場合です。これが起きてしますと最悪共有ディスク上のデータで不整合が発生して、データ破損に繋がってしまいます。 せっかくのHAクラスタ構成なのに データの不整合が起きてしまうのは避けたいわ LifeKeeper では、この様なスプリットブレインを発生させないために、Quorum/Witness(クォーラム/ウィットネスと呼びます) をいう機能を利用することが出来ます。 Quorum/Witnessとはなに？ また新しい言葉が出てきましたが「 Quorum/Witness 」とは、スプリットブレインが発生した場合に、どちらのサーバが稼働系になるべきかを判断する為の機能となります。 「Quorum」の主な機能は、多数決の仕組みを使って稼働系となるべきサーバを決定する機能です。「Witness」は障害が発生したノードのステータスについて「セカンドオピニオン」を取る機能です。「Quorum」による多数決だけでは、本当に稼働すべきサーバか判断が付きかねる場面において、障害が発生していると思われるサーバについて、Witnessサーバの「セカンドオピニオン」を取ることで、より確実な判断をすることができるようになります。 まずは一般的な障害シナリオを見てみましょう。 シナリオ１　サーバAと他の全ノードとの間の通信に障害発生(サーバAに障害発生) シナリオ２　サーバAとサーバBの間の通信で障害発生 次に、サーバ間の通信で障害が発生したものの、Quorum/Witnessサーバがいるお陰で、不要なフェイルオーバを抑止するパターンをご紹介します。 シナリオ２の場合では、もしもQuorum/Witnessサーバが存在しなかった場合は、サーバAで継続してサービス提供可能にも関わらず、フェイルオーバが発生してしまい、一時的ではありますが、サービスが利用できない時間帯ができてしまいます。 Quorum/Witness機能を実装するために必要な費用及び維持していく費用と、要求する可用性レベルとの天秤になるポイントとなりますので、お客様との十分なすり合わせが必要となります。 まとめ 今回は、Quorum/Witness機能についてご説明しましたがいかがでしたでしょうか？ システムとしてデータの整合性や一貫性が損なわれてしまうのは一大事ですよね。 非常に重要な機能ではありますが、LifeKeeperではQuorum/Witnessがオプションとして用意されているので、簡単に組み込むことができます。 まとめますと Quorum/Witnessは、スプリットブレイン対策として有効な機能 Quorumは、多数決により、どのサーバでサービス提供すべきかを判断する機能 Witnessは、第三者を介して相手ノードの状態についてセカンドオピニオンを取る機能 次回は、「たった１台で可用性を高められる！？　～ Single Server Protection ～」についてお伝えします。お楽しみに！！ 良いお年を！！

こんにちは、SCSK株式会社の大石です。 Zabbixにはディスカバリ機能があり、指定のネットワーク内から監視対象を見つけてホスト登録したり、テンプレートをリンクさせることもできますが、指定の時間で更新をかけることができなかったりホストを削除したい場合、すぐに消す場合はIPアドレスを除外→ホスト削除の操作が必要だったり、ちょっとだけ操作が必要になっています。 個人的にはホストだけ消して、IPアドレス除外を忘れて、後々復活。。。なんてことをやりそうです。 hostsファイルと同期取っておけば楽なのでは？と思いhostsファイルと同期とれるようにしてみました。 環境準備 以下のサーバを構築しておきます。 ZabbixServer6.0 (Redhat9)  監視対象: WindowsServer 2019 x 1 監視対象: Redhat9 x 2（うち1台はAgent無) 今回はpythonを使用するため、ZabbixServerにはpython3をインストールしておきます。 python3では以下のライブラリを使用します。 pyzabbix(zabbixのAPI使用する) pandas(hostsファイル加工用) subprocess(OSコマンド実行用) pyzabbixとpandasはインストールが必要なので、以下のコマンドでインストールしておきます。 ※あらかじめpipのインストールが必要です。 pip install pandas pyzabbix 実装 pythonでスクリプトを書いていきます。 まず、使用するライブラリをインポートしておきます。 import pandas as pd import pyzabbix import subprocess pyzabbixには、ZabbixWebコンソールのURLとログイン情報を指定します。 # Zabbixログイン情報 zapi = pyzabbix.ZabbixAPI("http://172.23.32.191/zabbix") zapi.login('Admin','zabbix') hostsファイルを取得し、Zabbixのホストには使用できない特殊文字を”＿”に変換します。 # /etc/hostsファイル取得 df = pd.read_table("/etc/hosts",sep="\s+",header=None, index_col=None) # ホスト名の列に特殊文字(ドット、ハイフン、アンダーバーを除く)がある場合、アンダーバーに置換 df[1]=df[1].replace(r'[^a-zA-Z0-9_.-]','_',regex=True) hostsfile=df.iloc[:,[0,1]] ZabbixServerのホスト登録する関数です。 # ZabbixServer登録 def zabbix_regist(hostname,ipaddr,templateid): zapi.host.create( host=hostname, interfaces=[ { "type":1, "main":1, "useip":1, "ip":ipaddr, "dns":"", "port":"10050" } ], groups=[ { "groupid":"23" } ], templates=[ { "templateid":templateid } ] ) hostsファイルから、IPアドレスとホスト情報を取り出し、接続可否、OSの種類(WIndowsかLinux)などで振り分けて、登録します。 接続可能で、ZabbixAgentが使用できれば、WindowsとLinuxで分岐させて各Windows用Linux用でテンプレートを登録し、Agentが使用できない場合は、Pingテンプレートを割り当てます。 def main(): # hostsファイルから、1行ずつ2列目(ホスト名)を引数に、ZabbixServerからホスト情報を取得 for index,row in hostsfile.iterrows(): hosts=zapi.host.get( filter={ "host":[row[1]] } ) # ホスト情報がZabbixに登録されていない場合、対象のマシンの情報を取得する if not hosts: # fpingで接続状況を確認 ping_result=subprocess.run(["fping","-r","1",row[0]],capture_output=True,text=True).stdout # 接続できる場合、ZabbixAgentの有無を確認 if ping_result.find("alive"): zabbixagent_ping=subprocess.run(["zabbix_get","-s",row[0],"-p","10050","-k","agent.ping","-t","1"],capture_output=True,text=True).stdout # ZabbixAgentが起動されている場合、LinuxかWindowsか確認し、それぞれのOS事のテンプレートを指定し、ZabbixServerに登録 if zabbixagent_ping: #監視退場のOS情報を取得 os_info=subprocess.run(["zabbix_get","-s",row[0],"-p","10050","-k","system.uname","-t","1"],capture_output=True,text=True).stdout if os_info.startswith("Linux"): # 100001がWindos用の監視テンプレートのID zabbix_regist(row[1],row[0],10001) elif os_info.startswith("Windows"): # 100081がWindos用の監視テンプレートのID zabbix_regist(row[1],row[0],10081) # ZabbixAgentが起動されていない、またはインストールされていない場合、Ping監視テンプレートのみ登録する。 else: # 10186がPing監視テンプレートのID zabbix_regist(row[1],row[0],10186) ZabbixServerから登録されているホスト情報を取得し、hostsファイルに登録されていないホストは削除します。 # /etc/hostsファイルに登録されていないホストをZabbixServerから削除する # すべてのホスト情報を取得 allhosts=zapi.host.get() for host in allhosts: # /etc/hostsファイル内に、取得したホスト情報が含まれていないのか確認 # 含まれていない場合、該当するホストを削除する。 if not (hostsfile[1] == host["host"]).any(): zapi.host.delete(host["hostid"]) スクリプト実行 hostsファイルは以下の様に記述しておきます。 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.23.32.191 ZabbixServer 172.23.32.187 testLinux-Agent 172.23.32.232 testLinux-Agentless 172.23.32.190 TestWIN,SCSK Zabbixのホスト登録状況は以下の様にしておきます。 Zabbix Server（ホスト名: ZabbixServer）のみ残しておきます。 実装したファイル名は何でもいいですが、今回は「zabbix_autoregistration.py」としました。 以下のコマンドで実行します。 python3 zabbix_autoregistration.py 実行すると以下の様に登録されます。 では、hostsファイルから、ホストを削除、ホスト名の変更をして、再実行します。 hostsファイルは以下のようにします。 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.23.32.191 ZabbixServer 172.23.32.187 testLinux-Agent 172.23.32.190 TestWIN,SCSKTEST 「TestWIN,SCSK」→「TestWIN,SCSKTEST」に変更しました。また、「testLinux-Agentless」を削除してみました。 この状態で再実行すると、以下の様になります。 「TestWIN,SCSKTEST」にホスト名が変更され、「testLinux-Agentless」が削除されました。 あとは、cronなどで、深夜帯に実行仕掛けておけば、指定の時間で同期取れるようになります。 課題 ホスト名変更は出来ているのですが、一回ホスト追加→削除で実現しているため、変更処理が必要です。 また、ZabbixServerを除外する処理はできていないので、この辺りを追加する必要があると考えています。 ネットワーク機器も対応できるようにしていきたいです。 今後の活動 課題の対処はもちろんですが、適用するテンプレートの選択をOSだけではなくて、ミドルウェアや物理・仮想等…サーバ環境によってテンプレートにできるようにしたいです。とはいえ、千差万別とある中、そのあたりを人が介すると難しいと思うので、もう少しやり方を考えて実装をしていきたいと思います。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント： www.youtube.com ★Twitterに、SCSK Zabbixアカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com

Catoクラウドの2024年2月に実施される価格改定について解説します（ただし、記事内で実際の価格については記載していません） 当社とご契約のお客様については、すでに本記事の内容および新価格体系を含む価格表のご提示をしております。 月例報告書サービスをご契約いただいているお客様については、すでに報告会でのご説明も実施しております。 当社とご契約のお客様で、ご説明がご希望の場合は、サービス窓口または当社担当者までご連絡ください。 はじめに 今回の価格改定については、Cato Networks社から2023年11月3日に Pricing Update として全世界のパートナーに対して一斉に通知が行われました。 後で紹介するリージョンの統廃合や、SiteライセンスのPoP接続帯域の統廃合、セキュリティオプションの統廃合、新サービスとして、XDR Security Pro、Endpoint Security（EPP）、Socket X1600 LTEモデル、そして、新しい価格体系および価格について発表が行われました。 日本国内においては、ディストリビュータ制度がとられているため、日本円での定価（メーカ希望小売価格）の提示があったのが、12月に入ってからです。 ちなみに、以前の記事にも記載しましたが、Catoクラウドの”定価”については、Cato Networks社の公式サイトでは価格を公開しておらず（”参考小売価格”は存在しません）、あくまでも”メーカ希望小売価格”となります。 まず、 価格は残念ながら 値上げ になっています 。 SCSKでは、2019年からCatoクラウドの取り扱いを開始しておりますが、2019年当時から、SiteライセンスのPoP接続帯域25Mbps（最低）は月額40,000円でしたが、2013年の今現在も同じ価格です。 2019年当時の円相場は1ドル110円前後でしたが、最近では、1ドル140～150円となっており、ドルに対して30～40%程度 円の価値が下がってしまっています。 直接ドルをベースに課金請求されるAWSやAzure、GCPなどのクラウドについては、ここ数年はリソースの利用が変わらないのに関わらず30～50%程度の値上げがありますので、Catoクラウドが2019年から4年間価格変更がなかったので頑張った方なのかも知れません。 今後もし円高に進めば、元の価格に戻るかと思いますが、少なくともいち早くSASE、Catoクラウドをご採用されていたお客様については、まさに先行者利益を得られたと言えます。   価格改定概要 それでは、今回の価格改定（Pricing Update）のアナウンスについて解説を行います。 Pricing Update アナウンスの主な概要は以下となります。 1.　リージョンの統廃合 2.　PoP接続帯域の統廃合 3.　セキュリティオプションの統廃合 4.　新サービスのリリース 　　・XDR Security Pro 　　・Endpoint Security（EPP） 　　・Socket X1700 LTEモデル リージョンの統廃合 現行は、11のリージョンでそれぞれ価格設定がされていましたが、2024年2月以降は、 3つのグループ （ Group1 、 Group2 、 Stand-alone Countries ）となり、Stand-alone Countries（単独国）には、 中国 、 ベトナム 、 モロッコ の3ヵ国が含まれており、それぞれの国毎に価格設定がされているため、 5つの価格体系へ統廃合 されます。 Group1、Group2、Stand-alone Countriesの国（世界地図）は以下の通りです。 価格としては、（安価）Group1 ＜ Group2 ＜ Stand-alone Countries （高額）となっています。 Group1、2は、より大きなグループになったことで、Pooledライセンスの分配がしやすくなりました。 Pooledライセンスは、これまでリージョン単位（APJ、NAM、EUROPE等）で購入し、同一リージョン内でしか分配できませんでしたが、Group1、Group2で購入し、グループ内で分配を行うことが可能となりましたので、例えば、Group1でPooledライセンスを購入した場合、アメリカとヨーロッパで分配することが可能となりました。 ちなみに、Stand-alone Countries（中国、ベトナム、モロッコ）には、Pooledライセンスはございません。 PoP接続帯域の統廃合 Stand-alone Countriesを除く、Group1、Group2においては、現状の17の帯域契約メニューから、 9つの帯域契約メニューへ統廃合 されます。 Stand-alone Countries（中国、ベトナム、モロッコ）は、従来のGlobal/Regional毎の1Mbps単位での契約メニューです。 75Mbpsや、200M、300M、400M等の帯域メニューが無くなりました。500Mの次は、1,000Mbpsとなります。 既存のお客様については契約更新時に、新しい帯域での契約更新を行う必要がありますので、例えば、現在300Mをご契約の場合は、250M、または500Mのいずれかを選択いただき契約更新を行うことになります。 また、クラウドとの専用線接続であるCross-Connectについては、501Mbps以上の契約が前提となりますが、これまでの600Mのメニューが廃止されたため、1,000Mbpsでの契約を行う必要があります。 セキュリティオプションの統廃合 セキュリティオプション「NGAM」と「IPS」が「 Threat Prevention 」に統廃合されます。 以前、別々のセキュリティオプションだった「AM（Anti Malware）」「NGAM（Next Generation Anti Malware）」が「NGAM」に統合されましたが、今回は、さらに「NGAM」と「IPS」が統合されました。 IPSは、次々と機能拡張されおり、DNS Protectionや、Suspicious Activity（不審な活動）などの機能がリリースされていますが、今回Threat Intelligence（脅威インテリジェンス）、インライン AI/ML、アンチフィッシング機能も含めて、「Threat Prevention」となります。 また、セキュリティオプションについては、Group1、Group2で同じ価格体系（同じ価格）となっております。 既存のお客様については、「NGAM」と「IPS」が購入できなくなりますので、「Threat Prevention」の購入をご判断いただく必要があります。 ただし、契約期間中のお客様については、契約満了までは「NGAM」、「IPS」を個別に購入することは可能です。 セキュリティオプションには幾つかの前提条件があります。 ・DLPは、CASB契約が前提となります。 ・SaaS Security APIはDLP契約が前提となります。 ・SaaS Security APIでマルウェア検査をする場合は、Threat Preventionの契約が前提となります。 ・SaaS Security APIのシングルコネクターは同じベンダーのアプリケーションはすべてで機能します。例えば、Microsoft app connectorは、Microsoft 365アプリケーション（One Drive、Sharepoint等）すべてで利用できます。 新サービスのリリース XDR Security Pro XDR Securityには、 Core と Pro の2種類があります。 XDR Security Coreについては、Catoクラウドをご利用のすべてのお客様が無料でご利用可能です。 Cato Management Application（CMA）の[Monitoring] > [Stories Workbench]にてストーリ（＝セキュリティインシデント）を確認することができます。 ただし、XDR Security Coreは、セキュリティオプションであるIPSのログを元に分析をしていますので、IPS（2024年2月以降は、Threat Prevention）の契約が必須となります。 XDR Security Proは、セキュリティインシデントに対する対応（SOC通知の対応）が可能なお客様向けに提供される機能で、AIベースの脅威ハンティング（Threat Hunting）、ユーザー行動分析（User Behavioral Analysis）、インシデントライフサイクル管理を追加したセキュリティオプションとなります。 すでに、既存のお客様向けに早期提供プログラムが開始されています。 CatoのマネージドサービスであるMDR（Managed Detection and Response）は、2024年2月以降は、XDR Security Proの契約が前提になります。 Endpoint Security（EPP） ついに、エンドポイントセキュリティ(EPP)がリリースされます。 これまでの SASEプラットフォームのカバレッジ範囲を、ネットワーク層を超えてエンドポイントにまで拡張する新しい製品 となります。 Cato EPPは、現行CMAに完全に統合管理され、クラウドネイティブな他のセキュリティスタックと連携して動作します。 EPPは、CatoのSDPユーザの利用デバイス数上限と同様に、3デバイスが上限となります。 すでに、既存のお客様向けに早期提供プログラムが開始されています。 SCSKでも早期提供プログラムで検証を実施しておりますので、追ってご案内ができるものと思います。 最後に、XDR Security Pro、Endpoint Security（EPP）、MDRについては、新たに Knowledge Users課金 と言うものが適用されることになります。 Knowledge Usersとは、企業内のM365やG-Suite契約ユーザ数のことで、同ユーザ数での契約が前提となります。 Socket X1600 LTEモデル これまでのSocket X1600（ベーシックモデル）に、LTE接続用のセルラーモジュールを組み込んだ新しいX1600がリリースされます。 モジュールは、現在全世界中で承認作業が行われており、2024年第2四半期（2024年4～6月）に発売を予定しています。 これまでSocket利用時に、メイン回線は有線（フレッツ等）を利用し、バックアップ回線は、無線（LTE）をご利用されているお客様が比較的多くいらっしゃいます。 無線（LTE）には、SIMが搭載可能なルータを別途手配されていましたが、これがSocket X1600（LTEモデル）では不要となります。 価格適用スケジュール 新価格は、2024年2月より適用されます。 契約期間中のお客様についても、2024年2月以降のライセンス追加時（拠点追加・拠点の帯域増速・モバイルユーザ追加）は、すべて新価格が適用されます。 現行価格については、2024年1月末までのお見積り提示分（ご注文が2月末まで）が最終 となります。 なお、ご利用開始月（課金開始月）については、最長で2024年5月まで延長することが可能ですので、例えば、1月末見積り提示、2月末までにご注文の場合、5月利用開始（課金開始）が可能です。 また、これから新規にCatoクラウドをご契約するお客様は、契約期間（最低契約期間は1年）を伸ばすことも可能です。   まとめ 今回は、価格改定の変更部分のみをピックアップして解説しましたが、2024年2月までには、新サービス体系を改めて記事にする予定です。 現行のサービス体系の解説記事 Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17 Catoクラウドは他のSASEソリューションと比較し、安価でコストパフォーマンスが非常に高かったのですが、今回の価格改定で、そのメリットが少なくなったかも知れません。 それでも、全世界中に85箇所以上に設置されている独自PoP（中国を含む）、ネットワーク接続性を拠点まで保証するSocketのサービス提供（責任分界点の差）、クラウドネイティブで実装されたアーキテクチャ（圧倒的な使いやすさ・シンプルさ）は、他のソリューションとは異なる大きな差別化ポイントです。 SASEの普及期となり、SASEの知名度が上がるにつれ、最近では、誤ったマーケティングが横行しています。 「SASEはそもそもマルチベンダーでしか実現できない」 → × 「統合型SASEソリューション」 → × 「（SSEなのに）SASEソリューション」 → × SASEを提唱したガートナーも「 SASEは単一のベンダーから導入すべきである」 と提言しており、2019年のSASEを提唱した後、組み合わせのSASEが多く登場したことから、2022年には「 シングルベンダーSASE 」を改めて提唱しています。 SASEは、ネットワーク・セキュリティが融合・統合された統合型ソリューションであるため、”統合型SASE”自体が本来誤ったマーケティングです。 SSEでは、ゼロトラストは実現できません。（境界型防御の”境界”のクラウドリフト） 立場上、ソリューションを名指しして誤りを指摘することはできませんが、シングルベンダーSASE、世界初のSASEソリューションであるCatoクラウドについて、是非一度ご紹介の機会をいただれば幸いです。

本記事は TechHarmony Advent Calendar 12/25付の記事です。 こんにちは、SCSKの木澤です。 今年初めて企画した TechHarmony Advent Calendar も、本日で完走となりました。 TechHarmony寄稿者から広く協力いただき、本企画を完遂できたことは感激ひとしおです。 各記事をご覧頂いた頂いた皆様も、ありがとうございました。 さて 今年の話題と言えば、最後としては何と言っても生成AIのブーム でしょう。 昨年11月のChatGPT発表以降一世を風靡し、AWSとしても今年4月に Amazon Bedrock を発表、プレビュー期間を経て9月にGAされました。 Amazon Bedrockの特徴としては、 多数の生成AIモデルから選択できる こと、 データセキュリティに強く配慮している こと、 他のAWSサービスと統合が容易なこと が挙げられます。 生成AIモデルの性能としては後塵を拝しているとの評価もありますが、用途によっては十分に使えるため、既にAWSを活用しているユーザーにとっては有力な選択肢になると思われます。 私は昨年、AWSブログの更新を検出しTeamsに通知するという記事を発信しました。 そこで今回はこれに生成AIの要素を追加し、記事を要約して通知することにチャレンジしてみたいと思います。 AWSアップデート情報を見落とさない！Microsoft Teamsへの通知方法 AWSでは毎日のようにアップデートがありますが、効率的に確認できるようにするため社内のMicrosoft Teamsに通知するようにしました。 その仕組みをご紹介したいと思います。 blog.usize-tech.com 2022.05.18 アーキティクチャ・生成AIモデルの選択 アーキティクチャとしてはこんな感じ。 前回の記事から、翻訳に用いていたAmazon TranslateをAmazon Bedrockに取り替えているだけです。 Amazon SNS経由メール通知 Amazon SMS経由Teams通知(HTMLメール) Webhook経由Slack など幅広く対応可能です。 生成AIモデルには Amazon Titan Text G1 – Express を利用しました。 こちらは 今年のre:Inventで発表があったAmazon Bedrockの言語モデル です。英語以外にも100を超える言語に対応しますが、2023年12月時点で英語以外はプレビューの扱いとなっています。 Amazon Titan Text モデル (Express と Lite) が Amazon Bedrock で一般提供されるようになりました aws.amazon.com 今回はTitan Textの日本語性能をチェックしてみたかったことや、コストの観点での選択した次第です。 もしやAWS情報の要約であるためAmazon謹製の生成AIモデルでも期待できるのでは？という思いもありました。 価格は Claudeの1/8～1/10程度、Claude Instantの2/3～1/2程度の費用となります。 もし実用に耐えるのであれば有力な選択肢になるでしょう。 基盤モデルを使用した生成系 AI アプリケーションの構築 – Amazon Bedrock の料金表 – AWS オンデマンドやプロビジョニングスループットなどの Amazon Bedrock の料金モデルの詳細情報と、AI21 labs、Amazon、Anthropic、Cohere、Stability AI などのモデルプロバイダーの料金内訳をご覧ください。 aws.amazon.com   設定手順 以下の手順を実施しました。 なお、当方では東京リージョン(ap-northeast-1)で実装しました。 パラメータストアの作成 後述のLambda関数では取得元RSSフィード情報をAWS Systems Managerのパラメータストアから取得するように設計してありますので、下記のようなJSON形式でパラメータストアを作成します。 タイトルとURL、言語のみしているシンプルなものです。 [ { "TITLE" : "AWS What's New(英語版)" , "URL" : "https://aws.amazon.com/about-aws/whats-new/recent/feed/" , "LANG" : "en" }, { "TITLE" : "AWS What's New(日本語版)" , "URL" : "https://aws.amazon.com/jp/about-aws/whats-new/recent/feed/" , "LANG" : "ja" }, { "TITLE" : "AWS News Blog(英語版)" , "URL" : "https://aws.amazon.com/blogs/aws/feed/" , "LANG" : "en" }, { "TITLE" : "Amazon Web Servicesブログ(日本語版)" , "URL" : "https://aws.amazon.com/jp/blogs/news/feed/" , "LANG" : "ja" }, { "TITLE" : "AWS JAPAN APN ブログ" , "URL" : "https://aws.amazon.com/jp/blogs/psa/feed/" , "LANG" : "ja" } ] Amazon SESへのメールアドレス登録 今回はAmazon SES経由で通知を行いますので、メールの「From」になるメールアドレスと、宛先となるTeamsのメールアドレスを登録し認証しておきます。 Amazon Bedrock 生成AIモデルのリクエスト Amazon Bedrockのコンソールに接続し、Model AccessからTitan Text G1 – Expressを有効化します。 Access grantedと緑で表示されていることを確認します。 Lambda関数の作成 IAMロールの事前準備 以下のアクションを許可したポリシーを作成し、これらをアタッチしたロールを作成します。 英語版ブログのタイトルの翻訳を含むため、Translateの権限も残してあります。 AWS Systems Manager(Parameter Store)からの値の取得 ssm:GetParameterHistory ssm:GetParametersByPath ssm:GetParameters ssm:GetParameter Amazon Translateでの翻訳実行 translate:TranslateText Amazon Bedrockでの推論実行 bedrock:InvokeModel SESでのメール送信 ses:SendEmail CloudWatch Logsへのログ送信 logs:CreateLogGroup logs:CreateLogStream logs:PutLogEvent Bedrockのモデル呼び出しはbedrock:InvokeModelのみで良いようです。ポリシーはこちら。 { "Version": "2012-10-17", "Statement": [ { "Action": "bedrock:InvokeModel", "Resource": "*", "Effect": "Allow" } ] } Lambda関数の作成 2023年12月にLambdaで Python 3.12ランタイムがリリースされました。 内包されているbotoのバージョンは1.28.72 となっており、 boto3をアップデートするためにLambdaレイヤーの作成もしくは関数内への埋め込みは不要になりました。 そこで、前回同様組み込みが必要なライブラリはfeedparserのみとなります。 AWS Cloudshellにログインし、適当なフォルダを生成し以下のようなコマンドで生成→S3バケットにプッシュします。 $ pip3 install feedparser -t . $ touch lambda_function.py $ zip -r func.zip ./* $ aws s3 cp ./func.zip s3: / /(S3バケット名)/ 関数のひな形をデプロイ後、ソースコードは以下のように改修しました（ダウンロードしご確認ください） AWSアップデート通知Python Lambdaコード(Bedrock-Titan要約版) Download Now! 2 Downloads   なお、botoにてAmazon Titan Textを呼び出すためのパラメータはこちらで確認できます。 Amazon Titan text models - Amazon Bedrock The Amazon Titan models support the following inference parameters for text models. docs.aws.amazon.com 一般設定・環境変数の設定 元々本Lambda関数はRSSのパース及び外部の呼び出しに少々時間がかかりますが、Bedrockの呼び出しで更に時間が掛かります。タイムアウト時間は3分程度まで延ばしておいた方がよいと思われます。 また環境変数として以下を指定します。 MAIL_FROM　送信するメールの発信元 MAIL_DEST_EN　英語版ブログの通知先メールアドレス(Teams) MAIL_DEST_JA　日本語版ブログの通知先メールアドレス(Teams) PARAMETER_STORE　作成したAWS Systems Managerパラメータストアの名前 EventBridgeルールの設定 最後に、Amazon EventBridgeのルールを追加し、作成したLambda関数を定期実行するように設定します。 動作確認 以上、AWSアップデートの要約チャレンジでした。 Lambdaを実行すると、Bedrock(Titan)で記事が要約された通知が行われます。 本サンプルはSNS経由メール通知で届いたものを掲載しています。 日本語版ブログを要約させたもの 概ね想定通りの結果が得られました。 英語版ブログをTitanで直接日本語解説させたもの 下記は比較的良い結果を載せましたが、出力結果が不安定な印象があります。   まとめ＆今後の展望 LambdaからBedrockを呼び出して、アプリケーションに生成AIモデルを組み込むことが非常に簡単なことが解りました 。 今回の検証の結果では、英語版ブログの翻訳まで組み込んだ形で要約するにはまだ不安定であるといった印象でしたが、Amazon Translateと組み合わせることで実用に耐えうるレベルに達するのでは無いかという印象です。 また今回は時間切れのため検証できませんでしたが、プロンプトの調整で改善される可能性もあるかと思います。 実際にはRSSで配布される記事の要約文(Description)もあるため、今後の本番運用に関しては引き続き検証し判断していきたいと思います。 今後ともAmazon Bedrockを用いて色々なサーバレスアプリに生成AI要素を組み込んでいきたいですね。 では。

本記事は TechHarmony Advent Calendar 12/24付の記事です。 こんにちは、SCSK齋藤でございます。 今回は、最近業務で調べる機会が多かったAWS Network Firewallについて、学んだことをアウトプットしたいと思います。 AWS Network Firewallとは？ AWSから提供される、VPC全体に適用されるファイアウォール型マネージドサービスです。 数クリックでファイアウォール自体は作成でき、ステートフルやステートレスのアクセス制御、Webフィルタリング、IPS/IDSといった幅広い機能が使えます。 VPCの前面に配置することで、インターネットからVPCに入ってくる通信に対してチェックを行うファイアウォールということです。 ファイアウォールとのことなので、個人的にはセキュリティグループやネットワークACLとの違いが最初よくわからなかったのですが、検証を踏まえて使ってみたことで、違いが見えてきました。 構成要素 AWS Network Firewallには主に３つの構成要素がございます。 ・Firewall その名の通り、ファイアウォールそのものです。数クリックで作成することができ、それをVPCやサブネットにアタッチします。 インターネットからVPCに入ってくる通信をチェックするので、パブリックサブネットに配置する必要がございます。 ファイアウォールそのものですが、これ単体ではパケットのチェックなどは実施しないので、後述する２つが必要となります。 ・ファイアウォールポリシー ファイアウォールの動作を定義したものです。後述するルールグループを紐づけることで、ステートレスもしくはステートフルなチェックを実施します。 ・ルールグループ ネットワークトラフィックのルールの集合体です。１つのルールグループに複数のルールを追加することができ、優先順位づけを実施することができます。 ５つの項目 (送信元IP、送信元ポート番号、宛先IP、宛先ポート番号、プロトコル番号)を細かく定義することができ、またその項目に対する挙動（通信をパスするか、ドロップするか、別のルールに分岐するかなど）も定義することができます。 ハンズオン 構成 今回は下記のような構成で通信を行い、インスタンスにSSHをしてみたいと思います。 パブリックサブネットにAWS Network Firewallを配置し、専用のサブネットとします。 その背後のプライベートサブネットにEC2を配置することで、外部からの通信は必ずAWS Network Firewallを通って、EC2のあるサブネットに疎通するようにします。 なお、今回のハンズオンではネットワークの設定や、EC2の立ち上げは省略いたします。 Firewallの作成 まずは、前述したFirewallを作成します。 基本的にマネジメントコンソールの内容に沿って設定を実施します。 VPC単位で適用されるサービスであるのと、Firewallを設置するサブネットの選択が必須になります。 また、ファイアウォールポリシーについてはこの段階で作成を行います。 ファイアウォールポリシーを作成する際に注意すべきは、デフォルトのアクションをどうするかです。 この後作成する、ルールグループでの評価に何もマッチしなかった場合に、通信を許可するか、拒否するかなどを設定することができます。 通常、セキュリティのことを考えたら、ルール評価にマッチしない場合は通信を拒否するのが普通かなと考えたので、今回はデフォルトで拒否するようにします。 下記のように準備が整ったら、「ファイアウォールを作成」を押下して作成します。作成には結構時間がかかるので、待ちましょう。   ルールグループの作成 ファイアウォールポリシーに、具体的なルールを設定するための、ルールグループを作成します。 ルールグループには2種類があり、「ステートレスルールグループ」と「ステートフルルールグループ」があります。 評価の順序については、下記ドキュメントに記載されている通り、「ステートレスルールグループ」→「ステートフルルールグループ」の順番となります。「ステートフルルールグループ」を作成しない場合は、「ステートレスルールグループ」のみの評価となります。 Network Firewall stateless and stateful rules engines - AWS Network Firewall Learn about the Network Firewall stateless and stateful rules engines. docs.aws.amazon.com ルールグループは複数作成してアタッチし、評価順序を設定できるので、より柔軟に設定が可能です。 今回は１つだけのルールグループを作成しました。 今回は上記のようなルールで、特定のインスタンスに、自宅のネットワークからのみSSHを許可するアクションを追加しました。 ステートレスで作成したので、行きの通信と戻りの通信それぞれのルールを設定する必要がありますね。 前述したようにファイアウォールポリシーのデフォルトのアクションが、拒否という設定をしたので、今回のルールグループの評価にマッチしない場合は、通信が全部拒否されます。 ファイアウォールポリシーとの関連付け 作成したルールグループをファイアウォールポリシーにアタッチします。 私はこれを忘れたまま、SSHの接続を試みて、全然アクセスができないという事象に陥りました。。。 ファイアウォールポリシーの画面に遷移し、ステートレスルールグループの「アクション」から、「アンマネージドステートレスルールグループを追加」をクリックします。 事前作成したルールグループを選択し、「ステートレスルールグループを追加する」を押下します。 これで、ルールグループの内容をもとに、ファイアウォールがパケットを評価する準備が整いました。   動作検証 SSH通信が許可されるかどうか では早速、インスタンスにSSHをしてみましょう。 問題なく、SSH接続をすることができました。 私が前述した通り、最初はルールグループをファイアウォールポリシーにアタッチするのを忘れていたのですが、ルールグループなしでSSH接続してみたらどうなるかを再度試してみましたところ、、 接続できませんでした。これは、ファイアウォールポリシーのデフォルトのアクションが拒否になっているので、通信が拒否されたものとなります。   セキュリティグループとの関係性はどうなのか？ ひとつ気になることとして、セキュリティグループとの関係性はどういうものなのか気になりました。 試しに、EC2のセキュリティグループで外部からのアクセスを許可する設定を入れなかった場合にどうなるか試してみたところ、SSH接続できませんでした。 これは、AWS Network FirewallがVPC単位でのファイアウォールなのに対して、セキュリティグループはインスタンス単位でのファイアウォールになるためです。 なので、AWS Network FirewallでVPC内への通信を許可しても、インスタンスの直前に立つセキュリティグループがブロックすれば、通信はできないということですね。   まとめ 今回は、AWS Network Firewallが何をできるのか知るために検証してみました。 ファイアウォールということで、セキュリティグループなどとはどう違うのかが1番気になっていたので、VPC単位での設定や、複数のルールグループをアタッチし順番に評価することが可能な点がわかり、より柔軟なアクセスコントロールができるのだと感じました。

本記事は TechHarmony Advent Calendar 12/23付の記事です。 こんにちは、広野です。 以前、別の記事で MUI から React のサンプルアプリが公開されていると紹介したことがあります。MUI をどのように使用するのか具体的なイメージを掴んでもらうためのサンプルだと思うのですが、なにげに React の学習用としても利用価値があると考えています。 今回は、その MUI 提供の React サンプルアプリを AWS Amplify 上で立ち上げる方法を紹介します。データベース無し、フロントエンドのみで動くサンプルになっているところも使い勝手の良い点です。 私自身、React と AWS サーバーレス関連のブログを書く上で、React のサンプルアプリがないと説明がしづらくなってきましたので、副産物的な目的として、私の今後のブログの参照先としても本記事は活用したいと思います。 やりたいこと 動かしたいサンプルアプリは以下です。 MUI: A popular React UI framework MUI provides a simple, customizable, and accessible library of React components. Follow your own design system, or start with Material Design. mui.com これを、 自分の AWS 学習用環境で動かしたいです。 ※アプリ稼働環境は AWS である必要はないのですが、AWS の学習も兼ねて、目標をそのようにセットします。 アーキテクチャ アーキテクチャと言うほどではないのですが、以下の AWS サービスを使用します。 AWS でサーバーレスアプリケーション開発をするときの一般的なプラクティスです。 開発環境は AWS Cloud9 を使用します。 Cloud9 内で MUI の React サンプルアプリを編集し、AWS CodeCommit にプッシュします。 CodeCommit に関連付けられた AWS Amplify に自動的にビルド、デプロイされます。 執筆時点の使用ランタイム、モジュールバージョンは以下です。バージョンは日々アップデートされいきますので、将来的にバージョン間の互換性の問題が発生する可能性があります。 React 18.2.0 Node.js 20.10.0 npm 10.2.5 Cloud9 の OS: Amazon Linux 2023 サンプルアプリ立ち上げ手順 サンプルアプリコードダウンロード 以下のサイトから、必要なコードのファイルをダウンロードします。本記事では、ブログサンプルを対象とします。 https://github.com/mui/material-ui/tree/v5.14.19/docs/data/material/getting-started/templates/blog github.com もしリンク切れしていましたら、 こちら から探してみてください。 必要なファイルは以下です。本記事では、TypeScript 版ではなく JavaScript 版を使用します。 Blog.js ※このファイルはこのままでは動かないため、後ほど修正箇所を紹介します。 FeaturedPost.js Footer.js Header.js Main.js MainFeaturedPost.js Markdown.js Sidebar.js blog-post1.md blog-post2.md blog-post3.md 開発環境構築 AWS Cloud9 と AWS CodeCommit を使用します。こちらは世の中に多くのナレッジがあるため、詳細な手順は割愛します。 以下の AWS 公式サイトを参考に、空の AWS CodeCommit リポジトリに連携した AWS Cloud9 を立ち上げて頂ければと思います。 AWS CodeCommit リポジトリを作成する - AWS CodeCommit AWS Management Console または AWS CLI を使用して CodeCommit リポジトリを作成する方法について説明します。 docs.aws.amazon.com AWS Cloud9 と AWS CodeCommit を統合する - AWS CodeCommit AWS Cloud9 を AWS CodeCommit と統合する方法について説明します。 docs.aws.amazon.com モジュールインストール AWS Cloud9 を立ち上げ、順番に実施していきましょう。 Node.js バージョン確認 まず、AWS Cloud9 上にインストールされている Node.js のバージョンを確認します。執筆時点では、デフォルトでバージョン 20 が使用されていました。 インストールされている Node.js バージョン確認 node -v Node.js の存在バージョン確認 nvm ls-remote Node.js 20 最新バージョンインストール (例) nvm install v20.10.0 nvm alias default v20.10.0 npm バージョン確認 インストールされている npm バージョン確認 npm -v npm の最新バージョンインストール npm install -g npm@latest React・MUI 関連モジュールインストール create-react-app という標準的な React 環境をセットアップしてくれるモジュールをインストールします。ここでは、AWS CodeCommit とソースコードを同期したディレクトリにインストールします。(例: reactapp) create-react-app reactapp 完了すると、以下のようなディレクトリ状態になります。   デフォルトでサンプルソースコードが入っているので、src 配下の不要なファイルを削除します。 App.css App.js App.test.js logo.svg reportWebVitals.js setupTests.js すっきりしました。 続いて、不要なモジュールを削除するコマンドを実行します。React をインストールしたディレクトリ (ここでは reactapp) に移動して、モジュール削除コマンドを実行します。 cd reactapp npm remove web-vitals @testing-library/jest-dom @testing-library/react @testing-library/user-event 追加で必要となるモジュールをインストールします。 npm install --save @mui/material @mui/icons-material @emotion/react @emotion/styled markdown-to-jsx prop-types axios   ソースコード配置・修正 src ディレクトリ配下に、ダウンロードしておいたサンプルアプリコードを全て配置します。こんな感じになります。 ただし、このままでは動かないので、ファイルを修正します。以下は修正後の状態です。 index.js import React from 'react'; import ReactDOM from 'react-dom/client'; import './index.css'; import Blog from './Blog'; const root = ReactDOM.createRoot(document.getElementById('root')); root.render( <React.StrictMode> <Blog /> </React.StrictMode> ); index.js は画面を表示したときに最初に実行されるスクリプトです。create-react-app 実行直後は App.js が呼び出されるようになっていたのですが、MUI サンプルアプリを呼び出すために Blog.js を呼び出すように書き換えています。また、不要なコードを削除しています。 Blog.js  下線を引いた箇所を修正または追記しています。 import * as React from 'react'; import CssBaseline from '@mui/material/CssBaseline'; import Grid from '@mui/material/Grid'; import Container from '@mui/material/Container'; import GitHubIcon from '@mui/icons-material/GitHub'; import FacebookIcon from '@mui/icons-material/Facebook'; import TwitterIcon from '@mui/icons-material/Twitter'; import { createTheme, ThemeProvider } from '@mui/material/styles'; import Header from './Header'; import MainFeaturedPost from './MainFeaturedPost'; import FeaturedPost from './FeaturedPost'; import Main from './Main'; import Sidebar from './Sidebar'; import Footer from './Footer'; import post1 from './blog-post.1.md'; import post2 from './blog-post.2.md'; import post3 from './blog-post.3.md'; import axios from 'axios'; const sections = [ { title: 'Technology', url: '#' }, { title: 'Design', url: '#' }, { title: 'Culture', url: '#' }, { title: 'Business', url: '#' }, { title: 'Politics', url: '#' }, { title: 'Opinion', url: '#' }, { title: 'Science', url: '#' }, { title: 'Health', url: '#' }, { title: 'Style', url: '#' }, { title: 'Travel', url: '#' }, ]; const mainFeaturedPost = { title: 'Title of a longer featured blog post', description: "Multiple lines of text that form the lede, informing new readers quickly and efficiently about what's most interesting in this post's contents.", image: 'https://source.unsplash.com/random?wallpapers', imageText: 'main image description', linkText: 'Continue reading…', }; const featuredPosts = [ { title: 'Featured post', date: 'Nov 12', description: 'This is a wider card with supporting text below as a natural lead-in to additional content.', image: 'https://source.unsplash.com/random?wallpapers', imageLabel: 'Image Text', }, { title: 'Post title', date: 'Nov 11', description: 'This is a wider card with supporting text below as a natural lead-in to additional content.', image: 'https://source.unsplash.com/random?wallpapers', imageLabel: 'Image Text', }, ]; //const posts = [post1, post2, post3]; const sidebar = { title: 'About', description: 'Etiam porta sem malesuada magna mollis euismod. Cras mattis consectetur purus sit amet fermentum. Aenean lacinia bibendum nulla sed consectetur.', archives: [ { title: 'March 2020', url: '#' }, { title: 'February 2020', url: '#' }, { title: 'January 2020', url: '#' }, { title: 'November 1999', url: '#' }, { title: 'October 1999', url: '#' }, { title: 'September 1999', url: '#' }, { title: 'August 1999', url: '#' }, { title: 'July 1999', url: '#' }, { title: 'June 1999', url: '#' }, { title: 'May 1999', url: '#' }, { title: 'April 1999', url: '#' }, ], social: [ { name: 'GitHub', icon: GitHubIcon }, { name: 'Twitter', icon: TwitterIcon }, { name: 'Facebook', icon: FacebookIcon }, ], }; // TODO remove, this demo shouldn't need to reset the theme. const defaultTheme = createTheme(); export default function Blog() { const [poststate1, setPoststate1] = React.useState(); const [poststate2, setPoststate2] = React.useState(); const [poststate3, setPoststate3] = React.useState(); React.useEffect(() => { axios.get(post1).then(res => setPoststate1(res.data)); axios.get(post2).then(res => setPoststate2(res.data)); axios.get(post3).then(res => setPoststate3(res.data)); }, []); return ( <ThemeProvider theme={defaultTheme}> <CssBaseline /> <Container maxWidth="lg"> <Header title="Blog" sections={sections} /> <main> <MainFeaturedPost post={mainFeaturedPost} /> <Grid container spacing={4}> {featuredPosts.map((post) => ( <FeaturedPost key={post.title} post={post} /> ))} </Grid> <Grid container spacing={5} sx={{ mt: 3 }}> {(poststate1 && poststate2 && poststate3) && <Main title="From the firehose" posts={[poststate1,poststate2,poststate3]} />} <Sidebar title={sidebar.title} description={sidebar.description} archives={sidebar.archives} social={sidebar.social} /> </Grid> </main> </Container> <Footer title="Footer" description="Something here to give the footer a purpose!" /> </ThemeProvider> ); } サンプルコードでは、md ファイル (マークダウン言語で書かれたドキュメント) を import というコマンドでロードして画面に表示するように書かれているのですが、ダウンロードしたコードをそのまま使用しても表示されません。代替策として axios というモジュールを使用して md ファイルをロードするよう書き換えています。 ここまでできましたら、AWS Cloud9 で編集したこれらコードを AWS CodeCommit に同期します。以下コマンドを使用します。 git add -A git commit -m "initial commit" git push origin master AWS Amplify 環境構築 AWS マネジメントコンソールで、AWS Amplify を表示します。ウェブアプリケーションをホストします。 AWS CodeCommit を選択します。 使用している AWS CodeCommit リポジトリを選択します。 AWS CodeCommit に格納されているコードから、React であることを自動判別してくれます。それに沿って必要なビルド設定をデフォルトで用意してくれるので、そのまま先に進みます。 デプロイが進みます。完了するとパイプラインの色が全て緑色になりますので、画面に表示されている URL をクリックすると、アプリが表示されます。 ただし、そのままでは画面の一部がエラーになってしまいます。Amplify 画面のメニューで、「リライトとリダイレクト」の設定を変更します。 この中で、以下の赤線部分を追記して保存します。 </^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json| md )$)([^.]+$)/> デフォルトのままでは、コードに書かれている axios で MD ファイルにアクセスする部分がブロックされてしまいます。拡張子が .md のファイルにアクセスできるよう、Amplify に登録してあげる必要があります。 完成品 これにて、ようやく MUI サンプルアプリを自分の AWS 環境で立ち上げることができました！ 以降は、AWS Cloud9 でソースコードを更新して AWS CodeCommit にプッシュすることで、Amplify 上の実行環境にデプロイされるのでコードの変更を画面に反映することができます。 まとめ いかがでしたでしょうか？ MUI サンプルアプリのコードがそのままでは動かない、AWS Amplify 側で設定変更が必要、など面倒なことはありましたが、何とか立ち上げることができました。自分で書き換えたコードが目に見えるようになるので、学習に活用できると思います。 本記事が皆様のお役に立てれば幸いです。

こんにちは。SCSKのふくちーぬです。 皆さんは、プライベート（閉域網）環境下でのLambdaを利用したことありますでしょうか。セキュリティに厳しい環境下でLambdaを利用する場合は、VPC設定を施したLambdaを利用する機会があると思います。 今回は、インターネットに接していないVPC Lambdaの設計ポイントをお話しします。また、VPC Lambdaを実現しているAWS内の裏側もご紹介します。 VPC Lambdaとは LambdaにVPC設定を施すことで、顧客VPC内のサブネット上に足を出すことができて(ENIが作成されます)、RDS等のプライベートなリソースにアクセスをすることができます。VPC設定をするためには、VPC・サブネット・セキュリティグループが必要なため、EC2同様のネットワーク設計を行う必要があります。 VPC Lambdaをプライベートサブネット内に配置することで、VPCエンドポイント経由でのプライベートアクセスも可能です。もしくは、パブリックサブネットのNAT Gateway経由でのインターネットアクセスも可能です。 VPC Lambdaの裏側について 以前までのVPC Lambdaの構成 実は遡ること2019年8月。以前までのVPC Lambdaは、以下のような構成でした。 [発表] Lambda 関数が VPC 環境で改善されます | Amazon Web Services 本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Mun aws.amazon.com VPC Lambdaを作成するとAWS Lambdaサービスが持つVPC内にLambdaが作成されます。顧客が持つVPC内とクロスアカウント接続することで、Lambdaが顧客VPC内にアクセスすることができます。 VPC Lambda実行時に顧客VPC内にENIが作成されてアタッチが行われてしまい、それが何対ものになるとサブネット内のIPアドレスを消費してしまいIP枯渇に直面してしまいます。アタッチに時間がかかるとコールドスタートが発生しVPC Lambdaのコード部分の実行に時間がかかり、想定よりも長い処理時間となってしまうという問題も抱えていました。 現在のVPC Lambda 現在のVPC Lambdaですが、クロスアカウント接続している点は以前と同様となります。VPC Lambdaを作成するとAWS Lambdaサービスが持つVPC内にLambdaが作成されます。顧客が持つVPC内とクロスアカウント接続することで、Lambdaが顧客VPC内にアクセスすることができます。 あくまで、VPC Lambdaは顧客VPC内のサブネットには存在しませんので、忘れないでください。なんだか構成がかなりシンプルになりましたね。Lambdaサービスが持つVPC内に、”VPC to VPC NAT”という機器が配置されています。この機器は、Hyperplaneという技術で実現されており、多数のリクエストの負荷を吸収してくれます。負荷分散機能を有しているため、NAT GatewayやNetwork Load Balancerにも利用されている技術となります。VPC Lambdaを利用する際にはこの機器の存在を気にすることなく利用できるので、「何となく裏側でマッピング処理や負荷分散処理を頑張っているのだな～」と思うくらいで良いかとおもいます。 VPC Lambdaを作成すると顧客VPC内には、Hyperplane ENIと呼ばれる特殊なENIが作成されます。 Hyperplane ENIは、サブネットとセキュリティグループのペアで作成されます。 なんと他のVPC LambdaもこのHyperplane ENIを利用できます！共用で利用できるため、サブネット内のIPアドレス枯渇の懸念もほとんどなくなりました。またLambdaの作成時にENIが作成されるので、最初だけENIの作成に時間がかかりますが、それ以降に作成されたLambdaは既存のENIを利用できるため迅速に関数を実行することができます。 構成図 プライベートサブネットをAZ-a、AZ-cに1つずつ配置してます。VPC LambdaをマルチAZ構成で3つ作成します。 Lambda所有VPC内には、”VPC to VPC NAT”が配置されます。別名は、”V2V”,”Hyperplane NAT”と呼ばれる機器です。 セキュリティグループを2つ作成します。アウトバウンドルールがフルアクセスなものと、VPC内に許可するもの計2種類です。 顧客所有VPC内には、サブネットとセキュリティグループのペアに応じたHyperplane ENIが作成されます。 この例では、”test-lambda-02″及び”test-lambda-03″は同じHyperplane ENIを共有することになります。 環境準備 VPCの作成 VPC・プライベートサブネット・ルートテーブルを作成するCloudFormationテンプレートです。 以下のテンプレートをデプロイしてください。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn vpc Resources: # ------------------------------------------------------------# # VPC # ------------------------------------------------------------# VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: PrivateVPC # ------------------------------------------------------------# # Subnet # ------------------------------------------------------------# PrivateSubnet1a: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.1.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false Tags: - Key: Name Value: PrivateSubnet-1a PrivateSubnet1c: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: 10.0.2.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false Tags: - Key: Name Value: PrivateSubnet-1c # ------------------------------------------------------------# # RouteTable # ------------------------------------------------------------# PrivateRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: PrivateRouteTable PrivateSubnet1aAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1a RouteTableId: !Ref PrivateRouteTable PrivateSubnet1cAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1c RouteTableId: !Ref PrivateRouteTable  デプロイが完了したら、VPCのID及び各サブネットのIDをメモとして控えておいてください。次のテンプレートのデプロイ時に使用します。 利用可能なIPアドレス数の確認(その1) サブネット内で利用できるIPアドレス数を確認しておきましょう。 256(2^8) – 5(AWSで予約済みIP) = 251 AWSで予約済みの5つのIPアドレスを引いた、合計251個のIPアドレスが利用できますね。 VPC Lambdaの作成 VPCのIDとサブネットのIDを利用して、以下のテンプレートをデプロイしてください。 VPC Lambda作成時に、Hyperplane ENIの作成を行っているためデプロイ完了まで数分ほど時間がかかると思います。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn lambda Parameters: VpcID: Type: String Description: Vpc id PrivateSubnet1aID: Type: String Description: Subnet1a id PrivateSubnet1cID: Type: String Description: Subnet1c id Resources: # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# LambdaSecurityGrouptoFull: Type: AWS::EC2::SecurityGroup Properties: GroupName: outbound-full-sg GroupDescription: Security Group for Lambda to full VpcId: !Ref VpcID SecurityGroupEgress: - IpProtocol: -1 CidrIp: 0.0.0.0/0 LambdaSecurityGrouptoVPC: Type: 'AWS::EC2::SecurityGroup' Properties: GroupName: outbound-vpc-sg GroupDescription: Security Group for Lambda to vpc VpcId: !Ref VpcID SecurityGroupEgress: - IpProtocol: tcp FromPort: 0 ToPort: 65535 CidrIp: 10.0.0.0/16 # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# LambdaFunction01: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: test-lambda-01 Runtime: python3.11 Timeout: 3 MemorySize: 128 Code: ZipFile: | def lambda_handler(event, context): print('Hello, World!') return { 'statusCode': 200, 'body': 'Hello, World!' } VpcConfig: SecurityGroupIds: - !Ref LambdaSecurityGrouptoFull SubnetIds: - !Ref PrivateSubnet1aID - !Ref PrivateSubnet1cID LambdaFunction02: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: test-lambda-02 Runtime: python3.11 Timeout: 3 MemorySize: 128 Code: ZipFile: | def lambda_handler(event, context): print('Hello, World!') return { 'statusCode': 200, 'body': 'Hello, World!' } VpcConfig: SecurityGroupIds: - !Ref LambdaSecurityGrouptoVPC SubnetIds: - !Ref PrivateSubnet1aID - !Ref PrivateSubnet1cID LambdaFunction03: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: test-lambda-03 Runtime: python3.11 Timeout: 3 MemorySize: 128 Code: ZipFile: | def lambda_handler(event, context): print('Hello, World!') return { 'statusCode': 200, 'body': 'Hello, World!' } VpcConfig: SecurityGroupIds: - !Ref LambdaSecurityGrouptoVPC SubnetIds: - !Ref PrivateSubnet1aID - !Ref PrivateSubnet1cID # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaExecutionRole: Type: AWS::IAM::Role Properties: RoleName: IRL-Lambda AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Principal: Service: 'lambda.amazonaws.com' Action: 'sts:AssumeRole' ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole 利用可能なIPアドレス数の確認(その2) Hyperplane ENIが作成されたために、サブネット内のIPアドレス数が減っているはずです。想定通りの数になっているか確認してみます。 PrivateSubnet-1a・PrivateSubnet-1c共にIPアドレスが2つ消費されていることが分かりますね。 Hyperplane ENIの確認 マネジメントコンソールでのENIの確認 マネジメントコンソールから、ENIを確認します。 ４つのENIが確認できましたね。サブネットとセキュリティグループのペアに応じて作成されていることが分かります。 次に、インターフェイスのタイプを確認します。普段EC2等を作成した場合は、インターフェイスのタイプが”Elastic Network Interface”となります。 ここでは、”lambda”になっていることが注目すべき点です。つまり、こいつこそがHyperplane ENIであるのです。 後に使用するため、セキュリティグループが異なる2つのENIのIDを控えておいてください。 ENI Finderの利用 スクリプトを動かすために、AWS CLIとjqコマンドが必要となります。 今回は、パブリックサブネット上に配置されたCloud9から実行します。Cloud9の準備については、こちらを参考にしてください。 AMI から AWS Cloud9 を復元する Cloud9を削除してしまった際の適切な復元方法についてお話します。 blog.usize-tech.com 2023.11.24 Cloud9上で以下のコマンドを実行します。jqをインストールします。 sudo yum install jq jqがインストール済か確かめます。 yum list installed | grep jq 無事インストールができました。 以下のスクリプト(ファイル名：findEniAssociations)を任意のディレクトリに配置してください。 https://github.com/awslabs/aws-support-tools/blob/master/Lambda/FindEniMappings/findEniAssociations github.com #!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # SPDX-License-Identifier: MIT-0 # jq is required for this script to work, exit if it isn't present which jq &> /dev/null if [ $? -ne 0 ] then echo "The json parsing package 'jq' is required to run this script, please install it before continuing" exit 1 fi set -e #fail if any of our subcommands fail printf "This script is for determining why an ENI that is managed by AWS Lambda has not been deleted.\n\n" # take the region and the ENI id as parameters POSITIONAL=() while [[ $# -gt 0 ]] do key="$1" case $key in --eni) ENI="$2" shift # past argument shift # past value ;; --region) REGION="$2" shift # past argument shift # past value ;; esac done set -- "${POSITIONAL[@]}" # restore positional parameters # Both parameters are required, fail if they are absent if [ -z $ENI ] && [ -z $REGION ]; then echo "Both --eni and --region are required" exit 1 elif [ -z $ENI ] then echo "--eni is required" exit 1 elif [ -z $REGION ] then echo "--region is required" exit 1 fi # search for the ENI to get the subnet and security group(s) it uses METADATA="$(aws ec2 describe-network-interfaces --network-interface-ids ${ENI} --filters Name=network-interface-id,Values=${ENI} --region ${REGION} --output json --query 'NetworkInterfaces[0].{Subnet:SubnetId,SecurityGroups:Groups[*].GroupId}')" read Subnet < <(echo $METADATA | jq -ar '.Subnet') SecurityGroups=() for row in $(echo $METADATA | jq -ar '.SecurityGroups[]') do SecurityGroups+=(${row}) done # Sort the list of SGs, so that we can easily compare with the list from a Lambda function IFS=$'\n' SortedSGs=($(sort <<<"${SecurityGroups[*]}")) unset IFS #convert Subnet to "echo-able", if $Subnet is used directly, GitBash skips the call outputting: ' using Security Groups "sg-012345example" ' SUBNET_STRING=$(echo $Subnet) echo "Found "${ENI}" with $SUBNET_STRING using Security Groups" ${SortedSGs[@]} echo "Searching for Lambda function versions using "$SUBNET_STRING" and Security Groups" ${SortedSGs[@]}"..." # Get all the Lambda functions in an account that are using the same subnet, including versions Functions=() Response="$(aws lambda list-functions --function-version ALL --max-items 1000 --region ${REGION} --output json --query '{"NextToken": NextToken, "VpcConfigsByFunction": Functions[?VpcConfig!=`null` && VpcConfig.SubnetIds!=`[]`] | [].{Arn:FunctionArn, Subnets:VpcConfig.SubnetIds, SecurityGroups: VpcConfig.SecurityGroupIds} | [?contains(Subnets, `'$Subnet'`) == `true`] }')" # Find functions using the same subnet and security group as target ENI. Use paginated calls to enumerate all functions. while : ; do NextToken=$(echo $Response | jq '.NextToken') for row in $(echo $Response | jq -c -r '.VpcConfigsByFunction[]') do Functions+=(${row}) done [[ $NextToken != "null" ]] || break Response="$(aws lambda list-functions --function-version ALL --max-items 1000 --starting-token $NextToken --region ${REGION} --output json --query '{"NextToken": NextToken, "VpcConfigsByFunction": Functions[?VpcConfig!=`null` && VpcConfig.SubnetIds!=`[]`] | [].{Arn:FunctionArn, Subnets:VpcConfig.SubnetIds, SecurityGroups: VpcConfig.SecurityGroupIds} | [?contains(Subnets, `'$Subnet'`) == `true`] }')" done # check if we got any functions with this subnet at all if [ $(echo "${#Functions[@]}") -eq 0 ] then printf "\nNo Lambda functions or versions found that were using the same subnet as this ENI.\nIf this ENI is not deleted automatically in the next 24 hours then it may be 'stuck'. If the ENI will not allow you to delete it manually after 24 hours then please contact AWS support and send them the output of this script.\n" exit 0 fi Results=() for each in "${Functions[@]}" do # Check if there are any functions that match the security groups of the ENI LambdaSGs=() for row in $(echo "$each" | jq -ar '.SecurityGroups[]') do LambdaSGs+=(${row}) done # Need both lists of SGs sorted for easy comparison IFS=$'\n' SortedLambdaSGs=($(sort <<<"${LambdaSGs[*]}")) unset IFS set +e # diff is wierd and returns exit code 1 if the inputs differ, so we need to temporarily disable parent script failure on non-zero exit codes diff=$(diff <(printf "%s\n" "${SortedSGs[@]}") <(printf "%s\n" "${SortedLambdaSGs[@]}")) set -e if [[ -z "$diff" ]]; then Results+=($(echo "$each" | jq -r '.Arn')) fi done if [ ${#Results[@]} -eq 0 ]; # if we didn't find anything then we need to check if the ENI was modified, as Lambda will still be using it, even if the SGs no longer match then printf "No functions or versions found with this subnet/security group combination. Searching for manual changes made to the ENI...\n" Changes="$(aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ModifyNetworkInterfaceAttribute --region ${REGION} --output json --query 'Events[] | [?contains(CloudTrailEvent, `'$ENI'`) == `true` && contains(CloudTrailEvent, `groupId`) == `true` && contains(CloudTrailEvent, `errorMessage`) == `false`]')" if [ "$(echo $Changes | jq -r 'length')" -gt 0 ] then printf "\nChanges were made to this ENI's security group outside of the Lambda control plane. Any Lambda function that pointed to this ENI originally will still be using it, even with changes on the ENI side.\n\nThe following functions share the same subnet as this ENI. Any of them that are will need to be disassociated/deleted before Lambda will clean up this ENI. Each of these could potentially be using this ENI:\n" for each in "${Functions[@]}" do echo "$each" | jq -r '.Arn' done else printf "\nNo manual changes to the ENI found. ENIs may take up to 20 minutes to be deleted. If this ENI is not deleted automatically in the next 24 hours then it may be 'stuck'. If IAM roles associated with a VPC Lambda function are deleted before the ENI is deleted, Lambda will not be able to complete the clean-up of the ENI. If the ENI will not allow you to delete it manually after 24 hours then please contact AWS support and send them the output of this script.\n" fi else printf "\nThe following function version(s) use the same subnet and security groups as "${ENI}". They will need to be disassociated/deleted before Lambda will clean up this ENI:\n" printf "%s\n" "${Results[@]}" fi  ファイルに対して、権限の付与を実施します。 chmod +x findEniAssociations 引数には、セキュリティグループとして”outbound-full-sg”を利用しているENIと対象リージョンを指定します。 ./findEniAssociations --eni eni-0704818dd4675e034 --region ap-northeast-1 以下のように、”test-lambda-01″のみ利用していることが分かります。 同様に、セキュリティグループとして”outbound-full-vpc”を利用しているENIについても実施してみます。 ./findEniAssociations --eni eni-0539d0e4405d91ff5 --region ap-northeast-1 以下のように、”test-lambda-02″及び”test-lambda-03″が同一のENIを利用していることが分かります。複数のVPC LambdaがHyperplane ENIを共用利用していることが分かります。 ENIの削除 VPC LambdaのENIが削除されるタイミングを検証します。 以下のテンプレートを利用して、Lambdaのスタックを更新してください。”test-lambda-01″及び”test-lambda-02″の記述を削除しています。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn lambda Parameters: VpcID: Type: String Description: Vpc id PrivateSubnet1aID: Type: String Description: Subnet1a id PrivateSubnet1cID: Type: String Description: Subnet1c id Resources: # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# LambdaSecurityGrouptoFull: Type: AWS::EC2::SecurityGroup Properties: GroupName: outbound-full-sg GroupDescription: Security Group for Lambda to full VpcId: !Ref VpcID SecurityGroupEgress: - IpProtocol: -1 CidrIp: 0.0.0.0/0 LambdaSecurityGrouptoVPC: Type: 'AWS::EC2::SecurityGroup' Properties: GroupName: outbound-vpc-sg GroupDescription: Security Group for Lambda to vpc VpcId: !Ref VpcID SecurityGroupEgress: - IpProtocol: tcp FromPort: 0 ToPort: 65535 CidrIp: 10.0.0.0/16 # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# LambdaFunction03: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: test-lambda-03 Runtime: python3.11 Timeout: 3 MemorySize: 128 Code: ZipFile: | def lambda_handler(event, context): print('Hello, World!') return { 'statusCode': 200, 'body': 'Hello, World!' } VpcConfig: SecurityGroupIds: - !Ref LambdaSecurityGrouptoVPC SubnetIds: - !Ref PrivateSubnet1aID - !Ref PrivateSubnet1cID # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaExecutionRole: Type: AWS::IAM::Role Properties: RoleName: IRL-Lambda AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Principal: Service: 'lambda.amazonaws.com' Action: 'sts:AssumeRole' ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole - arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole 利用可能なIPアドレス数の確認 先ほどと同様にサブネット内のIPアドレス数を確認します。 各AZごとに1つずつIPアドレスが解放されていますね。 マネジメントコンソールでのENIの確認 “test-lambda-01″で利用されていたHyperplane ENIが削除されていることが分かります。 “test-lambda-02″についてもLambda自体は削除しましたが、”test-lambda-03″が同一のHyperplane ENIを利用しているため、削除される挙動にはならないことを確認できました。 VPC Lambdaの設計の心得 三箇条 VPC Lambdaを利用するにおいて、設計の心得として3つ挙げます。 セキュリティグループとサブネットのペアでHyperplane ENIが作成されるため、用途に合わせたグループ化した設計をするべし いくらHyperplane技術によりVPC Lambdaが利用しやすくなったとはいえ、Lambdaごとに異なるセキュリティグループを作成しているとIP枯渇が発生します。EC2等と同様に、同じ機能を有するものには同一のセキュリティグループを付与するといった設計をおすすめします。 VPC Lambdaは、VPC内のリソースにアクセスするための機能のため、基本的にはセキュリティグループのアウトバウンドルールのみ設計するべし VPC Lambdaのセキュリティグループでは、基本的にインバウンドルールの評価はされず、アウトバウンドルールのみ評価されるのでアウトバウンドルールのみ考えてください。しかし一部のAWSサービス(Amazon MQ,Amazon MSK)でVPC Lambdaを利用する場合は、インバウンドルールについても評価されますのでご留意ください。 Amazon MSK で Lambda を使用する - AWS Lambda Amazon MSK で Lambda 関数を使用して、Apache Kafka トピックのレコードを処理します。 docs.aws.amazon.com Amazon MQ で Lambda を使用する - AWS Lambda メッセージブローカーからのレコードを処理するには、Amazon MQ で Lambda 関数を使用します。 docs.aws.amazon.com 他のAWSサービスと連携するためには、VPCエンドポイントまたはインターネットへの経路を確保するべし 特にプライベートサブネットを指定してVPC Lambdaを作成すると、他のAWSサービスに疎通することができません。利用したいAWSサービスのVPCエンドポイントの作成、またはパブリックサブネットにNAT Gateway,Internet Gatewayを配置してインターネットへの経路を作ってあげましょう。 最後に いかがだったでしょうか。 あまり意識することのないのVPC Lambdaの裏側を簡単に説明してみました。また、設計ポイントについても挙げていますので、VPC Lambdaを利用する際には振り返っていただければと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

「CatoはIPoE(IPv6)に対応していないの?」 というお問い合わせをよくいただきます。 主にNTTフレッツ回線において、従来のPPPoE方式(IPv4)の場合、NTTのNGN網とISPの接続点が混雑していることが多いため、接続方式をIPoE(IPv6)に変更してこの混雑を回避したいという内容のご相談です。 結論として、 IPv6対応ルータを間に挟めば利用はできますが、いくつかの注意が必要です。 本記事にて、利用構成と注意が必要な点をご紹介します。 本来は、PPPoEとIPoEは接続方式の違いであり、IPv4/v6とは直接は関係しないのですが、現在日本国内のインターネット接続サービスでは、IPv4はPPPoE、IPv6はIPoEで提供されることが多いため、本記事においてもPPPoE=IPv4、IPoE=IPv6として記載します。 一部回線事業者様においては、IPoE接続方式のIPv4サービス等、例外がありますのでご注意ください。 IPoE(IPv6)接続でのSocket接続構成 Catoクラウドは大変残念なことにIPv6に対応しておらず(※)、IPoE(IPv6)でSocketを直接接続することはできません。 ※当社からも対応を絶賛要望中です! しかしながら、IPv4の通信をIPv6にカプセル化する役割の 「IPv6対応ルータ」を挟むことで、IPoE接続の回線を利用した接続は可能 です。 構成イメージ ※DS-Lite方式での例です。NAPTを行う箇所は通信規格によって異なります。 Cato SocketはIPv4でしか通信できないため、そのままではIPv6のIPoE設備に接続することはできません。そこで、SocketとONUの間にIPv6対応ルータを接続します。IPv6対応ルータは、Cato SocketのIPv4通信をIPv6で包んでIPoE設備まで届けます。IPoE設備は受け取った通信をIPv4に戻してInternetへ送り出します。 これにより、Cato SocketはIPv6を意識することなく、通常どおりIPv4アドレスでCatoクラウドへ接続することができます。 IPv6対応ルータの選定 では、IPv6対応ルータとして、どのメーカーのどの機種を設置したら良いか?なのですが、IPv4 over IPv6の通信規格はISPによって異なり、対応している・していないルータがあるため、ISPに対応機種を確認するのが安全です。 当社では、この構成でYAMAHAのRTXシリーズの導入実績があります。RTXシリーズは日本国内のIPv4 over IPv6通信規格に概ね対応しております。以下ご参照ください。 ルーター | 製品情報 | ヤマハネットワーク製品 ヤマハルーター製品のページです。スループットやVPN対地数の違いにより、センターネットワークから拠点ネットワークまで幅広いラインナップ。VoIP等の電話機能を必要とする環境には、ネットボランチシリーズが最適です。 network.yamaha.com 動作確認済み IPv6 IPoE + IPv4 over IPv6 接続サービス一覧 なお、家庭用ルータでもIPv6対応のものは多数ありますが、一般的に性能が控えめに設計されているため、業務ご利用ではボトルネックになることがあり、おすすめしておりません。 IPoE接続を利用する場合の注意点 以上のように、ルータを設置することでIPoE(IPv6)回線の利用は可能ですが、いくつか注意点があります。 注意点1. IPv4グローバルアドレスを共用することによる問題 IPv4 over IPv6は、IPv4アドレスの枯渇対策として考えられた方式であることから、 基本はIPv4グローバルアドレスを複数利用者で共用 し節約する設計になっています。 このため、CatoクラウドでIPoE接続を利用し、IPv4 over IPv6での接続を行う場合、他のIPoE接続とIPv4アドレスが共用されることにより、 Cato SocketのOff-Cloud機能(※)がうまく動作しない可能性があります。 ※Site間の通信を、Catoクラウドを通さずにSocket間で直接通信させる機能です。Siteが固有のIPv4グローバルアドレスで接続していることが前提の機能のため、もし他のSiteとアドレスが重複してしまうと動作しません。 注意点2. IPv4通信のセッション数制限問題 IPoEでは、上記のようにIPv4アドレスを共用する都合上、多くのISPで 1回線がIPv4通信で使用できるNAPTポート数(セッション数)に上限が設けられています。 Cato Socketを接続するのみだと上限にかかる可能性は低いですが、もし同じ回線をCato以外の通信にも利用されていたり、またSocketを設置せず複数名がCatoクライアントを利用するような場合には、上限にかかり、IPv4での通信が不安定となる可能性があります。 問題の回避方法 上記2つの問題を回避するため、 IPoE接続の回線を選定される際は、法人向けで、固定のIPv4アドレスが付与されるタイプが安全です。 このタイプですと、IPv4アドレスが専用に割り当てられることから、アドレス重複の可能性を回避できます。また、専用アドレスのためポート数制限が大幅に緩和されているISPが多い模様です。詳細はご検討中のISPにもご確認ください。 その他の制限 なお、いずれの回線タイプであっても、SocketがIPv4グローバルアドレスを持たない構成となるため、SocketでのLocal Port Forwardingはできません。また、同様にSiteをIPsecでCatoクラウドへ接続することもできません。 まとめ IPv6対応ルータを導入することで、IPoE(IPv6)でCato Socketを接続することは可能です。 しかしながら、 IPoE接続サービスの仕様や制約はISPによって違いがあるため、ご検討の際は、ISPによくご確認いただくことをおすすめします。

この記事は Japan AWS Ambassador Advent Calendar 2023 の12/22付記事となります。 こんにちは、SCSKの木澤です。 昨日の記事は早川さんによる「 JAWS DAYS 2024 “LEAP BEYOND”～ラーニング・コミュニティで得られるもの～ 」でした。 早川さんは2024/3/2に開催される JAWS DAYS 2024 の実行委員長を担当されます。10月に福岡で開催された JAWS Festa 2023 で発表があり大変驚きましたが技術力/実行力とも兼ね備える才色兼備なアンバサダーです！ 私はAWS Ambassadorを拝命して3年目になりました。 AWSサービスの進化と共に、インフラエンジニア出身の私としては徐々に肩身が狭くなることを感じつつも、今後とも各社の優秀な方々と交流し刺激（プレッシャー）を頂くことを楽しみにしています。私自身としても、私ができる範囲でのアウトプットを続けて行ければと思います。 さて、今回は最近注目しているアップデートとして、Amazon CloudFront KeyValueStoreの活用について紹介したいと思います。 公式ブログはこちら CloudFront Functions 用の低レイテンシーデータストア、Amazon CloudFront KeyValueStore の紹介 | Amazon Web Services Amazon CloudFront は、静的コンテンツと動的コンテンツを、低レイテンシーかつ高速な転送速度でセ aws.amazon.com Amazon CloudFrontでのエッジコンピューティング Amazon CloudFrontとエッジ処理の概要 Amazon CloudFrontの特徴と概要については、以前当サイトにてご紹介しました。 Amazon CloudFrontとキャッシュ制御の基礎 CDNおよびAmazon CloudFrontの概要と、Webサイトにおけるキャッシュ制御の考え方、CloudFrontの設定方法まで解説をします。 Webサイトにおける基本的なCloudFront適用の考え方を一通り網羅しているかと思います。 blog.usize-tech.com 2022.03.29 Amazon CloudFrontはCDN(Contents Delivery Network)のサービスであり、極力ユーザの近くからに設置したキャッシュからWebコンテンツを配信することでサイトの高速表示とサーバの負荷軽減に貢献するサービスとなります。 CloudFrontの配信拠点をエッジロケーションと呼びます。 上記の記事を発信した際（2022年3月）には全世界で300以上と記載しておりましたが、約20ヶ月経過した現在では600以上と記載が変更されています。どんどんエッジロケーションは増えているようです。 特徴 - Amazon CloudFront | AWS Amazon CloudFront のグローバルコンテンツ配信ネットワーク (CDN) の主な機能について説明します。Amazon CloudFront は、データ、動画、アプリケーション、および API をすべてデベロッパーにとって使いやすい環境で、低レイテンシーの高速転送により視聴者に安全に配信する高速コンテンツ配... aws.amazon.com さて折角エッジロケーションで一旦アクセスを受け付けるのであれば、以下のような処理をエッジ側で行いたいというニーズが発生することがあります。 認証 URLリライト／リダイレクト 応答コードのカスタマイズ HTMLレンダリング処理/画像変換 これらの要求に対応するため、エッジロケーション内で処理を実装できるのが今回ご紹介するサービス群となります。 本記事内では一部、re:Invent 2023のワークショップで撮影した写真を利用しています CloudFront FunctionsとLambda@Edgeの違い CloudFront内で処理を行うサービスはCloudFront FunctionsとLambda@Edgeの2種類があります。 違いを表にまとめますと、以下のようになります。 サービス CloudFront Functions Lambda@Edge ユースケース 認証 HTTP応答コードのカスタマイズ URLリライト/リダイレクト サーバサイドレンダリング 応答のパーソナライズ ボットアクセスの排除 言語 JavaScript Node.js Python ネットワークアクセス 不可 可 スケール 10,000,000リクエスト/秒 10,000リクエスト/秒/リージョン 実行時間の制限 数ミリ秒 5秒 (ビューアーアクセス側処理) 30秒 (オリジンアクセス側処理)  関数の容量制限 10KB 250MB コスト $0.1/100万回 $0.6/100万回 ユースケースと適用場所の違いはこの図が解りやすいかと思います。 私の理解は下記の通りです。 限定的な用途だが大量処理でき安価な CloudFront Functions リージョン内の他AWSサービスと連携して高度な処理が出来る Lambda@Edge 制限事項等、仕様について詳しくは公式ページをご覧下さい エッジ関数に対する制限 - Amazon CloudFront CloudFront Functions と Lambda@Edge は、以下の制限の対象となります。 docs.aws.amazon.com   Amazon CloudFront KeyValueStoreについて さて今回発表されたKeyValueStoreですが、CloudFront Functionと連携し利用できる簡易データベースとなります。 従来、CloudFront Functionsはネットワークアクセスができないため他のAWSサービスと連携できず利用用途が限られていましたが、本機能を利用することで関数の容量制限(10KB)を超えたデータを持てるようになるため、認証等CloudFront Functionsの用途が格段に拡大するアップデートかと思います。 ビューアーアクセス（ユーザーリクエストへの応答）の制御にはCloudFront Functions+KeyValue Store、オリジンアクセスを高度化しコンテンツ生成のカスタマイズを行いたい向きにはLambda@Edgeと使い分けるのがベストプラクティスと考えられます。 本Key-Value StoreへのメンテナンスはマネジメントコンソールやAWS CLIで可能な他、APIアクセスによる値の変更も可能ですので、リージョン内のAWSサービスと連携した自動制御を行うことができます。 なお、本KeyValue Storeの価格は以下の通りです。 CloudFront Functionsからの読み取り：$0.03/100万アクセス APIアクセス：$1.0/1000アクセス 料金 - Amazon CloudFront | AWS AWS 無料利用枠を含む、Amazon CloudFront のグローバルコンテンツ配信ネットワーク (CDN) の料金の詳細。前払い料金や固定基本料金、長期使用契約、動的コンテンツの割増料金はありません。また、使用開始時の専門的なサービスも不要です。 aws.amazon.com   実装してみた さて今回はプレスリリース等、期日が来るまで発信してはならないユースケースを想定し、 特定URLにアクセスがあった際にURLリライトによる転送を行う といった実装を考えてみます。 KeyValue Storeの作成 CloudFrontのコンソール左側のメニューから「関数」を選択し「KeyValueStores」のタブをクリックします。 KeyValueStoreの名前を入力し作成します。 この際、事前にJSON形式のファイルをS3に作成しておき値を直接読み込むこともできます。 作成できました。 続いて値を入力します。 キーと値を入力し保存します。 今回は値が「Rewrite」となっているURIへのアクセスを書き換えることにします。 CloudFront Functionsの作成 続けて作成したKeyValueStoreを用いてアクセス制御する関数を実装します。 Functionsタブにて「関数を作成」ボタンをクリックします。 関数の名前を入力します。 ランタイムはcloudfront-js-2.0である必要があるようです。 関数のひな形が作成できました。 KeyValueStoreの紐付けを行います。 作成したKeyValueStoreを指定します。 紐付けが完了するとサンプルコードが表示されます。（優しいですね！） KeyValueStoreのIDが埋め込まれているので、これを活用してコーディングを開始すると良いかと思います。 今回は以下のようなコードにしました。 単純にKeyValueStoreに値「Rewrite」として登録があるURIへのアクセスがあった際に特定URIにリライトする処理です。 import cf from 'cloudfront'; const kvsId = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'; const rewriteURI = '/'; // This fails if the key value store is not associated with the function const kvsHandle = cf.kvs(kvsId); async function handler(event) { const request = event.request; const uri = request.uri; let value = "Not found" // Default value try { value = await kvsHandle.get(uri); if(value=='Rewrite'){ // URL rewrite to another path if the key is "Rewrite" console.log(`${request.uri} -> ${rewriteURI}`) request.uri = rewriteURI; } else { // No change to the pathname if the key is another value console.log(`${request.uri} | ${value}`); } } catch (err) { // No change to the pathname if the key is not found console.log(`${request.uri} | ${err}`); } return request; } コーディング後、コンソール上からテストを行うことも可能です。 URIに応じた動作を確認でき、助かります。 テストで動作を確認したら、発行しましょう。 CloudFrontディストリビューションへの割り当て 作成した関数をCloudFrontのディストリビューション（ビヘイビア）に紐付けます。 これにより、特定のビヘイビアに対してアクセスがあった際にCloudFront Functionsが反応して動作するようになります。 設定はディストリビューション側、関数側両方から行うことが出来ますが、今回は関数側から行います。 ディストリビューションとの「関連付けの追加」をクリックします。 関連付けるディストリビューション、イベントタイプ、ビヘイビアを選択します。 これで設定完了です。 ディストリビューション側の設定画面でも、作成したCloudFront Functionsと紐付いていることを確認できます。 ビヘイビアの選択後にCloudFront Functionsが実行される仕様のため、他ビヘイビアに跨がるURIへのリライトはできません。別オリジンに静的ページを設置しているようなケースではご注意ください。 動作確認 さて、以上で実装が完了しました。 ディストリビューションの配下の指定したURIにアクセスした際、特定のページ（上記コードの場合はトップページ）が表示されるようになっているはずです。 このコードを応用すれば 「特定IPアドレスからアクセスがあった際は表示するが、その他のアドレスには表示しない」 等の設定も容易に出来るはずです。柔軟にカスタマイズできて良いですね。 なお、CloudFront Functionsの動作ログは、us-east-1リージョンのCloudWatch Logs（ロググループ：/aws/cloudfront/function/関数名）に出力されます。 デバッグの際はこちらを参照すると良いでしょう。   まとめ 従来からAmazon CloudFrontについては私の好きなサービスの１つですが、CloudFront FunctionsやLambda@Edgeは必要性に駆られず、今まで触っていませんでした。 今回のアップデートを機にCloudFront Functionsを触ってみましたが、簡単に実装でき面白かったですね。 今後は色々なユースケースに積極的に活用していこうと思います。（Lambda@Edgeも） 皆さんのご参考にもなれば幸いです。 さて 明日の Japan AWS Ambassador Advent Calendar 2023 は、AmbassadorやJAWS-UGのイベントで今年も頻繁に交流させていただいた、EQに詳しいフェンリル柴田さんの投稿です！ お楽しみに。

  本記事は TechHarmony Advent Calendar 12/22付の記事です。 皆様、こんにちは！SCSKの佐藤海渡と申します。 今年度SCSKに新卒入社し、現在はUSiZE運営を担当しています。 TechHarmonyの過去記事を見ているとUSiZEに関する記事が少ない！ということにに気づき、本記事を投稿するに至りました。 まだまだ携わっている歴は短いため詳細をお伝えすることは難しいかもしれませんが、”新人が頑張ってまとめたんだな”と温かい目でご覧いただけると幸いです。 USiZEとは それでは早速USiZEとはなにかを一言で表しますと…   USiZE＝SCSKが運営するクラウドサービス   です！ SCSKは netXDC と呼ばれるデータセンタを保有しており、その設備をサービス基盤としたクラウドサービスがUSiZEです。サービスは大きく以下の2つに分かれています。 USiZEシェアードモデル （ マネージドクラウド ） USiZEパブリッククラウドモデル （パブリッククラウド（ AWS 、 Azure 、 Google Cloud ）） それぞれのサービスの詳細や事例が知りたい方はリンクをクリックして該当ページをご覧ください。 上記2つのサービスの組み合わせによってお客様の課題解決を実現しています。   新人目線でUSiZEのいいところまとめ では、USiZEの良いところは一体何でしょう？ 新人なりに考えてまとめてみた結果、以下の3点があると考えています。 クラウド移行に強みあり 実はパブリッククラウド3社よりも歴史の長いUSiZE… （USiZE：2004~ 、AWS:2006~ 、Google Cloud:2008~ 、Azure:2010~） そんな長い歴史の中でお客様のクラウド移行を支援してきた実績もあり、 クラウド移行 には強みがあるようです。 古いOSやアプリなどを搭載したいわゆる”塩漬けシステム”にも対応しており、 クラウド移行 は進めたいけどいきなりすべてをパブリッククラウドに変えるのはちょっと…という場合に最適かもしれません。 ハイブリッドクラウド・マルチクラウドとしての活用 ”USiZEとは”の項で説明したようにUSiZEにはマネージドクラウドのサービスとパブリッククラウドのサービスが存在します。 そして、それら二つのサービスを組み合わせることにより現在、需要の高まっている ハイブリッドクラウド としての活用が可能になります。   またUSiZEでは、netXDCで提供が開始された”SCNX”サービスによってパブリッククラウド（ AWS 、 Azure ）と専用接続することが可能になっています。”SCNX”サービスによってUSiZEを複数のパブリッククラウドとの接続点として利用し、 マルチクラウド として活用することが可能です。 ソブリンクラウドとしての活用 新人目線ということで最後の項目 ”ソブリンクラウド” 正直入社するまで聞いたことのない言葉でした… 意味を調べてみるとSovereign(主権者)という意味らしく、どうやら「クラウドで扱うデータの主権を確保したサービスを指す言葉」という意味だそうです。近年、世界各国でデータに関する法律が出来ていることによって注目されているみたいです。 その点でUSiZEは ・国内の SCSKが運用管理するデータセンターにサービスを配置 ・ISMS/ITSMS/BCMSの各種認証取得のデータセンターにて運営 ・DR構成による可用性向上 といった点で ソブリンクラウド としての活用が可能であり セキュリティやコンプライアンスのトレンドを押さえたサービスとなっています。   終わりに といったわけで今回はUSiZEを新人目線で簡単にまとめさせていただきました。 今回まとめてみて感じたことは、USiZEでは新しく覚えることが少ないということでした！（いい意味で） クラウド初学者の佐藤としては 他のパブリッククラウドではクラウドサービスの名称と機能を紐づけて新しい知識をINPUTするのが大変な印象でしたがUSiZEでは ”今まで使っていたシステムをクラウドに移行する” ”パブリッククラウドとの接続点として利用する” といった使い方で、USiZEを使うために必要な新しいINPUTは最低限という印象でした。 ”ソブリンクラウド”として国産のクラウドが期待されている現在、USiZEはその担い手になっていく予感がしました！ この記事で少しでも皆さんにUSiZEのことが伝わることを願っています。   実際にUSiZEを活用したい！ もっと詳しい話が聞いてみたい！ という方は以下のお問い合わせフォームからお問い合わせください。 お問い合わせフォーム   以上、SCSK佐藤海渡の初投稿記事でした。

今回は、2023年12月11日に発表された「Cato管理アプリケーションの管理者に対するMFA要件の強化」について解説します。 アップデートの概要 Catoクラウドのアカウント（テナント）の管理者（Administrator）のセキュリティ強化のため、ID/パスワードのクレデンシャル認証に加え、 MFA（Multi-Factor Authentication：MFA）が 必須 となりました。 これまで、MFAの利用は選択式で、以下設定箇所でMFA有効化のチェックボックスのチェックを外せば無効化ができましたが、2023年12月11日以降に新規作成されるアカウント（テナント）については、チェックボックス自体が非表示になりMFAは常に有効となります。 設定箇所：Administration＞Admin Configuration＞General また、このアップデートは、2023年12月11日以降に作成されたアカウント（テナント）に適用されるものであり、既存アカウント（テナント）については特に影響はございませんが、新規で管理者（Administrator）を追加する際はデフォルトでチェックボックスにチェックが入りますので、MFAは有効の状態となります。無効化にしたい場合にはチェックを外す必要があります。 MFA（多要素認証）設定手順 CatoクラウドのMFAは、Authenticatorアプリケーションを利用します。 Authenticatorアプリケーションは、スマートフォンやパソコンにインストールすることで、アプリケーション上で一定時間有効な認証コードを生成するものです。 TOTP（Time-based One-Time Password）の仕組みで、一度しか利用できないワンタイムパスワードを、時間に基づいた乱数から認証コード（6桁の数字）を生成します。 有名なものとしては、 Google Authenticator や Microsoft Authenticator がありますが、今回は、Microsoft Authenticatorを使ってMFAの設定方法を説明いたします！ 初回ログインまでの手順 Administrator登録 Invitationメール受信 パスワードの設定 Authenticatorアプリケーションのインストール AuthenticatorアプリケーションでQRコードを読み取り CMAログイン 1.Administrator登録 CMAを開いてAdministrationのページから登録を行います。 必要な情報は氏名とメールアドレスのみです。 この際権限付与が必要ですが、今回はテストなのでViewer権限を付与します。 2.Invitationメール受信 Administratorの登録を行うと、登録したメールアドレス宛にInvitationメールが届きます。 Click hereをクリックするとパスワードの設定画面へ遷移します。 3.パスワードの設定 パスワードの設定画面はこのような感じです。 8文字以上で、大文字小文字含む英数字でパスワードの設定を行います。 ”Configure Password”ボタンを押すとこのようなQRコードが表示されますが、 ”Continue”を押さずに 次の手順へ進みます。 4. Authenticatorアプリケーションのインストール スマートフォンにAuthenticatorアプリケーションをインストールします。 ※今回はMicrosoft Authenticatorを使用します 5.AuthenticatorアプリケーションでQRコードを読み取り インストールが完了したらアプリを立ち上げ、右上の +アイコン を押して ”QRコードをスキャン” を選択します。 手順3で出力されたQRコードをスマートフォンで読み取りを行うと、このように6桁のコードが作成されます。 6.CMAログイン “Continue”ボタンを押すと、MFA入力画面に遷移するので、Microsoft Authenticatorアプリケーションに表示されている6桁のコードを入力してログインします。 2回目以降のログイン手順 2回目以降のログインの際はメールアドレスおよびパスワードの入力後、Authenticatorアプリケーションの6桁のコードを入力してログインする流れになります。   まとめ 今回は、アップデート情報の中から”CMA管理者に向けたMFAの機能強化”についてご紹介をいたしました。 今後もCatoクラウドに関する新たな情報をお届けできればと思います！

こんにちは、SCSK株式会社の大石です。 Terraformには様々なプロバイダが存在していますが、その中にZabbixのプロバイダがあることをご存じでしょうか？ 今回は、Terraformを使用して、Zabbixの監視設定をしてみたいと思います。 監視内容は以下を想定します。 ホスト: test ホストグループ: testHostgroup テンプレート: testTemplate アイテム: CPU5分間のロードアベレージ トリガー: 最終取得データが2を超えた場合 使用するプロバイダは以下となります。 Terraform Registry registry.terraform.io   プロバイダのインストール terraformで使用するプロバイダをインストールします。 .tfファイルを作成し、以下を記述します。 terraform {     required_providers {         zabbix = {             source = "tpretz/zabbix"             version = "0.17.0"         }     } } 上記を記載したら、以下コマンドを実行してインストールをします。 terraform init   プロバイダの選択とZabbixログイン プロバイダをインストールしたら、プロバイダブロックを記載していきます。 プロバイダブロックは上記でインストールしたZabbixプロバイダとログイン情報を記載する必要があります。 provider "zabbix" { username = "<Webコンソールのユーザ>" password = "<Webコンソールのパスワード>" url = "http://<IPアドレス or ドメイン>/zabbix/api_jsonrpc.php" tls_insecure = false } 監視設定 続いてリソースブロックとデータブロックを記載して、監視設定をします。 // 作成するテンプレートが所属するホストグループを取得 data "zabbix_hostgroup" "templategroup" { name = "Templates" } // 今回作成するホストが所属するホストグループ作成 resource "zabbix_hostgroup" "test_hostgroup" { name = "testHostgroup" } // テンプレート作成 resource "zabbix_template" "test_template"{ host = "testTemplate" 　//1~3行目で 取得したホストグループのIDを指定 groups = [data.zabbix_hostgroup.templategroup.id] } // エージェントタイプのアイテム作成 resource "zabbix_item_agent" "test_item" { 　// 作成したテンプレートIDを指定 hostid = zabbix_template.test_template.id key = "system.cpu.load[all,avg5]" name = "test_item_system.cpu.load" valuetype = "float" } // トリガーを作成 resource "zabbix_trigger" "test_trigger" { name = "test_trigger_system.cpu.load[all,avg5]" expression = "last(/test/system.cpu.load[all,avg5])>2" priority = "disaster" } // ホストを作成 resource "zabbix_host" "test" { 　// 作成したホストグループのIDを指定 groups = [ zabbix_hostgroup.test_hostgroup.id ] host = "test" interface { ip = "172.23.32.191" type = "agent" } // 作成したテンプレートのIDを指定 templates = [zabbix_template.test_template.id] 　// アイテムとトリガーの依存関係を指定 depends_on = [ zabbix_item_agent.test_item ] } ここまで書いたら、以下のコマンドを実行して.tfファイルに書いたリソースを適用します。 // 適用前に確認 terraform plan // .tfファイルの内容を適用 terraform apply ZabbixのWebコンソールを開き、[設定]-[ホスト]を開くと、設定されたホストが登録され、 テンプレートの適用とアイテム、トリガーが登録されていることが分かります。 最後に Terraformには今回ご紹介したプロバイダ以外にもいくつかありますが、リソースを変更するとホストを削除して再登録する挙動をしたり、 バグで変更そのものができないものもあったりします。今回ご紹介したプロバイダも含め、バグを踏んで予想外の動作をすることもあるので、要検証したうえで使用しましょう。 弊社では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 ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com