みなさん、こんにちは。カスタマーソリューションマネージャー (CSM) の北川です。今回は AWS コストの最適化を行う際に役に立つ、コストモデルを用いたクラウドコストの見積もりの考え方と、出来上がった見積もりについてオンプレミス環境とクラウド環境の見積もりを比較する際の注意点をご紹介します。 コストのモデル化を行うことで、クラウド上で新たに稼働するワークロードの総保有コスト (TCO) の見積もりや、投資収益率 (ROI) の算出が可能になります。比較の際の注意点を確認いただくことで、適切な視点でコストの比較を行うことができるようになります。 クラウドコストの見積もりツール モデルのお話をする前に、まずは代表的な見積もりツールのご紹介をします。 料金ページ Amazon Web Service の各サービスにはウェブページが用意されており、サービスの内容、仕組み、料金設定の詳細が記載されています。コストの透明性は AWS の理念の一部であり、ウェブページを参照することでAWS のサービスに関連するコストを確実に把握できます。例えば、 AWS Lambda の料金は Lambda リクエストの所要時間 (ミリ秒単位) や、リクエストに割り当てられたメモリ量などに基づいて計算されます。当該サービスの 料金ページ には、詳細な料金の計算方法に加えて、具体的な例も記載されているため、予想される使用量に応じてコスト見積もりをすることができます。 AWS Price List API AWS の料金情報の取得および使用方法をプログラム的に行うには、 AWS Price List API を使用してください。JSON と HTML を使用して AWS サービスの価格をクエリできます。 また、 Amazon Simple Notification Service (Amazon SNS) の通知を購読して、価格の変動や、新サービスの導入時にアラートを受け取ることも可能です。 AWS 料金見積もりツール (AWS Pricing Calculator) AWS 料金見積もりツール (AWS Pricing Calculator) を用いてコスト見積もりを行うことも可能です。料金見積もりツール自体には こちら からアクセス可能です。このツールは、使用予定の AWS サービスと、その使用方法を指定することでコスト見積もりを行います。見積もり結果は、 CSV、 PDF、 JSON にエクスポートすることやリンクで共有することが可能です。リンクは公開リンクのため、機密情報が含まれないように注意が必要です。また、複数の条件を比較したい場合には、条件を変えて複数見積もりを作成することや、見積もりをグループに分類してグループ単位でコストの確認することも可能です。リージョンにより提供されているサービスが異なることも反映されています。なお、AWS 料金見積もりツールで算出可能な対象サービスは こちら をご参照ください。 移行評価ツール (AWS Migration Evaluator) 大規模なクラウド移行案件では、数百から数千のシステムが対象となることがあり、それぞれのシステムにおいてサーバとライセンスを特定して、AWS へのマッピングを行い、サイジングを行い最適化の検討が必要となります。この場合には、 移行評価ツール (AWS Migration Evaluator) を使用することが可能です。移行評価ツールは、大規模なクラウド移行案件の概算をするための優れたツールであり、仮説をもとにしたコスト再見積もりの自動化に加えて、主要なステークホルダーや意思決定者と共有するためのレポート (Business Summary Report) も提供します。当該ツールを使用するためには、 こちらのフロー を参照し、移行評価をリクエストする際には こちらのページ から必要な情報を送信ください。 クラウドコストモデル クラウド見積もりを行うためのコストモデルとして、まずは (1) 技術的なアーキテクチャの整理 から始めます。これには、既存環境の情報収集に加えて、新環境の要件の整理が含まれます。次に、想定しているアーキテクチャコンポーネントを実現するために、 (2) AWS サービスの特定とマッピング を行います。AWS サービスを特定した後には、要件を満たすために (3) AWS リソースの選定 をします。最後に、前述の見積もりツールを用いて (4) コスト概算の算出 をします。概算見積もりは設計を進める中で再作成が必要となる場合もあります。 1. 技術的なアーキテクチャの整理 見積もり対象がオンプレミスの移行ワークロードであるか、クラウド新規のワークロードであるかによって技術的なソリューションの整理を行う切り口が異なります。対象が移行ワークロードである場合には、クラウド環境の適切なリソースを選択するために既存環境のリソース使用履歴や稼働実績の情報が役に立ちます。対象がクラウド新規のワークロードである場合には、まずはアーキテクチャ方針の決定が必要です。アーキテクチャ方針は AWS Well-Architected フレームワーク を参考にして決定することが可能ですが、要件を踏まえてコストのトレードオフが必要な項目が含まれます。トレードオフとしては例えば、可用性の要件に応じてマルチ AZとするかマルチリージョンとするか、ということがあります。併せて、サードパーティー製品の構成やライセンス要件についても確認が必要です。オンプレミスのライセンスがそのままクラウド環境でも使用できるかどうかや、移行期間に環境が現新２環境になったときにライセンス追加が必要になるかどうかなどを明確にすることが必要です。 2. AWS サービスの特定とマッピング 技術的なソリューションの整理を行なった後には、ソリューションを実現する詳細アーキテクチャの決定をするために、ソリューションとAWSサービスのマッピングを行います。マッピングとは例えば、コンピューターサーバー（図ではCompute serverと表記）を Amazon EC2 にマッピングすることや、データベースサーバー（図ではTransactional databaseと表記）を Amazon RDS に変更することを行います。マッピングを行う際には、選んだAWS サービスが要件を満たすことを十分に確認することが必要です。 マッピングの例） 3. AWS リソースの選定 マッピングを行なった AWS サービスをより詳細化するために AWS リソースの選定を行います。リソースの選定としては例えば、システム要件を満たすために必要な、Amazon EC2 のインスタンスタイプを判断し決定することを意味します。 リソースの選定の例） 4. コスト概算の算出 AWS リソースの選定まで進めることで、コストの概算が可能になります。コストの概算には、前述のクラウドコストの見積もりツールを使用します。ワークロードによっては、リザーブドインスタンス、 Savings Plans、 スポットインスタンス などの購入オプションを使用する方針を決めることでさらに最適なコスト見積もりが可能です。例えば、移行期間はリソース使用量の変動が大きいためオンデマンド形式での購入を行い、移行後に安定稼働したところでリザーブドインスタンス や Savings Plans の購入を行うという方針や、冪等性が保証されるワークロードに対しては常にスポットインスタンスを使用する方針などが考えられます。 他の概算手法としては、実装と測定 (Build and Measure) アプローチがあります。 Proof-of-concept (PoC) として実際に小さな環境を実装してみて、AWS Cost Explorer でコストを確認することで、正確な予想の基準となる金額を実際に測定することが可能です。 PoC を実施する際に、PoC 用の AWS リソースに対して専用の AWS コスト配分タグ を付与することでリソースごとのコスト内訳を Cost Explorer で確認可能です。コスト配分タグについては、 こちらの記事 も合わせてご参照ください。 コストに関する追加の検討項目 より正確なコスト算出を行うために、例えば Amazon CloudWatch , AWS CloudTrail , Amazon GuardDuty などの監視ツールやセキュリティツール、バックアップに使う AWS Backup などの運用ツールのコストを含めることも重要です。また、開発やテストに必要な追加環境の検討も必要です。 AWS 金額見積もりツールを用いることで、これらの追加の検討項目についてもあわせて概算が可能です。 オンプレミス環境とクラウド環境のコスト比較 クラウド環境のコストを算出した後にはオンプレミス環境のコストとの比較が必要となるケースが多くあるかと思います。ここでは両コストを比較する際の注意点をご紹介します。 総所有コストの比較条件の一致 総所有コスト (TCO)を比較する際には、オンプレミス環境とクラウド環境で同一条件となるように注意が必要です。比較時に条件の不一致が発生しやすい項目は表中にオレンジで強調表示をしています。例えば、イニシャルコストの計算であれば、ハードウェアやソフトウェアの調達費用の算出時にサーバやストレージ費用だけでなく、ラック、電源タップ、スイッチ等の周辺機器も含めて条件が一致していることの確認が必要です。また、ランニングコストの計算であれば、物理機器の管理や保守の人件費、データセンターの使用量、場所代、電気代、空調代、ネットワーク機器代、ネットワーク回線費用や、定期的に発生する保守切れやリース切れに伴う機器交換費用を含めて条件が一致していることの確認が必要です。クラウド移行で実現できるビジネス価値と経済性評価の考え方については、 こちら の AWS Black Belt Online Seminar 資料も併せてご参照ください。 AWS クラウドエコノミクス AWS クラウドエコノミクス に基づいた検討を行うことで、上記でご説明をした総所有コスト (TCO) の削減だけでなく、クラウドを活用することでスタッフの生産性、運用の回復力、ビジネスの俊敏性、サステナビリティのそれぞれを向上させることが可能となります。以下の図に記載されている例にある通り、オンプレミス環境からクラウドへ移行することで得られる経済的メリットを定量化することで、数値的なメリットの可視化が可能になります。また、 The Business Value of Amazon Web Services, IDC Research, Inc. June 2022 によると、クラウド移行により得られる価値の90%以上をコスト削減以外の価値が占めていることが分かります。また、投資収益率 (ROI) の観点においても、インタビュー対象組織においては5年間で 413% の ROI と、10 か月以内の損益分岐点の試算をおこなったケースを報告しています。クラウドへの移行をご検討の際は、コスト削減（TOC）による価値だけでなく、それ以外の価値も含めて総合的にクラウド移行のメリットを評価されることをお勧めします。クラウドエコノミクスの詳細については、 こちら も併せて参照ください。 本ブログでは、コストモデルを用いたクラウドコストの見積もりの考え方と、出来上がった見積もりについてオンプレミス環境とクラウド環境の見積もりを比較する際の注意点をご紹介しました。ご紹介した考え方を活用して、最適なクラウドコスト見積もりを検討ください。 参考情報： この記事は、 AWS Cloud for Finance Professionals の “ Planning and Forecasting : Estimating Cloud Costs ” を基礎情報として、カスタマーソリューションマネージャーの北川裕介と山下大介により作成されました。 コストに関するご質問やお問い合わせは、 お問い合わせページ 、もしくは担当営業までご連絡をお願いします。 コスト最適化を行うために以下の情報も併せてご参照ください。 クラウドコストの請求と監視 30の目的別クラウド構成と料金試算例 Amazon Web Services ブログ：CFM

小売業で、過去の販売データをもとに売り上げ数量を予測する仕組みのサンプルソリューションを Github上でOSSとして公開しました。 実績データをDWHに取り込んで前処理し、LightGBMベースの予測を出すまでの仕組みをAWS  Cloud Development Kit (CDK) ベースで提供するものです。本エントリではソリューションの構成や使い方について説明します。 End2End Data Solution for Retail Industry (Github) シンプルで見通しが良い分析アーキテクチャの土台を提供する Amazon Web Services (以下AWS)では、多くのサービスが提供されており、それらを適切に組み合わせることで高い自由度でソリューションを構築できるようになっています。各サービスは数クリックですぐに起動でき、運用管理の負担が少ないマネージド・サービス、もしくはサーバーレスと呼ばれる形態で提供されています。 一方で、ソリューションを構築する時間が取れない場合もあります。特に巨大データの分析や予測といった用途においては、ある程度やってみてから発見・理解できる事も多く、すぐに始めることがビジネス上の優位性を生む場合があります。 そこで、複数のサービスを統合した構成（アーキテクチャ）を事前に検討してOSSで公開し、CDKでデプロイ可能にしておくことで、すぐに分析にトライすることができるようにしたのが今回のソリューションです。 ソリューションは、できるだけシンプルで見通しが良く、管理の手間が少ない予測ソリューションのひな形を提供することを目標に設計しました。ユースケースを「小売（リテール）業の売り上げ情報から売り上げ数量を予測する」こととし、構成済のアーキテクチャ、CDKによる構築、サンプルデータ、ドキュメントを提供します。 アーキテクチャは下図のような構成です。データをAmazon S3上に保存したうえで、AWS Step Functionsを起動すると、データをAmazon Redshift Serverlessにロードし、SQLを実行して前処理し、Amazon SageMakerのビルトインアルゴリズムであるLightGBMで学習し、予測をS3に出力します。そのデータはAmazon Athenaで閲覧したり、Amazon QuickSightで可視化することが可能です。 想定する利用者・使い方 本ソリューションはエンジニア（AWSについて技術的な知見がある方）が、自分の環境に合わせてカスタマイズをすることを前提に作成しています。 ソリューションは100%の完成品ではありません。例えば基幹システムからデータをS3に取り込む部分は含まれません。取り込む方法は環境によって大きく異なりますので、環境に合わせて(S3への)データ転送方法を検討・実装いただく事を前提にしています。同様にデータ整形（前処理）は、Redshift Serverless上でSQLを実行することで実施していますので、カスタマイズにはSQLの記述が必要になります。 一方で、見通しが良く設計しておりAWSエンジニアであれば拡張しやすい作りになっています。例外処理等、あえて作りこんでいない部分もありますが、その分全体をシンプルに保っています。このように、利用者がソースコードやSQLを修正して自分のニーズに合わせた活用がしやすい事を重視したソリューションです。全体の流れをつかむには、まずは ソリューション・アーキテクチャ を見ていただくと良いでしょう。 また、AWSのサーバーレス・サービスを中心としたアーキテクチャにすることで、運用の負担を減らす構成としつつ、大規模データ処理や将来の予測モデル拡張に耐えうるサービスを選択しています。ソースコードはAWS Cloud Development Kit (CDK) ベースで作成されており、ソリューションをほぼ自動的で構築可能です。サンプルデータと共に公開されており、動作を確認した後は利用者がニーズに合わせて改変して利用することが可能になっています。 フィードバック/プルリクエストをお待ちしております 今回のリリース (v0.1)はエンド・ツー・エンドで動作することを確認していますが、まだまだ不足している部分もあります。例えばドキュメントはもっと分かりやすいものがあると良いでしょうし、カスタマイズガイド等も充実させる必要があると思っています。機能面でも追加すべき部分が多数あると思いますし、不具合もあるかもしれません。 ご興味がある方はぜひ触っていただいて、Github上のIssueでのフィードバックや、プルリクエストをいただければと思います。必ずの対応をお約束するものではありませんが、できる範囲で改善していく予定です。 End2End Data Solution for Retail Industry (Github) AWS 伊藤、秋田、平間、下佐粉

AWS Cloud Development Kit (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。 AWS CDK は、プログラミング言語の使い慣れた表現力を利用してアプリケーションをモデル化します。 Construct は AWS CDK アプリケーションの基本的な構成要素です。 Construct は「クラウドコンポーネント」を表し、 AWS CloudFormation がコンポーネントを作成するのに必要なすべてのものをカプセル化します。さらに、 AWS Construct Library では、事前定義されたテンプレートとロジックを使用してアプリケーションを簡単に構築できます。 Construct には次の 3 つのレベルがあります。 L1 — これらは Cfn (CloudFormation の略) リソースと呼ばれる低レベルの Construct です。これらは AWS CloudFormation リソース仕様 から定期的に生成されます。名前パターンは Cfn Xyz で、 Xyz はリソースの名前です。これらの Construct を使用するときは、すべてのリソースプロパティを設定する必要があります。そのためには、基礎となる CloudFormation リソースモデルとそれに対応する属性を十分に理解している必要があります。 L2 — これらは、より高いレベルの使用用途に応じた便利な API を備えた AWS リソースを表します。デフォルトの設定、定型コード、コンポーネント間を簡単に結合するロジックなど、 L1 Construct を使って自分で開発するような追加機能を提供します。 AWS Construct には便利なデフォルト設定が用意されており、それが表す AWS リソースの詳細をすべて知る必要がなくなります。リソースの操作をよりシンプルにするための便利なメソッドが提供され、結果的にアプリケーションを作成することが簡単になります L3 — これらの Construct はパターンと呼ばれます。 AWS の一般的なタスクを完了するように設計されており、多くの場合、複数の種類のリソースが関係します。 このブログでは、サンプルアーキテクチャと、 L2 Construct を使用して AWS CDK アプリケーションの複雑さを軽減する方法を示します。 サンプルアーキテクチャの概要 このソリューションでは、 Amazon API Gateway 、 AWS Lambda 、および Amazon DynamoDB を使用して、シンプルなサーバーレスウェブアプリケーションを実装しています。アプリケーションは API Gateway 経由でユーザーから POST リクエストを受け取り、プロキシ統合を使用して Lambda 関数に転送します。 Lambda 関数はリクエスト本文を DynamoDB テーブルに書き込みます。 サンプルコードは GitHub にあります。 ウォークスルー GitHub リポジトリの README ファイルの指示に従ってスタックをデプロイできます。次のチュートリアルでは、それぞれの論理構成と、 L1 と L2 の Construct を使用して実装する場合の違いについて説明します。各サンプルコードの前に、ソースがある GitHub リポジトリ内のパスを示します。 DynamoDB テーブルの作成 まず、リクエストの内容を保存する DynamoDB テーブルを作成します。 L1 Construct L1 Construct では、テーブルの各属性を個別に定義する必要があります。 DynamoDB テーブルの場合、これらは keySchema 、 attributeDefinitions 、および provisionedThroughput です。これらはすべて、たとえば keyType の定義方法など、 CloudFormation に関する詳細な知識を必要とします。 lib/level1/database/infrastructure.ts dynamodb.CfnTable( this, "CfnDynamoDbTable", { keySchema: [ { attributeName: props.attributeName, keyType: "HASH", }, ], attributeDefinitions: [ { attributeName: props.attributeName, attributeType: "S", }, ], provisionedThroughput: { readCapacityUnits: 5, writeCapacityUnits: 5, }, }, L2 Construct 対応する L2 Construct では、 readCapacity (5) と WriteCapacity (5) のデフォルト値を使用できます。さらに複雑さを軽減するために、属性とパーティションキーを同時に定義します。さらに、 dynamodb.AttributeType.STRING 列挙型を利用しています。 lib/level2/database/infrastructure.ts this.dynamoDbTable = new dynamodb.Table( this, "DynamoDbTable", { partitionKey: { name: props.attributeName, type: dynamodb.AttributeType.STRING, }, }, ); Lambda 関数の作成 次に、リクエストを受け取って DynamoDB テーブルにコンテンツを保存する Lambda 関数を作成します。ランタイムは Node.js を使用します。 L1 Construct L1 Construct を使用して Lambda 関数を作成する場合、作成時にすべてのプロパティ (ビジネスロジックのコードの場所、ランタイム、関数ハンドラー) を指定する必要があります。これには Lambda 関数が引き受ける IAM ロールも含まれます。そのため、 IAM ロールのリソースネーム (ARN) を指定する必要があります。この記事の後半の「権限の付与」セクションでは、この IAM ロールの作成方法を示します。 lib/level1/api/infrastructure.ts const cfnLambdaFunction = new lambda.CfnFunction( this, "CfnLambdaFunction", { code: { zipFile: fs.readFileSync( path.resolve(__dirname, "runtime/index.js"), "utf8" ), }, role: this.cfnIamLambdaRole.attrArn, runtime: "nodejs16.x", handler: "index.handler", environment: { variables: { TABLE_NAME: props.dynamoDbTableArn, }, }, }, ); L2Construct Lambda 関数の NodeJSFunction L2 Construct を利用することで、同じ結果をより簡単に得ることができます。別のバージョンを明示的に指定しない限り、 Node.js ランタイムのデフォルトバージョンが設定されます。この Construct は、 TypeScript または JavaScript コードを自動的にトランスパイルしてバンドルする Lambda 関数を作成します。その結果、関数の実行に必要なコードと依存関係のみを含む Lambda パッケージが小さくなり、内部では esbuild が使用されます。 Lambda 関数ハンドラーコードはリポジトリの runtime ディレクトリにあります。 Lambda ハンドラーファイルへのパスは entry プロパティに指定しています。 NodeJSFunction Construct はデフォルトでハンドラー名を使用するため、ハンドラー関数名を指定する必要はありません。さらに、 L2 Lambda Construct の作成時に Lambda 実行ロール を指定する必要はありません。ロールが指定されていない場合は、 Lambda の実行権限を持つデフォルトの IAM ロールが生成されます。「権限の付与」セクションでは、 Construct の作成後に IAM ロールをカスタマイズする方法について説明します。 lib/level2/api/infrastructure.ts this.lambdaFunction = new lambda_nodejs.NodejsFunction( this, "LambdaFunction", { entry: path.resolve(__dirname, "runtime/index.ts"), runtime: lambda.Runtime.NODEJS_16_X, environment: { TABLE_NAME: props.dynamoDbTableName, }, }, ); API Gateway REST API の作成 次に、 クロスオリジンリソース共有 (CORS) を有効にして POST リクエストを受信するように API Gateway REST API を定義します。 L1 Construct 新しい API Gateway REST API の作成からデプロイプロセスまで、すべてのステップを個別に設定する必要があります。 L1 Construct では、 CORS とヘッダーとメソッドの正確な設定を十分に理解している必要があります。 さらに、 Lambda プロキシ統合タイプでは URI の構築方法を知っておく必要があるなど、すべての詳細を知っておく必要があります。 lib/level1/api/infrastructure.ts const cfnApiGatewayRestApi = new apigateway.CfnRestApi( this, "CfnApiGatewayRestApi", { name: props.apiName, }, ); const cfnApiGatewayPostMethod = new apigateway.CfnMethod( this, "CfnApiGatewayPostMethod", { httpMethod: "POST", resourceId: cfnApiGatewayRestApi.attrRootResourceId, restApiId: cfnApiGatewayRestApi.ref, authorizationType: "NONE", integration: { credentials: cfnIamApiGatewayRole.attrArn, type: "AWS_PROXY", integrationHttpMethod: "ANY", uri: "arn:aws:apigateway:" + Stack.of(this).region + ":lambda:path/2015-03-31/functions/" + cfnLambdaFunction.attrArn + "/invocations", passthroughBehavior: "WHEN_NO_MATCH", }, }, ); const CfnApiGatewayOptionsMethod = new apigateway.CfnMethod( this, "CfnApiGatewayOptionsMethod", { // fields omitted }, ); const cfnApiGatewayDeployment = new apigateway.CfnDeployment( this, "cfnApiGatewayDeployment", { restApiId: cfnApiGatewayRestApi.ref, stageName: "prod", }, ); L2 Construct CORS を有効にして API Gateway REST API を作成するのは、 L2 Construct を使用するとより簡単になります。 defaultCorspreflightOptions プロパティを利用すると、この Construct によって必要な OPTIONS メソッドが準備されます。オリジンとメソッドを設定するには、 apigateway.Cors 列挙型を使用できます。 Lambda プロキシオプションを設定するには、メソッドのプロキシ変数を true に設定するだけです。デフォルトのデプロイは自動的に作成されます。 lib/level2/api/infrastructure.ts this.api = new apigateway.RestApi( this, "ApiGatewayRestApi", { defaultCorsPreflightOptions: { allowOrigins: apigateway.Cors.ALL_ORIGINS, allowMethods: apigateway.Cors.ALL_METHODS, }, }, ); this.api.root.addMethod( "POST", new apigateway.LambdaIntegration(this.lambdaFunction, { proxy: true, }) ); 権限の付与 サンプルアプリケーションでは、次の 2 つの異なるリソースに権限を付与する必要があります。 Lambda 関数を呼び出す API Gateway REST API DynamoDB テーブルにデータを書き込む Lambda 関数 L1 Construct どちらのリソースでも、 AWS Identity and Access Management (IAM) ロールを定義する必要があります。これには IAM 、ポリシーの構造、必要なアクションに関する深い知識が必要です。次のコードスニペットでは、まずポリシードキュメントを作成します。その後、リソースごとに IAM ロールを作成します。これらは作成時に、前述のように対応する Construct に渡されます。 lib/level1/api/infrastructure.ts const cfnLambdaAssumeIamPolicyDocument = { // fields omitted }; this.cfnLambdaIamRole = new iam.CfnRole( this, "cfnLambdaIamRole", { assumeRolePolicyDocument: cfnLambdaAssumeIamPolicyDocument, managedPolicyArns: [ "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole", ], }, ); const cfnApiGatewayAssumeIamPolicyDocument = { // fields omitted }; const cfnApiGatewayInvokeLambdaIamPolicyDocument = { Version: "2012-10-17", Statement: [ { Action: ["lambda:InvokeFunction"], Resource: [cfnLambdaFunction.attrArn], Effect: "Allow", }, ], }; const cfnApiGatewayIamRole = new iam.CfnRole( this, "cfnApiGatewayIamRole", { assumeRolePolicyDocument: cfnApiGatewayAssumeIamPolicyDocument, policies: [{ policyDocument: cfnApiGatewayInvokeLambdaIamPolicyDocument, policyName: "ApiGatewayInvokeLambdaIamPolicy", }], }, ); 独自に定義された Database Construct は、任意の IAM ロールに書き込みアクセスを許可する関数を公開します。この関数はポリシーを作成し、データベースのテーブルで dynamodb:PutItem を許可し、それを IAM ロールに追加ポリシーとして追加します。 lib/level1/database/infrastructure.ts grantWriteData(cfnIamRole: iam.CfnRole) { const cfnPutDynamoDbIamPolicyDocument = { Version: "2012-10-17", Statement: [ { Action: ["dynamodb:PutItem"], Resource: [this.cfnDynamoDbTable.attrArn], Effect: "Allow", }, ], }; cfnIamRole.policies = [{ policyDocument: cfnPutDynamoDbIamPolicyDocument, policyName: "PutDynamoDbIamPolicy", }]; } この時点で、 Lambda 関数には DynamoDB テーブルにデータを書き込む権限がまだないことを除いて、すべての権限が設定されています。書き込みアクセスを許可するには、 Lambda 関数の IAM ロールを使用して Database Construct の grantWriteData 関数を呼び出します。 lib/deployment.ts database.grantWriteData(api.cfnLambdaIamRole) L2 Construct LambdaIntegration Construct を使用して API Gateway REST API を作成すると、 IAM ロールが生成され、そのロールが API Gateway REST API メソッドにアタッチされます。 Lambda 関数に DynamoDB テーブルへの書き込み権限を与えるには、次の 1 行を入力します。 lib/deployment.ts database.dynamoDbTable.grantWriteData(api.lambdaFunction); L3 Construct を使用する さらに複雑さを軽減するには、 L3 Construct を活用できます。このサンプルアーキテクチャの場合、 LambdaRestAPI Construct を使用できます。この Construct はデフォルトの Lambda プロキシ統合を使用します。メソッドとデプロイを自動的に生成し、権限を付与します。その結果、さらに少ないコードで同じことを実現できます。 const restApi = new apigateway.LambdaRestApi( this, "restApiLevel3", { handler: this.lambdaFunction, defaultCorsPreflightOptions: { allowOrigins: apigateway.Cors.ALL_ORIGINS, allowMethods: apigateway.Cors.ALL_METHODS }, }, ); クリーンアップ この記事で紹介するサービスの多くは AWS 無料利用枠 で利用できます。ただし、このソリューションを使用するとコストが発生する可能性があるため、不要になった場合はスタックを削除する必要があります。クリーンアップ手順は GitHub リポジトリ の README ファイルに含まれています。 結論 この記事では、 L1 と L2 の AWS CDK Construct を使用する場合の違いを、アーキテクチャ例とともに紹介しました。 L2 Construct を活用すると、定義済みのパターン、定型コード、コンポーネント間を簡単に結合するロジックを使用できるため、アプリケーションの複雑さが軽減されます。便利なデフォルト設定が用意されており、これらが表す AWS リソースの詳細をすべて知る必要がなくなると同時に、リソースをより簡単に操作できる便利なメソッドも用意されています。さらに、 L3 Construct を使用して一般的なタスクの複雑さをさらに軽減する方法も示しました。 AWS CDK のドキュメント を参照して、プログラミング言語の表現力を駆使して、耐障害性、スケーラビリティ、コスト効率の高いアーキテクチャを構築する方法の詳細をご覧ください。 本記事は、 David Boldt による “Leverage L2 constructs to reduce the complexity of your AWS CDK application” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。

行政 DX における生成系 AI の活用の可能性 民間企業における Generative AI（以下、生成系 AI ）のビジネスでの利活用に注目が集まっています。それに加え、政府・官公庁・自治体、教育、医療機関などの公共部門で業務の効率化や国民・市民サービスでの利活用においても、そのメリットや可能性が活発に話し合われ始めています。 アマゾン ウェブ サービス（以下、AWS ） は、過去 20 年以上にわたり、人工知能（ AI ）や機械学習（ ML ）を誰でもが使うことができるように民主化し、グローバル企業や大規模な公共部門の組織からスタートアップまで、あらゆる規模のお客様が安全に容易に、そして適切なコストで革新的な AI ソリューションを構築できるよう注力しています。その知識と経験は 2023 年 4 月以来発表している AWS の生成系 AI サービス群でも踏襲されています。 政令指定都市であり全国でも多くの人口を抱える大阪市では、データやデジタル技術の活用により、地域のあり方や、サービスおよび行政のあり方を再デザインし、社会環境の変化にも的確に対応していくデジタルトランスフォーメーション（ DX ）の取り組みを進めています。それにより、大阪市で生活や経済活動を行う多様な人々が、それぞれの幸せを実感できる都市への成長・発展をめざしています。とりわけ世界的に注目を浴びている生成系 AI の行政における活用の可能性について、大阪市は着目しています。 生成系 AI 活用で AWS と大阪市が共同検証 アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、2023 年 9 月 1 日に、大阪市と行政 DX に向けた生成系 AI の活用に関して連携することで協定を締結しました。大阪市における行政の業務の効率化と、市民サービスの向上に向けて、生成系 AI の利活用の可能性と、利用にあたっての課題解決などについて、共同検証を目的とするものです。なお、AWS ジャパンが生成系 AI の活用について、政令指定都市を含む自治体・行政機関と協定締結という形で連携するのは、大阪市が初となります。   （写真左）大阪市 市長 横山 英幸 ／ （写真右） AWS ジャパン　執行役員 パブリックセクター統括本部長 宇佐見 潮 現場の業務において検証 共同検証においては、実際の市民サービスに携っている市職員が、実際に現場の業務でどのように使えるかについて取り組みます。期待される効果としては、まず業務効率化や作業の負荷軽減、そして業務品質の向上を想定しています。手法やシステム構成などの技術面については、特定の手法やシステムありきではなく、利用内容に応じて大阪市と AWS ジャパンで検討していきます。 アマゾン ウェブ サービス ジャパン合同会社 AWS ジャパン 執行役員 パブリックセクター 統括本部長 宇佐見 潮は次の旨述べています。「この度、大阪市と市民サービスの向上及び業務の効率化に向けた生成系 AI の利活用において、AWS が連携させていただくことを大変嬉しく思います。AWS はテクノロジーの提供を通じて、日本政府や官公庁、各自治体、スタートアップと連携・支援し、イノベーションを起こし社会課題の解決や経済を加速させていくことにコミットしています。全国でもトップクラスの人口や経済の規模を誇る大阪市様の広い分野での市民サービスの向上や業務効率化において、AWS のサービスと知見が大阪市様の目指す行政 DX に大きく貢献できると考えています。今回の大阪市様との連携で新しいイノベーションが生み出されることを大いに期待しています」 AWS は、設計、開発、展開、運用といった包括的な開発プロセスの各段階を通じて、AI における正確性、公平性、適切な使用方法、社会への有害性、セキュリティ、安全性、プライバシーなど、さまざまな要素を考慮し、”責任ある AI ”を念頭に置いて AI を構築します。AI の責任ある利用は、継続的なイノベーションを促進する鍵であり、AWS は企業や政府機関向けに公正で正確な AI および ML サービスの開発に取り組み、企業や政府機関のミッションの実現に向けて支援していきます。

8月30日、Amazon Kinesis Data Analytics の名称が Amazon Managed Service for Apache Flink に変更されたことをお知らせします。これは、 Apache Flink を使ってリアルタイムのストリーミングアプリケーションを構築および実行するためのフルマネージドのサーバーレスサービスです。 進行中の運用、開発、またはビジネスユースケースに影響を与えることなく、同じエクスペリエンスが Flink アプリケーションで引き続き提供されます。Kinesis Data Analytics で実行中の既存のアプリケーションはすべてそのまま動作します。変更を加える必要はありません。 活気のあるオープンソースコミュニティによる多様なユースケースのサポートを始めとして、多くのお客様がデータ処理に Apache Flink を使用しています。Apache Flink アプリケーションは堅牢で広く使用されていますが、並列コンピューティングリソースまたはコンテナリソースのスケーリングと調整が必要なため、管理が難しい場合があります。データ量、データ型、データソースが飛躍的に増加する中、お客様は、パフォーマンスやコストを犠牲にすることなく、データのアクセス、処理、保護、分析をより簡単に行う方法を必要としています。 Amazon Managed Service for Apache Flink を使用すると、最小限のコードでデータソースまたは宛先を設定して統合すること、 Amazon Kinesis Data Streams や Amazon Managed Streaming for Apache Kafka (Amazon MSK) などの多くのデータソースからのデータを 1 秒未満のレイテンシーで継続的に処理すること、およびイベントにリアルタイムで対応することができます。 Apache Zeppelin による組み込みの視覚化機能を備えた Amazon Managed Service for Apache Flink では、数回のクリック操作だけでノートブックを使ってストリーミングデータをインタラクティブに分析することもできます。 Amazon Managed Service for Apache Flink では、規格に準拠したセキュアな高可用性アプリケーションをデプロイできます。サーバーやクラスターを管理する必要や、コンピューティングとストレージのインフラストラクチャをセットアップする必要はありません。請求はアプリケーションが消費するリソースに対してのみ発生します。 Apache Flink のサポートの歴史 独自の SQL エンジンをベースにとする Amazon Kinesis Data Analytics の 2016 年のローンチ以降、効率的なステートフルストリーム処理に必要な機能をお客様に提供するには SQL だけでは不十分であることがわかり、リアルタイムのデータストリーム処理で広く使われているオープンソースフレームワークおよびエンジンである Apache Flink への投資が開始されました。 2018 年には、Apache Flink ライブラリを使用してストリーミングアプリケーションを構築し、独自の統合開発環境 (IDE) でアプリケーションを構築するお客様向けのプログラム可能なオプションとして Amazon Kinesis Data Analytics for Java のサポートが提供されました。2020 年、Apache Flink への継続的なサポートを強調するために Amazon Kinesis Data Analytics for Java が Amazon Kinesis Data Analytics for Apache Flink に変更されました。2021 年、Apache Zeppelin による迅速な開発向けのシンプルで使い慣れたノートブックインターフェイスを備え、処理エンジンとして Apache Flink を使用する Kinesis Data Analytics Studio (現在の Amazon Managed Service for Apache Flink Studio) がリリースされました。 2019 年以降、Apache Flink コミュニティとの連携が強化され、Kinesis Data Streams や Kinesis Data Firehose など、Apache Flink 用 AWS コネクタの領域におけるコード貢献を拡大するとともに、毎年開催される Flink Forward イベントを後援してきました。最近では、 Flink 1.15 リリース に Async Sink を提供した結果、その他の更新と共に、クラウドの相互運用性が向上し、多くのシンクコネクタとフォーマットが追加されました。 コネクタ以外にも、AWS は、Flink コミュニティとの協力を継続し、可用性の向上とデプロイオプションに貢献しています。詳細については、AWS オープンソースブログの「 Making it Easier to Build Connectors with Apache Flink: Introducing the Async Sink 」を参照してください。 Amazon Managed Service for Apache Flink の新機能 先に説明したように、既存の Flink アプリケーションを Kinesis Data Analytics (現在の Amazon Managed Apache Flink) で引き続き実行できます。変更を加える必要はありません。コンソールの変更と新機能に加えて、ワンクリックでエンドツーエンドのデータパイプラインを作成するブループリントという新機能についてお伝えします。 最初に注目すべき点は、 Amazon Managed Service for Apache Flink の新しいコンソール を AWS の分析セクションから直接使用できることです。開始する際は、新しいコンソールで ストリーミングアプリケーション または Studio ノートブック を簡単に作成できます。操作方法は以前と同じです。 新しいコンソールでストリーミングアプリケーションを作成するには、 [一から作成] または [ブループリントを使う] を選択します。新しく追加されたブループリントオプションでは、 AWS CloudFormation を使用して 1 つのステップで使用を開始するために必要なすべてのリソースを作成および設定できます。 ブループリントは、厳選された Apache Flink アプリケーションのコレクションです。最初のアプリケーションには、Kinesis Data Stream から読み取られ、 Amazon Simple Storage Service (Amazon S3) バケットに書き込まれるデモデータがあります。 デモアプリケーションを作成したら、Apache Flink ダッシュボードを設定、実行、開いて Flink アプリケーションの状態をモニタリングできます。操作は以前と同じです。 GitHub リポジトリ のコードサンプルを変更して、独自のローカル開発環境で Flink ライブラリを使用してさまざまなオペレーションを実行できます。 ブループリントは拡張可能で、Amazon Managed Service for Apache Flink をベースにビジネス上の課題を解決するための複雑なアプリケーションを作成するために活用できます。 Apache Flink ライブラリの使用方法 の詳細については、AWS ドキュメントを参照してください。 ブループリントは、新しいセットアップオプションとして Apache Zeppelin を使用して Studio ノートブックを作成するために使用することもできます。この新しく追加されたブループリントオプションでは、AWS CloudFormation を使用して 1 つのステップで使用を開始するために必要なすべてのリソースを作成および設定することもできます。 このブループリントには、Amazon MSK トピックに送信され、Managed Service for Apache Flink で読み取られるでもデータを含む Apache Flink アプリケーションが含まれています。Apache Zeppelin ノートブックでは、ストリーミングデータを表示、クエリ、分析できます。ブループリントのデプロイと Studio ノートブックのセットアップには約 10 分かかります。セットアップが完了するまでコーヒーでも飲んでお待ちください。 新しい Studio ノートブックを作成したら、Apache Zeppelin ノートブックを開いて、ノート内の SQL クエリを実行できます。操作は以前と同じです。Apache Flink ライブラリの使用方法の詳細については、GitHub リポジトリのコードサンプルを参照してください。 このデモデータでは、ユーザー定義関数、タンブリングウィンドウとホッピングウィンドウ、 Top-N クエリ、ストリーミング向けの S3 バケットへのデータ配信など、多くの SQL クエリを実行できます。 また、 Studio ノートブックの使用方法 と Amazon MSK トピックのクエリ に関するブログ記事で説明されているように、Java、Python、または Scala を使用して SQL クエリを強化し、継続的に実行するアプリケーションとしてノートをデプロイすることもできます。 ブループリントのサンプルの詳細については、 MSK Serverless からの読み取りと Amazon S3 への書き込み 、 MSK Serverless からの読み取りと MSK Serverless への書き込み 、 MSK Serverless からの読み取りと Amazon S3 への書き込み などの GitHub リポジトリを参照してください。 今すぐご利用いただけます Amazon Kinesis Data Analytics から名称が変更された Amazon Managed Service for Apache Flink を使用できるようになりました。Kinesis Data Analytics で実行中の既存のアプリケーションはすべてそのまま動作します。変更を加える必要はありません。 詳細については、 新製品のページ と デベロッパーガイド を参照してください。フィードバックは、 Amazon Managed Service for Apache Flink の AWS re:Post または通常の AWS サポートチャネルから送ることができます。 — Channy 原文は こちら です。

イントロダクション 本日、 Amazon VPC Container Networking Interface (CNI) プラグイン での Kubernetes NetworkPolicy のネイティブサポートを発表できることを嬉しく思います。Kubernetes クラスター内の Pod ネットワーキングとネットワークポリシーの両方を実装するために、Amazon VPC CNI を利用できます。NetworkPolicy のネイティブなサポートは、私達の コンテナロードマップ において、最も要望の多かった機能の 1 つでした。 デフォルトでは、Kubernetes は全ての Pod が制限なく相互に通信することを許可しています。 Kubernetes の NetworkPolicy は、Pod 間のトラフィックフローのルールを定義し、強制できます。仮想ファイヤウォールとして機能し、クラスターをセグメント化し、保護します。これは、Pod の Label、Namespace、IP アドレス、IP ブロック (CIDR レンジ)、ポート番号などのさまざまな基準に基づいた受信および送信ネットワークトラフィックのルールを指定することでおこなわれます。今までは、お客様はサードパーティのネットワークポリシープラグインを使用して、NetworkPolicy を実装し、それによってしばしば運用と管理のオーバーヘッドが生じていました。Amazon VPC CNI の統合された機能によって、クラスターの構成とデプロイがシンプルになりました。トラフィックフローを制限することで、スケーリングの課題を心配することなく、より強力なセキュリティ体制を実現できます。 Amazon VPC CNI の NetworkPolicy のネイティブなサポートにより、AWS 上で Kubernetes を実行する場合に、機密性の高いワークロードを隔離し、認可されていないアクセスから保護するポリシーを作成できます。このきめ細やかなコントロールレベルにより、許可された Pod のみが相互に通信できる最小権限の原則を実装できます。NetworkPolicy は Amazon Elastic Computer Cloud (Amazon EC2) セキュリティグループ ( SG ) やネットワークアクセスコントロールリスト ( NACL ) などの、Amazon VPC によって提供されるセキュリティ機能を拡張する、多層防御のメカニズムを提供します。 Amazon Elastic Kubernetes Service (Amazon EKS) は、アップストリームの Kubernetes NetworkPolicy を完全にサポートしているため、互換性と Kubernetes 標準への準拠が保証されます。これは、Amazon EKS クラスターにおける NetworkPolicy API の全ての機能を使用できることを意味しています。アップストリームの API によってサポートされるさまざまな 識別子 を使って柔軟にポリシーを定義できます。これにより、Pod 間の通信を定義することが可能になり、クラスター内のセキュリティと分離が強化されます。 動作の仕組み Kubernetes の NetworkPolicy が最初に導入された時、広く採用されていたデフォルトの実装は iptables でした。 iptables はネットワークポリシーの強制には効果的であることが証明されましたが、特に Kubernetes クラスターのサイズが拡大する時に、いくつかの制約がありました。数多くの iptables ルールを管理することが課題になる可能性があります。また、各パケットでルールを順番に評価することで、ルール数の増加によって、パフォーマンスの問題が生じる可能性もあります。 これらの課題に対処し、パフォーマンスを改善するために、Amazon EKS は extended Berkeley Packet Filter ( eBPF ) を用いて NetworkPolicy を実装するという高度なアプローチを採用しました。このテクノロジーは NetworkPolicy の代替実装として、近年大きな支持を集めています。eBPF は iptables と比較してより効率的なパケットフィルタリングを提供し、全体的なパフォーマンスが向上する可能性を秘めています。これは、カーネル自体の中でカスタムコードを直接実行できるようにすることによって実現されます。 NetworkPolicy の実装を円滑に進めるために、Amazon EKS ではシームレスに連携する 3 つの主要なコンポーネントを導入しています。 Network Policy コントローラー: Amazon EKS は、最新バージョンの Amazon VPC CNI と共に、 Network Policy コントローラー のローンチを発表しました。現在、コントローラーは一般公開されています。新しい Amazon EKS クラスターを作成すると、機能が有効になった際に Network Policy コントローラーが Kubernetes のコントロールプレーンに自動的にインストールされます。クラスター内の NetworkPolicy の作成をアクティブに監視し、ポリシーエンドポイントを調整します。その後コントローラーは、ポリシーエンドポイントを通じて Pod の情報を公開することによって、ノード上で eBPF プログラムを作成または更新するよう、Node Agent に指示します。Network Policy コントローラーは、Pod のプロビジョニングと並行して、Pod のポリシーを設定します。それまで新しい Pod には、デフォルトの許可ポリシーが設定されます。既にあるポリシーに対して調整されるまで、新しい Pod への送受信トラフィックは全て許可されます。セルフマネージド型 Kubernetes クラスターの NetworkPolicy を効率的に管理するには、Network Policy コントローラーをデプロイする必要があります。この点については、この記事のウォークスルーのセクションで、セルフマネージド型クラスターに関する詳しい情報と重要な考慮事項を確認することができます。 Node Agent: Amazon VPC CNI の最新バージョンでは、クラスター内の全てのノードに CNI バイナリと ipamd プラグインと共に、 Node Agent もインストールされます。Node Agent は VPC CNI にバンドルされ、aws-node DaemonSet 配下でコンテナとして実行されます。NetworkPolicy がクラスターに適用されると、Node Agent はコントローラーからポリシーエンドポイントを受け取ります。Node Agent は eBPF プログラムの管理において重要な役割を果たし、シームレスな NetworkPolicy への道を開きます。 eBPF SDK (Software Development Kit): Amazon VPC CNI はサポートと運用を助けるために、ノード上の eBPF プログラムと対話するための直感的なインタフェースを提供する SDK を含んでいます。この SDK により、eBPF 実行時における、ランタイムのインストロペクション、トレース、分析が可能になり、接続性の問題の特定と解決に役立ちます。 本日より、v1.25 以降の新しい Amazon EKS (IPv4 および IPv6) で NetworkPolicy がサポートされます。Amazon EKS は、既存の全てのクラスターを、対応する Kubernetes マイナーバージョン用の最新の Amazon EKS プラットフォームバージョンに自動的にアップグレードします。まもなく、この機能をサポートするプラットフォームバージョンをリリース予定です。そのプラットフォームバージョンへの自動アップグレードがおこなわれた後に、NetworkPolicy が適用可能になります。 クラスターで NetworkPolicy を有効化するには、クラスターが Amazon VPC CNI 1.14.0 以降のバージョンを実行していることを確認します。新しいクラスターを作成する際には、Amazon VPC CNI 1.14.0 以降のバージョンを指定することができます。Amazon VPC CNI 1.14.0 で作成されていないクラスターについては、Amazon VPC CNI を更新してください。既存のクラスターのプラットフォームバージョンの更新が完了したら、VPC CNI をサポートされているバージョンに更新してください。 ローンチ時点では、NetworkPolicy は Kernel バージョン 5.10 以降を使った Amazon EKS-optimized Amazon Linux AMI 、 Amazon EKS-optimized Bottlerocket AMI 、 Amazon EKS-optimized Ubuntu Linux AMI でサポートされています。Kernel バージョン 5.10 以降を使って構築された Amazon EKS-optimized AMI は、eBPF ファイルシステム /sys/fs/bpf を自動的にマウントします。これは、ノードに NetworkPolicy を適用するために必要です。既存のクラスターにおいては、Amazon EKS プラットフォームバージョンが更新された時に、最新の Amazon EKS-optimized AMI に更新することを推奨します。カーネルバージョン 5.10 またはそれより下のバージョンを使用するノードの場合、eBPF ファイルシステムをマウントする手順について、Amazon EKS ユーザーガイド を参照してください。eBPF システムサポートを使用して独自のカスタム AMI を作成する方法については「 Amazon EKS-optimized Amazon Linux AMI ビルドスクリプト 」を確認してください。 始め方 NetworkPolicy の機能は Kubernetes マイナーバージョン 1.25 以降を実行しているクラスターでサポートされていますが、ローンチ時点ではデフォルトで無効になっています。クラスターを作成する際に、Amazon VPC CNI の設定パラメータを使用してクラスターの NetworkPolicy を有効化できます。 Amazon VPC CNI が IP アドレスを管理するには、AWS Identity and Access Management ( AWS IAM ) による許可が必要になります。Amazon EKS では、 AmazonEKS_CNI_Policy 管理ポリシーで定義されたアクセス権限を使用して、別の AWS IAM ロールを作成し、 IRSA (AWS IAM roles for service acount) を使用してそのロールを VPC CNI に関連付けることを推奨しています。IRSA は OpenID Connect (OIDC) エンドポイントを必要とするため、クラスター作成の一部として IAM OIDC プロバイダーを作成 します。詳細については「 サービスアカウントの IAM ロールを使用する Amazon VPC CNI plugin for Kubernetes の設定 」を参照してください。 以下の設定をコピーして cluster.yaml という名前のファイルに保存します。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: network-policy-demo version: "1.27" region: us-west-2 iam: withOIDC: true vpc: clusterEndpoints: publicAccess: true privateAccess: true addons: - name: vpc-cni version: 1.14.0 attachPolicyARNs: #optional - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy configurationValues: |- enableNetworkPolicy: "true" - name: coredns - name: kube-proxy managedNodeGroups: - name: x86-al2-on-demand amiFamily: AmazonLinux2 instanceTypes: [ "m6i.xlarge", "m6a.xlarge" ] minSize: 0 desiredCapacity: 2 maxSize: 6 privateNetworking: true disableIMDSv1: true volumeSize: 100 volumeType: gp3 volumeEncrypted: true tags: team: "eks" eksctl create cluster -f cluster.yaml Bash クラスターの作成が完了するのを待って、Amazon VPC CNI が Node Agent を実行するようになったかどうかを確認します。 kubectl get ds -n kube-system aws-node -o jsonpath= '{.spec.template.spec.containers[*].name}{"\n"}' 出力: aws-node aws-eks-nodeagent Apache Configuration eBPF SDK を使用する Amazon VPC CNI の最新バージョンには、ノード上の eBPF プログラムとやり取りするためのインタフェースを提供する SDK が付属しています。SDK は aws-node がノードにデプロイされる時にインストールされます。SDK バイナリはノードの /opt/cni/bin ディレクトリ配下にインストールされています。接続性の問題を特定したい場合は、SDK の使用を検討してください。ノード上の Pod のために eBPF プログラムが作成されていることを確認します。これを確認するには AWS System Manager ( AWS SSM ) を使用して、Amazon EC2 コンソールからノードに接続します。 ローンチ時には、SDK は eBPF プログラムやマップの検査など、基本的な機能をサポートしています。特定の利用リクエストがある場合は、 こちら の GitHub Issue から教えてください。SDK の使用方法については、ユーザーガイドを御覧ください。 sudo /opt/cni/bin/aws-eks-na-cli ebpf progs Apache Configuration サンプルアプリケーションのデプロイ 次に、demo-app というサンプル NGINX アプリケーションと、default Namespace にシンプルなクライアントアプリケーションをデプロイします。さらに、another-ns という default Namespace ではない Namespace に別のクライアントアプリケーションを作成します。 git clone https://github.com/aws-samples/eks-network-policy-examples.git cd eks-network-policy-examples kubectl apply -f advanced/manifests/ Apache Configuration 全ての Pod が Running 状態になるまで待ちます。 kubectl get pods --all-namespaces --watch Apache Configuration NetworkPolicy を実装する デフォルトでは、Kubernetes は全ての Pod が他の全ての Pod と自由に通信することを許可しています。Kubernetes の NetworkPolicy が Pod に適用されていない場合は、Pod に出入りする全てのトラフィックが許可されます。 アクセスを確認し、全ての送受信トラフィックを許可する 別のターミナルを使用して、前のステップでデプロイしたクライアントの Pod からの接続を確認できます。 kubectl exec -it client-one -- curl demo-app Apache Configuration API 呼び出しが成功したことを示す応答が表示されます。 全てのトラフィックを拒否する demo-app アプリケーションのために、全 Namespace に渡って全てのトラフィックを拒否するポリシーを適用することで、分離をおこないましょう。 kubectl apply -f advanced/policies/01-deny-all-ingress.yaml Apache Configuration NetworkPolicy では全ての Pod を選択したため、demo-app への受信トラフィックはすべて拒否されます。 kubectl exec -it client-one -- curl demo-app Apache Configuration 前のコマンドはタイムアウトになります。 curl: (28) Connection timed out after 3001 milliseconds<br />command terminated with exit code 28 同じ Namespace からの受信を許可する 次のステップでは、同じ Namespace 内で、client-one から demo-app への受信トラフィックを許可します。 kubectl apply -f advanced/policies/03-allow-ingress-from-samens-client-one.yaml Apache Configuration NGINX のウェルカムページの HTML が返されるはずです。 kubectl exec -it client-one -- curl --max-time 3 demo-app Apache Configuration another-ns Namespace からの受信を許可する 次に、別の Namesapce からのトラフィックを許可します。 kubectl apply -f advanced/policies/04-allow-ingress-from-xns.yaml これにより、別の Namespace のクライアントから demo-app にアクセスできるようになり、ウェルカムメッセージが返されるはずです。 kubectl exec -it -n another-ns another-client-one -- curl --max-time 3 demo-app.default 送信トラフィックを拒否する default Namespace の client-one Pod からの全ての送信の分離を適用します。 kubectl apply -f advanced/policies/06-deny-egress-from-client-one.yaml Apache Configuration DNS Lookup を含め、client-one からの全ての送信トラフィックが拒否されていることがわかります。 kubectl exec -it client-one -- nslookup demo-app Apache Configuration 送信トラフィックを許可する DNS トラフィックも含め、複数のポートと Namespace からの送信を許可しましょう。 kubectl apply -f advanced/policies/08-allow-egress-to-demo-app.yaml Apache Configuration DNS と demo-app への送信トラフィックを許可する必要があります。 kubectl exec -it client-one -- curl --max-time 3 demo-app Apache Configuration 重要な考慮事項 NetworkPolicy と Security Groups for Pods IPv4 モードの Amazon VPC CNI は、Security Groups for Pods と呼ばれる強力な機能があります。この機能により、Amazon EC2 セキュリティグループを使用して、ノードにデプロイされた Pod との間のインバウンドおよびアウトバウンドのネットワークトラフィックを管理するルールを定義できます。Security Groups for Pods と NetworkPolicy を組み合わせて活用することで、セキュリティ体制を強化できます。NetworkPolicy が有効になっている場合、Security Groups for Pods は多層防御戦略の追加のレイヤーとして機能します。NetworkPolicy を使うと、クラスター内のネットワークトラフィックの流れをきめ細かく制御できます。一方で、Security Groups for Pods は Amazon のセマンティックコントロールを活用し Amazon RDS データベースなどの Virtual Private Cloud (VPC) 内のリソースとの通信を管理することで保護を強化します。Amazon EKS では、Pod 間のネットワーク通信を制限する NetworkPolicy を採用することを強く推奨しています。これにより、攻撃対象領域が減少し、潜在的な脆弱性を最小限に抑えられます。NetworkPolicy とセキュリティグループの仕様に関する詳細のガイダンスについては、 Amazon EKS ベストプラクティス を参照してください。 NetworkPolicy とサードパーティ CNI プラグイン Amazon VPC CNI は、Kubernetes NetworkPolicy API を使って定義されたネットワークポリシーをサポートするようになりました。Pod ネットワーキング用のサードパーティ CNI プラグインを実行しているクラスターは、NetworkPolicy の機能を有効化するために、Amazon VPC CNI に移行しなければならないと注意しておくことが重要です。 この記事を書いている時点では、Amazon VPC CNI はサードパーティのネットワークポリシープラグインの Amazon VPC CNI へのインプレースでの移行をサポートしていません。移行を円滑に進めるために、Amazon EKS では Amazon VPC CNI の NetworkPolicy サポートを有効化する前に、既存のサードパーティネットワークポリシー API を Kubernetes NetworkPolicy API に変換することを推奨しています。本番環境に変更を適用する前に、移行したポリシーを別のテスト用クラスターでテストすることを推奨します。これによって、Pod 間通信の振る舞いにおける潜在的な問題や不一致を特定して対処できます。 一貫性を保ち、予期せぬ Pod の通信の振る舞いを回避するために、単一のネットワークポリシープラグインのみを実行することを推奨します。Amazon VPC CNI の最新バージョンにアップグレードする前に、既存のサードパーティのネットワークポリシー CNI プラグインを削除することが重要です。さらに、ワーカーノードを入れ替えることで、 iptables や eBPF プログラムなど、ノードに残っている変更を排除できます。Amazon VPC CNI の NetworkPolicy サポートに移行するための詳細な手順については、 こちら のドキュメントを参照してください。このオープンソース リポジトリ で提供されるスクリプトを使用して、サードパーティのネットワークポリシーを Kubernetes NetworkPolicy アーティファクトに変換できます。これらのリソースは Amazon EKS よって公式にサポートされておらず、ベストエフォートになります。リソースは、Amazon VPC CNI NetworkPolicy サポートへの移行を成功させるために、移行プロセスを合理化および簡素化することを目的としています。 セルフマネージド型 Kubernetes クラスター Amazon VPC CNI の最新バージョンでは、AWS 上のセルフマネージド型 Kubernetes に NetworkPolicy を適用できるようになりました。Amazon VPC CNI の更新に加えて、セルフマネージド型 Kubernetes クラスターに Amazon NetworkPolicy コントローラーをインストールして、NetworkPolicy を有効化します。 GitHub リポジトリに記載されている手順にしたがって、NetworkPolicy コントローラーをデプロイします。現在、Amazon VPC CNI と Network Policy コントローラーはサードパーティの NetworkPolicy プラグインとカスタム NetworkPolicy オブジェクトのインプレースでの移行をサポートしていないことに注意することが重要です。そのため、上記の手順に従って Amazon VPC CNI NetworkPolicy に移行するようにしてください。 クリーンアップ 将来のコストを避けるため、この演習用に作成した Amazon EKS クラスターを含む全てのリソースを削除してください。このアクションは、クラスターを削除するだけではなく、ノードグループも削除します。 eksctl delete cluster -f cluster.yaml Apache Configuration まとめ この記事では、Kubernetes NetworkPolicy が Amazon EKS でも利用できるようになったことをお伝えしました。これは、ロードマップで最も要望の多かった機能の 1 つに対応したものです。また、サードパーティのネットワークポリシープラグインを管理しなくても、きめ細やかな通信制御を実施し、ワークロードを分離し、AWS Kubernetes クラスター全体のセキュリティを強化する方法を示しました。 NetworkPolicy の領域を詳しく調べる時に、Amazon EKS ではアプリケーションの特定のセキュリティ要件を念頭に置き、新たな脅威に備えるために定期的にポリシーを見直して更新することを推奨しています。綿密な計画と実装をおこなうことで、Kubernetes NetworkPolicy のポテンシャルを最大限に活用して、アプリケーションとデータを不正なアクセスから保護できます。推奨事項や追加の考慮事項については、 Amazon EKS ベストプラクティスガイド をご覧ください。 Amazon VPC CNI のインストール手順については、Amazon EKS ユーザーガイド を参照してください。Amazon VPC CNI プラグイン に関するフィードバックは、GitHub でホストされている AWS コンテナロードマップ に Issue を開くか、コメントを残すことで提示できます。今後も機能を進化させ、eBPF テクノロジーを活用して Amazon VPC CNI 内でモニタリングやオブザーバビリティの機能を提供する追加の方法を模索していきますので、ご期待ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

本ブログの位置づけ AWS Customer Solutions Manager の山崎です。本ブログは現状オンプレミス上での多くの IT 資産が稼働しており、AWS への移行を考えたい、エンタープライズのお客様向けに記載しています。 オンプレミスからAWS への移行は評価、計画、移行、運用/最適化のフェーズに分かれます。本ブログは計画～移行のフェーズにおいて、個々のシステム群の移行をどのような切り口で整理するべきかを 前編 ／ 後編 でまとめています。ここでいう個々のシステム群の移行とは、システムを構成するリソースであるアプリケーションサーバー、データベース、ファイルサーバーの移行を指します。 前編 では、AWS へのシステム移行検討のアプローチとして、移行パターンの整理およびデータ転送経路の確保パターンについて整理しました。後編では、リソースごとの移行方法や活用できる AWS サービスについてご紹介していきます。 3. 移行に利用するサービスの識別 移行リソースごとに利用可能なAWS サービスを紹介していきます。リソースの種類や 移行方法 によって、最適なAWS サービスは変わります。お客様が移行したいリソース、準備状況、獲得したい効果、スケジュール感などを踏まえ、移行方法とあわせて利用するサービスを明確にしましょう。 3-1. アプリケーションサーバー移行 アプリケーションサーバーをどのように移行するのかは、 移行パス によって異なります。ここではリホスト、リロケート、リアーキテクチャの3 つのパターンで整理します。 オンプレミスからシステム構成を大きく変更せずにリホスト (リフト＆シフト) する場合 は、手動で移行する手段と自動で移行する手段があります。 運用の効率を高めるために OS やミドルウェアの最新化、パッケージ設定の整理やセットアップ・テストの自動化を付随して実施する場合は、手動での移行を考えます。 最新化やセットアップ作業が不要の場合、自動での移行が可能です。自動での移行には AWS Application Migration Service (AWS MGN) を利用します。AWS MGN は、移行元のサーバーにエージェントをインストールすることで、移行先であるAWS に環境をレプリケーションすることができます。ソースサーバーを物理、仮想、またはクラウドのインフラストラクチャから AWS でネイティブに実行するように自動的に変換することにより、AWS への移行を簡素化および迅速化します。 既存オンプレミスの vSphere ワークロードを AWS にリロケートする場合 、 VMwareCloud on AWS が利用できます。VMware Cloud on AWS により、VMware ベースのデータセンターと AWS 間で相互運用可能なインフラストラクチャとサービスが提供されるため、複雑な環境の管理を避け、関連するリスクを最小限に抑えることができます。 移行と同時に アプリケーションをリアーキテクチャしてモダナイズする場合 は、 AWS Lambda や  AWS Fargate といったサーバーレスプラットフォームが移行先として視野に入ります。この場合、アプリケーション自体をサーバーレスプラットフォームにあわせて変更するため、難易度は最も高くなります。得られる効果として、ビジネスアジリティの向上、運用負荷の削減、コストの最適化などがあります。 3-2. データベース移行 データベースは、一般的に顧客情報や商品情報などのマスタデータ、受注処理や入出金処理などのトランザクションデータを格納するために使用され、システムの基盤となります。 本章ではデータベースの中でも、オンプレミスのシステムで一般的に使われているリレーショナルデータベースについて記載します。 データベース移行には、 システムが許容できる停止時間 を見極めます。十分な停止時間をとれる場合は、一括移行が可能でなるべくシンプルな移行方式を選択します。ソースデータベースとターゲットが同一エンジンであればダンプツール  (Oracle の移行の場合は Oracle Data Pumpなど) 、異なる場合は CSV アンロードを使用します。 許容できる停止時間に余裕がない場合 は、差分移行が可能な移行方式を選択します。移行方式には、ソースデータベースとターゲットデータベースが同一エンジンでかつ純正のツールが使える場合はレプリケーション (Oracle の移行の場合は Oracle GoldenGate など)、それ以外の場合は AWS Database Migration Service (AWS DMS) を使用します。差分移行方式では、ダウンタイムを最小限にすることが可能ですが、一括移行方式に比較すると、難易度が高くなるため、事前の調査や検証、リハーサルなどを計画してください。 AWS-18：AWS のサービスを使ったオンプレミスからのデータベース移行 ダンプツールによる移行 データベース移行では、ダンプデータを転送しロードする方法がシンプルで確実です。停止時間を短縮する場合は、一括移行後に差分データを追加ロードすることが基本方針です。ダンプデータをロードする場合、データベースエンジンの純正ツールを使い、オンプレミスから AWS へデータを送りロードをします。移行先には一時的な領域とデータファイルの領域が必要です。 CSVアンロードによる移行 異なるデータベースエンジン間でデータベースを移行する際には、一般的にCSVのアンロードとロードが利用できます。オンプレミスのデータベースでは、SELECT 文などを使用して CSV 形式のファイルを作成し、それを AWS に送り、AWS 側でロードを行います。この移行方法では、ダンプファイルを使用する場合と同様に一時的な領域が必要です。CSV アンロードは、より柔軟な移行方式である一方、データ型 (LOB など) やデータ (制御文字など) によって CSV 化が難しい場合や、ダンプツールと比較して性能が劣る場合もありますので、利用範囲は限定的です。 レプリケーションによる移行 データベースベンダー純正のレプリケーション機能を利用することで、ダンプツールや CSV アンロードによるデータ移行よりもサービス停止時間を短縮できます。利用可能なライセンスやレプリケーション機能のノウハウがある場合には、純正レプリケーション機能 ( Oracleの移行の場合は Oracle GoldenGate や Oracle マテリアライズドビュー ) を検討してください。利用するレプリケーション機能については、各ベンダーのマニュアル等を参照し、事前調査や各種テストを計画してください。 AWS Database Migration Service (AWS DMS) による移行 AWS Database Migration Service (DMS) は、異なるデータベースエンジン間や同じエンジン内でのデータ移行を容易にするサービスです。AWS DMS はデータの抽出、変換、ロードを行い、既存の構成変更を最小限に抑えながらデータベースの移行を可能にします。AWS DMS はすでに存在するテーブルにデータをロードするという動きをするため、あらかじめテーブルやインデックスなどの各種オブジェクトを事前に作成する必要があります。これらの作業は、 AWS Schema Conversion Tool (AWS SCT) が利用可能です。AWS DMS を活用することで、短時間で安全かつ柔軟なデータベース移行が実現可能です。ただし AWS DMS は、柔軟な移行方式である一方、 ソースデータベースとしての制限 と ターゲットデータベースとしての制限 の双方があるため、プロジェクト初期フェーズでの確認が重要です。また、ソースデータベースのワークロードによっては同期性能が低下する場合やデータが正しく移行されない場合  (例: 文字コード変換による文字化け、制御文字の扱いなど) があるため、PoC (Proof of Concept) や各種テストを計画してください。 3-3. ファイルサーバー移行 ファイルサーバーのデータは、従来の転送プロトコルを使用して Amazon EC2 に転送できます。また、Amazon Simple Storage Service (Amazon S3) やマネージドファイルストレージサービスの移行方法も紹介します。 Amazon S3 へのデータ移行 Amazon S3 へのファイル転送方法について説明します。移行方式はオンラインとオフラインの2 つがあります。オンラインマイグレーションでは、AWS SDK や AWS CLI を使用して Amazon S3 の API を直接利用する方法がシンプルです。また Amazon S3 のPrivateLink や AWS Direct Connect を使用すれば、パブリックネットワークネットワークを経由せずにオンプレミスから Amazon S3にファイルを転送できます。 AWS Transfer Family を使用すれば、従来の FTP や SFTP などのプロトコルを使用して、データを Amazon S3 へと転送することができます。これにより、オンプレミスのサーバーのソフトウェア構成を変更せずに AWS 上にデータを送ることができます。オフラインマイグレーションでは AWS Snowball Edge または AWS Snowcone を使用し、大量のファイルを Amazon S3 に転送することも可能です。 マネージドファイルストレージサービスへのデータ移行 オンプレミスの Windows ファイルサーバーや NFS サーバーを AWS へ移行する方法について説明します。移行先としては、 Amazon EFS ( NFS プロトコル) 、 Amazon FSx for OpenZFS (NFS プロトコル)、 Amazon FSx for Windows File Server (SMB プロトコル) 、 Amazon FSx for NetApp ONTAP (NFS、SMB などのプロトコル) が利用できます。 オンラインマイグレーション に利用できるツールとして、 AWS DataSync がご利用できます。また、SnapMirror や robocopy などのオンプレミスでも使い慣れたツールもご利用できます。 オフラインマイグレーション では AWS Snowball Edge または AWS Snowcone を使用し、データの一括移行と差分のネットワーク転送を組み合わせます。移行対象データの量やネットワーク状況に応じて適切な方法を選択しましょう。 AWS Snowball Edge を利用した場合、大量のデータをオフラインで転送できるメリットがあるものの、メタデータが保持されない可能性があるため、プロジェクト初期フェーズでの確認が重要です。 4. 移行に付随するその他の作業 ここまでは主に、サーバー、データベース、データ (ファイル) に関する移行方法という技術的側面を説明してきました。実際にプロジェクトとしてシステム移行を考慮すると、サーバーやデータを移行する以外にもタスクがあります。これらのタスクは、 従来のオンプレミス間でのシステム移行と大きく変わるものではありません が、AWS を利用することで、各種テストなどの効率化が可能です。 4-1. アプリケーションテスト サーバーやデータを AWS へ移行した後は、移行したシステムの主要な機能をテストして、正常に動作していることを確認します。ユーザーが期待通りにシステムを利用できるかどうかを確認し、必要な修正や調整を行います。また、移行後のシステムのパフォーマンスをテストして、応答時間や処理能力などが要件を満たしているかどうかを確認します。 AWS であれば、移行したサーバーの Amazon Machine Image (AWS AMI) を取得し、そこからサーバーを複製することで複数の環境を作成し、並列で検証、テストを行うことが可能です。 4-2. システム移行時のサポート体制 システム移行のトラブル発生時のサポート体制や連絡体制の構築も重要です。ユーザ部門、システム部門、関連するシステムの関係部門などトラブルが発生した際の連絡体制を構築してください。AWSでは、本番切り替えなどの重要なイベントを実施する際に、 IEM (Infrastruture Event Managerment)  という特別なサポートを受けることが可能です。 4-3. 移行後の正常稼働の評価 本番運用を開始した後に、システムが正常に稼働していることの評価を行います。業務アプリケーションのイベントに合わせて、移行直後、週次バッチ後、月次バッチ後などのタイミングで、エラーの発生状況、性能やリソースの使用状況に問題がないかを確認します。 AWSはオンプレミス環境と比較して柔軟性に優れています。仮に、性能やリソース問題で性能チューニングが行われる期間中、一時的にリソースが必要になった場合にも柔軟に追加が可能で、性能チューニング完了後、不要なリソースを削減することも可能です。 5. まとめ ブログでは、オンプレミスから AWS への移行について、移行パターンの整理における切り口、データ転送経路やシステム移行をサポートする多様な AWS サービスを解説しました。移行パターンの整理や停止時間の考慮など、移行のポイントを押さえて十分な準備を行い、効率的かつスムーズな移行を実現しましょう。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM)　山崎 徹、甲斐 裕之 参考リンク これだけは押さえておきたい、AWS移行全12ツール一挙紹介！ AWS移行における移行プロセス 移行ツールを使ってWeb アプリケーションをAWS に移行したい – 目的別クラウド構成と料金試算例 はじめてAWS DMSを検討する際に読んでいただきたいこと AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証

本ブログの位置づけ AWS Customer Solutions Manager の山崎です。本ブログは現状オンプレミス上で多くの IT 資産が稼働しており、AWS への移行を考えたい、エンタープライズのお客様向けに作成しています。 オンプレミスから AWS への移行は評価、計画、移行、運用/最適化のフェーズに分かれます。本ブログは計画～移行のフェーズにおいて、個々のシステム群の移行をどのような切り口で整理するべきか 前編 ／ 後編 でまとめています。ここでいう個々のシステム群の移行とは、システムを構成するリソースであるアプリケーションサーバー、データベース、ファイルサーバーの移行を指します。 【移行全体のフェーズと本ブログの位置づけ】 本編に入る前に、AWS の移行における全体像と本ブログの位置づけを記載します。上図は AWS 移行全体のフェーズと、必要なワークストリームを クラウド導入フレームワーク (AWS CAF) の観点で整理した図です。AWS への移行では、まず評価フェーズから始まり、移行に係る総保有コストの分析 や準備状況評価、 移行戦略と移行パス (7R) の策定などを実施します。次に計画フェーズでは推進組織を立ちあげ、PoC (Proof of Concept、概念検証) や、移行計画策定を実施します。そして移行フェーズで IT 環境を整備したうえでシステム移行を実行し、運用/最適化フェーズにて運用の自動化などを実施します。本ブログは、移行計画の中でシステムごとの移行方法を確立し、IT 環境を整備する際に参考となる情報として位置づけられます。なお、その他のワークストリームで必要な情報は以下のブログもご参照ください。  6 つの視点で移行の準備状況を分析 MRA  (移行準備状況評価)  から見えるクラウド移行におけるよくある課題とその対策 推進組織の立ち上げ CCoE 活動検討のはじめの一歩 AWSのクラウド移行トータル支援プログラム AWS ITトランスフォーメーションパッケージ 2023 ファミリー AWS へのシステム移行検討のアプローチ システム移行では、個々のシステムが求められる要件、サービスレベル、リソースの種類を踏まえ、4 つのステップで進めます。 1. 移行パターンを整理し、2. データ転送経路を確保したうえで、3. 利用可能なAWS サービスを選択し、4. 移行と付随する作業を実行します。 従来のオンプレミスにおける移行では、物理的な制約からシステム停止時間が長くなる、人手を介することから人的ミスの混入が避けられないなどの課題がありました。しかしAWS が用意するサービス群を利用することで、効率よくスピーディに移行を実現できます。 一方で、移行時のシステム要件やサービスレベルの整理が不十分なままに移行方法を決めてしまうと、ビジネスに大きな影響を及ぼしたり、多大な工数・コストを費やしたりするリスクもあるため、システムの特性を踏まえて十分な検討を重ねましょう。 1. 移行のパターンの整理 システムの移行方針を考えるうえで、まず移行作業中に システムが許容できる停止時間 を見極めます。停止時間が長いほど、作業時間の確保が可能です。短時間しか停止が許されないシステムであれば、データの整合性を確保するための複雑な考慮が必要となります。これらは既存システムのサービスレベルや非機能要件をインプットに検討します。 また、システムの規模とトラブル時の影響範囲の大きさも考慮が必要です。規模の大きいシステムではトラブル時のリスクを極小化するため、一度に移行するのではなく移行単位の分割が選択肢に入ります。 1-1. 一括移行 一括移行は、既存システム全体を停止しシステムを一度に移行します。通常、規模の小さいシステムの移行で採用されます。システム停止中に移行作業を行うため、一般的に停止時間が長くなります。既存システムにデータが流入しないため、データ静止点が明確で整合性が担保しやすく、移行作業自体の難易度は低くなります。 許容されるシステムの停止時間が短く、すべてのデータを停止時間中に移行できない場合、 差分移行 を検討します。差分移行は、移行作業を複数のステップに分割し、データのスナップショットをあらかじめ新環境に転送しておきます。移行開始後に既存システムを停止し、転送したスナップショットから最新のデータまでの最終差分のみを停止時間中に新環境に反映します。最終差分を反映する時間だけがシステム停止時間となります。 1-2. 分割移行 大規模なシステムの移行では、システム全体を一度に移行すると停止時間の長期化や、トラブル時にビジネスに与える影響範囲が大きいリスクがあります。そのため、構成する機能ごとに移行する分割移行が選択肢となります。システムの停止時間は、機能のサービスレベルによって異なります。外部顧客に影響する機能はシステム停止時間を短くする必要がある、社内向けの機能は長い停止時間を確保できる、などです。機能ごとの依存関係を考慮して移行するため、移行難易度は高くなります。 分割パターンは様々です。例えばフロントシステム、ミドルシステム、バックエンドシステムと分割して各々を移行する、特定の業務や商品に関連する機能だけを移行し、特殊性の高い業務・商品を後から移行する、などです。 2. データ転送経路の確保 オンプレミスから AWS への移行において、AWS へのデータ転送経路をどのように設定するのかを考えます。データ転送経路は、転送速度、移行着手までのリードタイム、転送するデータ容量、回線・機器コストを考慮して検討します。 2-1. ネットワークによるデータ転送 専用線接続 AWS への専用ネットワーク接続には AWS Direct Connect が利用できます。AWS Direct Connect は専用線で独立した専用のネットワークであり、帯域が保証されているため安定したデータ転送が可能です。ただし、設置のためのリードタイムが長いため、十分な準備期間をとる必要があります。また、回線・機器コストがかかる点に注意が必要です。あらかじめ帯域を確保できているため、移行に要する時間を精緻に見積もる必要がある場合の選択肢となります。 AWS Direct Connect デリバリーパートナー 経由で払い出すことで、より柔軟で幅広い選択肢を利用できます。 インターネット接続 移行は専用線だけでなく、インターネットを経由して実行することもできます。ただし専用線接続と比べて帯域が確保されておらず、ベストエフォートでの転送となります。AWS VPN を利用することで安全かつ柔軟にデータを転送できます。AWS Direct Connect よりも短期間で設置可能であり、VPN 接続費用も安価です。移行開始までの期間が限られている場合や、設置コストを安価に済ませたい場合の選択肢となります。ただしデータ転送にかかる時間を事前に読み切ることができないため、移行完了までの時間を精緻に見積もりたい場合には向いていません。 2-2. 物理デバイスでのデータ転送 移行完了の目標時間に対して利用できるネットワーク帯域が十分でない場合や不安定な場合、またアーカイブデータの移行には、オフラインデバイスを活用することができます。 AWS Snowball Edge や AWS Snowcone は、安全で堅牢なデバイスを提供するサービスです。AWS のコンピューティング機能とストレージ機能を提供し、AWS との間でデータを転送できます。マネジメントコンソールからジョブを作成すると、後日指定した住所に発送されます。移行作業時間には物理デバイスの発送時間や対象環境へのコピーなどの時間を考慮する必要があります。 まとめ 前編では、AWS へのシステム移行検討のアプローチとして移行パターンの整理およびデータ転送経路の確保パターンについて整理しました。 後編 では、リソースごとの移行方法や活用できる AWS サービスについてご紹介していきます。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM)　山崎 徹、甲斐 裕之

AWS Step Functions は、ワークフローを通じてスケーラブルで分散型のサーバーレスアプリケーションを構築するための基礎ツールとして台頭しています。Step Functions チームは 2021 年に、 AWS マネジメントコンソール で Step Functions ワークフローを作成するためのローコードのビジュアルツールである Workflow Studio を立ち上げました。これにより、コーディングの経験が少ない人でもワークフローを構築できるようになりました。 お客様からのフィードバックに応えて、本日、Step Functions チームは包括的な新機能を導入しました。最も一般的なリクエストの一部に対応することで、構築体験がさらに直感的で汎用性が高まり、特定の開発アプローチに沿ったものになります。 What’s new? 最新リリースには、次の 3 つの新しいコンポーネントが含まれています。 スターターテンプレートエクスペリエンスの強化 : このアップデートは、開発者とビジネスユーザーに高度な基盤を提供し、ワークフローの作成とプロトタイプ作成を迅速に行うプロセスを効率化します。 Workflow Studio のコードモード : 本日、Workflow Studio には新しいコードモードが導入されました。これにより、ビルダーはデザインビューとコード構築ビューを切り替えることができます。この機能により、コンテキストを切り替える必要が減り、ワークフローの構築が迅速になります。たとえば、 Amazon States Language (ASL) のワークフロー定義を Step Functions Workflows Collection から直接 Workflow Studio にシームレスに貼り付けることができます。その後、デザインビューに移行してワークフロー開発を続行できます。または、新しい構築体験のスターターテンプレートを選択することもできます。必要に応じて、新しいコードモードに切り替えてきめ細かく調整できます。 ワークフローの実行と設定の強化 : このバージョンの Workflow Studio には、Workflow Studio 内の構築ビューから直接ワークフローを実行する機能も組み込まれています。さらに、権限、ロギング、トレースなどの補足的なワークフロー設定を構成して、ワークフロー管理を強化できます。 スターターテンプレートエクスペリエンスの導入 特筆すべき機能は、改善されたスターターテンプレートエクスペリエンスの導入です。これはワークフロー作成プロセスを迅速化するために設計された新しいインターフェースです。 ユースケースやサービスごとにテンプレートを絞り込むことができるため、プロジェクトのニーズに合った厳選されたテンプレートを選択できます。スターターテンプレートエクスペリエンスは強力な足がかりとなり、構築するための強固な基盤を築くことができます。 テンプレートからワークフローを作成する流れは下記のプロセスです。 AWS マネジメントコンソール の Step Functions ステートマシンページ に移動します。 [ステートマシンの作成] を選択します。 これにより、新しいテンプレート選択が表示されます。キーワードで検索するか、ユースケースとサービスでフィルタリングします。 [S3 で CSV ファイルを処理するための分散マップ] を選択し、 [次へ] を選択します。 次のビューには、ワークフローが視覚的に表示され、詳細な説明も表示されます。 各テンプレートには次の 2 つの使用オプションがあります。 デモの実行 : Step Functions は、ステートマシンとすべての関連リソースを備えた AWS CloudFormation スタックをアカウントに自動的にデプロイします。すぐに実行できるこのデモワークフローは、選択したテンプレートの機能を紹介するだけでなく、独自の構築を開始するきっかけにもなります。この基盤を土台に、お客様の仕様に適するようにワークフローをカスタマイズ、微調整、調整できます。 その上に構築する : これにより、ワークフローの ASL が新しい Workflow Studio コードビューに表示されます。重要なのは、この移行では関連するリソースは一切デプロイされないということです。目標は、ベストプラクティステンプレートを使用するワークフロー構築プロセスを迅速に行えるようにすると同時に、ゼロから構築しなくても特定のニーズに合わせてカスタマイズしたり調整したりできるようにすることです。 [デモの実行] を選択し、 [Use template] を選択します。これにより、ワークフローテンプレートは読み取り専用モードで Workflow Studio に配置されます。デモリソースをデプロイする前に、ワークフロー定義を詳しく調べることができます。 デモをデプロイするには、 [デプロイと実行] を選択します。 しばらくすると、デモアプリケーションがアカウントにデプロイされます。 ドラッグアンドドロップデザインとコードモード間のシームレスな移行 Workflow Studio のもう 1 つの強化点は、ドラッグアンドドロップのデザインビューと新しいコードモードをシームレスに切り替えられることです。この汎用性により、さまざまな好みやスキルセットに合わせて、ビジュアルデザインとコードベースの構築を切り替えることができます。デザインビューではワークフローを直感的に作成できますが、コードモードでは使い慣れたコーディング環境のような動的な空間が得られます。 以前にデプロイしたワークフローのデモを開くには、 ステートマシンのコンソール から選択して [編集] を選択します。 [Code] ボタンを選択して、コード構築ビューに切り替えます。 ここでは、 Visual Studio Code などの業界標準のコーディング環境を連想させるインターフェイスが表示されます。この変革により、経験豊富な開発者は ASL の可能性を最大限に活用して、複雑なカスタマイズや微調整が可能になります。また、右側のグラフビジュアライゼーションを使用して、簡単かつ迅速に順序を変更したり、ステップを複製、削除したりできるようになります。 [デザイン] ボタンを選択すると、ローコードエディターに戻ります。 これは、ASL の経験が少ないビルダーや、ワークフローのモックを迅速に構築する必要がある開発者、さらに編集するためのテンプレート、またはワークフローのプロトタイプを作成する必要がある開発者にとって理想的です。 Workflow Studio からワークフローを直接実行 Workflow Studio では、インターフェイス内からワークフローを開始できるようになりました。この機能は設計と実行の間のギャップを埋め、開発者は Workflow Studio の構築環境からワークフローを開始できます。 Workflow Studio 内からワークフローを開始するには、 [実行] ボタンを選択します。 これにより、Step Functions 実行インターフェースに直接移動し、入力ペイロードを入力してワークフローの実行を検査できます。この機能によりインターフェースを切り替える必要が減り、開発者はより迅速かつ効率的にイテレーションを行うことができます。 [ステートマシンの編集] を選択すると Workflow Studio に直接戻り、ワークフローを繰り返し調整できます。 Workflow Studio では、実行ロール権限の表示と編集、ロギングの設定、その他のパラメーターの調整もできるようになりました。このビューにアクセスするには、Workflow Studio から [設定] ボタンを選択します。 既存のワークフローの可用性 新機能は、追加費用なしで、既存のすべてのワークフローで自動的に利用できるようになります。これにより、追加の手順や設定を行わずに Workflow Studio の強化された機能を使用できるようになります。 Workflow Studio の新機能により、開発者は活動を強化できます。ワークフローの作成と実行を簡素化することで、開発者はより多くの時間とエネルギーをアプリケーション開発のクリエイティブな側面に注ぎ込むことができます。Workflow Studio の機能強化は、生産性を高めるだけでなく、クリエイティブなデザインを具体的でインパクトのあるアプリケーションに変えるためのプラットフォームも提供します。 結論 Workflow Studio は、Step Functions ワークフローを構築するプロセスを簡素化および強化するという継続的な目標のもと、進化を続けています。構築モードへのシームレスな遷移、直接実行する機能、改善されたスターターテンプレートエクスペリエンスの導入は、構築の効率と柔軟性の向上に向けた実用的な一歩であり、Workflow Studio を Step Functions のデフォルトの構築体験として確立しています。 その他のスターターテンプレート、パターン、ベストプラクティスについては、 Serverless Land の Serverless Workflows Collection をご覧ください。 翻訳はソリューションアーキテクトの松岡勝也が担当しました。原文は こちら です。

このブログはソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 このブログ記事では、 Amazon CodeCatalyst での .NET の使用に関する一連の投稿の最初の記事として、CodeCatalyst と AWS .NET deployment tool に含まれている ASP.NET Core Web API プロジェクトブループリントを使用して、.NET 6.0 ASP.NET Core Web API を構築して Amazon Elastic Container Service (Amazon ECS) にデプロイする方法について説明します。 Amazon CodeCatalystとは何ですか？ これは、ソフトウェア開発チーム向けの新しいクラウドベースの統合コラボレーションサービスです。継続的インテグレーションおよび継続的デリバリー (CI/CD) ツールのフルセットを提供し、開発チームが作業を計画し、コードで共同作業を行い、アプリケーションを構築、テスト、デプロイするのに役立ちます。CodeCatalyst は、開発者の生産性を高め、チームがより少ない労力でより多くのことを達成できるように支援する 豊富な機能セット を提供することでこれを実現します。 CodeCatalyst ビルドオプションについて ASP.NET 6.0 ベースの Web API をビルドおよびデプロイするための CodeCatalyst の全体的なエクスペリエンスについて説明する前に、CodeCatalyst が提供する .NET アプリケーションのビルド オプションについて説明します。CodeCatalyst には、 ワークフロー を実行するための 2 つのコンピュート タイプ があります： オンデマンドフリートは、 Amazon Elastic Compute Cloud (Amazon EC2) または AWS Lambda を使用してフルマネージド型の Linux ベースのコンピュートで、ビルドアクションの開始時にプロビジョニングされ、終了時にプロビジョニング解除されます。 プロビジョニングされたフリートは、CodeCatalyst が管理する Linux または Windows ベースの Amazon EC2インスタンスを提供します。プロビジョニングされたフリートを使用するには、価格は Standard ティア である必要があります。 .NET アプリケーションを構築するには、任意のフリートタイプとオペレーティングシステムを選択できます。このブログ記事では、オンデマンドフリートを使用して .NET Web API を構築します。今後のブログ記事では、Windows ベースのプロビジョニングされたフリートを使用して .NET Framework アプリケーションを構築する方法について説明します。 前提条件 以下の前提条件の一覧を確認して、ご使用の環境で以下のセクションで説明するすべての手順が実行できることを確認してください。次のものが必要です。 AWS ビルダー ID。 作成方法 は製品ドキュメントに記載されています。 CodeCatalyst スペース へのアクセス。 自分で作成する方法 、または 招待を受ける方法 については、製品ドキュメントを参照してください。 CodeCatalyst スペースに追加された AWS アカウント。これは、デプロイするインフラストラクチャが AWS 内にあるためです。詳細は、 製品ドキュメント をご覧ください。 スペースに追加する AWS アカウントの AWS Identity and Access Management (IAM) ロールで、CodeCatalyst をそのアカウントにデプロイできるようにします。このチュートリアルでは、 製品ドキュメント の手順に従って、 CodeCatalystPreviewDevelopmentAdministrator IAM ロールを作成し、CodeCatalyst スペースにアタッチします。ベストプラクティスとして、これらのロールには、チームの運用に必要な最小限のアクセス許可を割り当ててください。 CodeCatalyst プロジェクトの作成 前提条件を満たしたら、CodeCatalyst で プロジェクト を作成できます。 CodeCatalyst アカウント にログインし、CodeCatalyst スペースに移動します。[プロジェクトの作成] を選択し、[ブループリントで開始] オプションを選択します （図 1）。 ブループリントは、アプリケーションのサポートファイルや依存関係を生成し、拡張するプロジェクト・シンセサイザーです。 図 1: CodeCatalyst .NET ブループリント画面 [ブループリントの選択] 検索ボックスに “.NET” と入力します。.NET アプリケーションで使用可能なブループリントの一覧が表示されます。このブログ記事を書いている時点では、次の 2 つのブループリントを使用できます。 ASP.NET Core Web API : CI/CD ワークフローと共に ASP.NET Core 6.0 Web API プロジェクトを作成し、アプリケーションをビルドして選択した AWS サービスにデプロイします。 .NET serverless application : アプリケーションをビルドして AWS Lambda にデプロイする CI/CD ワークフローと共に、.NET 6.0 AWS サーバーレスアプリケーションプロジェクトを作成します。 ブループリントを選択すると、右側にサイドパネルが表示され、詳細な説明、アーキテクチャの概要、接続とアクセス許可、およびブループリントによって作成されるプロジェクトリソースが表示されます （図 2）。 図 2: ASP.NET Core Web API ブループリントの説明画面 このブログでは、 ASP.NET Core Web API ブループリントの使用について説明します。そのオプションを選択し、[次へ] を選択してプロジェクトの設定を続行します。 次の画面（図 3）では、CodeCatalyst がプロジェクトを作成するための構成オプションを提供します。このブループリントでは、次の情報を指定する必要があります。 図 3: ASP.NET Core Web API ブループリント構成画面 プロジェクト名（必須） : CodeCatalyst はそれを使用して、プロジェクトとデフォルトのソースコードリポジトリに名前を付けます。 環境（必須） : AWS アカウント接続とデプロイロール : デプロイ先の AWS アカウントと、アプリケーションのデプロイ時に CodeCatalyst が使用するロール。 [AWS アカウントなし] を選択した場合は後で追加できますが、追加するまでワークフローは正常に実行されません。 言語 : ソース コードを作成するために使用する .NET プログラミング言語。C# または F# を選択できます。 AWS デプロイサービス : アプリケーションのデプロイ先としてサポートされている AWS サービス。[なし] を選択した場合、ワークフローファイルにはアプリケーションを AWS にデプロイするためのアクションは含まれません。 コード（オプション） : コードリポジトリ名 : ソースコードリポジトリの名前。 .NET プロジェクト名 : 作成するプロジェクトと名前空間の名前。 本稼働環境のデプロイ : これを選択すると、負荷分散と AWS のサービスに割り当てられたより大きなリソースの両方を含む設定が使用されます。 AWS リージョン : アプリケーションをデプロイするリージョン。 画面の右側（図 4）には、前の画面と同じ説明を含む、ブループリントに関する情報が表示されます。また、 [コードの表示] と [ワークフローの表示] の 2 つの追加ボタンもあります。 図 4: ASP.NET Core Web API ブループリント情報画面 [コードの表示] を選択すると、プロジェクト構成に基づいてブループリント テンプレートによって生成されるコードファイルを調べることができるパネルが表示されます （図 5）。構成を変更すると、生成されたファイルが自動的に更新されます。 図 5: ASP.NET Core Web API ブループリントコードのプレビュー画面 [ワークフローの表示] を選択すると、ワークフローエディターが表示されます（図 6）。CodeCatalyst がプロジェクト構成に基づいて作成するワークフローを視覚的にまたは YAML 形式で表示します。プロジェクト構成を変更すると、生成されたコード ビューの場合と同様に、ワークフローが更新されます。 図 6: ASP.NET Core Web API ブループリント ワークフローのプレビュー画面 この例では、言語として C# を選択し、 デプロイサービス として Amazon Elastic Container Service を選択します。 [プロジェクトの作成] を選択して、プロジェクトの作成を開始します（図 7）。これは数秒で完了するはずです。 図7:プロジェクト作成画面 生成されたファイルの探索 プロジェクトの作成が完了すると、プロジェクトの概要画面にリダイレクトされます。プロジェクトを構成するリポジトリ、ワークフロー、プルリクエストなどの情報を表示できます。プロジェクトの [概要] 画面 で、 [リポジトリの表示] ボタンを選択して、既定のソースコードリポジトリに移動します （図 8）。 図8:プロジェクトリポジトリ画面 プロジェクトのリポジトリページでは、ブループリントによって生成されたソースコードの構造が次のようになっていることが分かります（図 9 参照）。 図 9: ASP.NET Core Web API ブループリントで生成されたコード構造 次のフォルダーに注意してください。 .cloud9 : 開発環境として使用する場合に AWS Cloud9 を設定するために使用される AWS Cloud9 ランナー が含まれます。 .codecatalyst deployment-settings : AWS Elastic Beanstalk (Windows & Linux)、 AWS AppRunner 、および Amazon ECS 上の AWS Fargate にデプロイするときに .NET デプロイで使用されるさまざまなデプロイ設定ファイルが含まれています。各ファイルには、本番用と非本番用の 2 種類があります。 workflows : アプリケーションをビルドしてデプロイするための CodeCatalyst ワークフローの YAML コードが含まれています。 .vscode : 開発環境として使用する場合の Visual Studio Code の既定の構成が含まれています。 src : プロジェクトのソースコードが含まれます。 tests : プロジェクトの単体テストが含まれます。 “devfile.yaml” という名前のファイルも作成されます。これは、 CodeCatalyst 開発環境 を構成するために使用されます。 続行する前に、ファイル構造をより詳細に確認して、CI/CD ワークフローで作成およびデプロイされる内容を理解することをお勧めします。 デフォルトの CI/CD ワークフローの探索 CodeCatalyst では、ワークフローは、CI/CD システムの一部としてコードをビルド、テスト、およびデプロイする方法を説明する自動化された手順です。ワークフローの実行中に実行する一連の手順またはアクションを定義し、ワークフローを開始するイベントまたはトリガーも定義します。 次に、ASP.NET Core Web API ブループリントによって生成されたワークフローを調べます。ナビゲーション メニューで、 [CI/CD] メニューを展開し、 [ワークフロー] を選択します（図 10）。 図 10: CodeCatalyst ワークフローメニュー項目 すでに pull-request と main の2つのワークフローが作成されていることに注意しましょう。 pull-request ワークフローはプルリクエストに応じて実行され、 main ワークフローは新しいコミットがリポジトリの main ブランチにプッシュされたときに実行されます。 main ワークフローには、 pull-request ワークフローと同じステップに加え、デプロイステップがあります。 main ワークフローを選択して、その構成を調べてみましょう（図11） 図 11: ASP.NET Core Web API ブループリントで生成されたワークフロー 次の画面で、 [Definition] タブを選択して、ワークフローの視覚的な表現と YAML 定義を並べて表示します（図12）。 図 12: ASP.NET Core Web API ブループリントのメインワークフロー YAML ワークフローは、次の 3 つの主要な要素で構成されています。 Triggers : コミットがメインブランチにプッシュされるたびにワークフローを開始します。 Build_And_Test : デフォルトのビルドイメージ で実行されている .NET 6 CLI を使用して、コードをビルドしてテストします。そして、 ./TestResults フォルダーにあるテストレポートを検索し、その結果を画面に表示します。 Deploy_To_AWS : AWS Deploy Tool for .NET を使用してアプリケーションを AWS にデプロイします。Amazon Linux 用の zip yum パッケージのような必要な依存関係をインストールし、使用する AWS 接続を設定します。 –apply に渡す JSON ファイルを変更することで、デプロイ先の AWS サービスを簡単に変更できます。 デフォルトの CI/CD ワークフローの実行 メインワークフローは、CodeCatalyst プロジェクトを作成するとすぐに初めて自動的に実行されます。この最初の実行は、完了するまでに 15 分から 30 分かかります。完了したら、図 13 に赤枠で示すように、 Deploy_To_AWS アクション内で、 dotnet aws deploy コマンドのログの末尾にあるエンドポイントの Amazon ECS サービスロードバランサー URL に移動して、デプロイされたアプリケーションを確認できます。 図 13: ASP.NET Core Web API ブループリント成功実行ログ AWS.NET デプロイツールの設定を調べる AWS Deploy Tool for .NET は、.NET CLI と AWS Toolkit for Visual Studio の両方に対応するインタラクティブなツールであり、最小限の AWS 知識と数回のクリックまたはコマンドで .NET アプリケーションをデプロイできます。AWS Deploy Tool for .NET コマンドラインツールは、1 つのコマンドでアプリケーションをデプロイできるため、CI/CD に最適です。AWS Deploy Tool for .NET は、デプロイレシピとデプロイ設定の概念を通じて、 複数のアプリケーションタイプと AWS コンピューティングサービス をサポートします。 .codecatalyst/deployment/settings/non-prod/ecs-fargate-deployment-settings.json でデプロイ設定の内容を調べることができます。このファイルは、.NET アプリケーション（この場合は AspNetAppEcsFargate ）をデプロイするために使用するレシピを定義し、レシピで定義されたデフォルト値の一部をオーバーライドします。 AspNetAppEcsFargate レシピの場合、Amazon ECS クラスタ名、vCPU 数、Amazon ECS タスク定義で使用するメモリ量などのオプションを上書きします。このレシピと他のすべてのレシピのオプション設定の詳細については、 公式の GitHub repo を参照してください。 AspNetAppEcsFargate レシピを使用してアプリケーションをデプロイすると、.NET デプロイツールは次のタスクを実行します。 プロジェクト内の Dockerfile を検索し、 docker build を実行します。Dockerfile が見つからない場合は、ツールが Dockerfile を試みます 。 コンテナイメージをプッシュするための Amazon Elastic Container Registry (Amazon ECR) を作成します。 コンテナイメージを Amazon ECR リポジトリにプッシュします。 レシピに関連付けられた AWS Cloud Development Kit (AWS CDK) プロジェクトを、デプロイ設定ファイルで上書きした値でデプロイします。 ロードバランサーエンドポイントなどのコンソール AWS リソースの詳細に出力します。 レシピがデフォルトで作成するリソースがアプリケーションに必要なものでない場合は、カスタム デプロイプロジェクト を作成して、ニーズに合わせてカスタマイズできる AWS CDK プロジェクトを作成できます。 クリーンアップ 今後の課金を避けるために、CodeCatalyst ワークフローによって作成されたリソースを削除してください。このブログ記事で提供されている値を使用した場合、リソースは名前が付けられます： AWS CloudFormation stack: CompanyHelloWebAPI Amazon ECR repository: companyhellowebapi まとめ このブログ記事では、ASP.NET Core Web API ブループリントを使用して、Amazon ECS 上の AWS Fargate に .NET アプリケーションをデプロイする方法を学びました。ブループリントは、ソースコードリポジトリ、サンプルソースコード、CI/CD ワークフローを持つプロジェクトを作成し、AWS にデプロイする準備をすべて整えました。 これは、アプリケーションの道のりの出発点にすぎません。次に、独自のソースコードをプッシュし、独自のアプリケーションのニーズに合わせて CI/CD ワークフローを変更できます。 CodeCatalyst ブループリントがどのように .NET アプリケーションの開発を迅速に開始し、より生産的にするのに役立つかについてのアイデアがあれば、 .NET on AWS の公式 Twitter ハンドル で共有してください。AWS 上で .NET アプリケーションを実行するための追加情報やリソースについては、 .NET on AWS をご覧ください。 AWS は、貴社がクラウドを最大限に活用する方法を評価するお手伝いをします。クラウドでの最も重要なアプリケーションの移行とモダナイズで AWS を信頼する何百万ものお客様の仲間入りをしてください。Windows Server または SQL Server の最新化の詳細については、 Windows on AWS をご覧ください。モダナイゼーションの旅を始めるには、今すぐ お問い合わせ ください。 投稿者について Cristobal Espinosa は Amazon Web Services のシニアソリューションアーキテクトです。AWS 上で稼働する .NET アプリケーションのモダナイゼーションを専門に支援。2009 年以来、オープン Web 技術、Kubernetes、CI/CD、クラウドネイティブサービスを使用して、レガシー .NET アプリケーションの近代化を支援しています。 Jagadeesh Chitikesi は、AWS のシニア マイクロソフト スペシャリスト ソリューション アーキテクトです。彼は過去20年間、ヘルスケア、金融、小売、公益事業、政府のあらゆる規模の企業で開発者およびアーキテクトとして働いていました。彼はクラウドとAWSで起こっているすべてのイノベーションに情熱を注いでいます。

この記事は、Professional Services team の Principal Bigdata Consultant である Takeshi Nakatani と Amazon QuickSight の Specialist Solution Architect である Wakana Vilquin-Sakashita によって書かれた Manage users and group memberships on Amazon QuickSight using SCIM events generated in IAM Identity Center with Azure AD (記事公開日: 2023 年 3 月 22 日) を翻訳したものです。 Amazon QuickSight は、ID フェデレーションをサポートするクラウドネイティブでスケーラブルなビジネスインテリジェンス (BI) サービスです。 AWS Identity and Access Management (IAM) により、組織はエンタープライズ ID プロバイダー (IdP) で管理されている ID を使用し、シングルサインオン (SSO) を QuickSight に統合できます。オンプレミスアプリ、サードパーティアプリ、AWS 上のアプリケーションなど、すべてのアプリケーションを使用して一元化されたユーザー ID ストアを構築する組織が増えているため、これらのアプリケーションへのユーザープロビジョニングを自動化し、その属性を一元化されたユーザー ID ストアと同期させるソリューションが必要です。 ユーザーのリポジトリを構築する際、組織によっては、ユーザーをグループにまとめたり、属性 (部署名など) を使用したり、あるいはその両方を組み合わせたりします。組織で一元管理された認証に Microsoft Azure Active Directory (Azure AD) を使用し、そのユーザー属性を利用してユーザーの構成を管理している場合は、すべての QuickSight アカウント間のフェデレーションを有効にできるだけでなく、AWS プラットフォームで生成されたイベントを使用して QuickSight のユーザーとそのグループメンバーシップを管理できます。これにより、システム管理者は Azure AD からユーザー権限を一元管理できます。このソリューションにより、QuickSight のユーザーやグループのプロビジョニング、更新、削除を、QuickSight 上で管理する必要がなくなり、自動同期にて Azure AD の情報と一貫性を保つことができるようになります。 この記事では、Azure AD の自動プロビジョニングが有効になっている AWS アイデンティティセンター (AWS Single Sign-On の後継) を介して QuickSight と Azure AD 間のフェデレーション SSO を設定するために必要な手順について説明します。また、クロスドメインID管理システム (SCIM) イベントを使用して、ユーザーとグループのメンバーシップを自動的に更新するデモも行います。 ソリューション概要 次の図は、ソリューションのアーキテクチャとユーザーフローを示しています。 この記事では、IAM Identity Center を使用してユーザーと AWS アカウントやクラウドアプリケーションへのアクセスを一元管理できます。Azure AD はユーザーリポジトリであり、IAM Identity Center で外部 IdP として設定されています。このソリューションでは、特に Azure AD での 2 つのユーザー属性 ( department , jobTitle ) の使用方法を示します。IAM Identity Center は、SCIM v2.0 プロトコルを使用して Azure AD から IAM Identity Center へのユーザーおよびグループ情報の自動プロビジョニング (同期) をサポートしています。このプロトコルでは、Azure AD の属性が IAM Identity Center に渡され、IAM Identity Center で定義されたユーザープロファイルの属性に継承されます。IAM Identity Center は、SAML (Security Assertion Markup Language) 2.0 とのアイデンティティフェデレーションもサポートしています。これにより、IAM Identity Center は Azure AD を使用して ID を認証できます。その後、ユーザーは QuickSight などの SAML をサポートするアプリケーションに SSO で接続できます。この記事の前半では、これをエンドツーエンドで設定する方法に焦点を当てています (図の Sign-In Flow を参照)。 次に、ユーザー情報は SCIM プロトコルを介して Azure AD と IAM Identity Center の間で同期され始めます。 Amazon EventBridge でキャプチャされた IAM Identity Center から発生した CreateUser SCIM イベントによってトリガーされる AWS Lambda 関数を使用して、QuickSight でのユーザーの作成を自動化できます。同じ Lambda 関数で、指定したグループ (名前が department-jobTitle という2つのユーザー属性で構成されるもの) に追加することでユーザーのメンバーシップも更新できます。グループが存在しない場合は、メンバーシップを追加する前にグループを作成してください。 この記事では、この自動化の部分は、次のセクションで説明する内容と重複するため、省略しています。 この記事では、Azure AD でのユーザープロファイルの更新によってトリガーされる UpdateUser SCIM イベントについて説明し、そのデモを行います。イベントは EventBridge でキャプチャされ、Lambda 関数を呼び出して QuickSight のグループメンバーシップを更新します (図の Update Flow を参照)。この例では、特定のユーザーは一度に 1 つのグループにのみ所属することになっているため、この関数はユーザーの現在のグループメンバーシップを新しいグループメンバーシップに置き換えます。 パート I では、IAM Identity Center 経由で Azure AD から QuickSight への SSO を設定します。(サインインフロー) Azure AD を IAM Identity Center の外部 IdP として設定します。 Azure AD に IAM Identity Center アプリケーションを追加して設定します。 IAM Identity Center の設定を完了します。 Azure AD と IAM Identity Center の両方で SCIM 自動プロビジョニングを設定し、IAM Identity Center 上でその動作を確認します。 IAM Identity Center に QuickSight アプリケーションを追加して設定します。 SAML IdP と SAML 2.0 フェデレーション IAM ロールを設定します。 QuickSight アプリケーションで属性を設定します。 AWS コマンドラインインターフェイス (AWS CLI) または API を使用して、ユーザー、グループ、およびグループのメンバーシップを手動で作成します。 IAM Identity Center ポータルから QuickSight にログインして、設定を確認します。 パート II では、SCIM イベント時にグループのメンバーシップを変更する自動化を設定します。(更新フロー) EventBridge の SCIM イベントとイベントパターンについて理解しましょう。 グループ名の属性マッピングを作成します。 Lambda 関数を作成します。 イベントをトリガーする EventBridge ルールを追加します。 Azure AD のユーザー属性値を変更して構成を確認します。 前提条件 このチュートリアルでは、次の前提条件を満たしている必要があります。 IAM Identity Center の設定。手順については、 AWS IAM Identity Center のユーザーガイドの「はじめに」 のステップ 1 ～ 2 を参照してください。 QuickSight アカウントのサブスクリプション。 IAM に関する基本的な知識と、IAM IdP の作成に必要な権限、ロール、およびポリシーの理解。 Azure AD のサブスクリプション。Azure AD 上に以下の属性をもつ少なくとも一人のユーザが登録されている必要があります。 userPrincipalName – Azure AD ユーザーの必須フィールド。 displayName – Azure AD ユーザーの必須フィールド。 Mail – IAM Identity Center が QuickSight と連携するための必須フィールド。 jobTitle – ユーザーをグループに割り当てるのに使用。 department – ユーザーをグループに割り当てるのに使用。 givenName – オプションフィールド。 surname – オプションフィールド。 パート I: IAM Identity Center 経由で Azure AD から QuickSight に SSO をセットアップする このセクションでは、サインインフローを設定する手順を示します。 IAM Identity Center で外部 IdP を Azure AD として設定する 外部 IdP を設定するには、次の手順を実行します。 IAM Identity Center のコンソールで、 Settings を選択します。 Identity source タブで Actions を選択し、 Change identity source を選択します。 External identity provider を選択し、 Next を選択します。 IdP メタデータが表示されます。このブラウザタブは開いたままにしてください。 Azure AD での IAM Identity Center アプリケーションの追加と設定 IAM Identity Center アプリケーションをセットアップするには、次の手順を実行します。 新しいブラウザタブを開きます。 Azure 管理者の認証情報を使用して Azure AD ポータルにログインします。 Azure services で Azure Active Directory を選択します。 ナビゲーションペインの Manage で、 Enterprise applications を選択し、 New application を選択します。 Browse Azure AD Galley セクションで IAM Identity Center を検索し、 AWS IAM Identity Center (AWS Single Sign-On の後継) を選択します。 アプリケーションの名前を入力し (この記事では IIC-QuickSight を使用しています)、 Create を選択します。 Manage セクションで、 Single sign-on を選択し、次に SAML を選択します。 Assign users and groups セクションで、 Assign users and groups を選択します。 Add user/group を選択し、少なくとも 1 人のユーザーを追加します。 役割として User を選択します。 Set up single sign on セクションで、 Get started を選択します。 Basic SAML Configuration セクションで、 Edit を選択し、次のパラメータと値を入力します。 Identifier – IAM Identity Center issuer URL フィールドの値。 Reply URL – IAM Identity Center Assertion Consumer Service (ACS) URL フィールドの値。 Sign on URL – 空欄のままにしておきます。 Relay State – 空欄のままにしておきます。 Logout URL – 空欄のままにしておきます。 Save を選択します。 設定は次のスクリーンショットのようになるはずです。 SAML Certificates セクションで、 Federation Metadata XML ファイルと Certificate (Raw) ファイルをダウンロードします。 これで、Azure AD SSO の設定は完了です。後でこのページに戻って自動プロビジョニングを設定するので、このブラウザタブは開いたままにしておいてください。 IAM Identity Center の設定を完了 次の手順で IAM Identity Center の設定を完了します。 前のステップで開いたままにしておいた IAM Identity Center コンソールのブラウザタブに戻ります。 Identity provider metadata プロバイダーメタデータセクションの IdP SAML metadata については、 Choose file を選択します。 以前にダウンロードしたメタデータファイル ( IIC-QuickSight.xml ) を選択します。 Identity provider metadata セクションにある IdP certificate については、 Choose file を選択します。 以前にダウンロードした証明書ファイル ( IIC-QuickSight.cer ) を選択します。 Next を選択します。 ACCEPT と入力し、 Change Identity provider source を選択します。 Azure AD と IAM Identity Center の両方に SCIM 自動プロビジョニングをセットアップ プロビジョニング方法はまだ Manual (non-SCIM) に設定されています。このステップでは、IAM Identity Center がユーザーを認識できるように自動プロビジョニングを有効にします。これにより、QuickSight への ID フェデレーションが可能になります。 Automatic provisioning セクションで、Enable を選択します。 Access token を選択してトークンを表示します。 Step 1 で開いたままにしていたブラウザータブ (Azure AD) に戻ります。 Manage セクションで、 Enterprise applications を選択します。 IIC-QuickSight を選択し、次に Provisioning を選択します。 Provisioning Mode で Automatic を選択し、次の値を入力します。 Tenant URL — SCIM endpoint フィールドの値。 Secret Token — Access token フィールドの値。 Test Connection を選択します。 テスト接続が正常に完了したら、 Provisioning Status を On に設定します。 Save を選択します。 SCIM プロトコルを使用して自動プロビジョニングを開始するには、 Start provisioning を選択します。 プロビジョニングが完了すると、1 人以上のユーザーが Azure AD から IAM Identity Center に伝達されます。次のスクリーンショットは、IAM Identity Center 上にプロビジョニングされたユーザーを示しています。 この SCIM プロビジョニングでは、IAM Identity Center から発生したイベントによってトリガーされる Lambda 関数を使用して QuickSight のユーザーを作成する必要があることに注意してください。この記事では、AWS CLI を使用してユーザーとグループのメンバーシップを作成します (Step 8)。 IAM Identity Center での QuickSight アプリケーションの追加と設定 このステップでは、IAM Identity Center で QuickSight アプリケーションを作成します。また、アプリケーションが動作するように IAM SAML プロバイダー、ロール、およびポリシーを設定します。次の手順を実行してください。 IAM Identity Center コンソールの Applications ページで、 Add Application を選択します。 Select an application に Pre-integrated application に quicksight と入力します。 Amazon QuickSight を選択し、 Next を選択します。 Display name に Amazon QuickSight などの名前を入力します。 IAM Identity Center SAML metadata file の下の Download を選択し、コンピューターに保存します。 他のフィールドはすべてそのままにして、設定を保存します。 作成したアプリケーションを開いて、 Assign Users を選択します。 先に SCIM 経由でプロビジョニングされたユーザーが一覧表示されます。 アプリケーションに割り当てるユーザーをすべて選択します。 SAML IdP と SAML 2.0 フェデレーション IAM ロールの設定 IAM Identity Center の IAM SAML IdP と、 IAM ロールをセットアップするには、以下の手順を実行します。 IAM コンソールのナビゲーションペインで Identity providers を選択し、 Add provider を選択します。 Provider type として SAML を選択し、 Provider name として Azure-IIC-QS を入力します。 Metadata document で Choose file を選択し、以前にダウンロードしたメタデータファイルをアップロードします。 Add provider を選択して設定を保存します。 ナビゲーションペインで Roles を選択し、次に Create role を選択します。 Trusted entity type で、 SAML 2.0 federation を選択します。 Choose a SAML 2.0 provider で、作成した SAML プロバイダーを選択し、 Allow programmatic and AWS Management Console access を選択します。 Next を選択します。 Add Permission ページで、 Next を選択します。 この記事では、AWS CLI コマンドを使用して QuickSight ユーザーを作成しているため、許可ポリシーは作成しません。ただし、QuickSight のセルフプロビジョニング機能が必要な場合は、(QuickSight ユーザーのロールに応じて) CreateReader 、 CreateUser 、 CreateAdmin アクションの許可ポリシーが必要です。 Name, review, and create ページの Role details に、ロールとして qs-reader-azure と入力します。 Create role を選択します。 ロールの ARN をメモしておきます。 ARN を使用して IAM Identity Center アプリケーションの属性を設定します。 QuickSight アプリケーションでの属性の設定 IAM SAML IdP と IAM ロールを IAM Identity Center の QuickSight アプリケーションに関連付けるには、以下の手順を実行します。 IAM Identity Center コンソールのナビゲーションペインで、 Applications を選択します。 Amazon QuickSight アプリケーションを選択し、 Actions メニューで Edit attribute mappings を選択します。 Add new attribute mapping を選択します。 次の表でマッピングを設定します。 User attribute in the application Maps to this string value or user attribute in IAM Identity Center Subject ${user:email} https://aws.amazon.com/SAML/Attributes/RoleSessionName ${user:email} https://aws.amazon.com/SAML/Attributes/Role arn:aws:iam:: <ACCOUNTID> :role/qs-reader-azure,arn:aws:iam:: <ACCOUNTID> :saml-provider/Azure-IIC-QS https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email ${user:email} 次の値に注意してください。 <ACCOUNTID> をAWS アカウント ID に置き換えてください。 PrincipalTag:Email は、QuickSight 管理ページで有効にする必要があるセルフプロビジョニングユーザー向けのメール同期機能用です。この記事では、ユーザーを AWS CLI コマンドで登録するので、この機能を有効にしないでください。 Save changes を選択します。 AWS CLI を使用してユーザー、グループ、およびグループメンバーシップを作成する 前述のように、このソリューションでは QuickSight のユーザーとグループが手動で作成されます。これらを以下の AWS CLI コマンドで作成します。 最初のステップは、以前に作成した IAM ロールと Azure AD に登録されているメールアドレスを指定して QuickSight でユーザーを作成することです。2 番目のステップでは、最初のステップで作成したユーザーのために、Azure AD の属性値を組み合わせた名称でグループを作成します。3 番目のステップは、以前に作成したグループにユーザーを追加することです。 member-name は、QuickSight で作成された <IAM Role name>/<session name> で構成されるユーザー名を示します。次のコードを参照してください。 aws quicksight register-user \ --aws-account-id <ACCOUNTID> --namespace default \ --identity-type IAM --email <email registered in Azure AD> \ --user-role READER --iam-arn arn:aws:iam:: <ACCOUNTID> :role/qs-reader-azure \ --session-name <email registered in Azure AD> aws quicksight create-group \ --aws-account-id <ACCOUNTID> --namespace default \ --group-name Marketing-Specialist aws quicksight create-group-membership \ --aws-account-id <ACCOUNTID> --namespace default \ --member-name qs-reader-azure/<email registered in Azure AD> \ –-group-name Marketing-Specialist この時点で、Azure AD、IAM Identity Center、IAM、および QuickSight のエンドツーエンド構成は完了しています。 IAM Identity Center ポータルから QuickSight にログインして設定を確認します。 これで、IdP が開始する SSO フローを使用して QuickSight にログインする準備ができました。 ブラウザで新しいプライベートウィンドウを開きます。 IAM Identity Center ポータル ( https://d-xxxxxxxxxx.awsapps.com/start ) にログインします。 Azure AD のログインプロンプトにリダイレクトされます。 Azure AD の認証情報を入力します。 IAM Identity Center ポータルにリダイレクトされます。 IAM Identity Center ポータルで、 Amazon QuickSight を選択します。 QuickSight ホームに自動的にリダイレクトされます。 パート II: SCIM イベント発生時のグループメンバーシップ変更の自動化 このセクションでは、更新フローを設定します。 EventBridge の SCIM イベントとイベントパターンを理解する Azure AD 管理者が特定のユーザープロファイルの属性に変更を加えると、その変更は SCIM プロトコル経由で IAM Identity Center のユーザープロファイルと同期され、アクティビティは sso-directory.amazonaws.com (IAM Identity Center) をイベントソースとして、 UpdateUser という名前のイベントで AWS CloudTrail に記録されます。同様に、 CreateUser イベントは Azure AD でユーザーが作成されたときに記録され、 DisableUser イベントはユーザーが無効になったときに記録されます。 Event history ページの次のスクリーンショットは、2 つの CreateUser イベントを示しています。1 つは IAM Identity Center によって記録され、もう 1 つは QuickSight によって記録されます。この記事では、IAM Identity Center のものを使用します。 EventBridgeがフローを適切に処理できるようにするには、イベントパターンと一致させたいイベントのフィールドを各イベントで指定する必要があります。次のイベントパターンは、SCIM 同期時に IAM Identity Center で生成される UpdateUser イベントの例です。 { “source”: [“aws.sso-directory”], “detail-type”: [“AWS API Call via CloudTrail”], “detail”: { “eventSource”: [“sso-directory.amazonaws.com”], “eventName”: [“UpdateUser”] } } この記事では、 UpdateUser SCIM イベントによってトリガーされる QuickSight のグループメンバーシップの自動更新について説明します。 グループ名の属性マッピングを作成 Lambda 関数が QuickSight のグループメンバーシップを管理するには、2 つのユーザー属性 ( department と jobTitle ) を取得する必要があります。プロセスを簡単にするために、Azure AD の属性マッピング機能を使用して、Azure AD の 2 つの属性 ( department , jobTitle ) を IAM Identity Center の 1 つの属性 ( title ) にまとめています。次に、IAM Identity Center は title 属性をこのユーザーの指定グループ名として使用します。 Azure AD コンソールにログインし、 Enterprise Applications 、 IIC-QuickSight 、および Provisioning に移動します。 Edit attribute mappings を選択します。 Mappings で、 Provision Azure Active Directory Users を選択します。 Azure Active Directory Attributes のリストから jobTitle を選択します。 次の設定を変更します。 Mapping Type – Expression Expression – Join("-", [department], [jobTitle]) Target attribute – title Save を選択します。 これで、プロビジョニングの設定は完了です。 属性は IAM Identity Center で自動的に更新されます。更新されたユーザープロファイルは、次のスクリーンショットのようになります (最初の図は Azure AD、その次の図が IAM Identity Center)。 Lambda 関数を作成する 次に、SCIM イベント時に QuickSight グループのメンバーシップを更新する Lambda 関数を作成します。この機能の中核となるのは、トリガーされたイベント情報に基づいて IAM Identity Center でユーザーの title 属性値を取得し、そのユーザーが QuickSight に存在することを確認することです。グループ名がまだ存在しない場合は、QuickSight でグループを作成し、ユーザーをグループに追加します。次の手順を実行してください。 Lambda コンソールで、 Create function を選択します。 Name に UpdateQuickSightUserUponSCIMEvent と入力します。 Runtime には Python 3.9 を選択します。 Time Out には、15 秒に設定します。 Permissions については、以下の権限を含む IAM ロールを作成してアタッチします (信頼できるエンティティ (プリンシパル) は lambda.amazonaws.com でなければなりません)。 { "Version": "2012-10-17", "Statement": [ { "Sid": "MinimalPrivForScimQsBlog", "Effect": "Allow", "Action": [ "identitystore:DescribeUser", "quicksight:RegisterUser", "quicksight:DescribeUser", "quicksight:CreateGroup", "quicksight:DeleteGroup", "quicksight:DescribeGroup", "quicksight:ListUserGroups", "quicksight:CreateGroupMembership", "quicksight:DeleteGroupMembership", "quicksight:DescribeGroupMembership", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } IdentityStore と QuickSight 用の Boto3 SDK を使用して Python コードを記述します。以下はサンプルの Python コード全体です。 import sys import boto3 import json import logging from time import strftime from datetime import datetime # Set logging logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): ''' Modify QuickSight group membership upon SCIM event from IAM Identity Center originated from Azure AD. It works in this way: Azure AD -> SCIM -> Identity Center -> CloudTrail -> EventBridge -> Lambda -> QuickSight Note that this is a straightforward sample to show how to update QuickSight group membership upon certain SCIM event. For example, it assumes that 1:1 user-to-group assigmnent, only one (combined) SAML attribute, etc. For production, take customer requirements into account and develop your own code. ''' # Setting variables (hard-coded. get dynamically for production code) qs_namespace_name = 'default' qs_iam_role = 'qs-reader-azure' # Obtain account ID and region account_id = boto3.client('sts').get_caller_identity()['Account'] region = boto3.session.Session().region_name # Setup clients qs = boto3.client('quicksight') iic = boto3.client('identitystore') # Check boto3 version logger.debug(f"## Your boto3 version: {boto3.__version__}") # Get user info from event data event_json = json.dumps(event) logger.debug(f"## Event: {event_json}") iic_store_id = event['detail']['requestParameters']['identityStoreId'] iic_user_id = event['detail']['requestParameters']['userId'] # For UpdateUser event, userId is provided through requestParameters logger.info("## Getting user info from Identity Store.") try: res_iic_describe_user = iic.describe_user( IdentityStoreId = iic_store_id, UserId = iic_user_id ) except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## User info retrieval succeeded.") azure_user_attribute_title = res_iic_describe_user['Title'] azure_user_attribute_userprincipalname = res_iic_describe_user['UserName'] qs_user_name = qs_iam_role + "/" + azure_user_attribute_userprincipalname logger.info(f"#### Identity Center user name: {azure_user_attribute_userprincipalname}") logger.info(f"#### QuickSight group name desired: {azure_user_attribute_title}") logger.debug(f"#### res_iic_describe_user: {json.dumps(res_iic_describe_user)}, which is {type(res_iic_describe_user)}") # Exit if user is not present since this function is supposed to be called by UpdateUser event try: # Get QuickSight user name res_qs_describe_user = qs.describe_user( UserName = qs_user_name, AwsAccountId = account_id, Namespace = qs_namespace_name ) except qs.exceptions.ResourceNotFoundException as e: logger.error(f"## User {qs_user_name} is not found in QuickSight.") logger.error(f"## Make sure the QuickSight user has been created in advance. Exiting.") logger.error(e) sys.exit() except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## User {qs_user_name} is found in QuickSight.") # Remove current membership unless it's the desired one qs_new_group = azure_user_attribute_title # Set "Title" SAML attribute as the desired QuickSight group name in_desired_group = False # Set this flag True when the user is already a member of the desired group logger.info(f"## Starting group membership removal.") try: res_qs_list_user_groups = qs.list_user_groups( UserName = qs_user_name, AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: # Skip if the array is empty (user is not member of any groups) if not res_qs_list_user_groups['GroupList']: logger.info(f"## User {qs_user_name} is not a member of any QuickSight group. Skipping removal.") else: for grp in res_qs_list_user_groups['GroupList']: qs_current_group = grp['GroupName'] # Retain membership if the new and existing group names match if qs_current_group == qs_new_group: logger.info(f"## The user {qs_user_name} already belong to the desired group. Skipping removal.") in_desired_group = True else: # Remove all unnecessary memberships logger.info(f"## Removing user {qs_user_name} from existing group {qs_current_group}.") try: res_qs_delete_group_membership = qs.delete_group_membership( MemberName = qs_user_name, GroupName = qs_current_group, AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error(f"## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## The user {qs_user_name} has removed from {qs_current_group}.") # Create group membership based on IIC attribute "Title" logger.info(f"## Starting group membership assignment.") if in_desired_group is True: logger.info(f"## The user already belongs to the desired one. Skipping assignment.") else: try: logger.info(f"## Checking if the desired group exists.") res_qs_describe_group = qs.describe_group( GroupName = qs_new_group, AwsAccountId = account_id, Namespace = qs_namespace_name ) except qs.exceptions.ResourceNotFoundException as e: # Create a QuickSight group if not present logger.info(f"## Group {qs_new_group} is not present. Creating.") today = datetime.now() res_qs_create_group = qs.create_group( GroupName = qs_new_group, Description = 'Automatically created at ' + today.strftime('%Y.%m.%d %H:%M:%S'), AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error(f"## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## Group {qs_new_group} is found in QuickSight.") # Add the user to the desired group logger.info("## Modifying group membership based on its latest attributes.") logger.info(f"#### QuickSight user name: {qs_user_name}") logger.info(f"#### QuickSight group name: {qs_new_group}") try: res_qs_create_group_membership = qs.create_group_membership( MemberName = qs_user_name, GroupName = qs_new_group, AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) else: logger.info("## Group membership modification succeeded.") qs_group_member_name = res_qs_create_group_membership['GroupMember']['MemberName'] qs_group_member_arn = res_qs_create_group_membership['GroupMember']['Arn'] logger.debug("## QuickSight group info:") logger.debug(f"#### qs_user_name: {qs_user_name}") logger.debug(f"#### qs_group_name: {qs_new_group}") logger.debug(f"#### qs_group_member_name: {qs_group_member_name}") logger.debug(f"#### qs_group_member_arn: {qs_group_member_arn}") logger.debug("## IIC info:") logger.debug(f"#### IIC user name: {azure_user_attribute_userprincipalname}") logger.debug(f"#### IIC user id: {iic_user_id}") logger.debug(f"#### Title: {azure_user_attribute_title}") logger.info(f"## User {qs_user_name} has been successfully added to the group {qs_new_group} in {qs_namespace_name} namespace.") # return response return { "namespaceName": qs_namespace_name, "userName": qs_user_name, "groupName": qs_new_group } この Lambda 関数には Boto3 1.24.64 以降が必要であることに注意してください。 Lambda runtime に含まれている Boto3 がこれより古い場合は、Lambda レイヤーを使用して Boto3 の最新バージョンを使用してください。詳細については、 How do I resolve “unknown service”, “parameter validation failed”, and “object has no attribute” errors from a Python (Boto 3) Lambda function を参照してください。 イベントをトリガーする EventBridge ルールの追加 以前に作成した Lambda 関数を呼び出すための EventBridge ルールを作成するには、以下の手順を実行します。 EventBridge コンソールで、新しいルールを作成します。 Name に updateQuickSightUponSCIMEvent と入力します。 Event pattern には、次のコードを入力します。 { "source": ["aws.sso-directory"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventSource": ["sso-directory.amazonaws.com"], "eventName": ["UpdateUser"] } } Targets については、作成した Lambda 関数 ( UpdateQuickSightUserUponSCIMEvent ) を選択します。 ルールを有効にします。 Azure AD のユーザー属性値を変更して構成を確認 Azure AD でユーザーの属性を変更し、新しいグループが作成され、そのユーザーが新しいグループに追加されているかどうかを確認してみましょう。 Azure AD コンソールに戻ってください。 Manage から Users をクリックします。 以前に IAM Identity Center ポータルから QuickSight へのログインに使用したユーザーを 1 人選択します。 Edit properties を選択し、 Job title と Department の値を編集します。 設定を保存します。 Manage から、 Enterprise application 、自身のアプリケーション名、 Provisioning を選択します。 Stop provisioning を選択し、次に Start provisioning を順番に選択します。 Azure AD では、SCIM のプロビジョニング間隔は 40 分に固定 されています。すぐに結果を得るために、プロビジョニングを手動で停止して開始します。 QuickSight コンソールに移動します。 ドロップダウンユーザー名メニューで、 Manage QuickSight を選択します。 Manage groups を選択します。 これで、新しいグループが作成され、ユーザーがこのグループに割り当てられていることがわかります。 クリーンアップ ソリューションを使い終わったら、環境をクリーンアップしてコストへの影響を最小限に抑えます。次のリソースを削除したい場合があります。 Lambda 関数 Lambda レイヤー Lambda 関数用の IAM ロール Lambda 関数用の CloudWatch ロググループ EventBridge ルール QuickSight アカウント 注 : AWS アカウントごとに作成できる QuickSight アカウントは 1 つだけです。そのため、QuickSight アカウントは組織内の他のユーザーによって既に使用されている可能性があります。QuickSight アカウントを削除するのは、このブログをフォローするように明示的に設定していて、他のユーザーがそのアカウントを使用していないことが確実である場合だけにしてください。 IAM Identity Center インスタンス Azure AD 用の IAM ID Provider 設定 Azure AD インスタンス サマリー この記事では、QuickSight ユーザーを一元管理するために IAM Identity Center SCIM プロビジョニングと Azure AD から SAML 2.0 フェデレーションを設定する手順を段階的に説明しました。また、IAM Identity Center で生成された SCIM イベントを使用し、EventBridge と Lambda を使用して自動化を設定することで、Azure AD のユーザー属性に基づいて QuickSight でグループメンバーシップを自動的に更新するデモも行いました。 QuickSight でユーザーとグループをプロビジョニングするこのイベントドリブンアプローチにより、システム管理者は組織に応じてさまざまなユーザー管理方法を柔軟に決定できます。また、ユーザーがいつ QuickSight にアクセスしても、QuickSight と Azure AD 間でユーザーとグループの整合性が保たれます。 Quicksight のコミュニティ に参加して、他のユーザーと一緒に質問したり、回答したり、学んだり、その他のリソースを調べたりしてみてください。 翻訳はソリューションアーキテクト 溝渕 匡 が担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、データベースアクティビティストリームをサポートするようになり、リレーショナルデータベース内のデータベースアクティビティをほぼリアルタイムでストリーム配信できるようになりました。データベースを内部および外部の脅威から保護し、コンプライアンスや規制要件を満たすために、データベースアクティビティストリームをサードパーティのデータベースアクティビティ監視ツールと簡単に統合して、データベースアクティビティを監視および監査できます。ログイン失敗などのデータベースアクティビティは、暗号化されたデータストリームに非同期的にプッシュされ、 Amazon Kinesis Data Streams を使用してデータベースインスタンスにプロビジョニングされます。 この投稿では、Amazon RDS for SQL Server で実行されているデータベースアクティビティのほぼリアルタイムのデータストリームのデータベースアクティビティストリームを有効にする方法を説明します。データベースアクティビティストリームを有効にすると、データベース内のアクティビティを監視して監査用のアラームを設定できます。 ソリューション概要 ソリューションを実装するには、以下の大まかな手順を実行します。 データベースアクティビティストリーム用の AWS Key Management Service (AWS KMS) キーを作成します。 Amazon RDS for SQL Server にサンプルデータベースを作成します。 サーバーとデータベースの監査仕様を作成します。 データベースアクティビティストリームを開始します。 データベースアクティビティを分析します。 ログを保存する Amazon Simple Storage Service (Amazon S3) バケットを作成します。 S3 バケットにログを保存するように Amazon Kinesis Data Firehose のデリバリーストリームを設定します。 次の図は、ソリューションアーキテクチャを示しています。 前提条件 Amazon RDS for SQL Server では、データベースアクティビティストリームには次の要件があります。 データベースアクティビティストリームでサポートされている DB インスタンスクラス サポートされている SQL Server バージョン (SQL Server 2016 以降、すべてのエディション) AWS キーマネジメントサービス (AWS KMS) のカスタマー管理型のキー データベースアクティビティストリーム用の KMS キーの作成 データベースアクティビティストリームには、記録されたデータベースアクティビティを暗号化および復号化するために管理する KMS キーが必要です。データベースアクティビティストリーミングにはデフォルトの Amazon RDS KMS キーは使用できません。カスタマー管理型の KMS キーを新たに作成する必要があります。詳細については、「 キーの作成 」を参照してください。 AWS KMS コンソールで、[ キーの作成 ] を選択します。 キータイプ には [ 対称 ] を選択します。 [ キーの使用方法 ] で [ 暗号化および復号化 ] を選択します。 [ 次へ ] を選択します。 「 ラベルを追加 」セクションの「 エイリアス 」で、キーの名前を入力します。 [ 説明 ] には、次のようなキーの説明を入力します。 Customer managed Key for Amazon RDS for SQL Server Database Activity Streaming (DAS) [ 次へ ] を選択します。 「 キーの管理アクセス許可を定義 」で、AWS KMS API を通じてこのキーを管理できる AWS Identity and Access Management (IAM) ユーザーとロールを選択します。 [ 次へ ] を選択します。 「 キーの使用アクセス許可を定義 」セクションで、キーを管理する IAM ユーザーまたはロールを選択します。 [ 次へ ] を選択します。 キーポリシーを確認し、[ 完了 ] を選択します。 Amazon RDS for SQL Server にサンプルデータベースを作成する 最初にサンプルデータベース TestDB を作成し、次にテーブル TestTable を作成します。以下のステップを完了してください。 SQL Server Management Studio (SSMS) を開きます。 RDS for SQL Server データベースインスタンスに接続します。 [ 新しいクエリ ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 CREATE DATABASE testDB Go Use testDB Go CREATE TABLE [testDB].[dbo].[TestTable]( textA varchar (6000), textB varchar (6000) ) サーバーレベル監査の仕様の変更とデータベース監査の仕様の作成 デフォルトでは、Amazon RDS 監査仕様は失敗したログインを追跡します。そこで、監査で成功したログイン情報を収集し、すべてのログイン試行を追跡できるようにしましょう。 まず、サーバーレベル監査の仕様から始めましょう。 SSMS では、[新しいクエリ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 ( SSMS で [セキュリティ] → [サーバー監査の仕様] に RDS_DAS_SERVER_AUDIT_SPEC が作成されているのでダブルクリックして内容を確認します。) USE [master] GO ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC] WITH (STATE = OFF) ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC] ADD (SUCCESSFUL_LOGIN_GROUP) WITH (STATE = ON) GO データベースレベルの監査では、テストテーブルの SELECT や INSERT などの DML ステートメントを監査します。 [ 新規クエリ ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 (SSMS の testDB の [セキュリティ] → [データベース監査の仕様] に RDS_DAS_DA_testDB が作成されているのでダブルクリックして内容を確認します。) USE [testDB] Go CREATE DATABASE AUDIT SPECIFICATION [RDS_DAS_DB_testDB] FOR SERVER AUDIT [RDS_DAS_AUDIT] ADD (SELECT ON OBJECT::[dbo].[TestTable] BY [public]), ADD (INSERT ON OBJECT::[dbo].[TestTable] BY [public]) WITH (STATE = ON) Go 仕様を設定したら、データベースアクティビティストリームを開始しましょう。 データベースアクティビティストリームを開始する Amazon RDS for SQL Server でデータベースアクティビティストリームを開始するには、以下のステップを実行します。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択します。 アクティビティストリームを開始する RDS for SQL Server データベースインスタンスを選択します。 「 アクション 」メニューで、[ データベースアクティビティストリームを開始 ] を選択します。 AWS KMS キー には、前に作成した KMS キーを選択します。 「スケジュール」セクションで、[ 今すぐ ] を選択します。 [ データベースアクティビティストリームを開始 ] を選択します。 この機能を有効にしても、ダウンタイムや再起動は必要ありません。 [ データベース ] ページで [ アクティビティストリームを設定中 ] から [ 使用可能] へのステータスの変化を監視します。 Kinesis Data Streams コンソールに移動し、データストリームのステータスが [ アクティブ ] であることを確認します。 Kinesis データストリームの サーバー側の暗号化 は無効のままにしておく必要があることに注意してください。暗号化を有効にすると、データベースのアクティビティストリームに直接影響します。 Kinesis クライアントアプリケーションを使用してデータベースアクティビティストリームを分析する データベースのアクティビティを記録するために、いくつかの INSERT ステートメントと SELECT ステートメントを実行してみましょう。 SSMS では、[ 新規クエリ ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 USE [testDB] Go INSERT INTO [testDB].[dbo].[TestTable] VALUES ('Bob', 'Johnson'); INSERT INTO [testDB].[dbo].[TestTable] VALUES ('Jinnie', 'Johnson'); INSERT INTO [testDB].[dbo].[TestTable] VALUES ('Rob', 'Brown'); select * from [testDB].[dbo].[TestTable] Kinesis データストリームから監査データを読み取るには、前に作成したのと同じ KMS キーを使用してデータを復号化する必要があります。 以下のサンプル出力では、Kinesis クライアントライブラリ for Java を使用して Kinesis データストリームからデータを抽出し、監査レコードとそのフィールドを表示しています。 { "type": "DatabaseActivityMonitoringRecord", "clusterId": "", "instanceId": "db- HAFFQILMCDWKPXURN67M5TQFXY", "databaseActivityEventList": [ { "class ": "TABLE", "clientApplication": "Microsoft SQL Server Management Studio - Query", "command": "INSERT", "commandText": "INSERT INTO [testDB].[dbo].[TestTable]\r\nVALUES ('Jinnie', 'Johnson')", "databaseName": "testDB", "dbProtocol": "SQLSERVER", "dbUserName": "admin", "endTime": null, "errorMessage": null, "exitCode": 1, "logTime": "2023-02-02 22:01:49.5283055+00", "netProtocol": null, "objectName": "TestTable", "objectType": "TABLE", "paramList": null, "pid": null, "remoteHost": " 10.145.xx.xx", "remotePort": null, "rowCount": 0, "serverHost": "172. 30.2.173", "serverType": "SQLSERVER", "serverVersion": "15.00.4236.7.v1.R1", "serviceName": "sqlserver-se", "sessionId": 75, "startTime": null, "statementId": "0xaffb4ff267b e9d45a3e7518553d73a40", "substatementId": 1, "transactionId": "22914 7", "type": "record", "engineNativeAuditFields": {} } ] } ストリームログを保存する S3 バケットを作成する さらに、ログストリームを Amazon S3 にエクスポートして、サードパーティによる監視やアプリケーションの監査を行うことができます。 Amazon S3 コンソール、AWS SDK を使用してストリームログを保存する S3 バケットを作成できます。 または AWS コマンドラインインターフェイス (AWS CLI)。手順については、「 バケットの作成 」を参照してください。 レコードを長期間アーカイブして保存するには、 S3 ライフサイクル を設定します。 Kinesis Data Firehose のデリバリーストリームの設定 データベースアクティビティストリームを有効にしたら、Firehose 配信ストリームを作成する必要があります。以下のステップを完了してください。 Kinesis Data Firehose コンソールで、[ 配信ストリームを作成 ] を選択します。 [ ソース ] には [ Amazon Kinesis データストリーム ] を選択します。 送信先 には Amazon S3 を選択します。 [ 配信ストリーム名 ] に、配信ストリームの名前を入力します。 監査仕様の変更 監査仕様を変更するには、次の手順を実行します。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択して DB インスタンスのリストを表示します。 RDS for SQL Server インスタンスを選択します。 「 アクション 」メニューで、[ データベースアクティビティストリームの変更 ] を選択します。 [ ロック解除済 ] を選択し、[ DB アクティビティストリームを変更 ] を選択します。 RDS for SQL Server インスタンスの監査仕様を必要に応じて変更します。 変更が完了したら、前のステップを繰り返して [ ロック済み ] を選択します。 データベースアクティビティストリームを停止する Amazon RDS for SQL Server のデータベースアクティビティストリームを停止するには、以下のステップを実行します。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択して DB インスタンスのリストを表示します。 RDS for SQL Server インスタンスを選択します。 [ アクション ] メニューで [ データベースアクティビティストリームを停止 ] を選択します。 [ 今すぐ ] を選択します。 データベースアクティビティストリームが停止していることを確認するメッセージが表示されます。 データベースの状態が [ アクティビティストリームを設定中 ] から [ 利用可能 ] に変わることを確認します。 結論 この投稿では、データベース監査要件を満たすように RDS for SQL Server インスタンスでデータベースアクティビティストリームを設定する手順を説明しました。監視や警告のために監査データを視覚化するさまざまな方法について説明しました。この機能は、データベースオブジェクトに対して行われたユーザーアクティビティを監視して記録するのに役立ちます。Amazon RDS for SQL Server でこの機能を使用する前に、監査要件を確認し、パフォーマンスへの影響と追跡するアクティビティの種類を検討し、コンプライアンス基準を遵守することをお勧めします。 著者について Vikas Babu Gali は、アマゾンウェブサービスのマイクロソフトワークロードを専門とするシニアスペシャリストソリューションアーキテクトです。インド出身のVikasは、クリケットをプレーしたり、家族や友人と屋外で過ごすことを楽しんでいます。 Sudhir Amin は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。ニューヨークを拠点に、さまざまな業種の企業顧客にアーキテクチャに関するガイダンスと技術支援を提供し、クラウドの導入を加速させています。彼はスヌーカー、ボクシングやUFCなどの格闘技の大ファンであり、野生生物保護区が豊富な国を旅して世界で最も雄大な動物を間近で見ることが大好きです。   翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

データベースのセキュリティを維持することは、あらゆる組織の成功にとって不可欠です。データベースユーザーの認証と認可の実装は、データベースシステムを保護するための重要な手順です。従来のデータベース認証は、ユーザー名とパスワードのメカニズムに基づいています。このプロセスでは資格情報を管理するために DBA とエンドユーザーの両方に一定の時間と労力が必要です。対照的にリレーショナルデータベース認証を Microsoft Active Directory (AD) などの集中認証サービスと組み込むことは、より安全で広く受け入れられている業界のベストプラクティスです。 SQL Server は ２ つの 認証 モードをサポートしています。 Windows 混合モード Amazon Relational Database Service (Amazon RDS) for SQL Server は、混合モード認証のみをサポートします。お客様が Windows 認証のみを利用したいシナリオでは、SQL ログイン作成を監視するカスタムソリューションを実装できます。 この投稿では、Amazon RDS for SQL Server インスタンス内で SQL ログインが作成されたときに E メール通知を受け取るソリューションを紹介します。 ソリューションの概要 この投稿のソリューションでは、 データベースメール が構成された Amazon RDS for SQL Server を使用します。データベースメールを使用すると、SMTP (Simple Mail Transfer Protocol) サーバーを使用して SQL Server からユーザーにメッセージを送信することができます。 Amazon RDS for SQL Server インスタンスには、データベースインスタンス内での SQL ログインの作成を定期的に監視するように設定された SQL エージェントジョブがあります。 SQL ログインの作成を検出すると、SQL Server エージェントジョブはデータベース管理者が適切なアクションを取れるように、ログインの詳細を含む E メールメッセージをデータベース管理者に送信します。 次の図は、ソリューションのアーキテクチャ図です。 Amazon Simple Email Service (Amazon SES) は、独自の E メールアドレスとドメインを使用して E メールを送受信するための簡単かつコスト効率の高い方法を提供する E メールプラットフォームです。 前提条件 開始するには、次の前提条件を満たしている必要があります。 Amazon RDS for SQL Server インスタンス Amazon SES で構成された SQL サーバー データベースメール SQL Server Management Studio (SSMS) の知識があること SQL エージェントジョブ の作成に関する知識があること Amazon SES 経由で E メールを送信するようにデータベースメールを構成する 「 Amazon RDS for SQL Server でのデータベースメールの使用 」の投稿では、Amazon SES でデータベースメールを設定するための詳細な手順を説明しました。データベースメールを使用すると、Amazon RDS on SQL Server データベースインスタンスからユーザーに E メールメッセージを送信できます。 Amazon RDS は、SQL Server の Web、Standard および Enterprise Edition のすべてのバージョンのデータベースメールをサポートします。 データベースメールを構成した後、テスト E メールを送信して成功したかどうかをすぐに検証できます。 SQLエージェントジョブの作成 次のステップは、SQL エージェントジョブを作成して、SQL ログインを定期的に監視するスケジュールを設定します。 SQL Server Management Studio を使用して SQL Server にログインします。 SQL Server エージェントの下の ジョブ のコンテキストメニューを開き (右クリック)、[ 新しいジョブ ] を選択します。 SQL エージェントジョブの 名前 を指定します。 「 ページの選択 」セクションで [ ステップ ] を選択し、[ 新規作成 ] を選択します。 ステップ名 を指定し、コマンドセクション内に次の T-SQL スクリプトをコピーして貼り付けます。このスクリプトは sys.sql_logins DMV を監視し、 マスターユーザー 以外の SQL ログインが見つかった場合に E メール通知を送信します。 必要に応じて、T-SQL スクリプトで次の変更を行う必要があります。 DECLARE @SQLLoginCount INT DECLARE @myTableVariable TABLE (SQLLogin Nvarchar(50), LoginCreateDate datetime) DECLARE @mailBody Nvarchar(MAX); DECLARE @xml NVARCHAR(MAX) DECLARE @body NVARCHAR(MAX) SET @SQLLoginCount = (SELECT count(*) FROM master.sys.sql_logins where name not like '##%' and name not in ('rdsa', 'admin')) --Edit master username Insert into @myTableVariable (SQLLogin, LoginCreateDate) Select [name], [create_date] FROM master.sys.sql_logins where name not like '##%' and name not in ('rdsa', 'admin') --Edit master username If @SQLLoginCount > 0 BEGIN SET @xml = CAST(( SELECT [SQLLogin] AS 'td','',LoginCreateDate AS 'td','' FROM @myTableVariable FOR XML PATH('tr'), ELEMENTS ) AS NVARCHAR(MAX)) SET @body ='<html><body><H3>A new SQL login(s) was detected on the RDS SQL Server. Please verify why this login(s) was created</H3> <table border = 1> <tr> <th> SQLLogin </th> <th> LoginCreateDate </th> </tr>' SET @body = @body + @xml +'</table></body></html>' EXEC msdb.dbo.sp_send_dbmail @profile_name = 'Notifications', @recipients = '<xyz@example.com>', --Edit email address @body = @body, @body_format ='HTML', @subject = 'New SQL Login(s) Created On RDS SQL server '; END admin – このソリューションではマスターユーザーとしてデフォルトの「admin」を使用しました。デフォルトの「admin」からマスターユーザー名を変更する場合は、マスターユーザー名を編集します。この変更箇所はスクリプト内で 2 箇所 あります。 @recipients – 必要に応じて受信者の E メールアドレスを編集します。この変更箇所はスクリプト内で 1 箇所 です。 スクリプトに変更を加えたら、[ OK ] を選択します。 「 ページの選択 」セクションで [ スケジュール ] を選択し、 [ 新規作成 ] を選択します。 ジョブ スケジュールの 名前 を入力し、必要に応じて 頻度 を選択し、[OK] を選択します。 [ OK ] を選択して SQL サーバーエージェントジョブを作成します。 セットアップのテスト SQL ログインを作成します。これは、T-SQL または SSMS を使用して実行できます。 USE [master] GO CREATE LOGIN [sid] WITH PASSWORD=N'******', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO 数分後、新しい SQL ログインについて警告する E メール通知が届きます。次のスクリーンショットは E メールの例を示しています。 後片付け このソリューションをテストした場合、追加の課金を回避するために次の手順を実行して作成されたコンポーネントを削除します。 SSMS を使用して RDS インスタンスに接続し、作成された SQL Server エージェントジョブを 削除 します。 Amazon RDS コンソールで RDS SQL Server インスタンスを選択し、[ アクション ] メニューで [ 削除 ] を選択します。 まとめ この投稿では、Amazon RDS for SQL Server インスタンス内で SQL ログインが作成されたときに Amazon SES を通じて E メール通知を送信する SQL Server エージェントジョブを作成する方法を説明しました。 ご質問、コメント、フィードバックがありましたら、この投稿のコメントセクションに残してください。 著者について Sid Vantair は、戦略アカウントを担当する AWS のソリューション アーキテクトです。リレーショナル データベースを扱う 10 年以上の経験を持つ彼は、顧客のハードルを克服するために複雑な技術的問題を解決することに熱心に取り組んでいます。仕事以外では、家族と過ごす時間を大切にし、子供たちの好奇心を育んでいます。 Poulami Maity は、アマゾン ウェブ サービスのデータベース スペシャリスト ソリューション アーキテクトです。彼女は AWS の顧客と協力して、既存のデータベースを AWS クラウドに移行して最新化するのを支援しています。       翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

監視はあらゆるリレーショナルデータベース管理システム (RDBMS) にとって重要な側面です。監視設定が適切であればデータベース設定の可視性と制御性が向上します。AWS のお客様の多くは、 Amazon CloudWatch メトリクスと Amazon Relational Database Service (Amazon RDS) のイベント通知を使用して、さまざまなメトリクスやイベントをモニタリングしています。 Amazon RDS イベントサブスクリプションは、 Amazon RDS for SQL Server のインスタンスレベルのモニタリングとアラートを提供します。ただし、データベースがオフラインになったり、オンラインに戻ったりしたときにアラートを出す直接的なメカニズムはありません。この記事では、RDS for SQL Server インスタンスがオンラインまたはオフラインになったときに Amazon Simple Notification Service (Amazon SNS) の通知を受け取る方法を説明します。 ソリューション概要 このソリューションでは、エラーログを Amazon CloudWatch ログに発行するように Amazon RDS for SQL Server を設定し、データベースの状態がオフラインまたはオンラインのときはいつでも Amazon SNS によるアラートを生成できるようにフィルタを設定します。 次の図は、ソリューションのアーキテクチャを示しています。 このソリューションの大まかな手順は次のとおりです。 Amazon RDS for SQL Server のエラーログを CloudWatch に公開します。 オフラインデータベースまたはオンラインデータベース用のフィルタパターンを作成します。 フィルターされたメトリクスのアラームを作成します。 前提条件 前提条件として、Amazon RDS for SQL Server をセットアップし、CloudWatch と Amazon SNS にアクセスできる必要があります。 Amazon RDS for SQL Server のエラーログを CloudWatch に公開 Amazon RDS for SQL Server のエラーログを CloudWatch に公開するには、DB インスタンスを変更する必要があります。以下のステップを完了してください。 このソリューションのコストについては、 Amazon RDS for SQL Server 、 Amazon CloudWatch 、 Amazon SNS の料金ページを参照してください。 Amazon RDS コンソール のナビゲーションペインで [ データベース ] を選択し、変更する必要がある DB インスタンスを選択します。 [ 変更 ] を選択します。 「 ログのエクスポート 」セクションで、CloudWatch への公開を開始するログを選択します。 [ エラーログ ] を選択します。 (オプション) [すぐに適用] を選択すると、変更がすぐに適用されます。 確認ページで、変更内容を確認します。内容が正しければ、[DB インスタンスを変更] を選択して変更を保存します。または、[戻る] を選択して変更を編集するか、[キャンセル] を選択して変更をキャンセルします。 オフラインまたはオンラインのデータベース用のフィルターパターンを作成 Amazon RDS for SQL Server のエラーログを CloudWatch に公開したので、次のステップはフィルターパターンを作成することです。以下のステップを完了してください。 CloudWatch console を開き、ナビゲーションペインの「ログ」セクションから ロググループ を選択します。お使いの DB インスタンスの Amazon RDS for SQL Server エラーログ (この記事では /aws/rds/instance/sql-database-ee/error ) を選択します。 [アクション] で [ メトリクスフィルターを作成 ] を選択します。 フィルターパターン に「 OFFLINE 」と入力します。 (オプション) 次の手順を使用して パターンをテスト できます。 「パターンをテスト」セクションの「テストするログデータを選択」ドロップダウンからテストするログデータを選択します (この場合は sql-database-ee.node2 ) [パターンをテスト] をクリックします。 [パターンをテスト] は、データベースの1つが OFFLINE 状態で、対応するエントリがエラーログにある場合にのみ機能します。 [ Next ] をクリックします。 フィルター名 、 メトリクス名前空間 、 メトリクス名 に「 OFFLINE Database(s)」と入力します。 メトリクス値 に「1」を入力します。 [ Next ] をクリックします。 [ メトリクスフィルターを作成 ] をクリックします。 同じ手順に従って、ONLINE データベース用のメトリクスフィルターを作成します。 フィルターパターン、フィルター名、メトリクス名前空間、メトリクス名を適宜変更します。 ユースケースに応じて、フィルター名、メトリクス名前空間、メトリクス名をカスタマイズできます。 フィルターされたメトリクスのアラームを作成 フィルターされたメトリクスのアラームを作成するには、次の手順を実行します。 OFFLINE Database(s) のフィルターを選択し、[ アラームを作成 ] をクリックします。 メトリクス名を入力します(この投稿では OFFLINE Database(s) )。 統計 で [ 最小 ] を選択し、 期間 を [ 30 秒 ] またはユースケースに応じて適切な値に設定します。 しきい値の種類 で [ 静的 ] を選択します。 [ より大きい ] を選択し、「0」を入力します。 [ 次へ ] をクリックします。 アラーム状態トリガー には [ アラーム状態 ] を選択します。 次の SNS トピック に通知を送信 で [ 新しいトピックの作成 ] を選択し、トピック名を入力します。(既存のトピックを使用することもできます)。 通知を受信するための有効なメールアドレスを入力してください。 [ トピックの作成 ] をクリックして、[ 次へ ] をクリックします。 アラーム名 に名前を入力します。 設定を確認して、[ アラームの作成 ] をクリックします。 SNS トピックが作成されたので、メールの Confirm subscription リンクをクリックしてサブスクリプションを確認してください。 同じ手順を繰り返してオンラインデータベースのアラームを作成し、それに応じて条件を調整します。 ソリューションのテスト ここで、SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server インスタンスに接続します。 次のスクリーンショットに示すように、データベース DemoDB を使用します。 Alter Database Set コマンドを使用して DemoDB データベースをオフラインにします。 次のスクリーンショットに示すように、SSMS でデータベースの状態を確認できます。 Alter Database Set コマンドを使用して DemoDB データベースをオフラインにします。 また、サブスクライブした E メール ID に通知メールが届きます。 次に、 rdsadmin.dbo.rds_set_database_online を使用して DemoDB をオンラインにします。 Alter Database db_name Set Online は Amazon RDS for SQL Server では機能しないため、このコマンドを実行すると次のエラーが表示されることに注意してください。 ただし、 rdsadmin.dbo.rds_set_database_online は正常に動作します。詳細については、「 Microsoft SQL Server データベースをオフラインからオンラインに切り替える 」を参照してください。 SSMS を使用してデータベースのステータスを確認できます。 また、データベースがオンラインであることを知らせるメールアラートも届きます。 主な考慮事項 シングル AZ の Amazon RDS for SQL Server を使用してこのソリューションを実演しました。インスタンスを再起動しても、オンラインまたはオフラインのデータベース通知は届かないことに注意することが重要です。これは、SQL Server が再起動後にデータベースの回復プロセスが実行されるためです。そのため、通知を受け取りたい場合は、Starting up database または Recovery is complete というフィルターパターンを使用してユースケースに応じたメトリクスフィルターを作成する必要があります。 SQL Server エラーログの抜粋を次に示します。 2023-04-13 05:17:19.570 spid29s Starting up database 'DemoDB'. ....... 2023-04-13 05:17:21.050 spid9s Recovery is complete. This is an informational message only. No user action is required. 後片付け 料金が発生しないようにこのソリューションを環境内でテスト目的で使用していた場合は、Amazon RDS for SQL Server インスタンスと CloudWatch ログをクリーンアップしてください。 CloudWatch ログを削除するには、次の手順を実行します。 Amazon CloudWatch コンソール に移動します。 左側のナビゲーションペインで、「ログ」セクションからロググループを選択します。 ロググループの検索フィールドにデータベース名を入力します (例 : sql-database-ee )。 ロググループ をクリックします。 [ アクション ] メニューから [ロググループの 削除 ] を選択します。 DB インスタンスを削除するには、 AWS マネジメントコンソール 、 AWS CLI 、または Amazon RDS API を使用します。RDS インスタンスを削除するのに必要な時間は、削除するデータ量、バックアップ保持期間 (削除するバックアップの数、最終スナップショットを取る必要があるかどうか) によって変わります。 Amazon RDS for SQL Server DB インスタンスを削除するには、下記のステップに従う必要があります。 Amazon RDS コンソール にアクセスしてください。削除保護が有効になっている場合はチェックを外し、次のステップに進む前にデータベースインスタンスを変更してください。有効になっていない場合は次のステップに進みます。 ナビゲーションペインで [ データベース ] を選択し、削除する DB インスタンスを選択します。 [ アクション ] メニューで [ 削除 ] を選択し、 [ 最終スナップショットを作成 ] を選択して、DB インスタンスの最終的な DB スナップショットを作成します。 最終スナップショットを作成する場合は、最終スナップショット名に名前を入力します。 自動バックアップを保持するには、[ 自動バックアップを保持 ] を選択します。 テキストフィールドに delete me と入力します。 [ 削除 ] をクリックします。 最後に、 SNS トピックとサブスクリプションを削除します 。 結論 この記事では、Amazon RDS for SQL Server のエラーログを CloudWatch に発行する方法、データベースがオフラインまたはオンラインのときに使用するメトリクスフィルタを作成する方法、SNS 通知と CloudWatch アラームを使用して E メールアラートを送信する方法について説明しました。このソリューションはこの記事で説明した内容に限定されません。メトリクスフィルタを使用して Amazon RDS for SQL Server のエラーログをスキャンして必要に応じてアラートを設定することができます。 Amazon RDS for SQL Server の詳細については、 Amazon RDS for Microsoft SQL Server を参照してください。この投稿についてコメントや質問がある場合は、コメントセクションに送信してください。 著者について Kanchan Bhattacharyya は、アマゾンウェブサービスのシニアデータベーススペシャリストテクニカルアカウントマネージャーです。彼は企業のお客様と連携して、データベースの運用パフォーマンスに関する技術支援を提供したり、データベースのベストプラクティスを共有したりしています。Amazon RDS for SQL Server、Amazon RDS for PostgreSQL、Amazon RDS for MySQL、Amazon を専門としています。     翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

はじめに AWS 上にシステム環境を展開する際に、アカウント単位でワークロードを分割するマルチアカウントという戦略があります。 マルチアカウント戦略 のベストプラクティスとして、ソフトウェア開発ライフサイクルごとにワークロードを分割することについて説明されています。その中で、開発環境、ステージング環境、本番環境がそれぞれ独自のアカウントを持つ戦略が推奨されています。 各環境に、アプリケーションをデプロイする際には、継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを活用してデプロイしたり、本番環境へのデプロイ前のテストや確認を行ったりします。 Amazon CodeCatalyst は、ソフトウェア開発チームが AWS でアプリケーションの計画、コーディング、ビルド、テスト、デプロイを始めるために必要なすべてをまとめた統合ソフトウェア開発サービスです。CodeCatalyst を利用することで、複数の AWS アカウントへの CI/CD パイプラインをセキュアで簡単に実現することができます。 本ブログでは、CodeCatalyst で Environment を利用した マルチアカウントデプロイの紹介をします。 前提条件 デプロイするための 2 つの AWS アカウントがあること。 CodeCatalyst にサインインするための AWS Builder ID を持っていること。 スペースに所属し、そのスペースの管理者ロールが自分に割り当てられていること。詳細は、「 Amazon CodeCatalyst でのスペースの作成 」、「 スペースのメンバーの管理 」、「 スペース管理者ロール 」を参照してください。 スペースに関連付けられた AWS アカウントを持ち、そのアカウントで IAM ロールを持っていること。ロールとロールポリシーの詳細については、「 CodeCatalyst サービスロールの作成 」を参照してください。 チュートリアル 概要 下記手順と図のように CodeCatalyst の CI/CD ワークフローから複数の AWS アカウントへデプロイするチュートリアルを行います。 CodeCatalyst のスペースに AWS アカウントを追加 デプロイ先となる AWS アカウントを Environment で設定 CodeCatalyst ワークフローの作成 複数の AWS アカウントへのデプロイの確認 CodeCatalyst の各用語について CodeCatalyst のコンセプト をご参照ください。 図1. CodeCatalyst から 開発環境と本番環境にデプロイ アプリケーションと AWS 環境は、Modern three-tier web application ブループリント を使用します。 CodeCatalyst ブループリントは、新しいプロジェクトのテンプレートを提供します。以下に沿って進める場合、「 Amazon CodeCatalyst でのスペースの作成 」で説明されているとおり、ブループリントを起動することができます。 これにより、以下に示すアーキテクチャがデプロイされます。本プログラムで使うブループリントの詳細は こちら をご確認ください。 図2. Modern three-tier web application ブループリントでデプロイされるアーキテクチャ CodeCatalyst のスペースに AWS アカウントを追加 ここでは、システムのデプロイ先となる AWS アカウントを CodeCatalyst のスペースに追加していきます。 AWS アカウントをスペースに追加することで、デプロイ先 AWS アカウントを増やしたり、CodeCatalyst の請求アカウントを管理したりすることができます。 下記手順に従って、CodeCatalyst のスペースに AWS アカウントを追加します。 CodeCatalyst スペースの画面に移動 Settings > AWS accounts に移動 追加する AWS account ID、CodeCatalyst で表示する display name、description を入力 Associate AWS account から追加 図3. CodeCatalyst スペースに AWS アカウントを追加する画面 Environment  の概要と各環境の設定 Environment では、アプリケーションがデプロイされる AWS アカウントの管理をすることができます。Environment には、develop、test、staging、production など、任意の名前を付けることができます。CodeCatalyst から Environment へのデプロイは、次項の手順にある CodeCatalyst ワークフロー内で定義する各 アクション に紐づけることで実現することができます。CodeCatalyst から Environment へのデプロイは、すべて Environment ページに表示されます。Environment を設定するには、 production などの名前を付け、それをスペースに追加した AWS アカウントに関連付けます。Environment では、デプロイメントのターゲット AWS アカウント、アクティビティ、デプロイメントターゲットの Amazon CloudFormation Stack 一覧をまとめて管理することができます。 Dev Environment と混同しないようにしてください。Dev Environment は、CodeCatalyst で利用できるクラウドベースの開発環境で、プロジェクトのソースリポジトリに保存されているコードに対してすばやく作業することができます。 下記手順に従って、Environment の作成をします。 ブループリントから立ち上げたプロジェクトの画面に移動 CI/CD > Environments に移動 ブループリントから作成された Environment に development があることを確認 図4. ブループリントから作成された Environment の画面 Create environment から新しく Production 用の Environment を作成 Environment name を「production」、Environment type を「Production」に設定 スペースに追加した AWS アカウントを AWS account connection に設定 Create environment から作成 図5. Environment の作成画面 CodeCatalyst ワークフローの設定 CodeCatalyst ワークフローでは、アプリケーションのビルド、テスト、デプロイを容易に行うことができます。ブループリントから立ち上げたプロジェクトの画面で、CI/CD > Workflows に移動します。既に、対象の ブループリントで定義されている CI/CD ワークフローである ApplicationDeploymentPipeline が確認できるかと思います。既にある ApplicationDeploymentPipeline に加えて、Production 環境にデプロイする CI/CD ワークフローを作成していきます。 最終的には、下記の図のように、Development 環境の Environment が関連づけられた CI/CD ワークフロー(左)、Production 環境の Environment が関連づけられた CI/CD ワークフロー(右) の2つのワークフローが存在する形になります。 図6. Development 環境と Production 環境のワークフロー 下記手順に従って、ワークフローの修正と作成をします。 既にある ApplicationDeploymentPipeline のワークフローのトリガーとなるブランチを main から development に変更 ApplicationDeploymentPipeline のワークフローをコピー & ペーストして新しい ApplicationDeploymentPipelineProduction という名前のファイルを同じディレクトリ内に作成 トリガーとなるブランチを development から main に変更 下記の変更のように、各 Environment に記載されている Name と Connections の Name を production に変更 図7. ApplicationDeploymentPipelineProduction ワークフローの変更内容 マルチアカウントデプロイ ここまでで、development ブランチにマージされた時に、Environment で定義した development 用の AWS アカウント に、main ブランチにマージされた時には、 Environment で定義した production 用の AWS アカウントへデプロイされます。 ここからは、実際に動作を確認してみます。Modern three-tier web application ブループリントの Readme にある Sample Change に従って変更し、デプロイをします。 development ブランチを作成 development ブランチから feature ブランチを作成 feature ブランチで 、Modern three-tier web application ブループリントの Readme にある Sample Change に従って変更 development ブランチへのマージ development 環境の Web サイトの確認 main ブランチに development ブランチをマージ production 環境の Web サイトの確認 各 Environment ごとのアクティビティを、Environment のページから確認することができます。 図8. Environment (development) のデプロイアクティビティの画面 図9. Environment (production) のデプロイアクティビティの画面 クリーンアップ このチュートリアルに従っていた場合、引き続き料金が発生しないように、デプロイしたリソースを削除する必要があります。まず、ブループリントを起動したときに関連付けた AWS アカウントで、CDK が AWS CloudFormation コンソールを使用してデプロイした 2 つのスタックを削除します。これらのスタックは、mysfitsXXXXXWebStack や mysfitsXXXXXAppStack のような名前を持っています。次に、Project settings に移動して Delete project ボタンをクリックし、CodeCatalyst からプロジェクトを削除します。 CodeCatalyst で発生する料金の 詳細は価格ページを参照してください 。 まとめ 本ブログでは、CodeCatalyst でマルチアカウントデプロイを実装しました。CodeCatalyst で、アプリケーションのデプロイ先 AWS アカウントの管理と CI/CD ワークフローに、AWS アカウントと関連づけた Environment を設定することで、簡単にマルチアカウントデプロイが可能となります。Environment を活用し、利用しているブランチ戦略に従ってマルチアカウントデプロイを実現してみましょう。 この記事の著者について 柳久保 友貴 ソリューションアーキテクトとして、ISV/SaaS 領域のお客様の技術支援を行っています。好きなサービスは Code シリーズです。好きな食べ物は、ラーメンです。

こんにちは！ アマゾン ウェブ サービス (AWS) でシニア ソリューション アーキテクトをしております、櫻田です。 普段はテクニカルな面から研究者の皆様のクラウド活用をサポートさせて頂いております。 シリーズでお送りしております「 高等教育機関におけるスケーラブルなセキュリティの必要性 」「 高等教育機関におけるサイバー攻撃に対する予防と準備 」はお読みいただけましたでしょうか。 前回までのブログでは 「Hartnell College」の事例 についてお伝えしました。これは大学がサイバーアタックを受け、ランサムウェアにより学内システムのサーバがロックされてしまった状況から、AWS を利用してシステムの復旧を迅速に行った事例でした。 海外での事例でしたので、 日本の研究コミュニティでは具体的にはセキュリティにどのようなリスクを抱えているか 疑問に思った方も少なからずいらっしゃるかと思います。 そこで今回はサイバー攻撃への対応準備のためのバックアップとリカバリについて考えてみたいと思います。 サイバーアタックには復旧のための新しい環境が必要になる Hartnell College の事例では全部のバックアップが揃っているわけでは無かったようですが、ゼロから AWS 上でシステムを立ち上げていき、大学の業務や講義を行えるよう迅速にシステムを構築されています。天災等で被害を受けハードウェアに被害が及んだ場合は、代替の環境が必要となることは容易に想像がつくでしょう。AWS を利用することで代替の環境をすぐに用意していくことが可能です。 ではサイバーアタックを受けた場合はどうでしょうか。 サイバーアタックを受けた場合には、手元のハードウェア自体は物理的には壊れていないことが多いでしょう。 そのため一見すると復旧するための環境が残っているため、天災等で被害を受けた場合と比べて復旧が容易と考える方もいらっしゃるかもしれません。 しかし本当にそうでしょうか。 実際は被害の状況の確認や他への被害拡大を防ぐために環境を隔離することが多いでしょう。 そうすると既存の環境は隔離されてしまうので、復旧には利用出来なくなります。また周辺の環境についても、どこまで侵害を受けているかが分からないため必要に応じて別の新しい環境が必要です。 迅速に復旧するには、このように 既存の環境とは別の新しい環境を用意しなければなりません 。AWSのクラウドを使えば、新しい環境を迅速に用意できます。 バックアップ自体が攻撃されていることも考慮が必要 さてバックアップはどうしょうでしょうか。 既にかなり前からシステムに侵入されてしまっていた場合、攻撃された後のデータが自動バックアップされて、最悪そのバックアップしか残っていない場合も考えられますし、 バックアップ領域自体も攻撃対象になりデータを損失してしまう可能性 も考えられます。 バックアップ領域が攻撃されたとしてもデータを守るには、Write Once Read Many ( WORM ) や Vault Lock 機能を使ってデータを改ざんから守ることが考えられます。 Amazon S3 や AWS Backup 等を使うことで、これらの機能は手軽に利用できますので、AWSを現在利用していない場合でも、バックアップを例えば Amazon S3 へ送ってこれら機能を活用することでデータを守ることができると考えられます。また平常時にバックアップからシステムを復旧する訓練は、復旧手順だけでなく、万が一バックアップデータの不足があったとしても気づくことができ有用ですのでお勧め致します。 また、AWS には Amazon GuardDuty、AWS CloudTrail や AWS Trusted Advisor などをはじめとしたセキュリティのベストプラクティスに対応していくための様々なサービスもありますので是非活用いただき、より安心できるシステムの運用をしていただければと思います。 この事例では、既存システムを単にAWS上で再構築をしただけでなく、新たに Amazon AppStream 2.0 を取り入れた事も記載されていました。 これにより学生は例えば CAD やデザインソフトウェアを使うためだけにコンピュータ教室に行く必要はなくなり、どこからでも手元の PC からソフトウェアにアクセスできるようになりました。学生の学びの環境の改善にもつながっているようです。このように新しいサービスを取り入れて環境を改善していくことも AWS を使えば容易になります。 最後に 今回のブログは前回のブログ「高等教育機関におけるサイバー攻撃に対する予防と準備」でお伝えした事例を元に、AWS を活用することで、データを守り、万が一何か起こった際にも迅速にシステムを再構築していくには何かできるかについてお伝えしました。安定的な運用だけでなく、新しい IT サービスの提供にも AWS を活用していただければと思います 相談したいことや疑問や思うことも多いかと思いますが、そのような時は お気軽に AWS までお問い合わせ頂ければと思います。 ご連絡はは下記よりお気軽にお問い合わせください 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 大学・研究機関のための AWS 資料 教育・研究機関におけるAWS のはじめ⽅ 関連投稿 高等教育機関におけるスケーラブルなセキュリティの必要性 高等教育機関におけるサイバー攻撃に対する予防と準備 この記事を書いた人 櫻田 武嗣 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター シニアソリューション アーキテクト “業務や研究内容に適したシステム構成のディスカッション等を通して技術面から皆様にご支援をしております”

こんにちは！ アマゾン ウェブ サービス (AWS) で事業開発を担当しております、吉田です。 先に公開されました「 高等教育機関におけるスケーラブルなセキュリティの必要性 」ではグローバルにおける教育コミュニティで昨今重要視されている「セキュリティ」についてレポートのご紹介と一緒に詳細をご紹介させて頂きました。 さて、みなさんはこちらのお話どのように感じられたでしょうか？ 多くの方が研究活動においてセキュリティが大切であることは共感されたのではないかと思います。 今回は Hartnell College の事例から サイバー攻撃に対する予防と準備のために検討する項目 について触れてみたいと思います。 事例詳細は “ カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか ” で詳しく説明しておりますので、フォームからダウンロードください。 サイバー攻撃は残念ながら高等教育において一般的な出来事となりつつあります。しかし、サイバーイベントが発生した場合に教育機関がレジリエンス（回復力）を発揮できるよう、リーダーの方々には先を見越して準備する方法があります。Hartnell College の経験から得た教訓に基づき、高等教育機関のリーダーは、サイバーイベントに対するより良い予防と準備のために、以下のステップを検討することができます。 1. IT 部門のプロセスの棚卸しと文書化 多くの大学や専門学校は、敷地内に大規模な IT インフラのフットプリントを有しています。 IT インフラ、ソフトウェア、セキュリティ対策を、（通常）小規模な IT 部門で最新の状態に保つことは、困難なことです。Hartnell Collegeの経験から、復旧に不可欠な要素は、最新の バックアップ目録ドキュメント 一式でした。このドキュメントを作成することは、サイバー問題またはイベントが発生した場合に回復するための最初のステップです。 2. リカバリー戦略を加速させるために、専門家に実装をアウトソーシングする。 多くの小規模な高等教育機関は、IT インフラをクラウドにうまく移行するための専門知識、リソース、経験を持っていません。 AWS パートナーとの連携 により、クラウドコンピューティングへの移行における参入障壁を減らし、取り除くことができます。 AWS パートナーネットワーク（APN）には、150 カ国以上から 10 万人以上のパートナーが参加しており、お客様はクラウドへの移行を加速させ、AWS が提供するサービスを最大限に活用することが可能になっています。 Hartnell College の近代化計画の一環として、Pham 博士はすでにカレッジの AWS アカウントチームと関わっており、高等教育での勤務経験を考慮して、AWS Select Tier Services Partner である Ferrilli のチームとカレッジの近代化計画に関する会話を始めていました。 サイバーインシデント発生後、Pham 博士は AWS と Ferrilli に連絡し、行動計画の策定を開始しました。1ヶ月足らずで、博士とそのチームは、AWS Control Tower と AWS Organizations を使用して、AWS 上のインフラをセットアップすることができたのです。Pham 博士は、Hartnell College のデジタルインフラをクラウドに移行することができたのは、AWS と Ferrilli のおかげであると評価しています。 3. バックアップとリカバリーの計画を立て、それを実践する Pham 博士は、最悪のシナリオにきちんと備えることを提唱しています。Hartnell にとって、AWS はクラウドで迅速に復旧するために重要な役割を果たしました。 AWS Well-Architected Framework の 5 つの柱の 1 つは信頼性で、 ディザスターリカバリー（DR）のための計画 の必要性が強調されています。 バックアップを AWS Backup に保存し、復旧に必要なリソースを迅速に利用頂くというオプションを、AWS は教育機関のお客様へ提供しています。また、AWS Elastic Disaster Recovery は、AWS への復旧によりダウンタイムやデータ損失を最小限に抑えるサービスです。教育機関のバックアップ戦略の範囲にかかわらず、AWS はプロセスを文書化し、緊急時に備えて復旧を実践することを推奨しています。 4. リーダーシップ、サポート、チームの結束が迅速な変革の鍵 Pham 博士は、サイバーインシデントやクラウドコンピューティングへの移行という困難な状況下で、Hartnell のリーダーシップチーム、Hartnell のコミュニティの学生や教職員のサポート、そして IT スタッフが団結し、サポートし、前進することができたと評価しています。 信頼関係があり、オープンマインドを備えた結束力のあるリーダーシップチームを持つことで、より速いスピードで変化を起こすことができます。Hartnell の IT インフラは現在、AWS でホストされています。Hartnell は、AWS の幅広いサービスを活用し、アクセシビリティとアジリティを向上させることで学生の成功をさらに高めるために、他の AWS マネージドサービスの機能についても検討を始めています。 このようにサイバー攻撃に対応するための準備は IT システムの棚卸しからはじまり、バックアップやリカバリー計画だけでなく、 リーダシップチームのサポートや組織作り も鍵となります。 最後に こうやって紐解いていくと、「備え有れば患い無し」ということがよくわかりますね。 次回は本記事でお話した中から、皆様がよく関心を持たれるバックアップを中心にお話を進めてみたいと思います。 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 大学・研究機関のための AWS 資料 カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか 関連投稿 高等教育機関におけるスケーラブルなセキュリティの必要性 高等教育機関におけるバックアップとリカバリ計画の考慮点 この記事を書いた人 吉田　尚子 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 事業開発マネージャー “AWSのサービスが、公共のお客様にどのような価値を提供できるのか、海外の事例を取り入れなが分かりやすくお届けいたします”

こんにちは！ アマゾン ウェブ サービス (AWS) で事業開発を担当しております、吉田です。 私は AWS の先進的なサービスを、いかに公共のお客様が抱えていらっしゃる課題解決の手段としてご利用頂けるかということを、お客様との対話、社内外への情報発信、提案素材の作成といった活動を通して、AWS が皆様へどのような価値を提供できるのかということを分かりやすくお届けするサポートをさせて頂いております。 こちらの記事では「セキュリティ」についてご紹介します。 セキュリティは、世界中の公共のお客様にとって優先事項の一つです。 研究分野では国境を越えた共同研究も活発化しており、研究データをいかにデジタル攻撃から安全に保護するかということは、教育機関の皆様にとっても考えていかねばならない項目となりつつあります。 また、関連資料として、グローバルに教育で取り組みべきことがどのように話されているのかをレポートにした資料もご紹介しており、このレポートではより詳細な情報が掲載されております。ぜひご確認下さい！ 2023 年 3 月 20 日に AWS Public Sector Blog 内で投稿された『 The top 3 innovation drivers in higher education in 2023 』という記事の中で、AWS の高等教育機関のお客様が、イノベーションを推進するための鍵として、2023 年に何を最優先事項としているかということを説明されています。 テーマは 3 つ挙げられており １つ目は『教育・学習における選択の幅を広げ、学生中心主義にする』 ２つ目が『研究コミュニティにおけるスケーラブルなセキュリティの必要性』 ３つ目が『組織のリーダーシップに新たに必要とされているサステナビリティ』 です。 今回はこの中で２つ目の『研究コミュニティにおけるスケーラブルなセキュリティの必要性』をご紹介いたします。 計算機研究がユビキタス化し、キャンパスや国境を越えてオンラインで共同研究を行う研究者が増えるにつれ、研究データを保護する必要性は、IT部門だけでなく教育機関のリーダーシップにとっても優先事項となっています。セキュリティに関する政府の要求により、教育機関では、貴重な知的財産を保護するためのスケーラブルなシステムとコントロールの確立を包括的に考える必要性がさらに強まっています。 サイバー攻撃は、高等教育機関における業務のあらゆる側面を脅かし、特に研究業務に深刻なリスクをもたらします。 科学の研究方法が変化したことで、数十年前とは異なるまったく新しいリスクが生まれており、これらの攻撃は、攻撃者へ支払われる金銭以上の影響を組織にもたらします。 カナダの British Columbia 大学の情報技術担当副学長兼最高情報責任者である Jennifer Burns 氏は、次のように述べています。 コストは、身代金だけではありません。取締役会、経営陣、ITチームがクリーンアップに費やす時間と労力もコストであり、例え迅速に対応したとしても６か月間かかる可能性があります。それはクリーンアップの請負業者にかかるコストでもああります。また、他の優先すべき事項への注意がおろそかになり、全体として考えた時に、これらの攻撃は多大な影響を与えるのです。 最新のレポート「 高等教育機関におけるイノベーションの鍵 」で、これらの優先事項の詳細や、教育機関のリーダーがどのようにクラウド技術を利用して最大の課題を解決し、教育機関の将来性を高めようと考えているかをご確認頂けます。 セキュリティの重要性を再確認できましたので、実際にオンプレミスで管理されていた大学のシステムがサイバー攻撃の対象となり、それをきっかけにAWSクラウドへの移行を迅速に推進されたという海外の事例 ( How Hartnell College recovered critical systems using AWS after a cyber attack ) をご紹介したいと思います。 サイバー攻撃後、Hartnell CollegeがAWSを使って重要なシステムを復旧させた方法 Hartnell College は、カリフォルニア州サリナスにある公立のコミュニティ・カレッジで、7,500 人以上の学部生が在籍しています（2020-2021）。2022 年春に最高情報システム責任者の Chelsy Pham 博士が着任したとき、カレッジは IT インフラの近代化の必要性を認識していました。Pham 博士と彼女のチームは、Amazon Web Services（AWS）への移行という長期的なビジョンを持っており、近代化を促進するためのクラウド戦略を策定している最中でした。 これが一変したのは、2022 年 10 月 2 日（日）午前 6 時のことでした。ネットワーク障害が発生したことから、サイバー攻撃の発生が疑われ、Hartnell の IT 部門はすべての内部ネットワークを停止させました。一時的に外部のウェブサイトやサービスにアクセスできなくなり、学内の教室のプロジェクターも使用できなくなりました。Hartnell College はサイバー調査員に依頼し、予備調査の結果、Hartnell College が高度なランサムウェア攻撃の被害を受けたことが判明しました。 同大学は可能な限りの復旧を行い、AWS 上でシステムの再構築を開始しました。AWS コンサルティングパートナーである Ferrilli のチームの協力により、中核となる学生情報システム（SIS）はすぐにクラウド上で稼働し、その後基盤インフラもクラウド上で稼働することになりました。これが Hartnell の IT チームが IT インフラを再構築して復旧をするはじまりとなりました。 彼らの復旧・再構築戦略の詳細については、ケーススタディ “ カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか ” で詳しく説明しております。フォームからダウンロード可能です。 最後に いかがでしたでしょうか？ 日本においても同じような課題感があるのではないかと思います。 こちらの記事ではグローバルの取り組みや事例についてご紹介させて頂きましたので、次回はサイバー攻撃に対する予防と準備のために検討しておく項目をHartnell Collegeの事例から読み解いてみたいと思います。 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 大学・研究機関のための AWS 資料 高等教育機関におけるイノベーションの鍵 カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか 関連投稿 高等教育機関におけるサイバー攻撃に対する予防と準備 高等教育機関におけるバックアップとリカバリ計画の考慮点 この記事を書いた人 吉田　尚子 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 事業開発マネージャー “AWSのサービスが、公共のお客様にどのような価値を提供できるのか、海外の事例を取り入れなが分かりやすくお届けいたします”

8月28日週は AWS Summit Mexico で多くのお客様とパートナーにお会いする予定です。ほとんどの時間は、コミュニティラウンジと F1 Game Day で過ごします。機会があれば声をかけてください。AWS での開発経験について語り、AWS での構築についての皆さんのお話を伺うことを楽しみにしています。 8月21日週のリリース サービスチームが AWS イスラエル (テルアビブ) リージョン とも呼ばれる新しい il-central-1 リージョンにサービスを驚くほど迅速にデプロイしました。。8 月 1 日のリージョン提供開始以来、先週の 10 のサービスを始めとして 25 以上の新しいサービス発表 がありました。 新しいリージョンでのこれらの開発に加えて、8月21日週、私が注目したローンチをいくつかご紹介します。 AWS Dedicated Local Zones – Local Zones と同様に、 Dedicated Local Zones は、AWS によって完全に管理される AWS インフラストラクチャです。しかし、Local Zones とは異なり、お客様またはコミュニティ専用に構築されていて、規制要件を満たすためにお客様が指定した場所またはデータセンターに配置されます。これらは専用の AWS インフラストラクチャの一部だと考えることができます。 AWS re:Post の検索機能の強化 – AWS re:Post はクラウドナレッジサービスです。強化された検索機能を使用すると、回答や記事をよりすばやく見つけることができます。検索結果は、re:Post のすべての AWS ナレッジの統合ビューを表します。ビューには、検索クエリに関連する AWS ナレッジセンターの記事、質問と回答、コミュニティの記事が表示されます。 スケジュールされたプログラムによる Microsoft Excel へのエクスポートを Amazon QuickSight がサポート – Amazon QuickSight のダッシュボードのシートから複数のテーブルとピボットテーブルビジュアルを選択して Excel ワークブックのスケジュール生成を行うことができるようになりました。ページ分割 PDF と CSV に加えて、 Snapshot Export API が Excel 形式へのプログラムによるエクスポート をサポートするようになりました。 Amazon WorkSpaces が Ubuntu 20.04 と 22.04 をサポートする新しいクライアントを発表 – WorkSpaces Streaming Protocol (WSP) を搭載し、強化されたウェブ会議機能、マルチモニターサポートの向上、よりユーザーフレンドリーなインターフェイスを提供する新しいクライアントでは、リモートデスクトップエクスペリエンスが向上します。使用を開始するには、 Amazon WorkSpaces クライアントダウンロードのウェブサイト から新しい Linux クライアントバージョンをダウンロードしてください。 Amazon Sagemaker CPU/GPU プロファイラー – 大規模な深層学習ワークロード向けの高度なオブザーバビリティツールである Amazon SageMaker Profiler のプレビュー がローンチされました。この新機能を使用すると、コンピューティングハードウェアに関連するきめ細かいプロファイルインサイトにアクセスして、 モデルトレーニング のパフォーマンスを最適化することができます。 Amazon Sagemaker のローリングデプロイ戦略 –  ローリングデプロイ戦略を使用して Amazon SageMaker エンドポイントを更新できるようになりました。 ローリングデプロイ では、多数の一般的な高速コンピューティングインスタンスにデプロイされ、完全にスケールしたエンドポイントを簡単に更新できます。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 AWS Lambda でのオンデマンドコンテナローディング – これは8月28日週の新しいトピックでははありませんが、休暇中に見つけました。 Marc Brooker のチームが「 On-demand Container Loading in AWS Lambda 」(pdf) で USENIX Association の Best Paper アワードを受賞しました。チームは、このドキュメントで AWS Lambda で (大規模な) コンテナイメージを読み込む際の課題について詳しく解説しました。 Lambda 関数が背後でどのように機能するか を知りたい方は必読です (pdf)。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報  – 私の同僚である Ricardo  が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Hybrid Cloud & Edge Day (8 月 30 日) – 無料で参加できる 1 日のバーチャルイベントに参加して、ハイブリッドクラウドとエッジコンピューティングの最新のトレンドと新しいテクノロジーに関する講演を聴き、AWS リーダー、お客様、業界アナリストが紹介するベストプラクティスを学習してくだだい。詳細については、 詳細なアジェンダを参照して、今すぐ登録 してください。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ  (8 月 30 日) と ヨハネスブルグ  (9 月 26 日) の 2 回の対面イベントです。 AWS re:Invent – re:Invent シーズン (11 月 27 日～12 月 1 日) が間もなく始まります。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。  登録が開始されました 。 AWS Community Day   – AWS ユーザーグループが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 ニュージーランド  (9 月 6 日)、 レバノン  (9 月 9 日)、 ミュンヘン  (9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 チリ (9 月 30 日) で開催されます。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 CDK Day (9 月 29 日) – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントです (英語とスペイン語)。 詳細については、ウェブサイトを参照してください 。 今週はここまでです。9月4日週に再びアクセスして、新たな Week in Review をぜひお読みください! この記事は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! — seb 原文は こちら です。

2023/08/10 に「最新のサイバー攻撃の現状と Web セキュリティ対策 (WAF/DDoS対策) 実例セミナー」を開催いたしました。このセミナーでは最新のサイバー攻撃の現状および AWS が提供する Web セキュリティ対策サービスを AWS からご紹介し、AWS のサービスを組み合わせて、どのように Web セキュリティ対策を講じたかをお客様よりご説明いただきました。 それではここから当日のセッション内容について簡単にご紹介していきます。 2023第一四半期サイバー攻撃動向アップデート : 動画 アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト マネージャー 中谷 喜久 最初のセッションでは、前半は AWS Threat Intelligence について説明をしました。インターネットでは DDoS 攻撃、アプリケーションの脆弱性を突いた攻撃や悪質なボットによる攻撃等のリスクにさらされています。AWS では Threat Intelligence チーム（脅威分析チーム）と呼ばれる部隊がインフラを安心してご利用いただくために疑わしい IP や C2/Command and Control への通信経路など様々な脅威となる情報を収集し対応を行っています。これらで得られた知見を元に AWS ウェブアプリケーションファイアウォール (AWS WAF) , AWS Shield , Amazon GuardDuty などの AWS のサービスにフィードバックを行っていることをご紹介しました。また後半では、AWS Edge Services / Perimeter Protection と DDoS トレンドについて説明しました。AWS が観測したデータによると昨年に引き続き DDoS は大きな脅威であり、アプリケーションレイヤーへの DDoS 攻撃は 48% を占め、年間の DDoS 発生件数は 40% 増と増加傾向であり、2023年 Q1 での帯域とパケットにおける攻撃の最大値は 996 Gbps(bits)/480 Mpps(packets per second) であったことを紹介しました。最後に AWS Shield Global Threat Dashboard を見ることで Mpps、Gbps、Krps の値を見ながら DDoS のトレンドが確認できることをご紹介しました。 ウェブアプリケーションのセキュリティ向上に貢献する Amazon CloudFront と AWS WAF の最新機能のご紹介 : 動画 アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト 岡 豊 続いてのセッションでは 、エッジネットワークサービスである Amazon CloudFront と AWS WAF を活用した Web セキュリティ対策をご紹介しました。前のセッションでもお伝えしましたが、DDoS 攻撃、アプリケーションの脆弱性を突いた攻撃や悪質なボットによる攻撃等は年々増加する傾向にあります。 まず最初に Amazon CloudFront できる対策として、 HTTP メソッドやプロトコルの制限、アプリケーション特有のヘッダーを削除する CloudFront の設定 オリジン直接の攻撃からの保護方法として、 オリジンアクセスコントロール (OAC) および CloudFront マネージドプレフィックスリスト さらに AWS WAF を CloudFront にアタッチすることで、 事前定義済みのルールセットであるマネージドルールやカスタムルールの作成 不正ログイン対策として Account Takeover Prevention (ATP) Bot 対策として AWS WAF Bot Control DDoS 対策としてのレートベースルール 等、様々な機能が利用できることをご説明しました。また、 不正アカウント対策をする Account Creation Fraud Prevention (ACFP) 検査するボディサイズの拡張 等の AWS WAF の最新アップデートもご紹介しました。これらの機能を活用することでコスト効率を高め、セキュリティレベルを向上できることをお伝えしております。 以降のセッションでは Web セキュリティ対策についてお客様が取り組まれた事例をご紹介いただきました。 BookLiveにおけるWebセキュリティ対策 ～安心して読書を楽しめる環境を守る～ : 動画 株式会社BookLive 技術・開発本部システム開発部 SRE チーム マネージャー 日向野 達郎 様 株式会社BookLive 様は「ブックライブ」をはじめとした電子書籍ストアを運営するストア事業を含む 4 つの事業を運営されており、お客様がいつでも安心して読書を楽しめる環境を守るために、サイバー攻撃に対して素早く・柔軟に対応するための様々な取り組みを行われています。本セッションではこの取り組みについてご紹介いただきました。2016 年に AWS 完全移行が完了し安定稼働した状態でしたが、セキュリティに関して「知名度向上に伴ってサイバー攻撃を受けるリスクが高くなる」、「悪性 Bot による WEB サーバの負荷増やエラーレートの増加」という課題をお持ちでした。 この課題解決のために、 AWS WAF+WafCharm によるサイバー攻撃に対して柔軟かつ素早く対策する環境の構築 AWS Shield Advanced による、DDoS 攻撃の緩和 AWS WAF のレートベースルールによって、Bot による過剰なリクエストの抑制 を実現され、セキュリティ対策を行われています。更に Bot 対策では、将来的なリスク低減のために、IP アドレス以外を条件としたレートベースルールや AWS WAF Bot Control の導入をご検討されています。最後に、「 BookLive ではお客様がいつでも安心して読書を楽しめる環境を守るために、これからも積極的にセキュリティ対策のアップデートを実施していきます。」とのコメントを頂きました。 ココナラが膨大なセキュリティログの可視化と分析を実現するまで : 動画 株式会社ココナラ様は事業として「知識・スキル・経験」を売り買いできるスキルマーケットを中心に 4 つのプロダクトを展開されており、現在はココナラビジネスの領域が伸びている状況で会員数も右肩上がりになっています。2021 年 9 月に立ち上げた CSIRT は 2 名の組織（2023 年 8 月時点）で、セキュリティ施策の企画からモニタリング運用まで担当されています。そのため、優先度の高い施策を効率的に遂行することが不可欠となっています。本セッションではセキュリティログの分析の課題や勘所をご説明いただきました。AWS WAF や Elastic Load Balancing（ELB） のセキュリティログ分析には難しい点が 2 つあります。1 つ目はそのままのログ形式では読みづらく他のログとの相関関係が判断しにくいという点、2 つ目はログの量が膨大であり人力で確認することが非現実的という点です。その解決策としてアクセス状況や攻撃・インシデントの可視化・予測を行うことを目的として SIEM on Amazon OpenSearch Service を導入されました。結果、可視化 → 分析 → 改善とサイクルを回せるようになり、累計 1000 万回以上の悪意のあるアクセスをブロックし、正規ユーザーのアクセスを守ることができています。最後に、一度導入して終わりではなく運用後の改善やリアクティブではなくプロアクティブな仕掛け、セキュリティ強化を進めていくために経営層にセキュリティ対策の必要性・効果を理解してもらうことが重要であるとご説明いただきました。 おわりに 本ブログでは 2023/08/10 に開催された「最新のサイバー攻撃の現状と Web セキュリティ対策 (WAF/DDoS 対策) 実例セミナー」の内容についてご紹介しました。AWS からの最新情報発信だけでなく、お客様から事例をご紹介いただいた非常に学びの多いセミナーでした。最後に今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続きの皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 このブログはソリューションアーキテクトの長谷川純也が担当しました。