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

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

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

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

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

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

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

本記事は 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 よろしくお願いします。