Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

AWS ホットスタートアップ – 2017 年 1 月

新年の始まりにあたり、再び Tina Barr が優れた多くのスタートアップ企業をさらに紹介します。ぜひご覧ください。 -Ana 本年も引き続き、AWS を利用しているホットなスタートアップ企業を紹介していきます。本日は、3 つの新しいスタートアップ企業を紹介します。 ClassDojo – 教師、児童生徒、親をクラスへとつなぎます。 Nubank – 銀行取引の概念を変える金融サービスのスタートアップ企業。 Ravelin – 機械学習モデルの上に構築された不正検出会社。 昨年の主なスタートアップ企業の紹介をまだお読みになっていない場合は、「1 年を振り返る」をぜひご覧ください。 ClassDojo (サンフランシスコ) 2011 年に Liam Don 氏と Sam Chaudhary 氏によって開始された ClassDojo は、クラス向けの通信プラットフォームです。教師、親、児童生徒は 1 日を通じて、写真、ビデオ、メッセージングを通じた重要な時間を共有するための場所としてこれを使用できます。今日、多くのクラスが万人向けのモデルとして運営されている中、ClassDojo の創設者は教育システムを改善し、世界中の 7 億人の初等教育の対象児童に、最善のコンテンツやサービスを受けさせたいと考えました。Sam と Liam が、クラスにとって何が最も役立つかを教師に質問したところ、多くの教師は、思いやりや寛容さのあるコミュニティが必要と答えました。つまり、クラスにかかわっている全員につながることができるコミュニティです。ClassDojo では、教師は児童生徒やその親と協力して独自のクラス文化を創造することができます。ClassDojo は 5 年で米国およびその他 180 か国の幼稚園から中学校までの 90% に拡大し、そのコンテンツは 35 か国語以上に翻訳されました。最近、ハーバード大学およびスタンフォード大学と共同作成された「Empathy and Growth Mindset」のビデオシリーズにより、さらに多くのクラスに拡大しました。これらのビデオは、米国の 14 歳以下の子どもの 3 […]

Read More

AWS IPv6 の更新 – 15 のリージョンおよび複数の AWS のサービスにまたがるグローバルサポート

過去数年間に、IPv6 のサポートを AWS の多くの異なる部分に追加してきました。最初は 、、、、、、および S3 Transfer Acceleration から開始し、最終的には先月発表した Virtual Private Cloud の EC2 インスタンスに対する IPv6 のサポート (当初は リージョンで利用開始) にまで拡大されました。本日は、VPC の EC2 インスタンスに対する IPv6 のサポートが、合計 15 のリージョンで利用でき、これらのリージョンのうち 9 つで、IPv6 に対する Application Load Balancer のサポートが利用できるようになったことをお知らせします。IPv6 アドレスを使用できるアプリケーションを構築およびデプロイして、サーバー、オブジェクトストレージ、ロードバランサー、およびコンテンツ配信サービスと通信できます。Apple および他のベンダーからの IPv6 サポートの最新のガイドラインに従い、モバイルアプリケーションは、AWS と通信するときに IPv6 アドレスを使用できるようになりました。 IPv6 が 15 リージョンで利用可能に 新しい VPC および既存の VPC の EC2 インスタンスに対する IPv6 のサポートが、、、、、、、、、、、、、、、および リージョンで利用可能になり、今すぐ使用を開始できます。新しい […]

Read More

AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント

同僚のJohn PignataがAmazon ECSに対する継続的デプロイメントパイプライン作成方法について素晴らしいブログを書いてくれました。 — 今日のビジネス環境では、新しいソフトウェアの反復を高速で提供することは競合に対するアドバンテージになります。企業がイノベーションを顧客に提供するスピード、変化する市場に適応するスピードは、ますます成功と失敗の違いを生む重要な要素になっています。 AWSは、企業がアプリケーションやサービスを高速に提供する組織の能力を向上させるDevOpsと呼ばれる文化哲学、実践、ツールの組み合わせを企業が採用できるように設計された一連の柔軟なサービスを提供します。 このポストでは、継続的デプロイメントと呼ばれるデプロイの実行方法について説明し、AWS CodePipeline、 AWS CodeBuild、および AWS CloudFormationを使用してAmazon ECS上のDockerコンテナとして提供されるアプリケーションの自動デプロイメントパイプラインを実装するためのリファレンスアーキテクチャの概要を説明します。 継続的デプロイメントとは? 俊敏性は、ITリソースのトラディショナルな提供方法に比べてクラウドコンピューティングが持つ重要な利点としてよく引用されています。他の部門が新しいサーバーをプロビジョニングするのに数週間か数ヶ月待つ代わりに、開発者はシングルクリックやAPIコールで新しいインスタンスを作成することができ、数分で使用開始することができます。この新たな速度と自律性は、開発者が新しい製品や機能を試し、できるだけ早く顧客に提供するこを可能にします。 製品の市場投入期間を短縮し、コードの品質を向上させ、より信頼性の高い製品やサービスのリリースを実現するために、開発チームはクラウド上でDevOpsの実践を採用しています。 継続的デプロイは、新しいソフトウェアリビジョンが自動的にビルドされ、テストされ、パッケージ化され、本番環境にリリースされる、DevOpsの実践です。 継続的デプロイにより、開発者は完全に自動化されたソフトウェアリリースプロセスを通じて機能や修正を出荷できます。開発者は、数週間や数ヶ月にわたる大規模なリリースをバッチ処理し、手動で展開する代わりに、新しいソフトウェアリビジョンが準備され次第、自動化されたプロセスを使用してアプリケーションのバージョンを1日に何回も配信することができます。クラウドコンピューティングがリソースの調達期間を短縮するのと同様に、継続的デプロイは新しいソフトウェアのリリースサイクルを数週間~数ヶ月から数分間に短縮します。 このスピードと敏捷性を活用することには、次のような多くの利点があります。 新機能やバグ修正を迅速にすることができる :  ソースコードリポジトリに置いてあるコードは、ビジネス価値をもたらしたり、顧客に利益をもたらすものではありません。新しいソフトウェアリビジョンをできるだけ早くリリースすることで、顧客はより迅速に利益を享受できるようになり、チームはより集中的なフィードバックを得ることができます。 変更セットが小さくなる : 大きな変更セットは、問題、バグ、およびその他の退化の根本原因を突き止める際に問題を引き起こします。より小さな変更セットを頻繁にリリースすることで、チームは発生した問題をより簡単に特定して修正することができます。 自働デプロイによりベストプラクティが促進される : ソースコードリポジトリにコミットされた変更は即座に自動プロセスによってデプロイすることができるため、チームはその変更が十分にテストされ、運用環境が厳重に監視されていることを確実にする必要があります。 継続的デプロイはどのように動くのか? 継続的デプロイは、ソフトウェアのリリースに関連する活動を調整する自動化されたパイプラインによって実行され、プロセスの可視性を提供します。プロセスの最中に、リリース可能な成果物が構築され、テストされ、パッケージ化され、本番環境にデプロイされます。リリース可能な成果物には、実行可能ファイル、スクリプトファイルのパッケージ、コンテナ、または最終的にプロダクションに配信されなければならないその他のコンポーネントが含まれます。 AWS CodePipelineは、新しいソフトウェアリビジョンができるたびにコードのビルド、テスト、およびデプロイを実行する継続的デプロイおよび継続的デリバリーのサービスです。 CodePipelineは、コード変更の統合、可視化を行い、ワークフローを介して最終的にユーザーの提供します。このパイプラインは、ソースコードリポジトリからのコード取得、ソースコードのビルド、テスト、および本番環境へのデプロイといったステージを定義し、これらのステージが順番に実行されること、障害が発生した場合には停止することを保証します。 CodePipelineはデリバリパイプラインを強化し、プロセスを統合しますが、ソフトウェア自体をビルドまたはテストする機能はありません。このステージでは、CodePipelineは、フルマネージドのビルドサービスであるAWS CodeBuildなど、いくつかのツールと統合されます。 CodeBuildはソースコードをコンパイルし、テストを実行し、デプロイする準備が整ったソフトウェアパッケージを生成します。このサービスは継続的なデプロイパイプラインの構築とテストに最適です。CodeBuildはDockerコンテナのビルドを含む多くの異なる種類のビルド環境をネイティブサポートしています。 コンテナは、予測可能で再現可能な環境を実現し、ある環境でテストされた変更が正常に展開できるという高いレベルの信頼性を提供するため、ソフトウェア提供の強力なメカニズムです。 AWSは、Dockerコンテナイメージを実行・管理するためのいくつかのサービスを提供しています。 Amazon ECSは、非常に高い拡張性とパフォーマンスを持つコンテナ管理サービスで、Amazon EC2インスタンスのクラスタ上でアプリケーションの実行環境を提供します。  Amazon ECRは、フルマネージドのDockerコンテナレジストリで、開発者は簡単にDockerコンテナイメージの格納、管理、およびデプロイが可能です。 最後に、CodePipelineはデプロイメントを容易にするために、AWS Elastic Beanstalk、AWS CodeDeploy、AWS OpsWorksや、AWS LambdaまたはAWS CloudFormationを使用した独自のカスタムデプロイメントコードやデプロイプロセスなど、いくつかのサービスと統合されます。これらのデプロイアクションを使用してパイプラインの最後に新しく構築された変更を本番環境にプッシュすることができます。 Amazon ECSへの継続的デプロイ これらのコンポーネントを組み合わせて、Dockerアプリケーションの継続的なデプロイパイプラインをECSに提供するためのリファレンスアーキテクチャを次に示します。 このアーキテクチャーは、CodePipelineを使用してECSおよびECRにコンテナをデプロイし、AWS上でフルマネージドの継続的デプロイパイプラインを構築する方法を示しています。この継続的デプロイのアプローチは、完全にサーバーレスであり、ソフトウェアの統合、ビルド、およびデプロイにマネージドサービスを使用します。 リファレンスアーキテクチャで作成されたパイプラインは、次のようになります。 このポストでは、このリファレンスアーキテクチャの各ステージについて説明します。開発者がランディングページの原稿を変更し、その変更をソースコードリポジトリにプッシュするとどうなるでしょう? まず、Source ステージでは、ソースコードリポジトリシステムにアクセスするための詳細がパイプラインに設定されます。リファレンスアーキテクチャでは、GitHubリポジトリにホストされているサンプルアプリケーションがあります。 CodePipelineはこのリポジトリをポーリングし、新しいコミットごとに新しいパイプラインを実行開始します。 […]

Read More

Raspberry Pi から、スーパーコンピューター、クラウドまで: Linux オペレーティングシステム

再び、Matthew Freeman および Luis Daniel Soto が、AWS Marketplace を通じた Linux の使用について説明します。 – Ana Linux は、ファイルサーバーからウェブサーバー、ネットワークセキュリティサーバーまで、すべての基礎として企業で幅広く使用されています。無料であること、そしてディストリビューションが商業的に利用可能であることが、多くのシナリオで当然のように選択される理由となっています。現在、Linux のディストリビューションは、小さな Raspberry Pi から世界最大のスーパーコンピューターまで、さまざまなマシンで利用されています。最小限およびセキュリティが強化された多様なディストリビューションがあり、その一部は GPU ワークロード向けに設計されています。さらに有用であるのは、クラウドベースのインフラストラクチャにおける Linux の使用です。その比較的軽量なアーキテクチャ、柔軟性、およびカスタマイズオプションにより、Linux はクラウド上の永続的なネットワークインフラストラクチャをはじめ、科学調査のコンピューティング負荷を処理する一時的な高パフォーマンスサーバーファームなどの特殊な用途に最適な選択となります。AWS は、Linux プラットフォームに対する独自の取り組みを示すため、AWS のサービスと緊密に連携した独自のバージョンの Linux を開発し、管理を継続しています。AWS は、AWS Marketplace を通じて、Linux およびオープンソースコミュニティのパートナーとなってきました。 これは、お客様がソリューションを構築してビジネスを営むのに必要なソフトウェアやサービスを簡単に発見、購入、デプロイできるマネージド型ソフトウェアカタログです。 お客様が簡単なクリック操作でユーザー契約を受諾し、価格オプションを選択して、ソフトウェアおよび関連 AWS リソースのデプロイを自動化できるようにすることで、ソフトウェアのライセンスと調達が簡略化されます。 検索およびフィルタリングにより、単独または他のコンポーネントと組み合わせて、ビジネスニーズに最適な Linux ディストリビューションを選択できます。 お客様用の Linux ディストリビューションの選択 Linux を初めて使用する場合、非常に多くのディストリビューションがあるため、戸惑うことがあります。使用するディストリビューションの決定はさまざまな要因によって影響を受けますが、お客様からは次のような考慮事項が重要であるという声が寄せられています。 Linux への既存の投資 (ある場合) Linux を初めて使用する場合は、すべてのオプションをかなり平等に検討する必要があります。 使用中の既存のプラットフォーム(オンプレミスネットワークなど) 社内ネットワークに接続する必要があるクラウドインフラストラクチャを追加する場合は、どの Linux ディストリビューションに必要なネットワーキングとアプリケーションコネクタがあるかを検討する必要があります。 複数のクラウドプラットフォームを使用する意図 […]

Read More

コストアロケーションタグがAmazon DynamoDBに対応しました

Amazon DynamoDBのテーブルにタグを設定可能になりました。タグは多くのAWSサービスでサポートしている、シンプルでユーザがカスタマイズ可能なキー・バリューのペアです。DynamoDBのタグ対応は DynamoDBの利用料金の可視化に有効です。テーブル毎にタグを設定でき、タグ毎に料金を参照出来ます。 様々な環境(development/staging/production)で複数のDynamoDBテーブルを持っているシナリオを例に上げてご説明します。DynamoDBテーブルにタグを設定出来ます。例として、keyにEnvironment、valueにDevelopment, Staging, Productionとそれぞれ設定します。 DynamoDBコンソールでどのように設定するか見ていきましょう。設定を行う前にListTagsOfResourceとTagResourceのAPI操作を行う適切な権限を持っているか確認をして下さい。 AWS Management Consoleにサインインをし、https://console.aws.amazon.com/dynamodb/からDynamoDBコンソールを開きます Tablesを選択し、設定を行ないたいテーブルを選択します Settingsタブで、Tagsをナビゲーションメニューから選択します Add Tagsセクションで、KeyにEnvironment、ValueにDevelopmentを入力し、Apply Changesをクリックします 標準の動作では、新しく追加されたキーはbillingでは無効化されています。以下の手順でBilling Consoleよりアクティベートを行えます: AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます ナビゲーションメニューからCost Allocation Tagsを選択します User-Defined Cost Allocation Tagsセクションから、タグキー内の Environmentタグ横のチェックボックスを選択し、Activateをクリックします アクティベート済みのコストアロケーションタグがある場合、AWS Cost Explorerからタグ付けされたAWSリソースのコストを簡単にブレークダウンして閲覧出来ます: AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます ナビゲーションメニューからCost Explorerを選択し、Launch Cost Explorerを選択します 左上のメニューからMonthly costs by serviceを選択し、右のメニュー内の Time rangeから閲覧したいタイムレンジを指定します Filteringセクション内のFilter byからTagを選択します タグキーのオートコンプリートフィールドから Environmentを選択、Developmentをタグバリューのオートコンプリートセクションから選択し、Applyをクリックします 指定したタグ(Environment=Development)でコストがフィルタリングされます。コストはタグをAWSリソースに指定した時点から表示されます DynamoDB Management Console, AWS CLIやAWS […]

Read More

AWS IoT Button Enterprise Program のご紹介

AWS IoT ボタンは 2015 年 10 月 に AWS re:Invent の AWS IoT サービスの発表で初めて IoT シーンに登場しました。その年の re:Invent の全参加者は、AWS IoT を実践する機会を提供する AWS IoT ボタンを受け取りました。その時以来、AWS IoT ボタンは、クリック可能な IoT デバイスに興味のあるすべての人に広く利用可能になりました。最近開かれた AWS re:Invent 2016 カンファレンスでは、AWS IoT Button Enterprise Program により企業向けの AWS IoT ボタンが公開されました。このプログラムは、物理的なボタンをクリックすることにより新しいサービスを提供したり、既存の製品を改善できるように企業を助けるためのものです。AWS IoT Button Enterprise Program では、企業はプログラム可能な AWS IoT ボタンを使用して、顧客エンゲージメントを高め、アプリケーションを拡張し、ユーザーエクスペリエンスを簡素化して、顧客に新しいイノベーションを提供することができます。IoT の力を活用することにより、企業は製品やサービスに対する顧客の需要にリアルタイムで対応することができ、シンプルなデバイスを通じて顧客に直接的なコミュニケーションを提供することができます。   AWS IoT Button Enterprise Program 新しい […]

Read More

RDS MySQL DBインスタンスからAmazon Aurora Read Replicaを作成可能になりました

24時間365日稼働しているアプリケーションが利用しているデータベースエンジンを他のデータベースエンジンに移行するにはいくつかの方法を使う必要があると思います。データベースをオフラインにせずに移行する良い方法として、レプリケーションを利用する方法があります。 本日、Amazon RDS DB for MySQLインスタンスを Amazon AuroraにAurora Read Replicaを作成して移行する機能をリリースしました。マイグレーションは、まず既存のDBスナップショットを作成し、そこからAurora Read Replicaを作成します。レプリカのセットアップが完了後、ソースデータベースとのレプリケーションの設定を行い最新のデータをキャッチアップします。レプリケーションラグが0になればレプリケーションが完了した状態です。この状態になった後に、 Aurora Read Replicaを独立したAurora DB clusterとして利用可能で、アプリケーションの設定を変更しAurora DB clusterに接続します。 マイグレーションはテラバイトあたり数時間かかります。また、6TBまでのMySQL DBインスタンスに対応しています。InnoDBテーブルのレプリケーションはMyISAMテーブルのレプリケーションよりもやや高速で、圧縮されていないテーブルの利点も受けられます。 RDS DBインスタンスをマイグレーションするためには、 AWS Management ConsoleからRDSのコンソールを選択し、Instance Actionsを選択します。その後、Create Aurora Read Replicaを選択するだけです: そして、データベースインスタンスの情報やオプションを入力し、Create Read Replicaをクリックします: コンソール上でマイグレーションの進捗状況を閲覧出来ます: マイグレーション完了後、Aurora Read Replicaでレプリカラグが0になるのを待ちます(SHOW SLAVE STATUSコマンドをレプリカで実行し、“Seconds behind master”を監視します)。その後、ソースのMySQL DBインスタンスへの新しいトランザクションを停止し、Aurora Read ReplicaをDBクラスタに昇格させます: 新しいクラスタが利用可能になるまで待機します(通常は1分程度): 最後に、アプリケーションの設定をクラスタのread/writeエンドポイントを利用するように設定し完了です! — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

すぐに使用できるソリューション: AWS Marketplace のオープンソースソフトウェア

AWS Marketplace では、すばらしいことがたくさん起きています。こちらで、マーケットプレイスのオープンソースソフトウェアについての詳細を、Matthew Freeman および Luis Daniel Soto が説明します。 – Ana 業界の調査によると、企業が使用するオープンソースソフトウェア (OSS) は増加しています。ますます多くの企業の開発者は、現在進行中の開発作業の一環として、利用可能な OSS ライブラリを使用するように求めています。これらの開発者は、自分のプロジェクト (夜間および週末など) で OSS を使用していることがあり、その場合自然に別の場所でもそのツールおよびテクニックを使用したいと考えます。そのため、すべての部門の開発組織は、販売するソフトウェアだけでなく、自社の IT インフラストラクチャ内のアプリケーションにオープンソースソフトウェアを使用するケースを検討しています。この概要では、AWS を通したオープンソースソフトウェアの入手が開発および財務の観点から理にかなっている理由について説明します。 オープンソース開発プロセス オープンソースソフトウェアは、一般的に参加者の独立したコミュニティで開発されるため、ソフトウェアのバージョンの取得および管理は、通常オンラインコードリポジトリを通して行われます。異なるソースからのコードを使用すると、コードライブラリおよび開発ツールを取得して共に機能させることが困難となる場合があります。しかし、AWS Marketplace は、このプロセスをスキップして、必要な OSS で EC2 インスタンスを直接起動できます。AWS Marketplace には、OSS ソリューションの基盤として使用できる Linux のディストリビューションもあります。 構成済みのスタックが与えるメリット 市販のソフトウェアでこの 1-Click 起動機能は当然のことと考えるかもしれませんが、OSS にとって構成済みの AMI を実装していることには大きなメリットがあります。AWS Marketplace は、最も一般的なオープンソースソフトウェアの組み合わせ、または「スタック」を作成するソフトウェア会社に、これらのスタックを AWS クラウドに起動できる場所を提供します。TurnKey および Bitnami のような企業は、OSS のエキスパートを使って、ソフトウェアが共にうまく機能するようにこれらのコードスタックを設定および最適化します。これらの企業は、OSS のリリースを最新の状態に保ち、新しいバージョンが利用可能になるとすぐにスタックを更新します。これらの企業の中には、クラウドベースのサーバーの起動および管理をさらに容易にするために、クラウドホスティングインフラストラクチャを有料サービスとして提供しているものもあります。たとえば、オープンソースソフトウェアの最も一般的な組み合わせの 1 つは、LAMP スタックで、Linux […]

Read More

AWS Lambda – 2016 年を振り返って

2016 年は AWS Lambda、Amazon API Gateway、そして、サーバーレスコンピューティングテクノロジーにとって、控えめに言ってもすばらしい年となりました。もしかすると、AWS Lambda および Amazon API Gateway でのサーバーレスコンピューティングについて耳にしたことがない方がいらっしゃるかもしれませんので、これらのすばらしいサービスについてご紹介したいと思います。AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。このイベント駆動型のサーバーレスコンピューティングサービスにより、開発者は、ほぼすべての種類のアプリケーションまたはバックエンドで機能を簡単にクラウドへ移行できます。Amazon API Gateway は非常にスケーラブルで、信頼性が高く、堅牢な API を大規模にすばやく構築するのに役立ち、作成した API の維持およびモニタリングの機能も提供します。2016 年のサーバーレスの勢いの締めくくりとして、AWS チームは re:Invent でサーバーレスソリューションの構築をさらに簡単にする強力なサービス機能を発表しました。その機能には次のものがあります。 AWS Greengrass: Lambda および AWS IoT を使用して、接続された IoT デバイスのローカルでのコンピューティング、メッセージング、データのキャッシングを実行します。https://aws.amazon.com/blogs/aws/aws-greengrass-ubiquitous-real-world-computing/ Lambda@Edge Preview: グローバル AWS エッジロケーションでコードを実行でき、Amazon CloudFront のリクエストに応じてトリガーされることで、エンドユーザーのネットワークレイテンシーを削減できる Lambda の新しい機能です。https://aws.amazon.com/blogs/aws/coming-soon-lambda-at-the-edge/ AWS Batch Preview: 今後予定されているバッチジョブとしての Lambda 統合を含む AWS コンピューティングサービスにおけるワークロードの計画、スケジューリング、実行のコンピューティング用バッチです。https://aws.amazon.com/blogs/aws/aws-batch-run-batch-computing-jobs-on-aws/ AWS X-Ray: マイクロサービスアーキテクチャを使用してビルドされたもの、Java、Node.js、.NET で記述されたもの、EC2、ECS、AWS […]

Read More

Amazon Aurora Clusterに監査機能を追加

re:InventでMySQLデータベースと互換性があり、コマーシャルデータベースの性能と可用性、オープンソースデータベースのコストパーフォーマンスの両面をそなえた、Amazon Auroraの新機能を発表しました。 今日、advanced auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。 advanced auditingとは Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。advanced auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。 Auroraのadvanced auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。 advanced auditingを利用するには まずはじめに、advanced auditingを有効にし、audit logを参照します。 advanced auditingの有効化 DBクラスタパラメータグループにあるパラメータを設定することでadvanced auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。また、動作は Aurora DB instance parametersと同様です。 機能を有効/無効化するために server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。 server_audit_excl_usersとserver_audit_incl_usersパラメータでどのユーザを監査対象にするか設定可能です: server_audit_excl_usersとserver_audit_incl_usersが未指定の場合(デフォルト値)は全てのユーザが記録されます server_audit_incl_usersにユーザを設定し、server_audit_excl_usersを指定しない場合、server_audit_incl_usersに指定したユーザのみ記録されます server_audit_excl_usersにユーザを設定し、server_audit_incl_usersを指定しない場合、server_audit_excl_usersに指定したユーザ以外が記録の対象になります server_audit_excl_usersとserver_audit_incl_usersに同一のユーザを設定した場合は、server_audit_incl_usersの優先度が高いため記録の対象になります advanced auditingのパラメータの詳細を以下でご説明します server_audit_logging 監査ログの有効/無効化を指定します。標準ではOFFになっているので、ONに指定することで有効になります Scope: Global Dynamic: Yes Data type: Boolean Default value: OFF (disabled) server_audit_events イベントのリストをカンマで区切って指定します。リスト中のエレメント間にスペースは入れなように気をつけて下さい Scope: Global Dynamic: Yes Data type: String Default value: Empty […]

Read More