本記事は TechHarmony Advent Calendar 12/21付の記事です。 こんにちは、「TechHarmony Advent Calendar 2023」21日目担当、SCSK三上です。 もうすぐクリスマス★日が落ちるのが早いことが寂しい冬ですが、この時期は日が落ちると街がイルミネーションでライトアップされていくのでわくわくします♦◊♦◊ 今回は、2022年re:Inventにて発表されたAmazon QuickSightをコード管理する『Assets as Code』(以下AaC)機能について、 概要と実際に触ってみたので画面イメージなど共有していきます！ Amazon QuickSightについてはこちらのブログ冒頭に記載しております！ Amazon QuickSight 「Paginated Reporting」ってなに？ Amazon QuickSight の Paginated Reporting を実際に触ってみたので画面イメージなど共有します。 blog.usize-tech.com 2023.10.04 Amazon QuickSightについて 今までのAmazon QuickSightに関する課題 一部のビジュアルや設定を変更してダッシュボードや分析の再利用  マルチテナントの各テナントに応じたテーマ設定など  マルチテナントの各テナントに応じたパラメータ変更など  ダッシュボードや分析のバージョン管理やバックアップおよびリストア 別AWSアカウントからのダッシュボードや分析のインポート  別AWSアカウントへのダッシュボードや分析のエクスポート アカウント間の移行など、コスト含める開発効率が悪い… Assets as Code (AaC)について AaCでできること、できないこと できること できないこと Amazon QuickSightの外部にダッシュボード/分析の定義をエクスポート AWS CodeCommitやGitHubによるバージョン管理が可能！ アセットを移行する前に ビジュアルやテキストなどのレイアウト修正 BCP （ Business Continuity Plan – 事業継続計画）または Disaster Recoveryの定義 災害があった場合に事前に定義ファイルを読み込むことで別リージョンで同じ環境を再現できる！ プログラムによるダッシュボード/分析の作成 他のツールから移行するための自動化作成 分析やダッシュボードの レイアウトのスナップショットを作成してAmazon QuickSightに保存 Amazon QuickSightアカウント内でのバージョン管理 データセットとデータソースの管理 （別途管理が必要） あくまでもダッシュボードや分析の管理になる！ つまり、AaCは今までGUI操作メインだったQuickSightがコード管理できるようになり、 アカウントの再現・再利用がしやすくなったということです！ Assets as Bundle (AaB)について AaCとは別にAaBという機能もあります。できること・できないことはAaCと基本的に同じですが、 AaCとの違いは、” AaBは、別環境への移行をよりシームレスにできる “ということです。 テンプレート vs AaC vs AaB 項目 Template AaC AaB 対応アセット 分析 ダッシュボード 分析 ダッシュボード 分析 ダッシュボード テーマ データセット データソース Ingestionスケジュール VPC接続 バージョン管理機能 あり Amazon QuickSight以外で可 Amazon QuickSight以外で可 可視化定義出力 不可 可 可 移行時に必要なその他のアセット データセット データソース テーマ データセット データソース テーマ なし シート対応（ダッシュボード） 不可（常に全シート） 可 可 CloudFormation/CDK対応 可 可 未対応 ※対応予定あり！ CLIバージョン 自動対応 手動管理 自動対応 用途 環境間のアセット移行やバージョン管理 コードレベルでのアセット管理 ダッシュボードや分析のSaaSや複数環境における展開 データセットやデータソースは共通化して、環境間のアセット移行として使用 環境間でのアセット移行やバックアップ コードレベルのアセット管理 コードで新しいダッシュボードを作成してみる まずは、コードでダッシュボードを作成してみます！アーキテクチャは下記の通りです。 作業は、Cloud9上でコマンド操作していきます。 今回実施することは、 既存で作成されたダッシュボードの定義ファイルをエクスポートし、 同一アカウント内で、定義ファイルをインポートし新規のダッシュボードとして作成 していきたいと思います！ 前提として、QuickSight操作可能なCloud9の環境はセットアップ済みとします。 また、コマンドに記載の変数はCloud9上で事前に定義設定しているものとします。 例：     export QUICKSIGHT_REGION =es-east-1 ① ダッシュボード定義ファイルの取得 まずは、エクスポートする既存ダッシュボードの定義ファイルを取得します。 aws --region ${QUICKSIGHT_REGION} quicksight describe-analysis-definition --aws-account-id ${AWS_ACCOUNT_ID} --analysis-id ${QUICKSIGHT_ANALYSIS_ID} > ${QUICKSIGHT_ANALYSIS_DEFINITION_FILE_PATH} QUICKSIGHT_ANALYSIS_IDは、既存ダッシュボードの分析IDです。分析IDの取得コマンドは、以下の通りです。 aws --region ${QUICKSIGHT_REGION} quicksight list-analyses --aws-account-id ${AWS_ACCOUNT_ID} QUICKSIGHT_ANALYSIS_DEFINITION_FILE_PATHは、ダッシュボード定義ファイルのパスです。ご自身のCloud9環境のパスをご指定下さい。 例： export QUICKSIGHT_ANALYSIS_DEFINITION_FILE_PATH= ~/xxxxxx/xx/analysis_definition.json ② ダッシュボード作成ファイル（スケルトンファイル）の取得 ダッシュボード定義ファイルは既存ダッシュボードの情報になります。コードで新規にダッシュボードを作成するスケルトンファイルを取得していきます。 AaCでは、「ダッシュボード定義ファイル」と「スケルトンファイル」が必要です！ スケルトンファイルは設定項目のみ記載しているテンプレートファイルです。 それでは、ダッシュボード用のスケルトンファイルを取得します。 aws --region ${QUICKSIGHT_REGION} quicksight create-dashboard --generate-cli-skeleton > ${QUICKSIGHT_DASHBOARD_SKELETON_FILE_PATH} QUICKSIGHT_DASHBOARD_SKELETON_FILE_PATHは、スケルトンファイルのパスです。ご自身のCloud9環境のパスをご指定ください。 例： export QUICKSIGHT_DASHBOARD_SKELETON_FILE_PATH = ~/xxxxxx/xx/dashboard_skeleton.json ③ 新しいダッシュボードの定義ファイルの作成 既存のダッシュボード定義ファイルとスケルトンファイルからそれぞれ実行時に必要なパラメータを抽出し、ダッシュボード定義ファイルの値を参考に、新しい定義ファイルを作成します。最低限必要なパラメータは下記の通りです。 定義ファイル スケルトンファイル AwsAccountId Name ThemeArn DashboardPublishOptions Name ThemeArn DashboardId 一部JSON抜粋したものが下記の通りです。 手動で抽出するのは結構面倒くさいので、ダッシュボード定義ファイルとスケルトンファイルを突き合わせて新しい定義ファイルを作成するスクリプトなど活用すると良いです！ ④ 新しいダッシュボードの作成 新しいダッシュボード定義ファイルを読み込ませ、新しいダッシュボードを作成していきます。 aws --region ${QUICKSIGHT_REGION} quicksight create-dashboard --cli-input-json file:// ${QUICKSIGHT_NEW_DASHBOARD_DEFINITION_FROM_DASHBOARD_FILE_PATH} QUICKSIGHT_NEW_DASHBOARD_DEFINITION_FROM_DASHBOARD_FILE_PATHは、新しいダッシュボードの定義ファイルのパスです。ご自身のCloud9環境のパスをご指定ください。 例： export QUICKSIGHT_NEW_DASHBOARD_DEFINITION_FROM_DASHBOARD_FILE_PATH = ~/xxxxxx/xx/new_dashboard_definition.json Cloud9のCreateStatusに『CREATION_IN_PROGRESS』と表示されれば成功です。 ステータスの確認方法は以下の通りです。 aws --region ${QUICKSIGHT_REGION} quicksight describe-dashboard --aws-account-id ${AWS_ACCOUNT_ID} --dashboard-id <ダッシュボードID> 値が『CREATION_SUCCESSFULL』になれば作成完了です。 ⑤ 権限付与＆確認 この状態でダッシュボードのコンソールを確認しても、ダッシュボードは表示されません。 QuickSightのユーザに対してアクセス権限を付与する必要があります。 aws --region ${QUICKSIGHT_REGION} quicksight update-dashboard-permissions --aws-account-id ${AWS_ACCOUNT_ID} --dashboard-id <ダッシュボードのID> --grant-permissions Principal = ${QUICKSIGHT_USER_ARN} ,Actions = quicksight:DescribeDashboard,quicksight:ListDashboardVersions,quicksight:UpdateDashboardPermissions,quicksight:QueryDashboard,quicksight:UpdateDashboard,quicksight:DeleteDashboard,quicksight:UpdateDashboardPublishedVersion,quicksight:DescribeDashboardPermissions これでコンソールを確認すると、新しいダッシュボードが表示されます！ 感想 今回は、同一アカウントでダッシュボードを作成しましたが、他アカウントへ分析・ダッシュボードの移行する際に役立つかと思います！ 実際にAaCを触ってみて、ポイントは 新しいダッシュボードの定義ファイルを作成する点 かと思います。 今回はスケルトンファイルと既存のダッシュボード定義ファイルから必要な設定項目を抽出し、新しいダッシュボードの定義ファイルを作成するPythonを用意していたので、問題なかったですがこれを一から手動で作成するのは厳しいな…と感じました。 それ以外は、比較的分かりやすく進めることができました！ 最近、QuickSightのアップデートが著しいので今後は新しい機能をどんどんトライしていきたいと思います★ New Amazon QuickSight API Capabilities to Accelerate Your BI Transformation | Amazon Web Services Regular readers of this blog, and AWS customers alike, know the benefits of infrastructure as code (IaC). It allows you to describe your infrastructure using a ... aws.amazon.com

本記事は TechHarmony Advent Calendar 12/20付の記事です。 こんにちは。SCSKの江木です。 Google Cloud Generative AI Summit Osakaに参加してきたので、イベントの内容と感想を投稿します。 Google Cloud Generative AI Summit Osakaとは？ Google Cloud Generative AI Summit Osakaとは2023年12月14日にコングレコンベンションセンターで開催された、生成AIに特化したGoogle Cloudのイベントです。現地とオンラインの両方での開催となりました。 本イベントは主に以下の内容で構成されています。 基調講演 セッション 展示ブース 基調講演・セッションをメインで聞き、休憩時間で展示ブースを回るといったイベントでした。 参加した基調講演・セッション 参加した基調講演・セッションを表にまとめてみました。 時間 基調講演・セッションタイトル 14:05~14:30 【基調講演】生成 AI の未来：創造性とイノベーションの新たな時代 14:30~14:55 実践 生成 AI 〜 Vertex AI で始める Google の大規模言語モデルの活用〜 15:10~15:35 生成 AI 時代のデータ エンジニアリング入門 〜 Google Cloud で実現する 生成 AI データ エンジニアリングの第一歩 〜 15:35~16:00 生成 AI を活用した検索アプリやチャットボットを迅速に開発する 〜Vertex AI Search and Conversation 紹介〜 16:15~16:40 Duet AI がもたらす新たな働き方の世界 16:40~17:00 Google Cloud 生成 AI パートナー エコシステムのご紹介 17:00~17:15 生成 AI による SQL 作成支援機能と AI 活用文化の醸成 17:15~17:30 Vertex AI を使った社内情報高度検索実現への取り組み それぞれの基調講演・セッションについて記載していきます。 【基調講演】生成 AI の未来：創造性とイノベーションの新たな時代 概要 生成AIの実用化に向けて、何が必要なのかを考える 内容・感想 生成AIが実験から実用へと踏み出した１年だったと話されていました。 生成AIは答えを知っているのか知らないのかではなく、工夫が裏でされていることが強調していました。学習された段階で知らない内容ではハルシネーションを起こすが、グラウンディングと呼ばれる技術によって、ハルシネーションを抑制することができるとのことでした。 先日発表されたGeminiを発表されていました。Geminiは、テキスト、音声、画像などを一度に処理できるマルチモーダルに対応しています。生成AIの応用の幅が一気に広がるのでとても楽しみですね！！ 生成AIに必要な要素として、検索や会話が挙げられていました。意味が近いものを取り出すセマンティック検索、生成AIを用いたFAQの会話フローが紹介されていました。 確かに、現在世の中にある生成AIを使ったサービスには、検索と会話の要素が含まれていると感じます。 実践 生成 AI 〜 Vertex AI で始める Google の大規模言語モデルの活用〜 概要 Vertex AIを用いたLLMのカスタマイズ手法の紹介 内容・感想 生成AIを活用したソリューションを作るためのサービスであるVertex AIが紹介されていました。 基調講演でも話されていましたが、生成AIを用いる際にはハルシネーションという問題があります。このハルシネーションを抑制するにはグラウンディングの他にもプロンプトデザイン、ファインチューニングといったモデルのカスタマイズ手法があるそうです。 プロンプトデザイン、ファインチューニング、グラウンディングの手法がかなりわかりやすく説明されていたので、改めて勉強になりました。また、グラウンディングの実装手段として、LangChain、Vertex AI Search & Conversationが紹介されていました。 生成 AI 時代のデータ エンジニアリング入門 〜 Google Cloud で実現する 生成 AI データ エンジニアリングの第一歩 〜 概要 BigQueryを用いた非構造化データの分析 内容・感想 音声や画像などの非構造化データは重要な情報を持っており、ビジネスの差別化のために、活用することが求められると話されていました。 データエンジニアリングに生成AIを使用することで、非構造化データの活用、データへのAI/ML処理の実行、AIアシストによる効率的な分析が可能になるとのことでした。データエンジニアリングに生成AIを取り入れるためのソリューションとしてBigQueryを紹介していました。 BigQuery MLのGENERATE_TEXT関数を使って、文章の要約や感情分析などを行うデモが行われておりました。SQLだけでAIを用いたデータ分析ができるなんてすごいですよね！！ 生成 AI を活用した検索アプリやチャットボットを迅速に開発する 〜Vertex AI Search and Conversation 紹介〜 概要 Vertex AI Search & Conversationの紹介 内容・感想 Google CloudのAIの統合基盤であるVertex AIの概要が説明されていました。Vertex AIのサービスの中でも、ノーコードで、Googleの最新基盤モデル、検索技術、会話AIの機能を組み合わせて体験を作ることができるVertex AI Search & Conversationを本セッションでは紹介していました。 Vertex AI Searchはマルチモーダルな検索、文脈維持のマルチターン、要約をノーコードで構築可能だそうです。グラウンディング機能もあるので、ハルシネーション抑制に効果的ですね。 Vertex AI Conversationは生成AIを利用したチャットボットを作ってくれるサービスで、作成したチャットボットの会話の要約、タスクの自動実行もできるそうです。 Vertex AI Search & Conversationの使用事例の紹介も行っていました。 日焼け止め開発でVertex AI Searchを使用した事例を紹介していました。日焼け止めのニーズを生成AIで検索することで、時間短縮を実現したそうです。 自転車が欲しいユーザーに適切な自転車を提案してくれるチャットボットを構築するためにVertex AI Conversationを使用した事例を紹介していました。マルチモーダル対応で自転車の写真付きで提案してくれるそうで、ユーザーとしてはかなり助かりますよね！ Vertex AI Search & Conversationのアップデート情報も紹介していました。先日発表されたGeminiに対応するそうで、ますますマルチモーダル化が進みますね！！ Duet AI がもたらす新たな働き方の世界 概要 Duet AI for Google Workspaceの紹介 内容・感想 Google Workspaceに生成AIの機能を追加したDuet AI for Google Workspaceを紹介していました。Duet AIの活用例として、ブログ作成、会議のリアルタイム字幕翻訳、AppSheetを用いたアプリ作成をデモで紹介していました。 ブログ作成のデモでは、チャットでAIに指示を出すことでブログを自動で作ってくれるといったものでした。他のブログのフォーマットを参照することもできるので、思い通りのブログをAIに生成させることができますね！ 会話のリアルタイム字幕翻訳のデモでは、複数の言語をリアルタイムで翻訳してくれるといったものでした。また、会議に遅れて入ってきた人のために会議の要約を表示できたり、議事録の作成を自動で行ってくれたりするそうです。議事録作成しなくてもよくなるので、かなり便利ですね！ AppSheetを用いたアプリ作成のデモでは、作りたいアプリについてAIにチャットで指示することで自動でアプリを作成してくれるといったものでした。ノーコードでアプリケーション開発ができるので、誰でもアプリケーション開発ができる時代がついに来たと感じました。 Google Cloud 生成 AI パートナー エコシステムのご紹介 概要 株式会社スリーシェイク様によるAzure OpenAI/Google Cloud/AWSの3社の生成AI比較とh1-slack-botの紹介 内容・感想 Google Cloudの生成AIソリューション支援パートナーである株式会社スリーシェイク様が発表されていました。 Azure OpenAI/Google Cloud/AWSの3社の開発状況とともに3社の生成AIの比較を説明していました。3社の生成AIには以下のような特徴があるそうです。 Azure OpenAI(GPT-4 Turbo、gpt-4-1106-preview) 高コスト、低速レスポンス、高品質レスポンス Google Cloud(PaLM2 API、text-bison) 低コスト、やや高速なレスポンス、シンプルな応答 AWS(Anthropic Claude2) 高コスト、やや高速なレスポンス、高品質レスポンス 用途に合わせて使い分けすると良さそうですね！ 3社の生成AIのLLM（大規模言語モデル）に対応したSlackのbotであるh1-slack-botを紹介していました。botにLLMを切り替えてほしいと入力するだけでLLMを切り替えてくれるそうです。h1-slack-botは現在社内で導入されているそうです。 生成 AI による SQL 作成支援機能と AI 活用文化の醸成 概要 日本特殊陶業株式会社様の生成AIによるSQL作成支援機能の社内導入とAI活用のための社内活動報告 内容・感想 社内データ活用のツールとして、コネクテッドシートが主流とのことでした。理由として、以下の3つが挙げられていました。 表計算ソフトに慣れている BigQueryコンソールが怖い SQLを書いたことがない これらの理由から、スキル教育が重要であると述べていました。しかし、教育だけでは難しいため、生成AIによるSQL作成機能を導入したとのことでした。私がSQLを勉強し始めたとき、このような機能があれば勉強がはかどっただろうなと感じました。 スライドにある通り、AIを活用するための活動を社内で行ったそうなのですが、以下の課題が発生したそうです。 最初から完璧を求める 複数業務掛け持ちによるAI技術者の不足 これらの課題を解決するために、完璧を求めない姿勢の浸透と、システム開発の優先順位付けを行ったそうです。その結果、コミュニティの参加人数は1か月で100人を突破したとのことでした。早い開発速度と意見を反映したシステムがウケたそうです。 Vertex AI を使った社内情報高度検索実現への取り組み 概要 株式会社LIXIL様による社内用生成AI活用システムの導入 内容・感想 生成AIを業務プロセスに組み込むことで業務効率が上がる一方で、重要な情報が流出する危険性があると説明していました。そこで社内用生成AI活用システムである「LIXIL AI Portal」を開発したそうです。また、以下の機能を紹介していました。 AI Tools テキスト生成AIを利用できるツール AI Collections 登録したデータとテキスト生成AIを組み合わせたAIアシスタント作成機能 デモではAI ToolsであるAI Assistant、AI Programmerを紹介していました。 AI Collectionsの課題を解決するために、「LIXIL Search Portal」を開発したとのことです。以下の機能があるそうです。 Helpdesk AI 社内固有の情報を回答するアシスタント Products AI 商品情報を回答するアシスタント デモではProducts AIを紹介していました。Vertex AI Search & Conversationを使っているそうで、一箇所での検索を可能とするために、構造化データをすべて非構造化データに変換するといった工夫をされていました。 見学したブース セッションの合間の隙間時間にブースを見学してきました。ブースにはMAPで色がついているGoogle Cloud Boothと黒色のPartner Boothがありました。私はGoogle Cloud BoothのBooth3とBooth4を見学しました。内容は以下の通りです。 Booth3：次世代のアプリ開発環境を体験「Duet AI + Cloud Workstations」 Booth4：AIとの新たなコラボレーション「Duet AI in Google Cloud Workspace」 Booth3では、コーディングを生成AIが手伝ってくれるというデモを紹介しておりました。Booth4では、セッションの紹介にあったDuet AI for Google Workspaceをより近くで見ることが出来るようになっていました。 感想 2023年12月14日、Google Cloud Generative AI Summit Osakaに参加してみて、Google Cloudの生成AIサービスの最新情報を学ぶことができ、とても勉強になりました。 セッションでは、ハルシネーションの抑制方法についてわかりやすく解説されていたことが印象的でした。生成AIの技術は、様々なクリエイティブコンテンツの生成に活用できる一方で、ハルシネーションのような副作用を引き起こす可能性があるので、ハルシネーションを抑制する方法を知ることは、生成AIを安全に活用するために重要であることを再確認しました。 今回のイベントは、生成AIの最新情報と知識を整理する良い機会となりました。今後も、生成AIの活用に積極的に取り組んでいきたいと思います。 最後まで読んでいただき、ありがとうございました。

こんにちは、広野です。 記事の概要はタイトル通りです。もはやこなれたソリューションだとは思うのですが、AWS CloudFormation とセットで扱っている記事は少ないようだったので上げておこうと思います。先日、本件が入用になって作成したテンプレートを簡略化しました。 やりたいこと Amazon S3 バケットをオリジンとした AWS CloudFront の WEB サイトに、404 などの HTTP エラーステータスが出てしまったときに表示する「カスタムエラーページ」を設定します。 この対応の意義の詳細説明は割愛しますが、ユーザーの混乱を避けたり、悪意のあるユーザーに不必要に情報を与えない効果があります。 本記事でのコンテンツ、カスタムエラーページはかなり簡略化しています。ブログ用のサンプルですので。 コンテンツは index.html のみ カスタムエラーページは error.html のみ ※エラーコードは複数あり、本来はそれごとにもしくは種類ごとにまとめた複数のエラーページを用意します。 アーキテクチャ Amazon CloudFront には Amazon S3 のオリジンを 2つ設定します。1つはコンテンツ配信用、もう1つはカスタムエラーページ用です。アクセス制御設定が特に無ければコンテンツ配信用バケットとカスタムエラーページ用バケットを統合することはできるのですが、コンテンツ配信用バケットに異常があったときのことを考慮すると、別バケットに分けておくことが ベストプラクティス だそうです。 Amazon CloudFront にユーザーがアクセスしたとき、デフォルトではコンテンツ配信用バケットに誘導されます。 サイトへのアクセスでエラーステータスを返したときには、カスタムエラーページ用バケット内、error.html に誘導します。Amazon CloudFront にそのようなルールを書きます。 Amazon S3 バケットは、OAC により Amazon CloudFront からのアクセスしか受け付けないようにしています。 AWS CloudFormation テンプレート 少々長いですが、最後に少し説明を入れています。本記事と関係ない部分の設定は適当に作成しております。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a S3 bucket, a CloudFront distribution with a custom error page. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SystemName: Type: String Description: System name Default: example999 MaxLength: 10 MinLength: 1 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3BucketContents: Type: AWS::S3::Bucket Properties: BucketName: !Sub ${SystemName}-contents PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Ref SystemName S3BucketContentsPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3BucketContents PolicyDocument: Version: "2012-10-17" Statement: - Action: - "s3:GetObject" Effect: Allow Resource: !Sub "arn:aws:s3:::${S3BucketContents}/*" Principal: Service: cloudfront.amazonaws.com Condition: StringEquals: AWS:SourceArn: !Sub arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution} DependsOn: - S3BucketContents - CloudFrontDistribution S3BucketErrorPage: Type: AWS::S3::Bucket Properties: BucketName: !Sub ${SystemName}-errorpage PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Ref SystemName S3BucketPolicyErrorPage: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3BucketErrorPage PolicyDocument: Version: "2012-10-17" Statement: - Action: - "s3:GetObject" Effect: Allow Resource: !Sub "arn:aws:s3:::${S3BucketErrorPage}/*" Principal: Service: cloudfront.amazonaws.com Condition: StringEquals: AWS:SourceArn: !Sub arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution} DependsOn: - S3BucketErrorPage - CloudFrontDistribution S3BucketLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub ${SystemName}-logs OwnershipControls: Rules: - ObjectOwnership: BucketOwnerPreferred PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Ref SystemName # ------------------------------------------------------------# # CloudFront # ------------------------------------------------------------# CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true Comment: !Sub CloudFront distribution for ${SystemName} HttpVersion: http2 IPV6Enabled: true PriceClass: PriceClass_200 Logging: Bucket: !GetAtt S3BucketLogs.DomainName IncludeCookies: false Prefix: cloudfrontAccesslog/ DefaultCacheBehavior: TargetOriginId: !Sub S3Origin-${S3BucketContents} ViewerProtocolPolicy: redirect-to-https AllowedMethods: - GET - HEAD CachedMethods: - GET - HEAD CachePolicyId: !Ref CloudFrontCachePolicy OriginRequestPolicyId: !Ref CloudFrontOriginRequestPolicy Compress: true SmoothStreaming: false CacheBehaviors: - TargetOriginId: !Sub S3Origin-${S3BucketErrorPage} ViewerProtocolPolicy: redirect-to-https AllowedMethods: - GET - HEAD CachedMethods: - GET - HEAD CachePolicyId: !Ref CloudFrontCachePolicy OriginRequestPolicyId: !Ref CloudFrontOriginRequestPolicy Compress: true PathPattern: error.html SmoothStreaming: false Origins: - Id: !Sub S3Origin-${S3BucketContents} DomainName: !Sub ${S3BucketContents}.s3.${AWS::Region}.amazonaws.com S3OriginConfig: OriginAccessIdentity: "" OriginAccessControlId: !GetAtt CloudFrontOriginAccessControl.Id ConnectionAttempts: 3 ConnectionTimeout: 10 - Id: !Sub S3Origin-${S3BucketErrorPage} DomainName: !Sub ${S3BucketErrorPage}.s3.${AWS::Region}.amazonaws.com S3OriginConfig: OriginAccessIdentity: "" OriginAccessControlId: !GetAtt CloudFrontOriginAccessControl.Id ConnectionAttempts: 3 ConnectionTimeout: 10 DefaultRootObject: index.html ViewerCertificate: CloudFrontDefaultCertificate: true CustomErrorResponses: - ErrorCachingMinTTL: 10 ErrorCode: 400 ResponseCode: 400 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 403 ResponseCode: 403 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 404 ResponseCode: 404 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 405 ResponseCode: 405 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 414 ResponseCode: 414 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 416 ResponseCode: 416 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 500 ResponseCode: 500 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 501 ResponseCode: 501 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 502 ResponseCode: 502 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 503 ResponseCode: 503 ResponsePagePath: /error.html - ErrorCachingMinTTL: 10 ErrorCode: 504 ResponseCode: 504 ResponsePagePath: /error.html Tags: - Key: Cost Value: !Ref SystemName DependsOn: - CloudFrontCachePolicy - CloudFrontOriginRequestPolicy - CloudFrontOriginAccessControl - S3BucketContents - S3BucketErrorPage CloudFrontOriginAccessControl: Type: AWS::CloudFront::OriginAccessControl Properties: OriginAccessControlConfig: Description: !Sub CloudFront OAC for ${SystemName} Name: !Sub OriginAccessControl-${SystemName} OriginAccessControlOriginType: s3 SigningBehavior: always SigningProtocol: sigv4 CloudFrontCachePolicy: Type: AWS::CloudFront::CachePolicy Properties: CachePolicyConfig: Name: !Sub CachePolicy-${SystemName} Comment: !Sub CloudFront Cache Policy for ${SystemName} DefaultTTL: 3600 MaxTTL: 86400 MinTTL: 60 ParametersInCacheKeyAndForwardedToOrigin: CookiesConfig: CookieBehavior: none EnableAcceptEncodingBrotli: true EnableAcceptEncodingGzip: true HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin - referer - user-agent QueryStringsConfig: QueryStringBehavior: none CloudFrontOriginRequestPolicy: Type: AWS::CloudFront::OriginRequestPolicy Properties: OriginRequestPolicyConfig: Name: !Sub OriginRequestPolicy-${SystemName} Comment: !Sub CloudFront Origin Request Policy for ${SystemName} CookiesConfig: CookieBehavior: none HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin - referer - user-agent QueryStringsConfig: QueryStringBehavior: none # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: #CloudFront CloudFrontOriginalDomain: Value: !GetAtt CloudFrontDistribution.DomainName Amazon CloudFront に 2つ以上のオリジンを設定するときには、メイン以外のオリジンに対するふるまい (behavior) を CacheBehaviors のところで設定します。ここに、 PathPattern: error.html と書いていますが error.html への通信であればこのオリジンに誘導しなさいよ、という意味のルールになります。ルールにはワイルドカードも使えます。AWS 公式ドキュメントによると先頭にスラッシュを入れても入れなくても動くそうです。本記事の構成ではバケット直下に error.html を保存していますのでディレクトリ構造は書いていませんが、必要に応じて入れましょう。 CustomeErrorResponses: の部分に、エラーステータスコード単位でどのカスタムエラーページを使用するかを定義できます。当然このエラーページ用 html がカスタムエラーページ用バケットに存在し、上述 PathPattern のルールにマッチする必要があります。この記述では、先頭のスラッシュは必須です。 カスタムエラーページを表示させる際に、エラーコードをオーバーライドすることができますが、本記事ではしていません。オリジナルのコードをそのままユーザーに返しています。必要に応じて書き換えましょう。 サンプル HTML サンプルコンテンツ、サンプルカスタムエラーページの HTML も用意しておきます。(ChatGPT 様に作ってもらったものですw) これらは、Amazon S3 のコンテンツ配信用バケット、カスタムエラーページ用バケットのそれぞれ直下に配置します。 index.html <!DOCTYPE html> <html> <head> <title>Welcome to My Website</title> </head> <body> <h1>Welcome!</h1> <p>This is a simple test page for your website.</p> </body> </html> error.html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>Error</title> <style> body { text-align: center; font-family: 'Arial', sans-serif; margin-top: 50px; } h1 { font-size: 48px; color: #333; } p { font-size: 22px; color: #666; } </style> </head> <body> <h1>Custom Error Page</h1> </body> </html> 実際の動作 実際にこのテンプレートでデプロイしたものにアクセスしてみます。テンプレートを流すと、最後「出力」欄に Amazon CloudFront の URL が表示されますので、そこにアクセスします。 通常のコンテンツ (index.html) が表示されましたね。 存在しないページ (ドメイン名 + /xxx/xxx.html) にアクセスしてみます。404 (Not Found) のエラーステータスコードが返ってくるので、カスタムエラーページが表示されましたね。本記事の設定をしていないと、Amazon CloudFront のデフォルトのエラー表示がされることになります。 AWS マネジメントコンソールで Amazon CloudFront のカスタムエラーページ設定もされていることが確認できます。 本記事ではカスタムエラーページをテキストのみの簡易な画面にしましたが、通常は WEB サイトのデザインに統一することが多いと思います。カスタムエラーページ内で画像などにリンクする場合は相対パスが使用できないので注意が必要です。（弊社川原のブログ参照） Amazon CloudFrontのカスタムエラーレスポンスを使用したエラーページ設定 ウェブサイトでエラーが発生した際、カスタムエラーページを表示することでユーザーエクスペリエンスを向上させる方法についてまとめました。 blog.usize-tech.com 2023.12.03 まとめ いかがでしたでしょうか。 簡単な構成でしたが、AWS CloudFormation で Amazon CloudFront のカスタムエラーページを設定できたと思います。 よく使われる構成だと思いますので、本記事が皆様のお役に立てれば幸いです。

こんにちは、広野です。 手持ちの React アプリで aws-amplify と @aws-amplify/ui-react モジュールのバージョン 5 を使用していたのですが、バージョン 6 にアップデートしてみました。アプリ内の設定フォーマットや、組み込みの AWS サービス呼び出し用モジュールに変更があったので結構手直しが入りました。ですがドキュメントから情報を探せば何とかなりました。 公式のドキュメントはこちらです。 Amplify Documentation - AWS Amplify Documentation Amplify documentation - Learn how to use Amplify to develop and deploy cloud-powered mobile and web apps. AWS Amplify Documentation docs.amplify.aws Amplify UI - Build UI fast with Amplify on React Amplify UI simplifies building accessible, performant, and beautiful applications with cloud-connected capabilities, building blocks, theming, and utilities. ui.docs.amplify.aws 変更点 私が経験した限りの変更点です。React アプリから以下の AWS サービスを呼び出していたので、その部分の紹介のみとなることをご了承ください。以降、それぞれの変更箇所にブレークダウンしていきます。 Amazon Cognito Amazon S3 Amazon Kinesis Data Firehose AWS AppSync ※使用しているのですがまだ未検証です、今後追記します。 aws-amplify モジュールの設定は Amplify.configure というコードでアプリ内に記述します。これまで、連携する AWS サービスごとに設定フォーマットがバラバラだったので、それらが統一された感じがします。それに伴ってかわかりませんが、アプリ内で実際にサービスを呼び出すときの命令コードも変更が入っています。大きな仕様変更と言うよりは、書き方を変えただけという感じでした。 (共通) Amplify.configure の設定 App.js に記述していた設定に変更が入っています。特に Amazon Kinesis Data Firehose 用の設定が大きく変わりました。変更前と変更後のコードを記載し、変更箇所に赤線を引いておきます。※パラメータは環境変数 (process.env.***) を使用しています。 変更前 import React from 'react'; import { Amplify, Analytics, AWSKinesisFirehoseProvider } from 'aws-amplify'; //Cognito, S3 連携設定 Amplify.configure({ Auth: { userPoolId: process.env.REACT_APP_USERPOOLID, userPoolWebClientId : process.env.REACT_APP_USERPOOLWEBCLIENTID, identityPoolId: process.env.REACT_APP_IDPOOLID, region: process.env.REACT_APP_REGION }, Storage: { AWSS3 : { bucket: process.env.REACT_APP_AMPLIFYSTORAGE, region: process.env.REACT_APP_REGION } } }); //Amplify Kinesis 連携設定 Analytics.addPluggable(new AWSKinesisFirehoseProvider()); Analytics.configure({ AWSKinesisFirehose: { region: process.env.REACT_APP_REGION, bufferSize: 1000, flushSize: 100, flushInterval: 5000, // 5s resendLimit: 5 } }); 変更後 import React from 'react'; import { Amplify } from 'aws-amplify'; //Cognito, S3, Kinesis 連携設定 Amplify.configure({ Auth: { Cognito: { userPoolId: process.env.REACT_APP_USERPOOLID, userPoolClientId : process.env.REACT_APP_USERPOOLWEBCLIENTID, identityPoolId: process.env.REACT_APP_IDPOOLID } }, Storage: { S3 : { bucket: process.env.REACT_APP_AMPLIFYSTORAGE, region: process.env.REACT_APP_REGION } }, Analytics: { KinesisFirehose: { region: process.env.REACT_APP_REGION, bufferSize: 1000, flushSize: 100, flushInterval: 5000, // 5s resendLimit: 5 } } }); Amazon Cognito @amplify-ui/react と Amazon Cognito を連携させるコードは、かなり変わりました。必要な情報が公式ドキュメント内に分散されて書かれていたので、繋ぎ合わせるのに苦労しました。 私の場合は useAuthenticator を使用しているので、その記述の限りになりますこと、ご了承ください。useAuthenticator で Amazon Cognito の認証を経て、ユーザーの情報やトークンを取得する仕様が変わりました。 変更前 import React from 'react'; import { useAuthenticator } from '@aws-amplify/ui-react'; const { user, signOut } = useAuthenticator((context) => [context.user]); この記述だけで、以下の情報が取れました。user の中に全て格納されていました。 ユーザー名（メールアドレス） 所属 Cognito グループ → アプリ内権限分けで使用 ID トークン (Base64 エンコード) → API Gateway の Cognito オーソライザーで使用 Amplify UI v2 が出たので v1 からアップグレードしてみた　[ AWS Amplify + Amazon Cognito + React ] AWS Amplify UI v2 による、Reactアプリのサインイン画面実装例を紹介します。実際にアップグレードした際のコード例や気付きがありますので是非ご覧下さい。 blog.usize-tech.com 2022.03.22 変更後 import React, { useState, useEffect } from 'react'; import { useAuthenticator } from '@aws-amplify/ui-react'; const { user, signOut } = useAuthenticator((context) => [context.user]); //ステート定義 const [username, setUsername] = useState(); const [authToken, setAuthToken] = useState(); const [groups, setGroups] = useState(); //セッション情報取得 const getSession = async () => { const { tokens } = await fetchAuthSession(); setUsername(tokens?.idToken?.payload.email); setGroups(tokens?.idToken?.payload["cognito:groups"]); setAuthToken(tokens?.idToken?.toString()); }; useEffect(() => { getSession(); }, []); 変更前の記述だけでは欲しいユーザー情報またはセッション情報が取得できないため、赤線部分を追記しています。平たく言うと user の中にユーザーの所属グループや ID トークンは入らなくなりました。そのため、 fetchAuthSession というモジュールを新たに追加しています。※他の取得方法もありますので一例です。 ユーザー名: tokens?.idToken?.payload.email ※メールアドレスをユーザー名にしているため。ユーザー名は user からも取れる。 所属 Cognito グループ: tokens?.idToken?.payload[“cognito:groups”] ID トークン: tokens?.idToken?.toString() Amazon S3 Amazon S3 バケットに JSON データを送信し、ファイルとしてアップロードしておりました。当時の記事は以下です。これに対して書き方の変更が入りました。動作仕様は変わっていないように見えます。 AWS Amplify Storage を AWS CloudFormation でマニュアルセットアップする サーバーレス WEB アプリ (SPA) から、ファイルをバックエンドにアップロードして処理したいことがあります。AWS Amplify と連携させた Amazon S3 バケット「AWS Amplify Storage」を使用すると、アプリとセキュアに連動したストレージを簡単に作ることができます。 blog.usize-tech.com 2022.05.31 変更前 import { Storage } from 'aws-amplify'; //AmplifyStorageにJSONデータを転送 const putFile = async () => { try { await Storage.put( "data.json", //S3に送信したデータファイルに付けるオブジェクト名 jsonData, //S3に送信したいJSONオブジェクトのデータ { level: "private", //private権限のフォルダに格納する progressCallback(progress) { setProgress(progress.loaded/progress.total); } } ); } catch (error) { alert("File uploading error occurred: " + error); } }; 変更後 import { uploadData } from ' aws-amplify/storage '; //AmplifyStorageにJSONデータを転送 const putFile = async () => { try { const result = await uploadData ({ key: "data.json", data: JSON.stringify(jsonData) , //Blobまたはstring等でないと送れなくなった options: { accessLevel : "private", onProgress: ({ transferredBytes, totalBytes }) => { if (totalBytes) { setProgress(transferredBytes / totalBytes); } } } }).result; } catch (error) { alert("File uploading error occurred: " + error); } }; Amazon Kinesis Data Firehose Amazon Kinesis Data Firehose の場合は、軽微な変更になります。以下変更前、変更後の記述方法の違いを見て頂ければと思います。data は送信する JSON データだと思って下さい。 変更前 import { Analytics } from 'aws-amplify'; Analytics.record({ data: JSON.stringify(data), streamName: process.env.REACT_APP_FIREHOSE_STREAMNAME_ACTIVITYLOG }, "AWSKinesisFirehose"); Amplify + Cognito + React アプリから Kinesis Data Firehose にログをストリームする AWS Amplify + Amazon Cognito + React の WEBアプリで、Amazon Kinesis Data Firehose にログをストリームする方法を紹介します。 blog.usize-tech.com 2022.03.22 変更後 import { record } from ' aws-amplify/analytics/kinesis-firehose '; record({ data: JSON.stringify(data), streamName: process.env.REACT_APP_FIREHOSE_STREAMNAME_ACTIVITYLOG }); まとめ いかがでしたでしょうか。 公式ドキュメントを見ながら四苦八苦して動く状態にできたので、本記事が皆様の参考になれれば幸いです。

  本記事は TechHarmony Advent Calendar 12/19付の記事です。 こんにちは、SCSK株式会社の中野です。 大変お待たせいたしました。AWS をZabbixで監視してみたシリーズ（第2弾）です。 ※第1弾の記事は「 AWSをZabbixで監視してみた 」の投稿でご確認いただけます。 前回は「AWS EC2 by HTTP」テンプレートを用いてEC2の監視を試してみましたが、 今回はRDSの監視をZabbixで試してみたいと思います。 Zabbixとは ※初めてご覧になられる方向けに繰り返し記述させていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution www.zabbix.com Zabbixには、AWSの各種サービスを監視するための設定をまとめた４つのテンプレートが用意されています。 ・AWS by HTTP（以下3つのテンプレートが自動で設定される） ・AWS EC2 by HTTP（EC2とAWS EBSボリュームのメトリクス監視） ・AWS RDS instance by HTTP（RDSのメトリクスを監視） ・AWS S3 bucket by HTTP（S3バケットのメトリクスを監視） ※ AWSテンプレートを利用するためには、Zabbix 6.0.13 LTS、または Zabbix 6.2 以上のバージョンが必要です。 今回は「 AWS RDS instance by HTTP 」テンプレートを利用してAWSのサービス（RDS）を監視していきたいと思います。 監視してみた（事前準備編） ZabbixでRDSを監視するために、EC2と同様にAWS側で以下の対応が必要になります。 ・AWS IAMの設定 １、監視用のAWSアカウント作成 ２、IAMポリシー作成 ３、アカウントのアクセスキー発行 IAMポリシーは、ZabbixがAWSへアクセスすることができるよう以下のように作成し、アカウントに適用させます。 { "Version": "2012-10-17", "Statement": [ 　　{ 　　　　　　"Action": [ 　　　　　　　　"cloudwatch:Describe*", 　　　　　　　　"cloudwatch:Get*", 　　　　　　　　"cloudwatch:List*", 　　　　　　　　"rds:Describe*" 　　　　　　], 　　　　　　"Effect": "Allow", 　　　　　　"Resource": "*" 　　　　} 　　] } 今回はRDSとCloudwatchのみですが、EC2やS3の監視も実施したい場合は、同様に必要な権限を”Action”に追加します。 ec2:Describe* s3:ListAllMyBuckets s3:GetBucketLocation AWS側の事前準備は以上です。 監視してみた（設定編） それではZabbixで監視するために、対象のRDSインスタンスをZabbixへホスト登録していきます。 Zabbix登録画面では、ホスト名やＩＰアドレスを設定して、テンプレートは「AWS RDS instance by HTTP」を選択します。 ホストマクロに、事前準備で発行したアカウントのアクセスキーとシークレットアクセスキーを設定します。 また、監視対象(RDS)のインスタンスIDとリージョンコードも設定する必要があります。 あとは「追加」または「更新」ボタンを押すだけで、Zabbixでの監視が開始されます。 データ取得まで数分待つと、以下の通りCPUやディスク等の監視アイテムを取得することができました。 最後に RDSをZabbixで監視してみた結果、EC２同様に簡単に監視データを取得することができることが分かりました。 今回も基本的な内容を試してみましたが、今後はもっと深掘りし情報を発信していきたいと思います。 最後まで読んでいただき、ありがとうございました！

こんにちは。 SCSK の和田です。 本日は、SCSKのプライベートクラウド「 USiZEシェアードモデル 」（ユーサイズシェアードモデル）についてご紹介します。 「USiZEシェアードモデル」の紹介サイトは以下になります。 運用付きの国産クラウドサービス│SCSK株式会社 VMwareベースで構築された、高可用性、高機密を備えた国産のプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp USiZEシェアードモデルとは？ USiZEシェアードモデルとは、SCSKの運営する「 運用付きの国産クラウドサービス 」です。（以下、USiZEと記載） SCSKの国内データセンターにVMWareベースで構築された、高可用性・ 高機密性 を備えたプライベートクラウドであり、マネージドサービスによる運用工数削減に加え、 セルフ運用機能 による利便性にも優れています。 クラウド市場動向の変化 インフラコストの最適化やグローバルインフラの持つ豊富なサービス・柔軟性への期待から、「Amazon Web Services」（AWS）や「Microsoft Azure」「Google Cloud」といったパブリッククラウドの普及が広がりを見せています。 そしてそのようなトレンドの中、パブリッククラウドオンリーではなく、 オンプレミス やプライベートクラウドのそれぞれの強みや特性を活かし、最適なクラウドの使い分け（マルチ/ハイブリッドクラウド）にて いいとこ取りをしたい という 新たなニーズ が生まれつつあります。 また、パブリッククラウドの普及期を経て、 パブリッククラウドへの移行や利用に関する課題 も見えてきました。 クラウドのメリットを享受しつつ、パブリッククラウドに対する 不安・課題の解消 に向けて下記のようなポイントが挙げられます。 新たなニーズやパブリッククラウドへの不安・課題に対して、どのように解決するか？が クラウドを定着させる 上で重要となります。 これらの ポイントを押さえつつ、いいとこ取りができるサービス 、それが「 USiZE 」なのです！   USiZE活用により、実現できること ハイブリッドクラウド戦略のサポート オンプレミスやプライベートクラウド・パブリッククラウド等、異なる複数のクラウド環境を組み合わせていいとこ取りするには、セキュリティや通信品質の不安なく、シームレスに相互接続可能なハイブリッドクラウド環境を構築する必要があります。 SCSKが提供するネットワークサービス「SCNX」（SCSK Cloud netXchange）を活用することで、USiZEとパブリッククラウド間を セキュア・低遅延・高コストパフォーマンスに接続 することが可能です。 サービス基盤は強固な国内データセンター USiZEは、 千葉県印西市、兵庫県三田市 のSCSKのデータセンター（netXDC）内で稼働しています。 netXDCは、各種ISO取得、FISC、日本DC協会が策定するファシリティスタンダードの最高レベル「ティア4」に適合し、 長年培ったノウハウをもとに万全なセキュリティ環境 を提供します。 また、ウィルス感染や不正侵入など外部からの脅威に対し、複数のセキュリティサービスもご用意しており、セキュリティリスクと守るべきデータに応じ、必要な対策の選択も可能です。 全面支援を受けつつ塩漬けシステムもクラウド化 クラウドメリットを最大限活かすために、業務特性やお客様の抱える課題解消を十分考慮した戦略とスムーズな移行に向けたアセスメントを通じ、 最適な設計構築および安心安全なクラウド移行のサポート を提供します。 特にパブリッククラウド移行の課題として声が上がることの多い、 サポート切れ OS やIPアドレス・構成の変更が難しいシステムでも、 現状環境を可能な限り維持したまま、クラウドのメリットを享受 することができます。 目的に応じたサービス利用でコスト最適化へ USiZEは、物理サーバリソースを共有し切り出して利用する「共有型」と、物理サーバを個別のお客様にて専有する「専有型」の2種類を提供しています。例えば、スペックをカスタマイズしてリソース最適化したい場合には共有型を、商用ライセンス費用の適正化をしたい場合には専有型をご利用していただくことで、 コスト最適化 を実現 します。 さらに、月額の料金体系が多いサービスラインナップであり、データダウンロードや外部サービス連携に追加通信費用がかからないため、 予算の上限管理や費用の見通しが立てやすい上、為替変動のリスクなく活用 することが可能です。 まとめ パブリッククラウドだけではなく、オンプレミスやプライベートクラウドのそれぞれの強みや特性を活かし「いいとこ取り」する時代へ お客様にとって最適な環境とするための課題やニーズのサポートへ「USiZE」が少しでも貢献できればと考えております。 是非以下URLをご参照ください。 運用付きの国産クラウドサービス│SCSK株式会社 VMwareベースで構築された、高可用性、高機密を備えた国産のプライベートクラウドです。ファシリティスタンダード最高レベルのティア4に適合する日本国内のデータセンター上で稼働し、お客様データの保護とデータ主権を確保します。 www.scsk.jp

こんにちは、広野です。 いつの間にか Node.js 16 が EoL になってしまい、最新のサポートバージョンは 20 になっていました。AWS Amplify のビルド環境がどう追随しているかというと、今時点 18 が最新のようです。 Fix support for node 18 · Issue #3109 · aws-amplify/amplify-hosting Before opening, please confirm: I have checked to see if my question is addressed in the FAQ. I have searched for duplicate or closed issues. I have read the gu... github.com とは言え AWS Cloud9 (Amazon Linux 2023) にはデフォルトで Node.js 20 がインストールされていました。ですのでわざわざ EoL が見えている 18 を使用したくありません。今回、AWS Amplify でも試しにやってみたら Node.js 20 でビルドできたので、そのやり方を紹介します。公式ドキュメントもいずれ更新されると思います。 試したこと Amazon Linux 2023 の AWS Cloud9 には Node.js 20 が入っていたので、そのままにします。 AWS マネジメントコンソールで AWS Amplify の画面を開いたら、以下のように「ビルドの設定」の中に「Build image settings」という項目が追加されていました。 これを、以下のようにビルド環境に Amazon Linux 2023 を、インストールするパッケージとして Node.js 20 を使用するように変更したところ、ビルドが通るようになりました。デフォルト設定のままでは、ビルドは失敗しました。 ビルドログを見ると、以下のように Node.js 20 を使用した形跡が残っていました。 2023-12-17T04:11:53.451Z [INFO]: # Node version 20 is available for installation 2023-12-17T04:11:53.557Z [INFO]: # Installing Node version 20 2023-12-17T04:13:38.677Z [INFO]: # Now using Node version 20 私は AWS Amplify を AWS CloudFormation でデプロイしているのですが、執筆時点ではこの設定をデプロイするためのテンプレート記述方法は見つけられませんでした。そのため、とりあえずマネジメントコンソールから手作業で変更しています。いずれ AWS CloudFormation でサポートされたらテンプレートに反映しようと思います。 厳格にバージョン指定しようと思ったら、buildspec.yml 内で希望するバージョンの Node.js をインストールする方法が必要であることを付け加えておきます。 まとめ いかがでしたでしょうか。 簡単な内容でしたが、なにげに今時点では有用と思いまして紹介いたしました。 本記事が皆様のお役に立てれば幸いです。

本記事は TechHarmony Advent Calendar 12/18付の記事です。 「TechHarmony Advent Calendar 2023」18日目担当の ひるたんぬ こと蛭田です。 もういくつねると クリスマス、ですね。Advent Calendar 2023も残りわずかとなってきました。 私は18年間過ごしてきた学生という身分を脱し、今年度よりSCSKで働いております。 まだまだ未熟者ではありますが、よろしくお願いします。 私の所属している部署では、配属された新人がおよそ3ヶ月でAWSを活用したサービスを構築するという伝統のようなものがあり、私も例にもれず取り組んでおります。今回はこの取り組みの中で、タイトルにもありますように「 開発（コーディング）環境の構築 – Cloud9の利用 」についてご紹介していきたいと思います。取り組み内容につきましては、改めて記事にする予定です。 AWS Cloud9 概要 そもそも「AWS Cloud9」とは何なのでしょうか。AWSでは、以下のように説明されています。 AWS Cloud9 は、ブラウザのみでコードを記述、実行、デバッグできるクラウドベースの統合開発環境 (IDE) です。 これにより、 ローカル環境へのIDEセットアップが不要 インターネットに接続された端末であれば、どこからでもプログラミングが可能 複数人での同時編集（ペアプログラミング）が可能 などといったメリットを享受することができます。また、AWSのサービスということもあり、他のAWSサービスとの親和性も高いということが特徴です。 AWS Cloud9（Cloud IDE でコードを記述、実行、デバッグ）| AWS AWS Cloud9 は、ブラウザのみでコードを記述、実行、デバッグできるクラウドベースの統合開発環境 (IDE) です。 aws.amazon.com これについて、ChatGPTにも聞いてみました。この名前を聞かない日は無いと言っても過言では無いくらい有名になりましたね… 余談ですが、ChatGPTを含む生成AIは「ハルシネーション」、分かりやすく言い換えると「嘘をつく」可能性があります。 今回のChatGPTの回答につきましては、私が内容の正確性を確認済みです。 実際はどうなの？ あくまで私感ですが、「あと少し…」というような印象です。 確かに上述したメリットはあり、Cloud9の環境構築（名前を決めて、ボタンを数回ポチポチする）だけですぐにコーディングが始められる点はとても気軽でした。しかし、いざコーディングを始めてみると コーディングミスの場所が分かりづらい 何行目が間違えているかはすぐに分かりますが、どこが間違えているかまでは示してくれません。一方、Visual Studio Code (VS Code)では、誤っている位置に下線を引いてくれます。 痒いところに手が届かない スペルミスがあるもののコーディング自体にミスがない場合、Cloud9では警告もなく先に進みます。もちろん動作自体には何も影響はありませんが、気を利かせてくれることに越したことはありません。 見た目のカスタマイズが柔軟にはできない エディタの色の変更やフォントの変更、フォントサイズの変更など基本的なカスタマイズは一通りは行うことができますが、自分の好きなフォントの設定はできないようです¹。 などと、細かいことなのですが気になってしまうことがありました。 「細かいことが気になるのが、僕の悪い癖。」ですね…（ ネタ元 ） 繰り返しますが、気軽に環境が構築できるため、「ちょっとだけ開発してみよう」「新しい言語に触ってみようかな」などと言った、比較的ライトな目的で使用するのはとても良いと思います。 ですが、「 快適に コーディングをしたい」という欲望を満たすために、少しばかり作業をします。 ¹ フォントのカスタマイズについて、プログラミング向けの等幅フォントで有名な”FiraCode”の設定方法がGitHubにて紹介されています。この方法では、Cloud9のテーマをCSSファイルの作成を通してカスタマイズしています。 Cloud9 Instructions Free monospaced font with programming ligatures. Contribute to tonsky/FiraCode development by creating an account on GitHub. github.com ですが、AWSのドキュメントには以下のように説明がありました。 Support for theme overrides has been discontinued. The contents of this styles.css file will no longer be applied on loading the AWS Cloud9 IDE. これによると、CSSファイルを用いたテーマの上書き（カスタマイズ）の対応は行われなくなったようなので、好きなフォントの設定は実質不可能になったと思われます。 Working with themes in the AWS Cloud9 Integrated Development Environment (IDE) - AWS Cloud9 Describes how to work with themes in the AWS Cloud9 IDE. docs.aws.amazon.com VS Code × Cloud9 前置きが長くなってしまいましたが、ここから本題です。 私は学生時代からVS Codeを使っており、操作感もある程度慣れていたので、「VS Codeの使い勝手の良さと、Cloud9の他リソースとの親和性の高さを両立させたい…」と思いました。 そこで、VS CodeからCloud9に接続してコーディングできる方法がないかを調査し、実際にやってみましたのでご紹介いたします。 最終的には以下に示す環境を構築します。 この環境を構築する際、またこの記事を執筆するにあたっては以下の記事を参考にさせていただきました。 Systems Manager を使用したインターネットアクセスなしでのプライベート EC2 インスタンスの管理 現在、インターネットにアクセスできない Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用しています。AWS Systems Manager を使用してインスタンスを管理する方法を教えてください。 repost.aws Field Notes: Use AWS Cloud9 to Power Your Visual Studio Code IDE | Amazon Web Services Everyone has their favorite integrated development environment, or IDE, as it’s more commonly known. For many of us, it’s a tool that we rely on for our day-to-... aws.amazon.com AWS Cloud9とVS Code Remote SSHを組み合わせて使ってみた | DevelopersIO しばたです。 以前.NETの開発環境を用意するためにAWS Cloud9を試してみた記事とVS Code Remote SSHを使った開発環境構築の記事を書きました。 環境構築はAWS Cloud9が容易で.NETの開発 … dev.classmethod.jp 今回はできる限りセキュアな環境で開発業務を行いたいという目標から、プライベートサブネットへCloud9を配置しております。単純に「VS CodeからCloud9に接続がしたい！」という場合は、パブリックサブネットに配置いただいても問題はありません。 クライアント側のソフトウェアの準備 Cloud9環境へ接続するにあたり、クライアント側の端末では以下のソフトウェアやプラグインが必要になります。 Visual Studio Code → 今回の主役の一人 OpenSSH Client（多くの環境で組み込み済み） → SSH認証や、キーペアの生成に利用 AWS CLI → AWS関連のリソースを操作するために必要 Session Manager plugin → Session Managerを用いて接続するために必要 VPC・プライベートサブネットの作成 Cloud9を配置するためのVPC・サブネットを作成します。この作業では、名前やIPv4 CIDRを任意に決めます。作成後にVPCのDNS設定を参照し、「 DNS解決を有効化 」と「 DNSホスト名を有効化 」にチェックが入っていることを確認してください。 セキュリティグループの作成 後段のVPCエンドポイントで利用するセキュリティグループを作成します。 セキュリティグループ作成画面より、セキュリティグループ名・説明を入力し、先程作成したVPCを選択します。 インバウンドルールでは、HTTPSを選択し、ソースは先程作成したプライベートサブネットのIPv4 subnet CIDRを入力します。アウトバウンドルールは設定しません。 以上の設定を終えたら、セキュリティグループの作成を実行します。 VPCエンドポイントの作成 Systems ManagerのセッションマネージャーとCloud9間が疎通するようにVPCエンドポイントを作成します。エンドポイントの作成画面より、任意で名前を設定し、下部のサービス欄でサービスを一つ選択します（一度に一つしか選択することができません）。今回は、 com.amazonaws.[リージョンコード].ssm com.amazonaws.[リージョンコード].ec2messages com.amazonaws.[リージョンコード].ssmmessages com.amazonaws.[リージョンコード].s3 の4つを作成する必要があるので、以下の作業を繰り返して作成してください。 最後の「com.amazonaws.[リージョンコード].s3」のタイプは、 Gatewayを選択 してください。 サービスを一つ選択したら、先程作成したVPC・プライベートサブネットが配置されているAZ・プライベートサブネットのサブネットIDを選択します。 最後に一つ前で作成したセキュリティグループを選択し、エンドポイントの作成を実行します。 Cloud9環境の作成 次にVS Codeからの接続先であるCloud9の環境を作成します。 コンソール画面より環境を作成してください。 EC2インスタンスタイプ 最初に作成する際は、無料利用枠の対象でもある「t2.micro」を選択しても問題ありません。 ですが、私は後述する問題から 最終的には「t3.small」にて開発をしています 。 インスタンスタイプは後からでも変更が可能ですので、お好きなものを選択してください。 ネットワーク設定 Cloud9へのアクセス方法は既定で選択されている「AWS Systems Manager (SSM)」のままにしてください。VPC設定では、先程作成したVPCとプライベートサブネットを選択してください。 接続の確認 作成の処理が完了すると、Cloud9への接続が可能になります。 作成したCloud9が正常に接続できるか確認しましょう。 正常に接続ができると、IDEの画面が表示されます。 設定に誤りがある場合は以下のような画面になります。今までの手順を振り返り、間違いがないか確認しましょう。 ＠ Cloud9 コンソール画面 作成中が数十分待っても変わらず、それでも待ち続けるとエラー画面が表示される。 ＠ Cloud9 IDE画面 接続中のまま画面が変わらず、しばらくすると性能不足や設定ミスが原因で接続に時間がかかっているというメッセージが表示される。 SSH鍵の作成 自身のローカル環境からCloud9環境へ接続するために必要なSSH鍵を作成します。 まずは、自身のホームディレクトリ（C:\Users\[ユーザ名]）に「.ssh」フォルダがあるかどうか確認します。存在しない場合は作成してください。 次に接続元のPCのターミナル（PowerShellなど）を起動し、下記コマンドを実行します。 > ssh-keygen すると以下のような画面になるので、保存先と鍵に設定するパスワードを入力します。 鍵の保存先は既定（.ssh内）で良いですが、名前は適宜変更しても問題ありません。 パスワードは未入力でEnterキーを押すことで省略することも可能です。 Generating public/private rsa key pair. Enter file in which to save the key (C:\Users\[UserName]/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\[UserName]/.ssh/id_rsa Your public key has been saved in C:\Users\[UserName]/.ssh/id_rsa.pub The key fingerprint is: SHA256:xxxxxx…xxxxxxxxxx XXXXXX@[PC Name] The key’s randomart image is: +—[RSA 3072]—-+ +—-[SHA256]—–+ 作成が完了したら、.sshフォルダ内に id_rsa id_rsa.pub の2つがあることを確認してください。 ファイル名を自身で指定した場合は、「id_rsa」の部分が指定した名前になっています。 SSH鍵の登録 Cloud9 IDEを操作し、作成したSSHの公開鍵をCloud9へ登録します。 まず、IDE左側にあるフォルダツリーの右上の歯車をクリックし、「Show Home in Favorites」をクリックし、ホームディレクトリをフォルダツリー上に表示させます。 ここから「~/.ssh/authorized_keys」を開き、一番下に公開鍵の値を貼り付けて保存します。 シャットダウンスクリプトの更新 Cloud9のシャットダウンスクリプトを更新し、VS Codeからの接続を確認するようにします。これにより、Cloud9が稼働しているEC2の予期せぬシャットダウンを防ぐことができます。 こちらは参考サイトとしてもご紹介した、AWS Architecture Blogにも掲載されています。 しかし、こちらで紹介されている方法ですと、インターネットからファイルを入手する必要がありますが、今回の環境では、インターネットからファイルを入手することができません。そのため、少々非効率ですが、回り道をして対処します。 まずはCloud9 IDE内の下部にあるbashに、以下のコマンドを入力します。 $ sudo mv ~/.c9/stop-if-inactive.sh ~/.c9/stop-if-inactive.sh-SAVE $ touch ~/.c9/stop-if-inactive.sh そして、左側のフォルダツリーより、「 ~/.c9/stop-if-inactive.sh 」を開きます。中身は空のファイルになっているので、 スクリプトファイル の内容をすべてコピーし、貼り付けて保存します。 その後bashに、以下のコマンドを入力します。 $ sudo chown root:root ~/.c9/stop-if-inactive.sh $ sudo chmod 755 ~/.c9/stop-if-inactive.sh これにより、インターネットからファイルを入手することなく、スクリプトファイルを更新することができました。 パブリックサブネットに配置した場合などCloud9がインターネットと直接通信できる環境の場合は、curlコマンドなどを用いてインターネットからファイルを直接入手することができるので、このような回り道は不要です。 SSH接続の準備 クライアント側の端末からCloud9環境への接続を行うために必要な認証情報などの登録を行います。ここからはクライアント側の端末を操作します。 まずは、プロファイルを作成し登録します。 これにはアクセスキーが必要となるので、コンソール画面（IAM – ユーザー）より作成します。アクセスキーの作成画面では、ユースケースに「コマンドラインインターフェイス（CLI）」を選択し、確認事項を読んだ上でチェックを入れます。 その次の説明タグでは、自身がわかるような説明を入力し、アクセスキーを作成します。 作成が完了すると、アクセスキーを確認することができます。アクセスキー・シークレットアクセスキーどちらも使用するので、ここで控えておいてください。 続いて、以下のコマンドをターミナルで実行します。[ProfileName]には、任意の名前を入力してください。 > aws configure --profile [ProfileName] すると、以下のような画面になるので、先程作成したアクセスキーなどを入力します。 AWS Access Key ID [None]:AKXXXXXXXXXXXXXX AWS Secret Access Key [None]:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Default region name [None]:[リージョンコード] Default output format [None]:json そして、ホームディレクトリ内の.ssh内にconfigファイルを作成します（ファイル名：config）。 ファイルの内容は以下のようにします。インスタンスIDや秘密鍵のある場所のパス、[ProfileName]は適宜変更してください。 # SSH to remote Cloud9 EC2 instance host ssh-to-cloud9     HostName “Cloud9(EC2)のインスタンスID”     Port 22     User ec2-user     IdentityFile “秘密鍵のパス(例…C:\Users\[UserName]\.ssh\id_rsa)”     ProxyCommand C:\Program Files\Amazon\AWSCLIV2\aws.exe ssm start-session –target %h –document-name AWS-StartSSHSession –parameters “portNumber=%p” –profile [ProfileName] ここまで設定が完了したら、接続ができるか確認します。 ターミナルより、以下のコマンドを実行してください。 > ssh ssh-to-cloud9 すると接続をしてよいか尋ねられるので、「yes」と入力します。以下のように接続ができたら成功です！ VS Codeの設定 最後の手順です。VS Codeを起動し、拡張機能「Remote – SSH」を検索してインストールします。 VS Codeから接続 ここまでお疲れ様でした。Cloud9へ接続しましょう。 左下の「 」をクリックし、「ホストに接続する」をクリックします。 上部に先程configファイルに登録した接続情報が出てくるのでそれをクリックします。 SSH鍵を生成した際にパスワードを設定した方は、このタイミングでパスワードの入力を求められるので、パスワードを入力します。 クリック後、別ウィンドウが表示され接続準備が始まります。OSの選択画面が出てくるので、「Linux」を選択します。 改めて接続準備が始まります。少し時間がかかりますので気長に待ちましょう。 左下のステータスが「SSH: ssh-to-cloud9」に切り替われば接続完了です！！ 困ったこと これで快適にコーディングができる！ …と手放しには喜べなかったので、私が実際に遭遇した問題について、解決したものは解決策も含めてご紹介いたします。 【解決済】言語が英語になってしまう こちらについては、SSH環境には拡張機能がインストールされていないことが原因です。SSH接続後に日本語パックの拡張機能をインストールすることで解消されます。他にも必要な拡張機能がある場合は併せてインストールしましょう。 Pythonの拡張機能をインストールすることで、PythonプログラムもCloud9上で無事に動きました。Hello World!! 【解決済】定期的に応答がなくなる コーディングをしていると、ある程度時間が経ったときにファイルの保存やコードの実行ができなくなるという症状が発生しました。これについて調べてみたところ、VS Codeの接続による負荷に耐えられていない可能性があるということを述べられている方がいらっしゃいました。 こちらのサイトを参考にさせていただきましたが、これでも症状は改善せず。 先輩に相談をしたところ、そもそものスペックが足りないのではないか、とアドバイスをいただきました。確かに…と思い「t3.small」に変更したところ、今までの苦労が嘘のように快適に開発に取り組めるようになりました！ 【未解決】コードの実行に失敗する場合がある 応答がなくなる問題よりは頻度は低いのですが、コードの実行時に An error occurred (ExpiredTokenException) when calling the XXXXXX operation: The security token included in the request is expired というエラーが出ることがあります。こちらに関しては、出る原因が現時点ではまだ分かっておりません。暫定的な対処法として、現在は コードの再実行 Cloud9 IDEへブラウザから再接続 を行うことで対処しています。 おわりに 今回は「快適に開発をしたい…！」という一心で、AWSのリソースのメリットとVS Codeを利用するメリット、どちらも享受する方法の一つをご紹介いたしました。プライベートサブネット上にあるリソースにインターネットを通じて接続ができたときは、驚きと感動と戸惑いと…様々な感情が一度に押し寄せてきました。 元々用意されている便利なサービスを、より自分好みに利用できる点は素晴らしいですね！ ツールの使い勝手が良くなると、仕事のモチベーションも高めてくれます。 最後までご覧いただき、ありがとうございました！

本記事は TechHarmony Advent Calendar 12/17付の記事です。 はじめに 私は主にインフラ・運用領域でのソフトウェアエンジニアであり、最近は通信や仮想ネットワーク周りを主戦場としています。 先日、弊社の Cato クラウド担当が次のブログ記事を書いていました。 レガシーインフラエンジニアから見た「Catoってどうなの?」 レガシーなネットワークインフラと、SASEであるCatoクラウドの違い、良い点・イマイチな点を率直にお話します。 blog.usize-tech.com 2023.11.13 この記事にインスパイアされ、私も Cato クラウドに関して思うところを書いてみたいと思います。特に、Cato クラウドのようなサービスを真似して開発・提供することを想像し、そのような視点で書いてみます。 Cato クラウドのすごいところ Socket の存在 Cato クラウドでは Socket がアプライアンス機器として提供される点が最も良いところだと思っています。 Cato クラウドの立場になって SASE を提供することを考えると、利用者にルータを用意してもらって IPsec か何かでインターネット VPN を張ってもらうのが最も楽ですし、拠点側に何か置くとしても機器ではなく仮想マシンイメージのような形でアプライアンスを提供するのがソフトウェア屋としては楽です。どちらにせよ利用者任せにしてしまいがちなところですが、専用機器というソフトウェア以外の部分も提供して利用者の手間を減らしている点は簡単には真似できないなぁと感じています。 また、Socket の管理画面でインターネット接続の設定は設置拠点ごとに必要となるものの、VPN 接続やそれ以降の設定は集中的な管理画面 (CMA) で行えるという点も良いです。特に、VPN 接続を張る際のクレデンシャル (パスワードやクライアント証明書など) を利用者に入力させることなく、いったん Cato クラウドのサンドボックス的な場所に接続させることで集中管理できるようにするという発想は良いアイデアで、機会があれば真似したい部分です。 イベントのダッシュボード機能が良い Cato クラウドの管理画面 (CMA) で各種イベントログを1つのダッシュボードで自由に検索して見られる点も良いですね。 イベントの発生源としては、Cato クラウド内部の各種機能だけでなく、Socket や Cato Client など様々なものがあります。これら様々なイベントを構造化データとして1つのドキュメントDBに放り込み、さらに検索もしやすくするというのは実装上けっこう面倒で手間がかかる部分なのに、それが上手く作られているなぁと感心しています。 また、イベント量は10億レコード以上あってかなり多いにもかかわらず、検索機能は意外と早く結果を返してきますので、インデックスや検索の実行計画が上手くチューニングされている印象です。時間フィールドだけでなく検索キーとして頻繁に利用されるフィールドもインデックスが張られているのでしょうけど、これは地道な改善の積み重ねが必要な部分です。 Web UI も全体的に良い イベントのダッシュボードに限らず、管理画面 (CMA) の Web UI も全体的に良く作られている印象があります。 Cato クラウドは機能が多いため必然的に1つの画面の情報量も多いですが、そのぶんシンプルかつ機能性重視の画面となっており、エンタープライズ的にも利用しやすいように感じています。また、ブラウザの開発者ツールで眺めてみると、フロントエンドは React、バックエンドは GraphQL で作られているようです。こういったレイヤのアプリケーション開発は私は敬遠しがちですので、しっかりと作られているものを見ると敬意を払いたくなります。 ただ、Web UI では非同期リクエストが多用されているために、ページを開いてから遅れて描画されるという部分は正直好きではないです…。モニタリング画面はまだ良いのですが、ネットワークやセキュリティの設定画面は素早く描画されるほうが嬉しいですね。 Socket で DPDK が利用されている Socket の Web UI を見ていると、その内部では DPDK が利用されている形跡が見つかります。 DPDK とは “Data Plane Development Kit” の略で、ネットワークのパケット処理を高速に行うためのライブラリやドライバのセットです。もともとは Intel が開発したものですが、現在は Linux Foundation の配下で開発されています。 Home - DPDK DPDK is the open source Data Plane Development Kit that consists of libraries to accelerate packet processing workloads running on a wide variety of CPU archite... www.dpdk.org Socket の内部では当然何らかのソフトウェアが動作しており、ネットワークに関する機能が実現されています。Linux Kernel には標準でネットワーク機能 (デバイスの操作、イーサネット、IP、UDP 通信など) が用意されていますので、UDP 以下のレイヤの通信やルーティングなどは Kernel の機能を活用して実現しつつ、UDP より上の DTLS 通信やその他機能は独自のソフトウェアで実装するというのがシンプルな発想です。 しかし、DPDK を利用しているということは、Kernel のネットワーク機能を使わずに DPDK で実現しているということであり、実装の難易度も高いです。DPDK を利用する場合、通常はC言語で開発する必要がありますので苦痛も多いです。Kernel を利用するよりもパケット処理を高速化できるかもしれないというメリットがあるとはいえ、技術的に高度で複雑なことを行っていることが覗えます。 Cato クラウドのいまいちなところ API が GraphQL なので扱いづらい Cato クラウドの API は全て GraphQL 形式で提供されています。 Cato Networks GraphQL API Reference api.catonetworks.com GraphQL は比較的新しい仕組みであり、RESTful あるいは REST API と比べて馴染みが薄いです。また、Cato クラウドの API に対するクライアントライブラリが用意されているわけでもないため、API を利用するには GraphQL 自体を理解する必要があり、学習コストがけっこう高い印象です。データ参照系の API だと GraphQL のメリットもあると思いますが、データ更新系 (設定変更など) の API だとメリットが多くなくて扱いづらいだけなのではと思っています。 今後 API が拡充されていくときに、利用しやすい API になっていることを期待したいです。 全ての通信が暗号化される Socket や Cato Client と PoP との間の通信は全て DTLS や TLS によって暗号化されています。また、独自にルータを用意して IPsec で PoP に接続する場合も暗号化されます。 拠点間通信のための閉域網やインターネット VPN の代替として Cato クラウドを活用する場合は、拠点と PoP の間の通信は全て暗号化されてインターネットを通ることを期待します。しかし、PoP 経由で行うインターネットとの通信については、拠点と PoP 間で暗号化されている必要は特にないように思います。Web サイトへのアクセスは HTTPS を使うことが一般的ですので、HTTPS で暗号化された通信をさらに暗号化する必要はないですよね。暗号化することは、スループット低下やレイテンシ増加に繋がりますので。 シンプルに考えるなら、PoP 経由のインターネット通信では暗号化せず、WAN 通信では暗号化するというのが良さそうなのですが、どうなのでしょうか。もちろん、暗号化する目的は単に機密性だけではなく、通信相手の認証、改ざん防止、リプレイ攻撃の防止などもありますので、全く暗号化しないというのも問題があるかもしれませんが。 ブロックされる通信もいったん PoP に送られる SASE (Secure Access Service Edge) における Edge とは、Cato クラウドでは PoP のことを指しています。Cato クラウドには Firewall, SWG, IPS, NGAM, ZTNA など様々な機能があり、これら機能は PoP で実現されています。 SASE 登場前のアーキテクチャ (※多数の拠点やリモートユーザがデータセンターに閉域網や VPN 接続を行い、そのデータセンター経由でインターネットや WAN 通信を行う構成) と比較して、Cato クラウドの SASE は効率的な通信や処理の負荷分散という観点で理にかなっています。一方で、従来であれば各拠点のファイアウォールで制御していた通信についても、Cato クラウドだと PoP で行うようになっているのではないでしょうか。 通信の中身を見ずに行えるファイアウォール機能は、ユーザにより近い Socket や Cato Client でも行うようになれば良いなぁと思っています。そうすれば、ブロックされる通信は PoP に送られなくなり、不要なトラフィックや通信コストを削減できますので。通信の中身を見るセキュリティ機能は負荷の高い処理ですし、PoP で行うというのは自然だとも思います。 将来的に SASE という概念がより高度化され、ユーザの手元にも Edge があるという時代が来るのだろうなぁと想像しています。 結びとして Cato クラウドは便利ですし機能も豊富なので、価格が見合うなら良いサービスだと思います。中の実装はブラックボックス的に外から観察して推測することしかできませんが、見える範囲ではしっかりと作られている印象ですし、技術的に高度なことも行われていますので、今後も永く続くサービスであって欲しいと願っています。 この記事を書き連ねる中で、こういうネットワークサービスを作る立場になるのも良いかもしれないと改めて感じました。

本記事は TechHarmony Advent Calendar 12/16付の記事です。 SCSK株式会社では 2023/12/5(火) 15:00～ より、 【導入検討企業様限定！】Catoクラウドデモセミナー ～Catoクラウドの主要機能を2時間で網羅～ と題して、世界初のSASEである「Catoクラウド」の概要をたっぷり2時間で解説するセミナーを開催いたしました！ 本セミナーのスピーカーを担当した私が、準備～当日にかけての裏話を記事にしてみました！ セミナー概要 項目 内容 開催日 2023年12月5日 15:00~17:00 開催場所 オンライン イベントHP Catoクラウドデモセミナー～Catoクラウドの主要機能を2時間で網羅～（2023年12月05日） ｜ SCSK株式会社   ここ十数年、クラウドの普及や、働く場所の多様化、高度化・巧妙化し続けるサイバー攻撃など、IT概況は変化しています。 ネットワークセキュリティの領域においては、あらゆる通信がデータセンターに集中することによる非効率な通信や終わりのない増速対応、セキュリティ対策の漏れや運用の煩雑化など、数えきれないほどの課題がある中、これらを解決するソリューションとして「SASE」（※1）を検討する企業が増えています。 そこで！ 世界初のSASEである「Catoクラウド」 の概要を解説するセミナーを開催いたしました！ さらに、ご希望の方（先着10名様）には、ハンズオン形式でご参加いただき、お手元の環境からCatoクラウドの使用感を体感していただけるような参加型セミナーとなりました！ ※1　SASEとは「Secure Access Service Edge」の略で、2019年8月にガートナー社が公開した新しいネットワーク/セキュリティモデルです。 想定のお客様 今回は以下のようなご要望にお応えできるよう、準備をさせていただきました！ SASEがどれくらい便利なのか知りたい Catoクラウドの実際の画面を見てみたい PoCや検証ライセンスなどの具体的な検討は未だ先…まずは触ってみたい プログラム Agenda Agendaはこのような感じで、全部で 7セクション にわたり実施いたしました。                                                    セクション 内容 時間 １ はじめに ・ご挨拶と注意事項 ・Catoクラウドの概要 15:00–15:05 ２ デモ構成について ・デモ構成とデモ内容のご説明 15:05–15:10 ３ CMAの概要と拠点(Site)接続 ・Cato Management Application (CMA)の概要 ・Adminアカウントの作成とログイン ・Siteの作成とSocket接続 15:10–15:30 ４ モバイル接続 ・Cato Clientのインストールと接続 15:30–15:50 休憩 15:50–16:00 ５ インターネット接続 ・通信ログ確認 ・固定IPアドレスの利用 16:00–16:20 ６ セキュリティ機能 ・Internet Firewall / WAN Firewallの設定 ・CASBの設定 16:2０–16:50 ７ おわりに ・SCSKのCatoの取り組みについて ・ご連携事項とお願い事項 16:50– 17:00 デモ環境構成 SCSK検証環境は、Socketを1台設置して接続をするSite接続の構成を用意しました！ モバイルユーザーは、Cato Client（VPN Client）を端末にインストールして接続する モバイル接続とし、Catoクラウド経由でInternetおよびSaaSサービスへの接続が可能となるといった構成です。                                                 実際にハンズオンでご参加いただいた方には、赤矢印の通信を実際にお試しいただき、CMAにて接続状況をご確認いただきました！ セミナーの様子 今回はオンラインでの開催で、81名からお申込みをいただきました。 内容はCatoクラウドの概要をたっぷり解説するものであり、多くの方にご注目いただけたように思います。 QA 当日はZoomの機能を利用し、QA対応を行っておりましたので、一部ご紹介します。 Q． SocketのWANインターフェースの設定でWAN1とWAN2がありましたが、違いはなんですか？ A． Socketには、物理的にWANポートが2つございます。 A． WAN1とWAN2をそれぞれ異なる回線に接続して、回線を冗長化してのご利用が可能です。 Q． Device Posture等のアクセスコントロール機能は全てのライセンスで利用可能でしょうか？ A． Device Posture機能は標準機能となっており、全ライセンスでご利用可能です。 Q． クライアントソフトのインストールに関して、コマンドラインによるサイレントインストールは可能ですか？ A． はい、可能です。 Q． クライアントソフトのアップデート時は管理者権限（WindowsのAdministrators権限）を必要としますか？ A． いいえ、クライアントのアップデート時は管理者権限は不要です。 A． なお、初回のインストール時は管理者権限が必要です。 Q． グローバルIPのNATのセッション上限数（制限）はありますか？ A． いいえ、セッション上限数はございません。こちらはクラウドサービスならではの利点と言えるかと思います。 Q． Internetファイアウォールルールに関して、暗黙のpermitから暗黙のdeny に変更することは可能でしょうか？ A． 変更はできませんが、Permitのひとつ上に無条件のDenyルールを書いていただくことで、実現は可能です。 裏話 セミナーの開催が決定してから当日まで、1.5か月ほどの時間をかけ、準備を行いました。 特に、CatoクラウドではCMAで設定を行った後、反映までに最低でも約5分、そしてその時間は可変するためシナリオ検討には時間を要しました。シミュレーションと修正を繰り返し行い、シナリオのブラッシュアップに努めました。 そしていよいよセミナー当日。 シナリオ通り進むはずが、セクション4のモバイル接続でトラブル発生！ タイミング悪くCatoクラウドの障害にあたってしまいました・・・ 本来、モバイルユーザの登録（氏名とメールアドレスの登録）を行うと、登録したユーザ宛にInvitationメールが届くはずですが、障害によりなかなか届かず、急遽シナリオ修正が必要になりました。 まずは、別のアカウントでモバイルユーザの登録を試みましたが、同様にInvitationメールが届かず失敗。 ここでユーザの作成を断念し、別のアカウントで既に登録済みのユーザで接続を試みましたが、Device Postureにより接続に失敗。 急ぎDevice Postureの設定を解除しましたが、反映に5分程度かかるためその間なかなか接続できず、さらに自動アップデートを走らせてしまい追加で2,3分待機。その後やっと接続に成功しました・・・ このように、セクション4では度重なるトラブルによりバタバタとしてしまいましたが、その後のセクションはオンスケで進みセミナーは終了いたしました。 こんな状況ではございましたがご参加いただいた方にはCatoクラウドの概要や魅力が少しでもわっておりましたら幸いです！ 投影資料(一部抜粋) 当日投影しました資料にはSCSKの取り組みの記載がございますので是非ご確認ください！

本記事は TechHarmony Advent Calendar 12/15付の記事です。 Catoクラウドをご利用いただいてるお客様から、よくいただくご質問に「Catoクライアントが繋がらないです」といったお問い合わせを頂きます。 そんなときの対処法や問題の切り分け方を今回ご紹介いたします。 繋がらない状態ってどんな状況？ Catoクライアントが繋がらない状態に関しては大きく分けて、以下2パターンの状況が考えられます。 ①Catoクラウド側の問題 Catoクラウドにて障害や不具合などが発生していて、接続できない状況になります。 以前発生した障害・不具合の例として、Catoクラウドへ接続する際、クライアント認証中の際に画面が真っ白くなるという問い合わせを複数のお客様から頂いた事例がありました。こちらの事象は、クライアントのバージョンを5.8以上へアップグレードすることで解消されました。 こういったCato側の問題で接続できない場合があります。Catoの障害情報やサービス稼働状況について確認したい際は、以下サイトにて確認が可能となります。   Loading... status.catonetworks.com   ②Catoクラウド以外の問題 Catoクラウド以外ですと、以下の問題などが挙げられます。 ・User Nameやパスワード入力ミスなどの基本的な部分の確認 ・Catoクライアントを入れている端末、ネットワークなどお客様側の環境での問題 ・Catoクラウドに入れている設定にてブロックされている ・その他   Catoクライアントが繋がらない状態については、大きく分けてこれらのことが考えれられます。 原因によって対処方法が異なってきますので、まずはどこが問題を引きを起こしているのか切り分け作業を行い、正しい対処に努められるようにしましょう。   Let’s トラブルシューティング！ Catoクラウド以外の問題にて、Catoクライアントを起動しても正常にCatoへ接続ができない場合は、まずは問題の特定ができるよう切り分けを実施しましょう。 Catoクライアントから接続できない場合、エラーメッセージが表示されます。まずは、メッセージ内容で問題箇所が判明するか確認しましょう。 実際にどのようなエラーメッセージが出るか、確認してみたいと思います。   基本的な確認 まず、Catoクライアントを開くとこのような画面が表示されます。 画面真ん中の起動ボタンを押すとログインIDとパスワードを入力する画面が出てきます。 User Name（メールアドレス）、パスワードのログイン情報を入力します。 User Nameとパスワードのミスがあると、以下のような「Login Error」のエラーメッセージが表示されます。 ログイン情報に誤りがないか確認し、ログインしましょう。   続いて、インターネット接続が正常に動作しているか確認をしましょう。 Catoクラウドはインターネットに接続していないと利用できないため、前提としてインターネットに接続しているかの確認も必要となります。 インターネットに繋がっていない状態で接続を試みた場合、以下のようなエラー画面が表示されます。 「Network Error」が表示されましたら、インターネットに接続されているか確認しましょう。   ●ご利用のCatoアカウントが有効であるか CatoクラウドをCatoクライアントにて使用するために、対象のアカウントにSDPユーザーのライセンスが割り当てられている必要がありますので確認しましょう。 ライセンスが付与されていないアカウントにてログインを試みた場合、エラーメッセージには「Incorrect Credentials」という表示がされます。   確認には管理画面へのログインが必要になりますので、管理者にて確認が可能となります。     端末・NW設定などお客様環境の確認 基本的な確認をしても改善されない場合、お客様環境のデバイスやネットワークの設定（ファイアウォール、セキュリティソフトウェアの設定）を確認し、Catoクライアントへの通信がブロックされていないか接続環境として問題ないか確認しましょう。 具体的には以下の確認をしていきましょう。   ●サードパーティ製のVPNソフトをインストールしていないか インストールされている場合、起動ボタンを押した直後以下のようなエラー画面が表示され、ログイン情報の入力すらさせてくれません。。。 サードパーティ製のVPNソフトをインストールをしていたり、ウィルス対策ソフト等でVPNを有効にしている場合、Catoクライアントが接続できない可能性があります。Catoクラウドは、サードパーティのドライバーがCatoクライアントと競合すると正常に接続ができない場合がございますのでご注意ください。 Catoクライアントが接続できないという問い合わせで、繋がらない原因が一番多いのがこちらになります。   ●PCのネットワークアダプタの確認 ネットワークアダプタが、最新のバージョンであるかを確認しましょう。 最新ではない場合は最新のバージョンに更新ください。 ネットワークアダプタが最新バージョンであっても問題が改善されない場合は、PCのネットワークをリセット、ネットワークアダプタを再インストールし、PCの再起動をお試しください。 また過去に、仮想アダプタに原因があり、仮想アダプタを無効にして際Catoクライアントへの接続がうまくいった事例もありますので、こちらもご確認ください。 ●Windows 端末で IP ルーティングが有効になっていないか IP ルーティングが有効になっている場合は、Catoクライアントの認証は失敗します。 理由いたしましては、IP ルーティングを有効にすると、SDP クライアントの認証プロセスに干渉するため、クライアントは説測できなくなります。 無効にした場合、クライアントが認証にCatoNetworksアダプタのIPアドレスを使用するため接続がいくようになります。 ●お客様環境のポートにてCatoへの通信が制御されていないか Catoクライアントが利用する通信ポートの53/udp、443/udp がお客様側の設定にて通信が許可されている必要があります。 なお、Socketにつきましては、53/udp、443/udp 、443/tcpが許可されている必要があります。 お客様側のNW設定のご確認をお願いいたします。 Catoクラウドの設定確認 アクセス制御などのCatoクラウド側で設定しているルールにてCatoクラウドへ接続できない場合などもございます。 例えば、Device Postureなどのクライアント接続のルールに該当し、Catoクライアントが接続できないといったこともあります。 上記画面は、Device Postureのルールに該当して接続不可の場合を例として表示します。 エラーメッセージにFail理由が記載されているので原因が判明しやすいですね。 端末や端末にインストールされているソフトのバージョンなどが、Catoクラウドに設定されているアクセスルールに引っ掛かり、接続できない事象などあります。その際は、設定の見直しやソフトのバージョンが設定したルールと問題ないか確認しましょう。 その他 Catoクライアントが接続できないという類似の問い合わせに、MacOS や ios端末などのデバイス証明書のインストール方法がわからない/上手くいかないというご連絡をいただきます。 MacOS/iOSデバイスにて証明書認証を行いたい場合、OSの仕様上、Apple ConfiguratorやMDMを使用して、デバイス証明書をVPNプロファイルに含めて端末に配布する必要があります。なお、手動でのデバイス証明書のインストールでは、認証を行うことができません。 デバイス証明書に関する質問が来た際、我々もよく確認するサイトを以下に記載いたしますので、デバイス証明書周りでお困りのお客様はご参照いただければ幸いです。 Distributing Certificates for Device Authentication and Device Checks Device Authentication Troubleshooting   確認後の対応 上記トラブルシューティングを実施してみても改善が見込まれない場合は、Catoクライアントの再インストールを実施してみましょう。 最新のバージョンを再インストールし、クライアントが接続できるかトライしましょう。 最新版はCatoクライアントダウンロードページからダウンロードが可能です。 Catoクライアントダウンロードページ： https://clientdownload.catonetworks.com/ 上記、端末側の状態をチェックしてみても改善しない場合は、Cato側の障害などが疑われます。 対象のお問い合わせ窓口までご連絡ください。 最後に Catoクライアントが繋がらないというお問い合わせは、Cato導入後皆さまから良くいただく質問です。 この記事を作成できたのも、これまで接続できないとお問い合わせ頂いたユーザー様の賜物になります。 Catoクラウドをお使いの皆様にこの記事をご覧いただき、問題解決の一役買えておれば幸いでございます。

本記事は TechHarmony Advent Calendar 12/14付の記事です。 今回は比較的新しい機能であるLAN Firewallをご紹介します。 CatoのKnowledge Baseをみると2023年9月頃に「（従来の）Local Routing画面は、LAN Firewallと呼ばれるようになりました」という記事があります。元々Local Routingという機能でVLAN間のルーティングを制御していたのですが、LAN FirewallにUpdateすることでアクセス制御が可能になりました。 LAN Firewallのメリット Cato LAN Firewallのメリットとして3つを挙げてみました。 1.オンプレFirewallが不要になる 一番のメリットは、拠点内にあったオンプレのFirewallが不要となるということでしょう。 機器が1つ不要になるということに加え、Firewallのセキュリティポリシーやログの管理もCato Management Application （CMA）で一元化できるので運用コストの抑制に繋がります。 2.セキュリティ強化 「Firewallは無いけれども本当はLAN内のアクセス制御が必要だ」とか「ルータのACLで代用している」などケースであれば、追加費用なくセキュリティ強化ができます。LAN FirewallはCatoの標準機能なので追加費用は発生しません。 ＜拠点内のアクセス制御（例）＞ ・開発部門セグメントのサーバには他部門ユーザーをアクセスさせない ・ゲスト用WiFi接続ユーザーは社内セグメントにはアクセスさせずCatoのみ（インターネット接続のみ）アクセスを許可する 3.回線負荷軽減 Catoを使用している前提の話になりますが、CatoにLAN Firewall機能がなかった時は、同一拠点のセグメント間のアクセス制御はWAN Firewallで実施するしかなかったため回線によけいなトラフィックを流すしかありませんでした。LAN Firewallを使用するとトラフィックはCato Socketで折り返す経路となるので回線に負荷をかけることがありません。 Catoクラウドの3つのFirewall LAN Firewallが実装されたことで、Catoクラウドには3つのFirewallが存在することになりました。 尚、Internet FirewallとWAN Firewallについては以下のブログ記事を参照下さい。 CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 3つのFirewallの概要は次の通りです。 1 Internet Firewall CatoクラウドからInternetにでていく通信を制御します。URLフィルタ機能もココにあります。 2 WAN Firewall Catoクラウドに接続した拠点やユーザー間の通信を制御します。 例えば、複数のグループ会社がCatoに繋がっていて共通のデータセンタにシステムがある場合、会社毎に宛先サーバのアクセス制御を行うことができます。 3 LAN Firewall Cato Socketを介して拠点内のVLAN間の制御を行います。 利用用途は「LAN Firewallのメリット」に記載の通りです。 全体のネットワーク構成の中で、各Firewallがどこで機能しているかは「 CatoクラウドのFirewall機能について 」を見ていただくこととし、早速LAN Firewallの内容に進みます。 SocketにVLANを設定する まず、拠点内に複数のセグメントがある環境を想定してSocket配下に複数のVLANを作成します。 ここでは以下の2つを構成を作ってみました。 Socketの物理ポート毎にVLANを分ける タグ付きVLANでSocketと配下のスイッチをトランク接続する 物理ポート毎にVLANを分ける 接続イメージは図1の通りです。 Socketのlan1ポートをNative VLAN、lan2ポートをVLAN10として各VLANにIPアドレスを設定します。 図.1 物理ポートにVLAN追加 lan1のNative VLANはサイト作成時に設定するのでここでは省略し、lan2ポートにNativeとは別のVLANを追加するところから始めます。 該当サイトのSite Configuration >Socket で「2(LAN2)」をクリックして、IPアドレス及びDHCP設定を行います。（図2） 図2. lan2ポートにVLAN作成(1) 図2. lan2ポートにVLAN作成(2) Socketの物理ポート数は限りがあり、Socket X1500だと全部で4ポート搭載なので最大2VLAN（計3セグメント）しか追加できません。 以下はX1500の4ポートをフルに利用する場合の例です。 Port 1(lan1) ：Native VLAN Port 2(lan2) ：VLAN10 Port 3(wan1) ：回線接続 Port4(wan2) ：VLAN20 更に追加でセグメントが必要な場合は、Socketと配下のL2スイッチ間でトランク接続（タグVLAN）を使用します。 この場合、 Catoでサポートしているカプセル化形式はIEEE 802.1Qのみ です。 トランク接続（タグVLAN） 接続イメージは図3の通りです。 物理的にはSocketのlan1ポートを使用し、その中にNative・VLAN10・VLAN20を通すという環境を作成します。 図3. トランク接続でVLAN追加 設定箇所は該当サイトのSite Configuration >Networksで、それぞれVLANを追加していきます。図4はVLAN10の設定画面です。 図4. VLAN10の設定 同様にVLAN20を設定した後の状態が図5となります。これでトランク接続による3セグメントの作成が完了しました。 図5. トランク接続によりVLAN作成 但し、 この状態ではVLAN間のルーティング等が完全ではない ので、正常に通信させるためには次のステップが必要です。 Local Routing をLAN Firewallにアップデートする 2023年12月現在、CMAのデフォルト状態では「LAN Firewall」というメニューがありません。「Local Routing」からアップデートする必要があります。 まず、該当サイトでSite Configuration >Local Routingを表示させる（図6）と「Update to LAN FW」のボタンがあるので、これをクリックします。するとポップアップメッセージ（図7）が出るので続けて「Confirm」をクリックします。これによりメニューが「Local Routing」 から「LAN Firewall」にアップデートされます。（図8） 図6. LAN Firewallアップデート前 図7. Update to LAN FWをクリック 図8. Local Routing からLAN Firewallに変わる これで、LAN Firewallが使える状態となりました。 LAN Firewallでアクセス制御する LAN Firewallのルール設定は少しクセがあるので注意が必要です。 設定方法は従来のFirewallと同様で、許可するルールや禁止するルールを作成すると、上のルールから順番に適用されていくのですが、 LAN Firewallのルールと一致しない通信はCato PoPに転送されます。つまり 「暗黙のPoP転送」 が存在するのです。 当社の検証環境で試している際に、意図せぬ通信が通ってしまうのが理解できなかったのですが、LAN Firewallのルール設定が漏れていたため、Cato PoPに転送されWAN Firewallの全通信を許可するポリシーに一致していたようです。WAN Firewallのログに通過しているログがしっかり残っていました。試しにこの時は、WAN Firewallで「送信元」と「宛先」を同一サイトにして全通信をブロックするルールを追加したところ、意図する制御ができました。 では次のアクセス制御要件に対するルールを作成し実際の動作を確認してみましょう。 【アクセス制御要件】 ・VLAN1からVLAN10のRDPのみ禁止し、VLAN10/VLAN20へのその他通信は許可する。 　・VLAN10/VLAN20からVLAN1の通信は禁止する。 　・VLAN10～VLAN20間の通信は禁止する。 設定方法は、LAN Firewallの画面から「New」をクリックしてルールを作っていくのですが、少し気になったのは「送信元」と「宛先」で該当のVLANを選択する際に、Nativeと追加したVLANで選択するカテゴリ（？）が異なる点です。（たいした話ではないです） Native VLANは「Network Interface」を選択すると表示がされ設定が可能 追加したVLANは「Interface Subnet」を選択すると表示がされ設定が可能 図9. 送信元と宛先にNativeとVLANを設定 ということで、今回のアクセス制御要件に対するルールを以下のように作成しました。 図10. 作成したLAN Firewallルール（例） このルールで通信確認した結果、以下の通り想定したアクセス制御を確認することができました。 No 送信元 宛先 通信内容 結果 1 VLAN1 VLAN10 RDP 通信不可 2 VLAN1 VLAN10 Ping、ファイル共有 通信可 3 VLAN1 VLAN20 Ping、ファイル共有 通信可 4 VLAN10 VLAN1 Ping、ファイル共有 通信不可 5 VLAN20 VLAN1 Ping、ファイル共有 通信不可 6 VLAN10 VLAN20 Ping、ファイル共有 通信不可 7 VLAN20 VLAN10 Ping、ファイル共有 通信不可 参考までに、LAN FirewallでRDPがブロックされた時のログです。 図11. RDPブロックログ 最後に 今回は、LAN Firewallの設定方法と動作を確認しました。多数の拠点で使用するものではないかもしれませんが、あると便利な機能です。Catoクラウド化をお考えの際に「拠点のFirewallは必要」という要件がありましたら、十分使える機能かと思いますのでご安心下さい。

こんにちは、SCSKの木澤です。 今回、 Storage JAWS #2 にて、当社におけるファイルサーバ利用事例を紹介させていただきました。 概要については以下ブログ記事で説明しておりますが、今回は導入効果を中心に説明させていただいた次第です。 AWS上でファイルサーバを実現する方法と、導入にあたっての勘所 弊社で実施した人気ウェビナーの内容から、AWS上でファイルサーバを実現するにあたっての各種の方式と選択のポイント、また導入にあたっての勘所について解説したいと思います。 blog.usize-tech.com 2023.07.03 資料ダウンロード 登壇資料はこちらです。 StorageJAWS#2登壇資料 ダウンロード 5 Downloads まとめ 以上、当社事例をご紹介させていただきました。 皆様のクラウドマイグレーションの参考になれば幸いです。 なお、本事例はいくつかのメディア、セミナーで既に発表しております。併せてご確認ください。 （オンデマンドセミナー） 事例から読み解く！NetApp on AWSでファイルサーバをクラウド化するポイント｜セミナー｜クラウド移行だけでは描けない、理想のDXを実現する www.scsk.jp （事例記事） 【事例】SCSKが「100TB超え」のファイルサーバ移行に選んだ最適解とは？ 優に1万人を超える従業員を抱えるシステムインテグレーターのSCSK。同社では、社内のファイルサーバに膨大なデータが蓄積され、アクセス性能は限界を迎えていた。ファイルサーバの性能低下は業務に多大な影響を及ぼしかねない。データの肥大化はストレージを拡張して対応しようにも、そのコストも無視できない。性能劣化と増大する保守コス... www.sbbit.jp SCSKの従業員1万ユーザーが使う 統合ファイルサーバーをAWS へ移行、 NetApp Cloud Volumes ONTAPを採用し 性能と運用管理性を大幅に向上 SCSK が、自らの変革を軸にした成長戦略を加速させています。SCSKグループは2030年に目指す姿として「グランドデザイン2030」を策定しました。 ここで掲げた「2030年 共創ITカンパニー」の実現というメッセージは、SCSK が主体的に社会への価値創出に取り組みながら、顧客や社会と共に成長していく決意を示したも... www.netapp.com またSCSKでは自社ファイルサーバの運用事例も踏まえ、ファイルサーバを含めた各種サーバのマイグレーションを承っております。 詳細は、ぜひ弊社までお問い合わせ頂ければと思います。 お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する www.scsk.jp よろしくお願いします。

はじめに こんにちは。SCSKのふくちーぬです。 皆さんは、イベントベースのCodePipelineのパイプラインを利用していますでしょうか。それともポーリングベースのパイプラインを利用していますでしょうか。 まだポーリングベースを利用している方は、本記事を読んでいただきイベントベースへの移行をしていただけると幸いです。（ふくちーぬもその内の1人でした。。） 本記事では、以下のAWS公式ドキュメントに従いCodeCommitをソースとしたCloudFormationで構築済みのポーリングベースのCodepipelineからイベントベースへの移行を実施します。 ポーリングパイプラインを移行してイベントベースの変更検出を使用する - AWS CodePipeline パイプラインをイベントベースの変更検出用に更新する方法をソースタイプ別に説明します。 docs.aws.amazon.com CodePipelineの検出オプションの種類 CodePipelineには、ソースの検出オプションとしてポーリングベース・イベントベースの2種類があります。 ポーリングベースでは、CodePipelineがCodeCommit内の対象ブランチに対して定期的に監視することで、変更を検出しています。 イベントベースでは、対象ブランチに変更があった際にEventBridgeにイベントを送信するだけです。すなわちCodePipelineは、どんと構えてEventBridgeからのメッセージを待っていればよいだけです。 ポーリングベースのパイプラインの移行を推奨している件 2023年4月下旬に、AWS サポートから以下のようなメールが届きました。 本メッセージは、1つ以上ポーリングパイプラインをお持ちのお客様にお送りしています。ポーリングパイプラインは、変更をポーリングするように設定されたソースアクションが少なくとも1つあるパイプラインとして定義されます。AWS CodePipelineチームは、2023年5月25日より、非アクティブなパイプラインでのポーリングを無効にします。非アクティブなパイプラインとは、過去30日間にパイプラインの実行が開始されていないパイプラインと定義されます。Amazon EventBridgeルール、AWS CodeStar接続、またはウェブフックのみを使用してパイプラインをトリガーする非アクティブなパイプラインは影響を受けません。また、アクティブなパイプラインも影響を受けません。 ソースのトリガーメカニズムとして、Amazon EventBridge、AWS CodeStar接続、またはウェブフックを使用するように更新することをお勧めします。 つまり、「30日以上利用されていないポーリングベースのパイプラインを無効にする」、「ポーリングベースのパイプラインを移行することを推奨する」のアナウンスをしています。 現時点でも、ポーリングベースのパイプラインを新規に作成することはできます。また無効になったパイプラインも手動で実行することで、パイプラインを起動することは可能です。 推測ですが、AWS的にCodePipelineがポーリングするコストが割りに合っていないことも要因の1つかもしれませんね。 イベントベースのパイプラインを推奨する理由 ソースリポジトリのブランチの変更を迅速に検出できるようになり、パイプライン実行パフォーマンスが向上する CI/CDパイプラインの準備 Cloud9の作成 以下に AWS Cloud9 の作成方法を記載しているので参考にしてください。 AMI から AWS Cloud9 を復元する Cloud9を削除してしまった際の適切な復元方法についてお話します。 blog.usize-tech.com 2023.11.24 Cloud9とCodeCommitの連携 Cloud9からCodeCommitにプッシュできるように準備してください。 AWS Cloud9 と AWS CodeCommit を統合する - AWS CodeCommit AWS Cloud9 を AWS CodeCommit と統合する方法について説明します。 docs.aws.amazon.com CodeCommitへのソースコード配置 今回の検証ではCodeCommitに配置するものは任意のもので問題ありませんが、以下を利用することにします。 CI/CD配下でネストされたスタックの子スタックに対して、変更セットを有効にするテクニック[AWS CodePipeline＋AWS CloudFormation] CI/CD 配下のネストされた AWS CloudFormation スタックに対して変更セットを有効化する方法を紹介します。 blog.usize-tech.com 2023.12.07 CI/CDパイプラインの作成 ご使用のAWSアカウント内にポーリングベースのパイプラインがCloudFormationにて作成済みの方は、それをご利用ください。 今回は、新規にポーリングベースのパイプラインを作成した後に、イベントベースへ移行します。 ポーリングベースのパイプラインの作成 ポイントはパイプラインの定義にて、”PollForSourceChanges”を”true”に設定することでポーリングベースのパイプラインを作成できます。 以下のCloudFormationテンプレートをデプロイして、ポーリングベースのパイプラインを構築してください。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn CI/CD Pipeline Parameters: ResourceName: Type: String REPOSITORYNAME: Type: String Description: aws codecommit repository name STACKNAME: Type: String MailAddress: Type: String Resources: ArtifactStoreBucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub s3bucket-${AWS::AccountId}-artifactbucket CodeBuildBucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub s3bucket-${AWS::AccountId}-codebuildtbucket # ------------------------------------------------------------# # CodeBuild Role (IAM) # ------------------------------------------------------------# CodeBuildRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: codebuild.amazonaws.com Path: / ManagedPolicyArns: - !Ref CodeBuildPolicy - arn:aws:iam::aws:policy/AWSCloudFormationFullAccess RoleName: !Sub "IRL-CODEBUILD-S3CloudWatchlogsAccess" # ------------------------------------------------------------# # CodeBuild Role Policy (IAM) # ------------------------------------------------------------# CodeBuildPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodeBuildAccess PolicyDocument: Version: '2012-10-17' Statement: - Sid: CloudWatchLogsAccess Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: - !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/* - Sid: S3Access Effect: Allow Action: - s3:PutObject - s3:GetObject - s3:GetObjectVersion Resource: - !Sub arn:aws:s3:::${ArtifactStoreBucket} - !Sub arn:aws:s3:::${ArtifactStoreBucket}/* - !Sub arn:aws:s3:::${CodeBuildBucket} - !Sub arn:aws:s3:::${CodeBuildBucket}/* - Sid: IAMPass Effect: Allow Action: - iam:PassRole Resource: "*" - Sid: CloudFormationAccess Effect: Allow Action: cloudformation:ValidateTemplate Resource: "*" # ------------------------------------------------------------# # CodeBuild linter Project # ------------------------------------------------------------# CodeBuildProjectLint: Type: AWS::CodeBuild::Project Properties: Name: !Sub ${ResourceName}-project-lint ServiceRole: !GetAtt CodeBuildRole.Arn Artifacts: Type: CODEPIPELINE Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 EnvironmentVariables: - Name: AWS_REGION Value: !Ref AWS::Region - Name: S3_BUCKET Value: !Ref CodeBuildBucket Source: Type: CODEPIPELINE # ------------------------------------------------------------# # CodeBuild changeset Project # ------------------------------------------------------------# CodeBuildProjectChangeset: Type: AWS::CodeBuild::Project Properties: Name: !Sub ${ResourceName}-project-changeset ServiceRole: !GetAtt CodeBuildRole.Arn Artifacts: Type: CODEPIPELINE Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 EnvironmentVariables: - Name: AWS_REGION Value: !Ref AWS::Region - Name: S3_BUCKET Value: !Ref CodeBuildBucket - Name: STACK_NAME Value: !Ref STACKNAME - Name: CFNROLE_ARN Value: !GetAtt CloudformationRole.Arn Source: Type: CODEPIPELINE BuildSpec: changeset-buildspec.yaml # ------------------------------------------------------------# # CloudFormation Role (IAM) # ------------------------------------------------------------# CloudformationRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: cloudformation.amazonaws.com Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AdministratorAccess RoleName: "IRL-CLOUDFORMATION-ServiceFullAccess" # ------------------------------------------------------------# # CodePipeline Role (IAM) # ------------------------------------------------------------# PipelineRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: codepipeline.amazonaws.com Path: / ManagedPolicyArns: - !Ref PipelinePolicy RoleName: "IRL-CODEPIPELINE-Access" # ------------------------------------------------------------# # CodePipeline Role Policy (IAM) # ------------------------------------------------------------# PipelinePolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodePipelineAccess PolicyDocument: Version: '2012-10-17' Statement: - Sid: S3FullAccess Effect: Allow Action: s3:* Resource: - !Sub arn:aws:s3:::${ArtifactStoreBucket} - !Sub arn:aws:s3:::${ArtifactStoreBucket}/* - Sid: FullAccess Effect: Allow Action: - cloudformation:* - iam:PassRole - codecommit:GetRepository - codecommit:ListBranches - codecommit:GetUploadArchiveStatus - codecommit:UploadArchive - codecommit:CancelUploadArchive - codecommit:GetBranch - codecommit:GetCommit Resource: "*" - Sid: CodeBuildAccess Effect: Allow Action: - codebuild:BatchGetBuilds - codebuild:StartBuild Resource: !GetAtt CodeBuildProjectLint.Arn - Sid: CodeBuildChangesetAccess Effect: Allow Action: - codebuild:BatchGetBuilds - codebuild:StartBuild Resource: !GetAtt CodeBuildProjectChangeset.Arn - Sid: SNSAccess Effect: Allow Action: - sns:Publish Resource: !Sub arn:aws:sns:${AWS::Region}:${AWS::AccountId}:${ResourceName}-topic # ------------------------------------------------------------# # CodePipeline # ------------------------------------------------------------# Pipeline: Type: AWS::CodePipeline::Pipeline Properties: Name: !Sub ${ResourceName}-pipeline RoleArn: !GetAtt PipelineRole.Arn ArtifactStore: Type: S3 Location: !Ref ArtifactStoreBucket Stages: - Name: Source Actions: - Name: download-source ActionTypeId: Category: Source Owner: AWS Version: 1 Provider: CodeCommit Configuration: RepositoryName: !Ref REPOSITORYNAME BranchName: main PollForSourceChanges: true #ポーリングベースのパイプラインでは、"true"に設定 OutputArtifacts: - Name: SourceOutput - Name: Test Actions: - InputArtifacts: - Name: SourceOutput Name: testing ActionTypeId: Category: Test Owner: AWS Version: 1 Provider: CodeBuild Configuration: ProjectName: !Ref CodeBuildProjectLint - Name: Build Actions: - InputArtifacts: - Name: SourceOutput Name: changeset ActionTypeId: Category: Build Owner: AWS Version: 1 Provider: CodeBuild OutputArtifacts: - Name: BuildOutput Configuration: ProjectName: !Ref CodeBuildProjectChangeset Namespace: BuildVariables - Name: Approval Actions: - Name: approve-changeset ActionTypeId: Category: Approval Owner: AWS Version: 1 Provider: Manual Configuration: ExternalEntityLink: !Sub https://${AWS::Region}.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/changesets/changes?stackId=#{BuildVariables.SackId}&changeSetId=#{BuildVariables.ChangeSetId} NotificationArn: !GetAtt SNSTopic.TopicArn - Name: Deploy Actions: - Name: execute-changeset ActionTypeId: Category: Deploy Owner: AWS Version: 1 Provider: CloudFormation Configuration: StackName: !Join [ '-', [ !Ref ResourceName, 'infra-stack' ] ] ActionMode: CHANGE_SET_EXECUTE ChangeSetName: changeset RoleArn: !GetAtt CloudformationRole.Arn # ------------------------------------------------------------# # SNS # ------------------------------------------------------------# SNSTopic: Type: AWS::SNS::Topic Properties: Subscription: - Endpoint: !Ref MailAddress Protocol: email TopicName: !Sub ${ResourceName}-topic ポーリングベースのパイプラインの一覧の取得 今回はboto3(Python)を使用して、ポーリングベースのパイプラインの一覧を取得してみます。 Cloud9へのboto3のインストール 以下のコマンドを実行して、boto3ライブラリのインストールをします。 pip install boto3 以下のコマンドを実行して、バージョンが返却されればインストール済みとなります。今回は、”boto3 1.33.11″が返ってきています。 pip list | grep boto3 Pythonスクリプトの作成 Cloud9におけるGUI経由でのファイル作成方法は、以下を参照ください。 AMI から AWS Cloud9 を復元する Cloud9を削除してしまった際の適切な復元方法についてお話します。 blog.usize-tech.com 2023.11.24 以下のPythonファイルを任意のディレクトリに作成してください。ファイル名は、” PollingPipelinesExtractor . py”とします。 import boto3 import sys import time import math hasNextToken = True nextToken = "" pollablePipelines = [] lastExecutedTimes = [] if len(sys.argv) == 1: raise Exception("Please provide region name.") session = boto3.Session(profile_name='default', region_name=sys.argv[1]) codepipeline = session.client('codepipeline') def is_pollable_action(action): actionTypeId = action['actionTypeId'] configuration = action['configuration'] return actionTypeId['owner'] in {"AWS", "ThirdParty"} and actionTypeId['provider'] in {"GitHub", "CodeCommit", "S3"} and ('PollForSourceChanges' not in configuration or configuration['PollForSourceChanges'] == 'true') def has_pollable_actions(pipeline): hasPollableAction = False pipelineDefinition = codepipeline.get_pipeline(name=pipeline['name'])['pipeline'] for action in pipelineDefinition['stages'][0]['actions']: hasPollableAction = is_pollable_action(action) if hasPollableAction: break return hasPollableAction def get_last_executed_time(pipelineName): pipelineExecutions=codepipeline.list_pipeline_executions(pipelineName=pipelineName)['pipelineExecutionSummaries'] if pipelineExecutions: return pipelineExecutions[0]['startTime'].strftime("%A %m/%d/%Y, %H:%M:%S") else: return "Not executed in last year" while hasNextToken: if nextToken=="": list_pipelines_response = codepipeline.list_pipelines() else: list_pipelines_response = codepipeline.list_pipelines(nextToken=nextToken) if 'nextToken' in list_pipelines_response: nextToken = list_pipelines_response['nextToken'] else: hasNextToken= False for pipeline in list_pipelines_response['pipelines']: if has_pollable_actions(pipeline): pollablePipelines.append(pipeline['name']) lastExecutedTimes.append(get_last_executed_time(pipeline['name'])) fileName="{region}-{timeNow}.csv".format(region=sys.argv[1],timeNow=math.trunc(time.time())) file = open(fileName, 'w') print ("{:<30} {:<30} {:<30}".format('Polling Pipeline Name', '|','Last Executed Time')) print ("{:<30} {:<30} {:<30}".format('_____________________', '|','__________________')) for i in range(len(pollablePipelines)): print("{:<30} {:<30} {:<30}".format(pollablePipelines[i], '|', lastExecutedTimes[i])) file.write("{pipeline},".format(pipeline=pollablePipelines[i])) file.close() print("\nSaving Polling Pipeline Names to file {fileName}".format(fileName=fileName))  Pythonスクリプトの実行 以下のコマンドを実行して、pythonスクリプトを実行します。 引数として、指定のリージョンを入力します。ここでは、東京リージョンの”ap-northeast-1″を指定します。 python3 PollingPipelinesExtractor.py ap-northeast-1    指定のリージョン内に存在しているポーリングベースのパイプラインの一覧を取得することができます。これで、どのパイプラインがポーリングベースを採用しているのか一目瞭然ですね。またCSVファイルとしても出力されています。 今回は、”cicd-20231210-pipeline”を新規作成したので表示されています。ご自身で作成したものと読み替えてください。 イベントベースのパイプラインへ移行 ポーリングベースからイベントベースへ移行するために、CloudFormationテンプレートの修正をしていきます。 PollForSourceChangesの変更 以下のように、ポーリングベースを採用しないようにCodePipelineの”PollForSourceChanges”プロパティを”false”に変更します。 Stages: - Name: Source Actions: - Name: download-source ActionTypeId: Category: Source Owner: AWS Version: 1 Provider: CodeCommit Configuration: RepositoryName: !Ref REPOSITORYNAME BranchName: main PollForSourceChanges: false #イベントベースを採用するためfalseに変更 OutputArtifacts: - Name: SourceOutput  EventBridgeが利用するIAMポリシー・ロールの追加 以下のように、EventBridgeが利用するためのIAMポリシー・ロールを作成するための記述を追加します。 EventBridgeがCodePipelineを起動できる権限を付与しています。 # ------------------------------------------------------------# # CodePipeline Events Role (IAM) # ------------------------------------------------------------# PipelineEventsRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: events.amazonaws.com Path: / ManagedPolicyArns: - !Ref PipelineEventsPolicy RoleName: !Sub "IRL-EVENTBRIDGE-CodePipelineAccess" # ------------------------------------------------------------# # CodePipeline Events Role Policy (IAM) # ------------------------------------------------------------# PipelineEventsPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodePipelineAccessForEvents PolicyDocument: Statement: - Action: codepipeline:StartPipelineExecution Effect: Allow Resource: - !Sub arn:aws:codepipeline:${AWS::Region}:${AWS::AccountId}:${Pipeline} Version: "2012-10-17"  EventBridgeの追加 以下のように、EventBridge本体の記述を追加します。対象のリポジトリや付与するロール等の指定もしています。 これによりCodeCommitのブランチの更新をトリガーにCodePipelineを起動できるようになります。 # ------------------------------------------------------------# # EventBridge Rule for Starting CodePipeline # ------------------------------------------------------------# PipelineEventsRule: Type: AWS::Events::Rule Properties: Name: !Sub ${ResourceName}-rule-pipeline EventBusName: !Sub "arn:aws:events:${AWS::Region}:${AWS::AccountId}:event-bus/default" EventPattern: source: - aws.codecommit resources: - !Sub arn:aws:codecommit:${AWS::Region}:${AWS::AccountId}:${REPOSITORYNAME} detail-type: - "CodeCommit Repository State Change" detail: event: - referenceCreated - referenceUpdated referenceName: - main State: ENABLED Targets: - Arn: Fn::Join: - "" - - "arn:" - Ref: AWS::Partition - ":codepipeline:" - Ref: AWS::Region - ":" - Ref: AWS::AccountId - ":" - Ref: Pipeline Id: Target RoleArn: !GetAtt PipelineEventsRole.Arn  完成したテンプレート 完成したテンプレートは、以下の通りです。 AWSTemplateFormatVersion: 2010-09-09 Description: cfn CI/CD Pipeline Parameters: ResourceName: Type: String REPOSITORYNAME: Type: String Description: aws codecommit repository name STACKNAME: Type: String MailAddress: Type: String Resources: ArtifactStoreBucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub s3bucket-${AWS::AccountId}-artifactbucket CodeBuildBucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub s3bucket-${AWS::AccountId}-codebuildtbucket # ------------------------------------------------------------# # EventBridge Rule for Starting CodePipeline # ------------------------------------------------------------# PipelineEventsRule: Type: AWS::Events::Rule Properties: Name: !Sub ${ResourceName}-rule-pipeline EventBusName: !Sub "arn:aws:events:${AWS::Region}:${AWS::AccountId}:event-bus/default" EventPattern: source: - aws.codecommit resources: - !Sub arn:aws:codecommit:${AWS::Region}:${AWS::AccountId}:${REPOSITORYNAME} detail-type: - "CodeCommit Repository State Change" detail: event: - referenceCreated - referenceUpdated referenceName: - main State: ENABLED Targets: - Arn: Fn::Join: - "" - - "arn:" - Ref: AWS::Partition - ":codepipeline:" - Ref: AWS::Region - ":" - Ref: AWS::AccountId - ":" - Ref: Pipeline Id: Target RoleArn: !GetAtt PipelineEventsRole.Arn # ------------------------------------------------------------# # CodePipeline Events Role (IAM) # ------------------------------------------------------------# PipelineEventsRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: events.amazonaws.com Path: / ManagedPolicyArns: - !Ref PipelineEventsPolicy RoleName: !Sub "IRL-EVENTBRIDGE-CodePipelineAccess" # ------------------------------------------------------------# # CodePipeline Events Role Policy (IAM) # ------------------------------------------------------------# PipelineEventsPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodePipelineAccessForEvents PolicyDocument: Statement: - Action: codepipeline:StartPipelineExecution Effect: Allow Resource: - !Sub arn:aws:codepipeline:${AWS::Region}:${AWS::AccountId}:${Pipeline} Version: "2012-10-17" # ------------------------------------------------------------# # CodeBuild Role (IAM) # ------------------------------------------------------------# CodeBuildRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: codebuild.amazonaws.com Path: / ManagedPolicyArns: - !Ref CodeBuildPolicy - arn:aws:iam::aws:policy/AWSCloudFormationFullAccess RoleName: !Sub "IRL-CODEBUILD-S3CloudWatchlogsAccess" # ------------------------------------------------------------# # CodeBuild Role Policy (IAM) # ------------------------------------------------------------# CodeBuildPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodeBuildAccess PolicyDocument: Version: '2012-10-17' Statement: - Sid: CloudWatchLogsAccess Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: - !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/* - Sid: S3Access Effect: Allow Action: - s3:PutObject - s3:GetObject - s3:GetObjectVersion Resource: - !Sub arn:aws:s3:::${ArtifactStoreBucket} - !Sub arn:aws:s3:::${ArtifactStoreBucket}/* - !Sub arn:aws:s3:::${CodeBuildBucket} - !Sub arn:aws:s3:::${CodeBuildBucket}/* - Sid: IAMPass Effect: Allow Action: - iam:PassRole Resource: "*" - Sid: CloudFormationAccess Effect: Allow Action: cloudformation:ValidateTemplate Resource: "*" # ------------------------------------------------------------# # CodeBuild linter Project # ------------------------------------------------------------# CodeBuildProjectLint: Type: AWS::CodeBuild::Project Properties: Name: !Sub ${ResourceName}-project-lint ServiceRole: !GetAtt CodeBuildRole.Arn Artifacts: Type: CODEPIPELINE Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 EnvironmentVariables: - Name: AWS_REGION Value: !Ref AWS::Region - Name: S3_BUCKET Value: !Ref CodeBuildBucket Source: Type: CODEPIPELINE # ------------------------------------------------------------# # CodeBuild changeset Project # ------------------------------------------------------------# CodeBuildProjectChangeset: Type: AWS::CodeBuild::Project Properties: Name: !Sub ${ResourceName}-project-changeset ServiceRole: !GetAtt CodeBuildRole.Arn Artifacts: Type: CODEPIPELINE Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 EnvironmentVariables: - Name: AWS_REGION Value: !Ref AWS::Region - Name: S3_BUCKET Value: !Ref CodeBuildBucket - Name: STACK_NAME Value: !Ref STACKNAME - Name: CFNROLE_ARN Value: !GetAtt CloudformationRole.Arn Source: Type: CODEPIPELINE BuildSpec: changeset-buildspec.yaml # ------------------------------------------------------------# # CloudFormation Role (IAM) # ------------------------------------------------------------# CloudformationRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: cloudformation.amazonaws.com Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AdministratorAccess RoleName: "IRL-CLOUDFORMATION-ServiceFullAccess" # ------------------------------------------------------------# # CodePipeline Role (IAM) # ------------------------------------------------------------# PipelineRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: codepipeline.amazonaws.com Path: / ManagedPolicyArns: - !Ref PipelinePolicy RoleName: "IRL-CODEPIPELINE-Access" # ------------------------------------------------------------# # CodePipeline Role Policy (IAM) # ------------------------------------------------------------# PipelinePolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodePipelineAccess PolicyDocument: Version: '2012-10-17' Statement: - Sid: S3FullAccess Effect: Allow Action: s3:* Resource: - !Sub arn:aws:s3:::${ArtifactStoreBucket} - !Sub arn:aws:s3:::${ArtifactStoreBucket}/* - Sid: FullAccess Effect: Allow Action: - cloudformation:* - iam:PassRole - codecommit:GetRepository - codecommit:ListBranches - codecommit:GetUploadArchiveStatus - codecommit:UploadArchive - codecommit:CancelUploadArchive - codecommit:GetBranch - codecommit:GetCommit Resource: "*" - Sid: CodeBuildAccess Effect: Allow Action: - codebuild:BatchGetBuilds - codebuild:StartBuild Resource: !GetAtt CodeBuildProjectLint.Arn - Sid: CodeBuildChangesetAccess Effect: Allow Action: - codebuild:BatchGetBuilds - codebuild:StartBuild Resource: !GetAtt CodeBuildProjectChangeset.Arn - Sid: SNSAccess Effect: Allow Action: - sns:Publish Resource: !Sub arn:aws:sns:${AWS::Region}:${AWS::AccountId}:${ResourceName}-topic # ------------------------------------------------------------# # CodePipeline # ------------------------------------------------------------# Pipeline: Type: AWS::CodePipeline::Pipeline Properties: Name: !Sub ${ResourceName}-pipeline RoleArn: !GetAtt PipelineRole.Arn ArtifactStore: Type: S3 Location: !Ref ArtifactStoreBucket Stages: - Name: Source Actions: - Name: download-source ActionTypeId: Category: Source Owner: AWS Version: 1 Provider: CodeCommit Configuration: RepositoryName: !Ref REPOSITORYNAME BranchName: main PollForSourceChanges: false #イベントベースを採用するためfalseに変更 OutputArtifacts: - Name: SourceOutput - Name: Test Actions: - InputArtifacts: - Name: SourceOutput Name: testing ActionTypeId: Category: Test Owner: AWS Version: 1 Provider: CodeBuild Configuration: ProjectName: !Ref CodeBuildProjectLint - Name: Build Actions: - InputArtifacts: - Name: SourceOutput Name: changeset ActionTypeId: Category: Build Owner: AWS Version: 1 Provider: CodeBuild OutputArtifacts: - Name: BuildOutput Configuration: ProjectName: !Ref CodeBuildProjectChangeset Namespace: BuildVariables - Name: Approval Actions: - Name: approve-changeset ActionTypeId: Category: Approval Owner: AWS Version: 1 Provider: Manual Configuration: ExternalEntityLink: !Sub https://${AWS::Region}.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/changesets/changes?stackId=#{BuildVariables.SackId}&changeSetId=#{BuildVariables.ChangeSetId} NotificationArn: !GetAtt SNSTopic.TopicArn - Name: Deploy Actions: - Name: execute-changeset ActionTypeId: Category: Deploy Owner: AWS Version: 1 Provider: CloudFormation Configuration: StackName: !Join [ '-', [ !Ref ResourceName, 'infra-stack' ] ] ActionMode: CHANGE_SET_EXECUTE ChangeSetName: changeset RoleArn: !GetAtt CloudformationRole.Arn # ------------------------------------------------------------# # SNS # ------------------------------------------------------------# SNSTopic: Type: AWS::SNS::Topic Properties: Subscription: - Endpoint: !Ref MailAddress Protocol: email TopicName: !Sub ${ResourceName}-topic  CI/CDパイプラインの更新 上記テンプレートを使用して、CI/CDパイプラインのスタックを更新します。 CloudFormationコンソールから該当のスタック選択して、”更新”を押下してください。   修正済みのテンプレートファイルをアップデートして、”次へ”を押下してください。   既存のパラメータ等は変更することなく、”次へ”を押下してください。 “次へ”を押下してください。   最後にレビュー画面に遷移します。内容に間違いがないか確認します。 変更セットのレビューにて、IAMポリシー・IAMロール・EventBridgeルールが追加されることを確認します。またCodePipelineでは、変更があることも確認します。問題なければ”送信”を押下してください。   数分経過すると、スタックの更新が完了します。 移行の確認 移行が完了したかどうか、 こちらの手順 で再度スクリプトを実行することで確かめます。 先ほどまで存在した”cicd-20231210-pipeline”が表示されていないため、イベントベースのパイプラインとして正常に認識されています。 これにて移行完了となります。お疲れ様でした。 パイプライン起動確認 念の為、イベントベースのパイプラインが起動するか確認しておきます。 CodeCommitにプッシュすると、パイプラインが起動していることが分かります。(承認ステージを組み込んでいるため、レビュー中で一時停止しています。) また、イベントベースへの移行を勧める警告メッセージも表示されなくなっています。 ちなみに、ポーリングベースのパイプラインを利用していると、CodePipelineの対象パイプラインの画面を開くたびに以下のように警告メッセージが表示されます。 パイプラインがアクティブの場合： このパイプラインには、ポーリング用に設定されたソース（download-source）があります。変更検出用に推奨されるイベントベースのメカニズムにパイプラインを移行（更新）します。詳細については、「 移行ガイド 」を参照してください。   30日以上パイプラインを起動していない(アクティブでない)場合： ○か月前時点で、CodePipelineはこのパイプラインのポーリングを無効にしています。これは、以前30日間に実行されていないためです。推奨されるイベントベースのメカニズムを使用して、新しいパイプライン実行を開始します。 最後に いかがでしたでしょうか。 CodeCommitをソースとしたCloudFormationで構築済みのポーリングベースのCodePipelineをイベントベースへと移行しました。 既存のCodePipelineでポーリングベースを利用している方は、是非この手順に沿って移行の検討をしていただければと思います。また新規でパイプラインを構築する際は、イベントベースでパイプラインを構築するように意識してください。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

本記事は TechHarmony Advent Calendar 12/13付の記事です。 どうも、Catoクラウドを担当している佐々木です。 今回は、先日機能追加が発表された Catoクライアントの常時起動 「Always-On」の新機能 についてご紹介します。   ※画⾯は2023年12⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。   Always-Onとは SDP ユーザーのインターネットセキュリティを強化するための機能です。 「Always-On」を使用すると、CatoクライアントのON/OFFをユーザー側で制御することができなくなり、 SDPユーザーからのトラフィックが常に「Catoクラウド」を通過するようにできます。   詳細は、以下のブログ記事を参照ください。 CatoクラウドのAlways-Onを試してみた Catoクラウドで「Always-On」を試してみました。設定方法～動作検証までやってます。 blog.usize-tech.com 2023.08.28   Always-Onの新機能 2023/11/20のアップデート情報で以下3つの新機能が発表されました。 Remote Internet Security with One Time Authentication New Bypass Mode for Always-On Always-On Recovery Mode   それぞれ異なる機能になりますので、個別に説明していきます。 なお、このアップデート情報は以下で確認できます。 Catoクラウドアップデート情報（2023年11月20日） | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK □新機能と機能強化・ソケット（Socket）接続ステータスの可視性を強化　ソケット・ポートとリンクのステータスを表示するために以下の拡張を行いました。　ソケットの物理ポートと接続ステー... cato-scsk.dga.jp   2023/12/13時点で、この機能はまだ利用できません。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Remote Internet Security with One Time Authentication　⇒　EA（Early Availability）　　　　　　　　　　　　　　　New Bypass Mode for Always-On / Always-On Recovery Mode　⇒　2023/12/4から数週間後にアップデート予定　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　※EAの申し込みは当社担当者またはサービス窓口までご連絡ください。   「Remote Internet Security with One Time Authentication」について 直訳すると、「ワンタイム認証によるリモートインターネットセキュリティ」となります。   この機能は、Catoのナレッジやアップデート情報を見ても何ができるのか非常にわかりにくいのですが、 端的に言えば、 Catoとの認証の有効期限が切れた時の動作を指定できるようになります。   機能・用途 これまでの動作 Always-Onが有効な場合、これまでは以下の動作をします。 認証成功後、認証の有効期限が切れると再認証するまでインターネットアクセスやWAN通信ができません この動作は変更できません   アップデート後の動作 有効期限切れ後の動作を以下の3つから指定できるようになります。 認証の有効期限が切れると再認証するまでインターネットアクセスやWAN通信ができません（これまでと同じ） 認証の有効期限が切れてもインターネットアクセスだけ継続利用することが可能です 認証の有効期限が切れてもインターネットアクセス、WAN通信ともに利用可能です つまり、一度の認証（ワンタイム認証）で、インターネットアクセスやWAN通信が継続的に利用することができる。 といったことを実現できます。   どういう時に使うのか？ 個人的には、以下のようなシチュエーションで利用できるかと思っています。   長期休暇対策　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　長期休暇などでCatoの再認証ができなかったとしても、この機能を利用して、認証切れ後もインターネットアクセスは許可します。　これまでは再認証するまでは業務できませんでしたが、再認証前でもインターネット経由の業務は継続して可能です。　　　　　　　　　　例：メール送受信、WEB会議、TeamsやSlackなどのチャットツールなど　※お客様業務システムに依存しますが。。 ※Catoのナレッジにも利用用途が複数記載されていましたが、商習慣の違いなのかどれも正直ピンときませんでした。。   設定方法 設定箇所は大きく2つです。 Client Connectivity Policyの設定 ユーザー単位で認証中・もしくは認証切れの時にどのような動作をするか定義します。 Client Access(Authentication)の設定 再認証の間隔や有効期限切れの通知有無などを定義します。   Client Connectivity Policy の設定 CMAにログインし、 「Access」 ＞ 「Client Connectivity Policy」 を選択します。 右端の 「New」 をクリックすると、設定ウィンドウが表示されます。 以下の画面にて各設定項目を入力ください。 ※ルール名や対象ユーザーなどはこれまでの設定方法と同じため説明を割愛します。適宜任意の値を設定ください。   「Confidence Level（信頼レベル）」について ユーザーが認証している時の状態を「 Confidence Level（信頼レベル） 」として定義します。 High ：ユーザーは認証に成功しており、かつCatoトークン（認証）の有効期限は切れていない状態（通常のCato利用時）。 Low ：ユーザーは認証に成功しているが、Catoトークン（認証）の有効期限は切れている状態。 Any ：あらゆる状態（認証の状態に応じて制限をかけない場合に使用）。   「Action」について どのような動作をさせるのか定義します。   Allow WAN and Internet ：WANとインターネットアクセスを許可する。 Allow Internet ：インターネットアクセスのみを許可する。 Block ：ブロックする（Catoへの接続不可）。   Client Connectivity Policy の設定例 例：すべてのユーザーが、認証切れ後もインターネットアクセスのみ可能とする設定   注意事項 Client Connectivity Policyは、ホワイトリスト形式です。 ルールにマッチしない通信は、すべてブロックされてしまいます。 そのため、すべてのユーザーで信頼度がHigh/Lowの時の動作を設定する必要があります。 ※Low（認証切れ）の時にブロックしたい場合、Lowの設定はなくても構いません。   以下のように、すべてのユーザーで信頼度がHigh場合、インターネットアクセスもWANアクセスも許可する といったルールを最後に設定することを推奨します。   Client Access(Authentication) の設定 CMAにログインし、 「Access」 ＞ 「Client Access」 を選択します。 「Authentication」 をクリックすると、設定ウィンドウが開きます。 以下の画面にて各設定項目を入力ください。 Default Method ：認証方式を定義（MFA/SSO/User & Password） Token validity ：トークンの有効期間を定義します。1分～999日まで設定可能です。 Before token expires: Notify User ：ユーザーに有効期限の通知をするかどうか。48時間/24時間/2時間前に通知します。 After token expires: Prompt User re-authentication ：有効期限切れ後に再認証を求めるプロンプトを表示するかどうか。   設定は以上です。   Catoクライアントイメージ 本機能利用時は、Catoクライアントは以下のような表示になります。   「New Bypass Mode for Always-On」について ユーザーが理由を記載するだけでCatoをBypassすることが可能なモードが追加になりました。   機能・用途 これまでの動作 Always-Onが有効な場合、CatoクラウドをBypassするためにはワンタイムパスワード（Bypassコード）の入力が必要でした。 また、ワンタイムパスワードはCMA上でしか確認できないため、Bypassしたい場合、管理者がワンタイムパスワードを確認⇒ユーザーに共有 という手間がありました。   アップデート後の動作 Bypassの実施方法を以下から指定できるようになります。 ワンタイムパスワード方式（これまでと同じ） ユーザー自身が任意の理由をCatoクライアント上に入力するだけで、いつでもBypass可能な方式 ユーザー単位でどちらの方式を利用するか選択可能で、（一回の操作で）Bypassできる時間も設定可能です（1分～100時間）。   なお、新方式を全ユーザーに適用してしまうと、全ユーザーが常時CatoクラウドをBypass可能となります。 Catoのメリットがなくなりますので、新方式の適用は特定のユーザーに限定することを推奨します。   どういう時に使うのか？ 上述の通り、この機能を多用するとセキュリティホールになりかねないので、結構ピンポイントな使い方になると考えます。   運用管理者向け設定　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Always-Onが必須な組織にて、万が一運用管理者がAlways-Onの機能でインターネットアクセスできなくなると業務に影響が出るため、運用管理者のみ任意にBypass可能な新方式を採用する。他のユーザーはこれまで通りワンタイムパスワード方式とする。 ※何とかひねり出してます。。運用管理者だけAlways-On無効にすれば、、、というツッコミはお控えください。   設定方法 設定箇所は1つです。 Always-On Policyの設定 BypassモードとBypass可能な時間を定義します。   Always-On Policyの設定 CMAにログインし、 「Access」 ＞ 「Always-On Policy」 を選択します。 右端の 「New」 をクリックすると、設定ウィンドウが表示されます。 以下の画面にて各設定項目を入力ください。 ※ルール名や対象ユーザーなどはこれまでの設定方法と同じため説明を割愛します。適宜任意の値を設定ください。   「Bypass Mode」について Bypass Modeで以下のいずれかを選択します。 Admin passcode required to disconnect ：ワンタイムパスワード方式（これまでと同じ） User can choose to disconnect ：ユーザーが自身でBypassを選択可能な方式。 また、 Disconnect Duration でBypass可能な時間を設定できます（1分～100時間）。   設定は以上です。   クライアントイメージ 新方式でユーザーがBypassを選択すると、以下の画面が表示されます。 「緑の枠」に何でもいいので理由を記載し、EnterをクリックするとBypass可能です。   また、ユーザーがBypassしていること、記入した理由は、以下のように「event」で確認可能です。   「Always-On Recovery Mode」について 何らかの理由でCato クラウドへの接続が利用できない場合に、これまで通りインターネットアクセスを制限するか、許可するか、 選択ができるようになります。   機能・用途 これまでの動作 何らかの理由でCatoとのトンネルが構築できない場合、Always-Onの制限でインターネットアクセスができなくなります。   アップデート後の動作 上記のような場合の動作を以下から指定できるようになります。 インターネットアクセス不可 インターネットアクセス可   Always-On Recovery Modeの発動条件 クライアントがどの PoP へのトンネルも確⽴できない場合に発動します。 例） ネットワーク接続なし (ホストが接続されていない / ルータのダウン) インターネット接続無し (ISP障害) Captive Portalが検出されない ネットワークルールが必要な通信をブロックしてしまう   どういう時に使うのか？ 先に紹介したBypassモードと二者択一になるかと思っています。   運用管理者向け設定　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Always-Onが必須な組織にて、万が一運用管理者がAlways-Onの機能でインターネットアクセスできなくなると業務に影響が出るため、運用管理者のみRecovery Modeでインターネットアクセス可にする。   設定方法 設定箇所は1つです。 Always-On Policyの設定 Recovery Modeの動作を定義します。   Always-On Policyの設定 CMAにログインし、 「Access」 ＞ 「Always-On Policy」 を選択します。 右端の 「New」 をクリックすると、設定ウィンドウが表示されます。 以下の画面にて各設定項目を入力ください。 ※ルール名や対象ユーザーなどはこれまでの設定方法と同じため説明を割愛します。適宜任意の値を設定ください。   「Recovery Mode」について Recovery Modeで以下のいずれかを選択します。 Restrict Internet access ：インターネットアクセス不可（これまでと同じ） Allow internet ：インターネットアクセス可。   設定は以上です。   クライアントイメージ Recovery Modeが動作していると以下のような表示がでます。     アップデートに伴う注意事項 機能アップデートにあたり、既存の設定に影響を及ぼさないか気になる方もいらっしゃると思います。   本アップデートで新しい設定項目が追加されるため、既存設定にも自動的に新しいパラメータが適用されますが、 今の動作と同じ設定が適用されるため、通信に影響は出ません。   ただし、「Remote Internet Security with One Time Authentication」の注意事項でも記載したように、 「Client Connectivity Policy」設定が現在有効になっている方は、 一番最後に「すべてのアクセスを許可する」ルールの設定をお忘れなきようご注意ください。   まとめ ここまでAlways-On機能アップデート情報の紹介をしてきましたが、個人的に今回のアップデートのポイントは以下だと思っています。   今まで仕様だった動作が、ユーザーのやりたいようにカスタマイズできるようになったこと   これまで通りの動作を希望される方は、特に設定を変えず今まで通りの利用で問題ありませんし、 「こうしたい！」がある方は、このアップデート機能を活用してぜひチューニングをご検討いただければと思います。   上記以外のアップデート情報についても弊社の 「Catoに関するFAQサイト」 に多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp   最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！

はじめに こんにちは。SCSKのふくちーぬです。 前回・前々回の記事では、CI/CD配下でネストされた AWS CloudFormation スタックに対してパイプラインを構築してきました。こちらの記事を読んでいない方は、是非ご一読していただけると幸いです。 CI/CD配下でネストされたスタックの子スタックに対して、変更セットを有効にするテクニック[AWS CodePipeline＋AWS CloudFormation] CI/CD 配下のネストされた AWS CloudFormation スタックに対して変更セットを有効化する方法を紹介します。 blog.usize-tech.com 2023.12.07 CI/CD配下のネストされたスタックを利用しているパイプラインに承認プロセスを組み込む[AWS CodePipeline＋AWS CloudFormation] CI/CD配下のネストされたスタックに対して、変更セットが妥当なものか判断するための承認フローをパイプラインに追加します。 blog.usize-tech.com 2023.12.11 今回は、ネストされたスタックのスタック間の依存関係起因による変更セットの挙動を検証したので整理します。 構成図 前回から、サンプルスタック内にEC2が追加されています。   CI/CDパイプラインの構成 前回作成したスタックを更新します。スタックを作成していない方は、新規にスタックを作成してください。 Cloud9及びCodeCommitのディレクトリ構成について ディレクトリ構成は前回から、”ec2.yaml”が追加されました。ファイルの中身は、子スタックとしてEC2を記述したものとなります。 以下のファイルに対して更新があります。 -param.json -cfn.yaml -ec2.yaml param.json インスタンススタックで使用する、AMIIdを追加しています。 [ { "ParameterKey": "Environment", "ParameterValue": "dev" }, { "ParameterKey": "VPCCidrBlock", "ParameterValue": "192.168.0.0/16" }, { "ParameterKey": "AMIId", "ParameterValue": "ami-012261b9035f8f938" } ]  cfn.yaml 親スタックでは、インスタンススタックの内容を追記しています。ポイントとして、他の子スタックからサブネットID及びセキュリティグループIDを参照しています。 AWSTemplateFormatVersion: 2010-09-09 Description: Parent Stack Parameters: Environment: Type: String VPCCidrBlock: Type: String AMIId: Type: String Resources: # ------------------------------------------------------------# # Network Stack (VPC Subnet RouteTable InternetGateway) # ------------------------------------------------------------# NW: Type: AWS::CloudFormation::Stack Properties: TemplateURL: src/network.yaml Parameters: Environment: !Ref Environment VPCCidrBlock: !Ref VPCCidrBlock # ------------------------------------------------------------# # Security Stack (SecurityGroup) # ------------------------------------------------------------# SECURITY: Type: AWS::CloudFormation::Stack Properties: TemplateURL: src/securitygroup.yaml Parameters: Environment: !Ref Environment VpcId: !GetAtt NW.Outputs.VpcId # ------------------------------------------------------------# # Instance Stack (EC2) # ------------------------------------------------------------# INSTANCE: Type: AWS::CloudFormation::Stack Properties: TemplateURL: src/ec2.yaml Parameters: Environment: !Ref Environment AMIId: !Ref AMIId SubnetId: !GetAtt NW.Outputs.SubnetId SGId: !GetAtt SECURITY.Outputs.SGId  ec2.yaml ここでは、EC2を1台作成する記述がされています。 AWSTemplateFormatVersion: 2010-09-09 Description: EC2 Stack Parameters: Environment: Type: String AMIId: Type: String SubnetId: Type: AWS::EC2::Subnet::Id SGId: Type: AWS::EC2::SecurityGroup::Id # ------------------------------------------------------------# # EC2 # ------------------------------------------------------------# Resources: EC2Instance: Type: AWS::EC2::Instance Properties: ImageId: !Ref AMIId InstanceType: t2.micro SubnetId: !Ref SubnetId SecurityGroupIds: - !Ref SGId  CodeCommitへのプッシュ 更新済みの以下のファイルをCodeCommitにプッシュします。 -param.json -cfn.yaml -ec2.yaml EC2の作成 承認ステージにて、変更セットの内容を確認します。インスタンススタックが追加されて、EC2が新規作成されることが分かります。 問題なければ、”承認します”を押下してデプロイしてください。 セキュリティグループの更新 ここから本題です。依存関係による変更セットの挙動を検証するために、セキュリティグループを更新してみます。 今回は、以下のようにインバウンドルールを更新します。 AWSTemplateFormatVersion: 2010-09-09 Description: Security Group Stack Parameters: Environment: Type: String VpcId: Type: AWS::EC2::VPC::Id Resources: # ------------------------------------------------------------# # SecurityGroup # ------------------------------------------------------------# SG: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Enable ssh and web access VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 192.168.0.0/26 #変更 - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 192.168.0.0/26 #変更 Tags: - Key: Name Value: !Sub ${Environment}-sg Outputs: SGId: Value: !Ref SG 更新済みの”securitygroup.yaml”をCodeCommitにプッシュしてください。 変更セットの確認 数分待つと承認ステージまで進んでいるので、通知されたメールから変更セットを確認してください。 親スタックの変更セットの確認 親スタックの変更セットを確認してみると、”INSTANCE”,”SECURITY”に更新があります。セキュリティグループのみ変更しているはずが、セキュリティスタックに加えてインスタンススタックも更新されるように判断してしまいますね。 子スタックの変更セットの確認（INSTANCE） 子スタックの変更セットの中身を確認します。やはり、EC2の更新（置き換えまで）が発生しそうです。 子スタックの変更セットの確認（SECURITY） こちらは意図した挙動になっていますね。セキュリティグループが更新されることが分かります。 承認とデプロイ 上記の変更セットの中身を確認したら、”承認します”を押下してデプロイしてください。 デプロイが完了しました。 スタックの挙動の確認(INSTANCE) 子スタックのイベントをみてみます。ここでリソースの作成・更新・削除の順序を確認することができます。 どうやら子スタック(INSTANCE)全体の更新はされているようですが、論理IDであるEC2Instanceの更新はされていないですね ➡EC2に対しての更新はされていないことが明らかになりました。 EC2の置き換え等発生していないことが分かって、安心しましたね！ スタックの挙動の確認(SECURITY) 上記と同様に確認します。論理IDであるSGの更新がされていて、子スタック(SECURITY)全体の更新もされたことが分かります。 ➡セキュリティグループに対して更新されたことが明らかになりました。 まとめ 今回の検証で、子スタック間で依存関係がある際に、変更されていない子スタックの変更セットにおいて誤検知が発生していることが判明しました。 以下の注意点を理解した上で、ネストされたスタックを利用する必要があります。下記の理由としては、!GetAtt等で取得する値については変更セットの作成時点では、変更の有無を判断できない仕様によるものとなります。すなわち変更の有無は、変更セットの実行（デプロイ）時に決定されるということですね。 現状CloudFormationでは、 ネストされたスタックにおいて、Outputs等にて依存関係がある場合、参照先の子スタックにて差分が表示される可能性があります。   Nested Stack Change Set Evaluation · Issue #142 · aws-cloudformation/cloudformation-coverage-roadmap Duplicate of posted Mar 30, 2016. The current behavior of evaluating a change set on the "root" stack is that all nested ... github.com   Nested ChangeSets w/ !Ref or !GetAtt · Issue #759 · aws-cloudformation/cloudformation-coverage-roadmap Nested ChangeSets w/ !Ref or !GetAtt Originally posted by @herbertmuraro in #142 (comment) While using --include-nested-stacks option, when parameters of a nest... github.com 最後に いかがだったでしょうか。 CI/CD配下のネストされたスタックに対して、変更セットの挙動を検証してみました。ネストされたスタックを利用する際に依存関係が複雑な場合、適切な差分を把握することができず、デプロイに少々不安が残る結果になりました。 特にネストされたスタックを利用する場合は、子スタックを分割しすぎないことで子スタック間の依存関係を減らすことが可能なことを念頭においていただければと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

本記事は TechHarmony Advent Calendar 12/12付の記事です。 昨日に引き続き、Catoクラウドについてです。どうぞお付き合いください。 現在稼働中のWANをCatoクラウドに移行しようとしたとき、どのような点に考慮が必要でしょうか。またどういった順序で進めるべきでしょうか。 今年もいくつかの移行をご支援した振り返りとして、移行の進め方の例をご紹介します。 一般的な閉域網WAN構成と移行後イメージ 現状のWAN構成として、以下のような構成で運用されている例は多いかと存じます。 拠点を閉域WANサービスで接続 データセンタに社内システムを集約 インターネット向けの通信は、データセンタに設定したセキュリティアプライアンスを通って、データセンタのインターネット回線から出ていく データセンタにリモートアクセスシステムを設置し、社外から社内のシステムへアクセスする データセンタまたは閉域WANから、SaaSやパブリッククラウドへのアクセス経路がある このWAN構成のイメージが下図の左側、これをCatoクラウドに移行した場合の例が右側です。 データセンタでのボトルネックを解消し、セキュリティアプライアンスをCatoクラウドのセキュリティ機能に置き換え、シンプル化するイメージです。 移行フェーズの例 では、Catoクラウドの移行はどのように取り組んでいけばよいのでしょうか。おおよその流れは以下です。 現状構成の調査 移行要件の整理 移行設計 移行の実施 それぞれのフェーズでの実施内容をご紹介します。 1. 現状構成の調査 ネットワークを切り替えるにあたり、まずは現状の構成がどうなっているかを整理する必要があります。 具体的には、以下のような情報を確認し、最新化します。 ネットワーク全体のIPアドレス設計 通信フロー ルーティング設計 (使用しているルーティングプロトコル、拠点間通信の制限有無、例外ルールの有無等) データセンター内の物理・論理構成、回線情報 各拠点の物理・論理構成、回線情報 リモートアクセスシステムの利用者数、アクセス制限 これらの情報に 不明瞭な箇所があると、移行時に考慮漏れが起こってしまう ことがあるため、情報が最新でない場合には、稼働中の機器のConfig確認や現地の調査を行います。 2. 移行要件の整理 Catoクラウドへの移行にあたり、支障となる点や、特別な考慮が必要な点がないかを検討します。 多くの場合は、これらを確認するためにPoCを実施します。 また、あわせて移行後の構成を検討します。 移行要件の確認ポイント フェーズ1で調査した現状の構成情報を用いて、以下のような点を確認していきます。 IPアドレス体系はそのまま移行できるか。 拠点間での重複や、Catoの管理アドレス(10.254.254.0/24)の利用がないか。 ※あった場合移行設計時に考慮が必要になるため リモートアクセスをCatoに移行できるか。現状のリモートアクセス装置でないと実現できない、固有の通信要件がないか。 拠点間通信・Internet向け通信において特殊な経路・要件がないか。 外部向けの公開サーバなど、Internetから内部向けの通信があるか。ある場合、その通信の宛先となるグローバルIPアドレスは変更が可能か。 ※Catoに移行するとグローバルIPアドレスが変更されるため 現行のセキュリティアプライアンスとCatoセキュリティ機能を比較し、対応できない機能がないか。あった場合にはその機能の必要性や代替手段を検討する。 移行後構成の検討ポイント 同じく、現状の構成情報をもとに、移行後の構成を検討していきます。 各拠点のCatoクラウドへの接続を冗長化するか、シングル構成とするか。 各拠点の接続帯域の検討。 各拠点で利用する回線の選定、手配。 ※申込みから開通まで2～3ヶ月かかるため早めの手配が必要です モバイル接続ユーザ数の検討。 モバイル接続ユーザの登録・認証方法・接続制限の検討。 パブリッククラウド(AWS/Azure/GCP等)がある場合、Catoクラウドへの接続方法の検討。 拠点間通信の見直しについて なお、閉域ネットワークからCatoクラウドへの移行は、境界型防御からゼロトラストモデルへの移行でもあり、セキュリティ環境を見直す絶好の機会です。 境界型防御は社内ネットワーク=安全とするモデルのため、拠点間の通信に制限をかけていない場合が多いですが、ゼロトラストにおいてはすべての通信を信頼せず、許可すべき通信のみを許可することが推奨されます。 Catoクラウドでは「WAN Firewall」機能にて、拠点間やユーザ間、またユーザと拠点間の通信の制御を簡単に実現できます。また、ルール内で、アプリケーションやサービスの指定や、OS等デバイス条件の指定も可能ですので、許可すべき通信だけを細かに指定して許可し、ネットワーク内のセキュリティを高めることが可能です。 このフェーズにて、ネットワーク内通信の厳格化を検討することをおすすめしております。 WAN Firewallの機能については、以下の記事もご参照ください。 CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 3. 移行設計 移行後の構成が描けましたら、続いて実際の移行方法を考えていきます。 移行Stepの検討 多くの場合、全拠点の一斉移行は難しく、各拠点の都合にあわせて順次移行していくことになります。 順次移行は、データセンター等、主要なシステムがある拠点にまずCato Socketを設置し、その拠点を中継してCatoクラウドと既存網の間を相互通信させることにより実現します。 以下は移行Stepの一例です。 Step0 主要なシステムのある拠点(データセンタ等)にCato Socketを設置し、限定したユーザで導入テストを行う。 ※このStep0をPoCとして実施する場合が多いです Step1 リモートユーザの接続をCatoクラウドに切り替える。  Step2 パイロット拠点をCatoクラウドに切り替える。 Step3 各拠点を順次Catoクラウドに切り替えていく。 Step4 パブリッククラウド(AWS/Azure等)をCatoクラウド経由の接続に変更する。 ※Catoへ切り替え済みの拠点/ユーザとの通信効率を重視する場合には、より早い段階で移行します Step5 不要となった回線・機器を廃止する。 既存網とCatoクラウドのルーティング方法 前述のとおり、拠点の順次移行を行うには、中継拠点を設け、既存網とCatoクラウドを相互ルーティングさせる必要があります。 移行中のルーティングをどのように制御するかは移行前の構成によりますが、随時手動でルートを設定するか、ダイナミックルーティングで制御するかのどちらかとなります。 CatoクラウドはルーティングプロトコルとしてBGPのみに対応しております。このため中継拠点のルータ・L3SW等がBGPに対応していれば、既存網とCatoクラウド間のルーティングを動的に制御することが可能です。 以下は移行時のルーティングの例です。BGPが利用できる場合には、移行時の手間を減らすために、この方法がおすすめです。 前提として、既存網のネットワークがダイナミックルーティング(図の例はOSPF)で制御されている データセンター内のL3SWにてOSPFとBGP間のルート再配布を行い、既存網とCatoクラウド間で経路交換する 拠点が既存網を外れ、Catoクラウドへ接続されると、自動でCatoクラウド側から経路広報される なお、この方法がとれない場合(BGP対応機器がない、元々ダイナミックルーティングをしていない等)には、拠点を移行するたびに手動でルートを変更する必要があります。 移行手順の作成 移行Stepを決めた後、続いて各Stepの移行作業の詳細を詰めていきます。特にStep3の拠点移行については、現状構成の調査や移行要件の整理であきらかになった情報に注意し、移行手順を作成します。 切り替え時の作業項目、障害試験内容、正常性確認項目等を作成し、実施日程を調整します。 4. 移行の実施 Catoクラウドの機能設定 移行を開始する前に、Catoクラウドの各種機能を移行要件に沿って設定し、ユーザが本番利用して問題ない状況にしておきます。 また、忘れがちな事前作業として、端末へのルート認証局証明書の導入があります。拠点に据え置きのデスクトップ端末やサーバなど、Catoクライアントを導入しない端末には、Catoのルート認証局証明書の導入が必要です。詳細は下記の記事もご参照ください。 CatoクラウドのTLS Inspection機能で躓く証明書の仕組み Cato クラウドでHTTPS通信のセキュリティ対策を行うためのTLS Inspection機能で躓くことの多いTLS証明書関連の仕組みや課題について解説します。 blog.usize-tech.com 2023.10.06 移行の実施 準備ができましたら、計画に沿って、実際にStepごとの移行を実施していきます。 最後に Catoクラウドへの移行について、駆け足でご説明しました。あらためて流れを振り返りますと、以下のようなフェーズです。記事ではご説明しきれない内容も多いのですが、概要として参考にしていただけますと幸いです。 現状構成の調査 移行要件の整理 移行設計 移行の実施 SCSKでは、各フェーズにてお客様のご要望に合わせた移行ご支援を行っております。1～4すべてをお任せいただくことも可能ですし、1～3のみご支援し、4の移行作業はお客様にて実施される例もございます。 移行にかかる期間は、拠点数や構成の複雑さに左右されますが、 フェーズ1～3を3ヶ月間 で実施させていただくことが多いです。フェーズ4の期間は、拠点数やスケジュールによりまちまちです。 Catoクラウドはもちろん、ネットワーク・インフラ全般に精通したエンジニアが、お客様ネットワーク構成にあわせた最適な移行をご支援します。ぜひご相談ください。

はじめに こんにちは。SCSKのふくちーぬです。 前回の記事では、CI/CD配下でネストされた AWS CloudFormation スタックの子スタックに対して、変更セットを有効にするテクニックを紹介しました。こちらの記事を読んでいない方は、まずご一読いただけますとより内容理解が進むと思います。 CI/CD配下でネストされたスタックの子スタックに対して、変更セットを有効にするテクニック[AWS CodePipeline＋AWS CloudFormation] CI/CD 配下のネストされた AWS CloudFormation スタックに対して変更セットを有効化する方法を紹介します。 blog.usize-tech.com 2023.12.07 今回は、変更セットが妥当なものか判断するための承認フローをパイプラインに追加してみます。 構成図 前回から、パイプライン内の承認ステージの追加とメール送信用のSNSが追加されています。 CI/CDパイプラインの構成 前回作成したスタックを更新します。スタックを作成していない方は、新規にスタックを作成してください。 Cloud9及びCodeCommitのディレクトリ構成について ディレクトリ構成は前回と同様です。”cicd.yaml”と”changeset-buildspec.yaml”のみファイルの更新があります。 changeset-buildspec.yaml 環境変数として”expoted-variables”を追加しています。これらの環境変数をエクスポートすることで、承認ステージで利用できます。 CodeBuild のビルド仕様に関するリファレンス - AWS CodeBuild AWS CodeBuild でのビルドの仕様 (buildspec) ファイルに関するリファレンス情報を提供します。 docs.aws.amazon.com   ここでは、スタックIDと変更セットIDを参照できるようエクスポートしています。 version: 0.2 env: exported-variables: #変数のエクスポート - SackId - ChangeSetId phases: install: commands: build: commands: - | [ -d .cfn ] || mkdir .cfn aws cloudformation package \ --template-file cfn.yaml \ --s3-bucket $S3_BUCKET \ --output-template-file .cfn/packaged.yaml post_build: commands: - pwd - | #変数の設定 stack_name=$STACK_NAME change_set_name="changeset" template_body="file://.cfn/packaged.yaml" parameters="file://params/param.json" capabilities="CAPABILITY_NAMED_IAM" role_arn=$CFNROLE_ARN #スタックが存在するか確認する関数 function stack_exists() { aws cloudformation describe-stacks --stack-name "$1" 2>&1 1>/dev/null | grep -e "ValidationError" > /dev/null #|| aws cloudformation describe-stacks --stack-name "$1" | grep -e "REVIEW_IN_PROGRESS" > /dev/null } #スタックがレビュー中か確認する関数 function stack_reviewin() { aws cloudformation describe-stacks --stack-name "$1" | grep -e "REVIEW_IN_PROGRESS" } #変更セットが存在するか確認する関数 function changeset_exists() { local stack_name="$1" local change_set_name="$2" aws cloudformation describe-change-set --stack-name "$stack_name" --change-set-name "$change_set_name" 2>&1 1>/dev/null | grep -e "ChangeSetNotFound" > /dev/null } #変更セットを削除する関数 function delete_changeset() { local stack_name="$1" local change_set_name="$2" aws cloudformation delete-change-set --stack-name "$stack_name" --change-set-name "$change_set_name" sleep 3 #既存の変更セットが削除されるまで待つ } #変更セットを作成する関数 function create_changeset() { local stack_name="$1" local change_set_name="$2" local template_body="$3" local parameters="$4" local capabilities="$5" local change_set_type="$6" local role_arn="$7" aws cloudformation create-change-set \ --stack-name "$stack_name" \ --change-set-name "$change_set_name" \ --template-body "$template_body" \ --parameters "$parameters" \ --capabilities "$capabilities" \ --change-set-type "$change_set_type" \ --role-arn "$role_arn" \ --include-nested-stacks > output.json } #メイン if stack_exists "$stack_name"; then #0の場合 echo "Stack doesn't exist. Creating new changeset." # if changeset_exists "$stack_name" "$change_set_name"; then # echo "Changeset exists. Deleting the changeset." # fi create_changeset "$stack_name" "$change_set_name" "$template_body" "$parameters" "$capabilities" "CREATE" "$role_arn" else #1の場合 echo "Stack exists." if changeset_exists "$stack_name" "$change_set_name"; then #0の場合 echo "Changeset doesn't exist. Creating new changeset." else #1の場合 echo "Changeset exists. Creating new changeset." delete_changeset "$stack_name" "$change_set_name" fi if stack_reviewin "$stack_name"; then #0の場合 echo "Stack review_in_progress." create_changeset "$stack_name" "$change_set_name" "$template_body" "$parameters" "$capabilities" "CREATE" "$role_arn" else create_changeset "$stack_name" "$change_set_name" "$template_body" "$parameters" "$capabilities" "UPDATE" "$role_arn" fi fi - SackId=`cat output.json | jq .StackId | sed 's/"//g'` #変数の代入 - ChangeSetId=`cat output.json | jq .Id | sed 's/"//g'` #変数の代入 artifacts: files: - .cfn/* - params/* discard-paths: yes cicd.yaml 以下3つを追加しています。 メール送信用のSNSトピックの追加 CodePipelineのIAMロールにSNSトピック発行の権限を追加 CodePipelineのパイプラインに承認ステージを追加 CodePipeline で承認アクションを管理する - AWS CodePipeline CodePipelineステージでマニュアルの承認リクエストおよび Amazon SNS 通知を作成し、管理する方法について説明します。 docs.aws.amazon.com 変数の受け渡し 重要な点を少し嚙み砕いて説明します。名前空間である”Namespace”を指定することで、ビルドステージにてエクスポートした変数（ここでは”SackId”・”ChangeSetId”を指す。）を後続のステージへ渡すことが可能になります。 可変 - AWS CodePipeline パイプラインアクションにおける変数と名前空間のリファレンス。 docs.aws.amazon.com - Name: Build Actions: - InputArtifacts: - Name: SourceOutput Name: changeset ActionTypeId: Category: Build Owner: AWS Version: 1 Provider: CodeBuild OutputArtifacts: - Name: BuildOutput Configuration: ProjectName: !Ref CodeBuildProjectChangeset Namespace: BuildVariables  レビュー用URLの作成 承認ステージの”ExternalEntityLink”にて、任意のレビュー用URLを指定することができます。 CodePipeline でパイプラインに手動の承認アクションを追加する - AWS CodePipeline 認証アクションまたは承認リクエストを CodePipeline パイプラインに追加する方法について説明します。 docs.aws.amazon.com 変更セットのURLには規則性があるので、それを変数と組み合わせることで動的にリンクを作成することができます。  https://【リージョン】.console.aws.amazon.com/cloudformation/home?region=【リージョン】#/stacks/changesets/changes?stackId=【スタックID】&changeSetId=【変更セットID】 ここでは以下を設定することで、変更セットを確認できるURLを動的に作成します。 - Name: Approval #承認ステージの追加 Actions: - Name: approve-changeset ActionTypeId: Category: Approval Owner: AWS Version: 1 Provider: Manual Configuration: ExternalEntityLink: !Sub https://${AWS::Region}.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/changesets/changes?stackId=#{BuildVariables.SackId}&changeSetId=#{BuildVariables.ChangeSetId} NotificationArn: !GetAtt SNSTopic.TopicArn  完成したcicd.yaml AWSTemplateFormatVersion: 2010-09-09 Description: cfn CI/CD Pipeline Parameters: ResourceName: Type: String REPOSITORYNAME: Type: String Description: aws codecommit repository name STACKNAME: Type: String MailAddress: Type: String Resources: ArtifactStoreBucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub s3bucket-${AWS::AccountId}-artifactbucket CodeBuildBucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub s3bucket-${AWS::AccountId}-codebuildtbucket # ------------------------------------------------------------# # EventBridge Rule for Starting CodePipeline # ------------------------------------------------------------# PipelineEventsRule: Type: AWS::Events::Rule Properties: Name: !Sub ${ResourceName}-rule-pipeline EventBusName: !Sub "arn:aws:events:${AWS::Region}:${AWS::AccountId}:event-bus/default" EventPattern: source: - aws.codecommit resources: - !Sub arn:aws:codecommit:${AWS::Region}:${AWS::AccountId}:${REPOSITORYNAME} detail-type: - "CodeCommit Repository State Change" detail: event: - referenceCreated - referenceUpdated referenceName: - main State: ENABLED Targets: - Arn: Fn::Join: - "" - - "arn:" - Ref: AWS::Partition - ":codepipeline:" - Ref: AWS::Region - ":" - Ref: AWS::AccountId - ":" - Ref: Pipeline Id: Target RoleArn: !GetAtt PipelineEventsRole.Arn DependsOn: - PipelineEventsRole - Pipeline # ------------------------------------------------------------# # CodePipeline Events Role (IAM) # ------------------------------------------------------------# PipelineEventsRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: events.amazonaws.com Path: / ManagedPolicyArns: - !Ref PipelineEventsPolicy RoleName: !Sub "IRL-EVENTBRIDGE-CodePipelineAccess" # ------------------------------------------------------------# # CodePipeline Events Role Policy (IAM) # ------------------------------------------------------------# PipelineEventsPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodePipelineAccessForEvents PolicyDocument: Statement: - Action: codepipeline:StartPipelineExecution Effect: Allow Resource: - !Sub arn:aws:codepipeline:${AWS::Region}:${AWS::AccountId}:${Pipeline} Version: "2012-10-17" # ------------------------------------------------------------# # CodeBuild Role (IAM) # ------------------------------------------------------------# CodeBuildRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: codebuild.amazonaws.com Path: / ManagedPolicyArns: - !Ref CodeBuildPolicy - arn:aws:iam::aws:policy/AWSCloudFormationFullAccess RoleName: !Sub "IRL-CODEBUILD-S3CloudWatchlogsAccess" # ------------------------------------------------------------# # CodeBuild Role Policy (IAM) # ------------------------------------------------------------# CodeBuildPolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodeBuildAccess PolicyDocument: Version: '2012-10-17' Statement: - Sid: CloudWatchLogsAccess Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: - !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/* - Sid: S3Access Effect: Allow Action: - s3:PutObject - s3:GetObject - s3:GetObjectVersion Resource: - !Sub arn:aws:s3:::${ArtifactStoreBucket} - !Sub arn:aws:s3:::${ArtifactStoreBucket}/* - !Sub arn:aws:s3:::${CodeBuildBucket} - !Sub arn:aws:s3:::${CodeBuildBucket}/* - Sid: IAMPass Effect: Allow Action: - iam:PassRole Resource: "*" - Sid: CloudFormationAccess Effect: Allow Action: cloudformation:ValidateTemplate Resource: "*" # ------------------------------------------------------------# # CodeBuild linter Project # ------------------------------------------------------------# CodeBuildProjectLint: Type: AWS::CodeBuild::Project Properties: Name: !Sub ${ResourceName}-project-lint ServiceRole: !GetAtt CodeBuildRole.Arn Artifacts: Type: CODEPIPELINE Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 EnvironmentVariables: - Name: AWS_REGION Value: !Ref AWS::Region - Name: S3_BUCKET Value: !Ref CodeBuildBucket Source: Type: CODEPIPELINE # ------------------------------------------------------------# # CodeBuild changeset Project # ------------------------------------------------------------# CodeBuildProjectChangeset: Type: AWS::CodeBuild::Project Properties: Name: !Sub ${ResourceName}-project-changeset ServiceRole: !GetAtt CodeBuildRole.Arn Artifacts: Type: CODEPIPELINE Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 EnvironmentVariables: - Name: AWS_REGION Value: !Ref AWS::Region - Name: S3_BUCKET Value: !Ref CodeBuildBucket - Name: STACK_NAME Value: !Ref STACKNAME - Name: CFNROLE_ARN Value: !GetAtt CloudformationRole.Arn Source: Type: CODEPIPELINE BuildSpec: changeset-buildspec.yaml # ------------------------------------------------------------# # CloudFormation Role (IAM) # ------------------------------------------------------------# CloudformationRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: cloudformation.amazonaws.com Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AdministratorAccess RoleName: "IRL-CLOUDFORMATION-ServiceFullAccess" # ------------------------------------------------------------# # CodePipeline Role (IAM) # ------------------------------------------------------------# PipelineRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: sts:AssumeRole Effect: Allow Principal: Service: codepipeline.amazonaws.com Path: / ManagedPolicyArns: - !Ref PipelinePolicy RoleName: "IRL-CODEPIPELINE-Access" # ------------------------------------------------------------# # CodePipeline Role Policy (IAM) # ------------------------------------------------------------# PipelinePolicy: Type: AWS::IAM::ManagedPolicy Properties: ManagedPolicyName: CodePipelineAccess PolicyDocument: Version: '2012-10-17' Statement: - Sid: S3FullAccess Effect: Allow Action: s3:* Resource: - !Sub arn:aws:s3:::${ArtifactStoreBucket} - !Sub arn:aws:s3:::${ArtifactStoreBucket}/* - Sid: FullAccess Effect: Allow Action: - cloudformation:* - iam:PassRole - codecommit:GetRepository - codecommit:ListBranches - codecommit:GetUploadArchiveStatus - codecommit:UploadArchive - codecommit:CancelUploadArchive - codecommit:GetBranch - codecommit:GetCommit Resource: "*" - Sid: CodeBuildAccess Effect: Allow Action: - codebuild:BatchGetBuilds - codebuild:StartBuild Resource: !GetAtt CodeBuildProjectLint.Arn - Sid: CodeBuildChangesetAccess Effect: Allow Action: - codebuild:BatchGetBuilds - codebuild:StartBuild Resource: !GetAtt CodeBuildProjectChangeset.Arn - Sid: SNSAccess #SNSトピック発行の権限を追加 Effect: Allow Action: - sns:Publish Resource: !Sub arn:aws:sns:${AWS::Region}:${AWS::AccountId}:${ResourceName}-topic # ------------------------------------------------------------# # CodePipeline # ------------------------------------------------------------# Pipeline: Type: AWS::CodePipeline::Pipeline Properties: Name: !Sub ${ResourceName}-pipeline RoleArn: !GetAtt PipelineRole.Arn ArtifactStore: Type: S3 Location: !Ref ArtifactStoreBucket Stages: - Name: Source Actions: - Name: download-source ActionTypeId: Category: Source Owner: AWS Version: 1 Provider: CodeCommit Configuration: RepositoryName: !Ref REPOSITORYNAME BranchName: main PollForSourceChanges: false OutputArtifacts: - Name: SourceOutput - Name: Test Actions: - InputArtifacts: - Name: SourceOutput Name: testing ActionTypeId: Category: Test Owner: AWS Version: 1 Provider: CodeBuild Configuration: ProjectName: !Ref CodeBuildProjectLint - Name: Build Actions: - InputArtifacts: - Name: SourceOutput Name: changeset ActionTypeId: Category: Build Owner: AWS Version: 1 Provider: CodeBuild OutputArtifacts: - Name: BuildOutput Configuration: ProjectName: !Ref CodeBuildProjectChangeset Namespace: BuildVariables - Name: Approval #承認ステージの追加 Actions: - Name: approve-changeset ActionTypeId: Category: Approval Owner: AWS Version: 1 Provider: Manual Configuration: ExternalEntityLink: !Sub https://${AWS::Region}.console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/changesets/changes?stackId=#{BuildVariables.SackId}&changeSetId=#{BuildVariables.ChangeSetId} NotificationArn: !GetAtt SNSTopic.TopicArn - Name: Deploy Actions: - Name: execute-changeset ActionTypeId: Category: Deploy Owner: AWS Version: 1 Provider: CloudFormation Configuration: StackName: !Join [ '-', [ !Ref ResourceName, 'infra-stack' ] ] ActionMode: CHANGE_SET_EXECUTE ChangeSetName: changeset RoleArn: !GetAtt CloudformationRole.Arn # ------------------------------------------------------------# # SNS # ------------------------------------------------------------# SNSTopic: Type: AWS::SNS::Topic Properties: Subscription: - Endpoint: !Ref MailAddress Protocol: email TopicName: !Sub ${ResourceName}-topic   ポイント CodeBuild内で環境変数をエクスポートして、次のステージに渡すよう設定する 承認ステージのレビュー用URLにて、スタックID及び変更セットIDを使用するようURLを動的に設定する CI/CDパイプラインの更新 更新した”cicd.yaml”ファイルを利用して、パイプラインを構成したスタックを更新してください。 サブスクリプションの確認 その後、指定したメールアドレスに届くSNSのサブスクリプションを許可してください。 E メール通知 - Amazon Simple Notification Service Amazon SNS で E メール通知を送信します。 docs.aws.amazon.com サブスクリプションの確認が完了しました。 CodeCommitへのプッシュ ここでは、更新済みの”changeset-buildspec.yaml”と”securitygroup.yaml”をCodeCommitにプッシュします。”securitygroup.yaml”では、前回同様にソースアドレスの変更等実施してください。 パイプラインが起動して、承認ステージまで進んでいます。 通知の確認 承認プロセスを挟んでいるため、指定のメールアドレスに以下のようなメッセージが届いています。 “Content to review”を押下すると、変更セットの画面に飛びます。 “Approve or reject”を押下すると、パイプラインの承認画面に飛びます。 “Approve or reject”を押下してみてください。 変更セットの確認とレビュー 承認ステージ内の”レビュー”を押下してください。以下のような画面になります。 “レビュー用URL”を押下すると、変更セットの内容を確認することができます。今回は、セキュリティグループが変更されることが明らかですね。 先ほどの画面に戻ってください。 変更セットの内容に問題ないため、コメントを記載の上”承認します”を押下して、システムをリリースします。   デプロイできましたね！ちょー気持ちいい まとめ いかがだったでしょうか。 CI/CD配下のネストされたスタックに対して、承認用のレビュー用URLを組み込んでみました。 CodePipelineに承認プロセスを取り入れることで、品質を担保したデプロイが可能になり思わぬ事故を防ぐことができます。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

本記事は TechHarmony Advent Calendar 12/11付の記事です。 TechHarmony Advent Calendar 2023 の 11日目を担当します。 また、本日12月11日（月）から17日（日）まで 7日間連続 でCatoクラウドの記事を投稿しますので、ご期待ください。 それでは、Catoクラウドを検討される場合、ほぼ100%のお客様が実施されるPoCについて解説します。   PoC PoC（ピーオーシー、ポック） は「 Proof of Concept 」の略称で「 概念実証 」を意味しますが、少し前までは「事前（効果）検証」「技術検証」「実証実験」と言われていた新しい製品やソリューションを検討する際に、お客様の既存環境において、その製品・ソリューションが適切な効果を実現（発揮）することが可能か、期待通りの効果を見込めるかどうかを試すことです。 特に、Catoクラウドは、SASE（サッシー、サーシ）と言う新しいネットワークとセキュリティが統合されたクラウドサービスとなるため、ほぼ100%のお客様がPoCを実施されます。 ※ SASE （ Secure Access Service Edge ）とは、アメリカ調査会社ガートナーが2019年8月発行したレポート「ネットワークセキュリティの未来はクラウドにある（The Future of Network Security Is in the Cloud）」において提唱した、新たなネットワークセキュリティフレームワークです。ネットワークとセキュリティを統合し、ユーザが場所を問わず企業のシステム、アプリケーション、クラウドサービス、データにアクセスできるよう、安全で信頼性が高く、最適化されたネットワーク接続を提供することがコンセプトになっています。 また、SASEと最近よく比較されるSSEとの違いについては以下の記事をご覧ください。 SSEとSASEどちらを選べばよいのか？ SSE（Security Service Edge）とSASE（Secure Access Service Edge）どちらを選択すれば良いのかについて解説を行っています。 blog.usize-tech.com 2023.11.27 Catoクラウドは、PoC向けに30日間無償の評価アカウントを発行することが可能 です。 ただし、1企業につき、評価アカウント発行は原則1回のみで、期間（30日間）の延長はできません。 アカウントは30日間を経過するとロック（Lock）状態となり、さらに30日間が経過すると無効（Disable）状態となります。 アカウント設定情報は一定期間は保持されますが、その後アカウント削除が行われると設定情報は削除されます（設定情報をExport/Importする機能はございません） そのためPoCの30日間を如何に有効に活用できるかが重要になります。   PoC構成パターン PoCを実施される構成は、大きく以下の3パターンになります。 1. モバイルユーザのみ 2. モバイルユーザ＋DC（本社） 3. モバイルユーザ＋DC（本社）＋拠点 「1.モバイルユーザのみ」のPoCは、お申込みからおよそ3日間程度で評価アカウント発行が可能のため、すぐに開始することが可能です。 ご利用になられるデバイス（PC、スマートデバイス）にCato Clientをインストールするだけでご利用いただけます。 セキュリティ機能としては、SWG（Secure Web Gateway）とクライアント制御が中心の検証になります。 「1.モバイルユーザのみ」での検証内容 ・管理ポータル Cato Management Application（以下、CMA）全般 ・モバイルユーザ管理（LDAP/SCIM連携、SSO連携） ・URLフィルタリング（Internet Firewall） ・モバイルユーザ間の通信制御（WAN Firewall） ・クラウドサービス利用および制御（EgressIP設定など） ・クライアント制御（常時起動、デバイスポスチャ、デバイス認証、スプリットトンネル等） ・その他のセキュリティ機能（CASB/DLP/RBI/SaaS Security API）   「2.モバイルユーザのみ+DC」「3.モバイルユーザのみ+DC+拠点」のPoCは、物理エッジデバイス（Socket）が必要な場合と、仮想エッジデバイス（vSocket）が必要な場合で準備期間が異なります。 vSocketは、AWS、Azure、VMware ESXiをサポートしています。GCPは今後サポート予定です。 Socketのお貸出しは原則はX1500となりますが、必要であれば（在庫があれば）お申込みから2-3日でお届けすることが可能です。 Socketの設置は、以下のような構成（設定例）が多いですが、お打ち合わせも可能です。 Socketを設置する拠点には、インターネット回線（またはインターネット接続環境）が必須となります。 Socketは、DHCP（Default）、固定IP、PPPoEのいずれかでの方法での接続します。 SocketをFirewall配下に設置する場合には、経路設定（ルーティング）と特定ポート（udp/53、tcp/443、udp/443）の許可が必要です。 2.3.は、拠点内での利用検証をいただくことが可能となります。3.では拠点間での利用検証をいただくことが可能です。 「2.モバイルユーザのみ+DC」「3.モバイルユーザのみ+DC+拠点」で実施できる追加検証内容 ・Officeモード（クライアント） ・モバイルユーザと拠点間の通信制御（WAN Firewall） ・拠点内の通信制御（LAN Firewall） ・Port Forwarding ・QoS制御（Quality of Service） ・バイパス   「3.モバイルユーザのみ+DC+拠点」でのみ実施できる追加検証内容 ・拠点間ルーティング ・拠点と拠点間の通信制御（WAN Firewall） ・Off-Cloud（Socket間のVPN通信） 機能が多岐に渡るため、検証期間中にすべてを実施することはできないことを前提に、検証項目の優先順位付けが必要となります。   PoC支援 SCSKでは以前はPoCの支援を無償で実施していましたが、現在は原則有償で実施させていただいております。 PoC支援の課題 無償で実施していた際は、お客様へ30日間の無償アカウント発行し（営業ベースの）メールでの問い合わせ対応を行っていました。 しかしながら、Catoクラウドは、Knowledge Base（ナレッジベース）、各種説明動画、コミュニティ等が非常に充実しているのですが、残念ながら、現時点（2023年12月時点）でも、 英語のみ での提供となっております。 Webブラウザ・翻訳サイトでの日本語翻訳は可能ですが、やはり英語ドキュメントは敷居が高いです。 また、管理ポータル（CMA）で、まっさらな何も無い状態からイチから設定を行うのは、何をどこからどの順番で始めて良いのかも分からず、こちらもかなり敷居が高い状態でした。 ※ちなみに、 管理ポータル（CMA）については日本語化対応が完了 しています。 そのため、お客様から、PoC開始時点は質問をいただくのですが、その後は質問が減り、30日間が経過した後に、検証状況や結果をご確認すると殆ど検証を進めることができず、そのまま検証終了となるケースが発生しました。 皆さんお忙しいので、ゼロからいちいち調べてPoCを実施するのは、かなり無理があることが分かりました。 また、問い合わせをいただいても、当社がいち早く回答を行うこともできていませんでしたので、不明な点が発生し、問い合わせのメールをすると、その日は検証を進めることができなかったのではないかと推測して思います。 PoC支援の課題解決に向けて これらの課題を解決するために、よくある質問と回答をFAQとして資料（Excel）にとりまとめて提供する、主要な機能の操作手順書を作成し提供することにしましたが、残念ながら、これもあまりうまくは行きませんでした。 FAQは、どんどん増えて数十行を超え、一覧性が無くなった時点でExcelのFAQはお客様にあまり活用されなくなりました。 手順書についても、個々の機能の手順書は揃えたのですが、お客様毎にPoCで優先して実施したいこと（実施する必要がないこと）、優先順位が異なっていたり、何よりこれはCatoクラウドだけではなく、他のクラウドやSaaSでも同じ課題を抱えていますが、作成した手順書の画面イメージ（CMAのスクリーンショット）が頻繁に変更となるため、手順書がすぐに陳腐化する問題が発生しました。手順書がどんどん増えていくため、この課題も大きくなってきました。 FAQについては、Catoクラウドのご契約いただいた既存のお客様からの問い合わせも増加していたこともあり、PoCのお客様も対象にしたFAQシステムを立ち上げることにしました。 CatoクラウドのFAQについては以下の記事で紹介しています。 Catoクラウド FAQサイトについて SCSKが2022年より運営するCatoクラウドのFAQサイトに関してご紹介を行っています。 blog.usize-tech.com 2023.10.11 そして手順書の問題については、すぐにCMA（画面）が変更になることから、必要最低限の資料のみを作成し、お客様へは、都度CMAの操作レクチャーを実施する方針としました。 また、基本的な操作方法については、この技術ブログ（TechHarmony）の記事として無料公開にすることにしました。 例えば、以下のような記事です。 Catoクラウド はじめの一歩 Catoクラウドのテナント開設後、テストユーザ・テスト拠点をCatoクラウドへ接続するまでの流れを紹介します。 blog.usize-tech.com 2023.08.18 問い合わせは、FAQを充実し自己解決率を増やすことに注力していますが、やはり一番の課題は、限られた30日という期間で、限られた時間の中でPoCを実施されている中で、 問い合わせに対する回答を可能な限り短くすること でした。 そのため、SCSKではPoC支援時に、 Catoクラウドエンジニアを担当者としてアサインし、問い合わせに対する回答を可能な限り当日中に回答する体制を取る ことにしました。 PoC支援の有償化 担当者アサインも含め、結果として、 PoCを成功裏に導くために 、PoCの支援を有償で実施させていただくことにしました 。 当社支援が不要のアカウント発行のみのPoCについては、引き続き無償で実施させていただいております。 PoCのコストは、もしCatoクラウドを採用しなかった場合に「お金をドブに捨てるようなものだ」というお客様もいらっしゃいますが、その場合は、当社でなく無償PoCを実施されているパートナー（ディストリビュータ）様へご相談ください。 ただし「ただより高いものはない」ので、お気をつけてください。 当社の PoC支援（有償）の主なサービス内容 は以下となります。 PoC支援サービス内容 ・ヒアリングシートをもとにしたPoC要件のヒアリング ・Catoクラウド PoCアカウント作成 ・Socketのお貸し出し（Socketが必要な場合のみ） ・ヒアリングシート、およびSCSK推奨設定をもとにした初期設定作業 ・CMAのご利用方法、操作方法のレクチャー ・ 担当エンジニアをアサインしたPoC期間中の問い合わせ対応 ・ FAQサイトの契約者IDの付与（PoC期間中） PoC支援の期間は、原則PoCアカウントと同じ30日間となります。 打ち合わせは、すべてオンライン会議としております。 問い合わせの受付および返信は、基本メールとなりますが、問い合わせ内容に応じてはオンライン会議を開催させていただきます。 また、PoC支援期間は、FAQサイトの契約者IDを付与しますので、契約者サイトで当社の作成した各種手順書をご覧いただくことも可能です。 PoC支援の有償化にて、殆どのお客様が、Catoクラウドが適切な効果を実現するかどうかの確認、期待通りの効果を見込めるかどうかの確認を期間中に実施いただけることとなりました。 このPoC支援は、PoCを実施しないお客様向けに「簡易初期構築サービス」としてメニュー化をしております。 ちなみに、CatoクラウドのPoCを実施したお客様の半数以上は、Catoクラウドをそのまま契約（継続利用）されるケースが多いです。 前述しましたが、PoCの期間切れで、アカウント（設定）削除される前に最小構成で購入されるケースとなります。   スターターパック 「Go!Go!SASEキャンペーン!」 PoC支援を有償で実施させていただいた場合も、30日間で検証が完了しない例が少なからず発生しています。 クライアント関連の検証を幅広く実施される場合に、期限切れになるお客様が多いです。 例えば、最初にWindowsで検証を開始され、Always-On（常時接続）、Device Posture（デバイス状態確認）、Device Authentication（デバイス証明書）などを検証された後に、macOSを実施し、さらにiOS（iPhone/iPad）を検証される場合や、CASB/DLP等を検証される場合に時間切れになる場合が多いです。 そのため、Catoクラウドを30日間と言う限られた時間でのPoCではなく、 Catoクラウドの最低契約期間1年間 で、 最小構成である1拠点PoP接続（25Mbps） と モバイル（SDP）ユーザ10名 、さらに、Catoクラウドの特徴の1つである Socket X1500 1台 をセットとして、今回ご紹介した PoC支援 と、1年間の Catoクラウドサポート窓口 をつけた「 Catoクラウドスターターパック 」の発売を開始することにしました。 また発売記念に 「Go!Go!SASEキャンペーン!」として、55万円（税抜）の超特別価格で期間限定発売 します。 ※2024年2月にCatoクラウドの価格改訂があるため、価格は変更になる可能性があります。 Catoクラウドライセンスが61.2万円（定価）と、当社サービスを加えると約150万円相当となります。 Catoクラウド スターターパック内容 ・PoP接続（25Mbps）1拠点　　　　　　定価40,000円/月（年額480,000円） ・モバイル（SDP）ユーザ10名　　　　　 定価 8,000円/月（年額96,000円） ・Socket X1500 1台　　　　　　　　　 定価 3,000円/月（年額36,000円） ・PoC支援・簡易初期構築サービス（1ヵ月間） ・Catoクラウドサポート窓口（1年間） モバイルユーザは、予備の5ユーザを含めると 最大15名までご利用が可能 です。 Catoクラウドサポート窓口は、メール/電話による24時間365日受付、技術問い合わせ回答は当社営業日の09:00-17:00となります。もちろん FAQサイトの契約者IDの付与（1年間） も含まれます。 特別価格のため、2024年3月末までの期間限定となります。また、販売状況によっては数量限定とさせていただく可能性もありますので予めご了承ください。また、同業企業様やリセラー様への販売はお断りさせていただきます。 もしSASE、Catoクラウドをご検討のお客様、この際1年間実際にSASEを使用してみたいお客様は是非この機会に「Catoクラウドスターターパック」を検討されてはいかがでしょうか？ お問い合わせは以下へお願いします。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp

本記事は TechHarmony Advent Calendar 12/10付の記事です。 皆さんこんにちは。SCSKで飼育されているひつじです。 突然ですがエンドポイントちゃんと理解して使っていますか！？ エンドポイントと聞いて私が思い出すのはヨーロッパに赴任していたころです。 ヨーロッパにはシェンゲン協定というものがあり、協定内の国家間の移動は入国審査などが免除されます。 日本の場合は下図のように出向審査、入国審査を経て外国に行きますよね。 しかしシェンゲン協定内たとえばスペイン、ポルトガル間は審査不要で入国できるのです。 このような外国への移動が、まるで国内のように移動できる体験をVPCエンドポイント体験と名付けております。 さて、本題ですがそんなエンドポイントですがなんとなく使っていたりはしませんでしょうか。 今日はそんなエンドポイントの役割について説明したいと思います。 AWSのVPC外にあるサービスにつなぐ場合に使う 以下の図をご覧ください。よく聞くサービスですが実はVPCの外に配置されているサービスがいくつかあるのがわかりますね。 このようなVPCの外にいるサービスにはどのようにアクセスすればよいでしょうか。 例えばVPC内のEC2から別のSubnetにあるEC2につなぐことを考えた場合、同一VPC内にインスタンスを立てることでIPベースでの接続が可能になりますね。これは非常に単純でわかりやすいと思います。 しかし、VPC内に構築できないサービスと接続したい場合はどうでしょうか。 このような場合に使われるのがVPCエンドポイントです。 たとえばS3にアクセスしたいとします。S3はインターネットにも公開できるためインターネット経由でアクセスすることも可能です。 しかしインターネット公開はセキュリティ的に安全な手法とは言えません。 そこでインターネットを経由しないでAWSの中を通ってアクセスする必要があります。 エンドポイントの役割のひとつはインターナルに接続する手段となります。 別のVPC環境につなぐ場合に使う 次に別のVPC環境につなぐ場合のケースを考えてみましょう。 別のVPCということNW環境としては分離されています。 そのため、IPベースでの通信を行うことができません。 ではVPC間を接続（Peering）しNWを拡張することを考えてみましょう。 この場合はVPCに接続することができますが、以下の点に注意です。 NWアドレス帯が重複している場合はコンフリクトを起こして正常な通信ができない。 VPC間の通信を制御する仕組みが必要（接続元IPをフィルタする、通信プロトコルを制限するなど） より管理する手間を省き安全な接続を実現するためにエンドポイントを利用します。 このようなエンドポイントの使い方はPrivateLinkと呼ばれます。 通信をHTTPSに限定することができる。 送信元と送信先を明確に定義することできる。 これはクロスアカウントの場合も同様です。別のアカウントや他社が提供するAWSリソースにアクセスする要件があった場合に、PrivateLinkを使うことで安全に接続することが可能です。 VPCエンドポイントの種別について このように便利なエンドポイントですが大きく3つの種類があります。 ゲートウェイ型 DynamoDBとS3の2種類のみで利用することが可能です。 無償で使えるため お手軽に利用することができます。 このゲートウェイ型で払い出されるエンドポイントの実態は パブリックIP です。 そのためインターナル接続だと思い通信をローカルに閉じてしまった場合は接続ができなくなります。 ※本仕様について、パブリックIPへのアクセスだとインターネットを経由しているのでは？みたいな記事も散見されましたが、正確な情報はつかめませんでした。 インターフェース型 200種類近い種類が用意されています。そのためECRやCodeシリーズへのアクセスにも利用することが可能です。 インターフェース型のエンドポイントの IPはプライベート となります。 ただし１エンドポイントあたりに金額がかかります。ただNATGatewayと比較してもリーズナブルな価格となっています。 1か月で10GB通信した場合の試算（2023年12月時点/アジアパシフィック(東京)） エンドポイント インターフェース型 NAT Gateway 約10USD VPC エンドポイント 1 つあたりの料金 (USD/時間)：0.014USD 処理データ 1 GB あたりの料金 (USD)0.01USD 約45USD NAT Gateway 1 つあたりの料金 (USD/時間)：0.062USD 処理データ 1 GB あたりの料金 (USD)0.062USD Gateway Loadbalancer 型 こちらは今までの文脈とは少し異なる使い方になります。 通信経路にエンドポイントを介在させて、別VPC（例えばセキュリティ用VPC）に用意した仮想アプライアンスで通信を検査する場合などに有効なエンドポイントとなります。 引用：AWSドキュメント( https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/vpce-gateway-load-balancer.html ) まとめ いかがでしたでしょうか。 普段なんとなく使っているエンドポイントにもさまざまな種別がありましたね。 AWSを触り始めた当初、「VPC外にあるサービスに接続する」という概念がわかりにくかったのですが図にすることでイメージできました。 また冒頭でも記載した入国審査の例に関しても、クロスアカウントで接続するためのエンドポイントがまさしく言い得て妙なのかと思います。 AWSリソース間＝シェンゲン協定というイメージで覚えていこうかなと思います！ もし海外旅行などで入国審査しないで入国する場合「VPCエンドポイント体験だ～」と感じて頂ければと思います。 それではご査収ください。