Amazon Web Services ブログ

オートメーションを活用したCloudEndureによるAWSへの容易な移行

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。

オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。

オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。

ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式(リフト&シフト)に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。

ソリューションの概要

このブログ記事で説明するソリューションでは、CloudEndureAWS Database Migration Service(AWS DMS)を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス(Gogs)の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。

CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。

CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。

移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。

次の図は、この記事で取り上げる移行プロセスを示しています。

プロセスの仕組みは次のとおりです。

  1. Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。
  2. AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。
  3. CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。
  4. CloudEndureが初期同期を完了すると、Continuous Data Protection(CDP)エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 (この変数は、CloudEndureダッシュボードにインスタンス名として表示されます)。
  5. CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。
  6. CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。
    1. DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。
    2. Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。

      "Message": "{"instanceId": " i-0bb669daff4b1eea1","Pass": "True"}"

    3. CloudEndure Lambda関数は、CloudEndure Pass / Fail SNSトピックに登録されています。ラムダ関数は成功メッセージを探します。成功メッセージを受信すると、着信インスタンスIDに基づいてAmazon Machine Image(AMI)を作成し、AMI情報をAmazon SQSに送信します。 CloudWatchでLambda関数のステータスを追跡できます:
  7. CloudEndure.pyスクリプトは、移行されたインスタンスに関するメッセージをSQSキューに常にポーリングします。メッセージを受信すると、AMIが準備完了であるかどうかを確認します。準備ができたら、スクリプトはGogs CloudFormationテンプレートを起動し、AMI IDをパラメータとして渡します。 CloudFormationテンプレートは、次のような高可用性環境を展開します;

始めましょう

移行プロセスの仕組みが分かりましたので始めてみましょう。まず、CloudEndureでアカウントを設定する必要があります。アカウントをお持ちでない場合は、AWS SaaSサブスクリプションマーケットプレイスのCloudEndure Migration製品ページで登録できます。[1]

アカウントを設定し、CloudEndureのウェブサイトのスタートガイドに従ったら、以下のファイルに慣れておく必要があります。完全な解決策はGitHub上でより詳細に説明されています。

Ansibleプレイブック、変数、ファイル:

  • playbooks/files/CloudEndure.sh  – このファイルはCloudEndureが移行後のスクリプトを実行する/ boot/ce_conversionにデプロイされます。 GogがRDSを指すように再構成し、サービスをテストするために使用されます。
    • reinvent-ent312-source-instances.yml CloudFormationテンプレートは、このファイルのすべてのent312.five0.ninja
      を、Auto Scalingを使用して高可用性のGogs環境用のELBロードバランサを指し示すAmazon Route 53ドメインエイリアスに置き換えます。この値は、CloudFormationテンプレートのGogsDNSパラメータを介してテンプレートに渡されます。
  • playbooks/cloudendure_agent_install.yml
    • einvent-ent312-source-instances.yml CloudFormationテンプレートは、CloudEndure UserNameとパスワードをCloudEndureUserとCloudEndurePasswordのCloudFormationテンプレートのパラメータに基づいて、この「AnEure Playbook」の「Install CloudEndure」セクションに設定します。

CloudEndure.pyスクリプトで使用される移行スクリプトconfig.yml:

ファイルを編集して、次の情報を入力します。

  • username – CloudEndureのユーザー名
  • password – CloudEndureのパスワード
  • hosttomigrate – CloudEndureダッシュボードで移行するホストの名前。 CloudEndureが最初のレプリケーションプロセスを開始するまで、この値はダッシュボードで使用できません。
  • stackname –CloudFormationスタックの名前。 CloudFormationスタックに名前を付けるときに、CloudEndureBlogDemoのデフォルト値を変更することを選択した場合にのみ、これを変更してください。
  • keypairname – Gogs自動スケーリングスタックを起動するためのキーペア
  • gogsdns – Gogs自動スケーリング用にELBロードバランサにマップするRoute 53ドメインエイリアス

CloudFormation テンプレート:

  • reinvent-ent312-migrated-gogs.template
    • この値は、Gogs自動スケーリングのELBロードバランサにマップするRoute 53ドメインエイリアスです。パラメータGogsDNSNameは、CloudEndure.pyスクリプトの実行時にconfig.ymlのgogsdns値に基づいて渡されます。

AWS CloudFormationを使用してソリューションをデプロイする

次に、移行を詳しく見て、各ステップを実行してみましょう。このデモンストレーションでは、CloudFormationテンプレートは、AWSアカウントの別個の仮想プライベートクラウド(VPC)でソース環境を紡ぎ出し、同じアカウント内の宛先VPCに移行します。

まず、AWS CloudFormationテンプレートをAWSアカウントに展開する必要があります。
テンプレートをダウンロードして、独自の実装の出発点として使用することもできます。

テンプレートの選択」ページで、テンプレートURLのデフォルト設定を維持し、「次へ」を選択します。

デフォルトのスタック名のままにするか、スタックの名前を入力し、下のスクリーンショットごとに値を入力します。

Gogsを構成する際に必要なため、ソースデータベースのユーザー名とパスワードに設定した値に注意してください。次の2つの画面で「次へ」および「次へ」を選択し、「AWS CloudFormationがカスタム名でIAMリソースを作成する可能性があることを確認します」というチェックボックスをオンにして、「作成」を選択します。

CloudFormationがアカウント内のリソースを作成するまでには数分かかります。 {YourStackName} -SourceInstanceResourcesがCREATE_COMPLETEとマークされたスタックが表示されたら、ログインしてGogsを設定できます。

CloudFormationで作成したカスタムDMSタスクは、Gogs DBが存在するかどうかによって異なりますので、CloudFormationスタックが完了する前にGogsをインストールして設定する必要があります。 (この執筆時点では、CloudFormationはDMSリソースをサポートしていませんが、移行の特定の側面について自動化を構築するための具体的な方法の1つを示したいと思います。)

スタックの[出力]タブで、AnatileSourceInstanceを見つけます。 SSHを次のコマンドで値を使用してインスタンスに追加します。

ssh -i {KeyPairYouAssociatedWithTheStack}centos@{ValueFromAnsibleSourceInstance}

インスタンスにSSHしたら、次のコマンドを実行して、更新とCloudFormationのユーザーデータステップが完了していることを確認します。

sudo tail -f /var/log/cloud-init.log

クラウド・イニシエータがインスタンスのブートストラップを終了すると、以下のようなメッセージが表示されます。

Mar 7 18:30:29 ip-10-10-138-101 cloud-init: Cloud-init v. 0.7.5 finished at Tue, 07 Mar 2017 18:30:29 +0000. Datasource DataSourceEc2. Up 369.01 seconds

これでインスタンスへのキーペアを追加する必要があります。そのため、SSHを使用してソースインスタンスに使用したり、Gogを構成したりすることができます。ローカルマシン上で、鍵ペアを保存したディレクトリから、次のコマンドを使用して秘密鍵をクリップボードにコピーします。

cat {KeyPairYouAssociatedWithTheStack}.pem | pbcopy

Ansibleソースインスタンスで、次のコマンドを実行します。

vi key.pem

プライベートキーをviウィンドウに貼り付け、ファイルを保存します。次に、次のコマンドを実行してアクセス許可を変更します。

chmod 400 key.pem

次のコマンドを実行して、ssh-agentが有効になっていることを確認します。エージェントpidを受け取る必要があります(たとえば、Agent pid 417)。

eval `ssh-agent`

ssh-agentにSSH鍵を追加し、空のパスフレーズを入力するためにEnterキーを押します。

ssh-add key.pem 
今度は、あなたのソースGogs DBをAnsible経由でプロビジョニングできます:

ansible-playbook -i playbooks/hosts playbooks/database_provision.yml

ソースのGogsインスタンスをプロビジョニングします。

ansible-playbook -i playbooks/hosts playbooks/gogs_provision.yml

GogsがAnsible経由で設定されると、ログイン環境でGogsをログインして設定することができます。 CloudFormationのSourceInstanceResourcesスタックのOutputsタブにGogsSourceInstanceの値が必要です。

http://{ValueFromGogsSourceInstance}:3000

「Gogsのユーザーパスワード」フィールドに、CloudFormationのソースデータベースのユーザー名とパスワードから前述した値を入力します。

Gogsであなたの選択したユーザーとパスワードを登録することができます。このデモンストレーションの後半に注意してください。

CloudFormationのDMSスタックが完了したら、セットアップを調べることができます。レプリケーションインスタンスが表示されます。

送信元と宛先の両方のエンドポイントも表示されます。

データベース同期を実行するタスクも表示されます。

DMSの検証が終了したら、AnatileSourceInstance SSHウィンドウに戻り、次のコマンドを実行してApplication Discovery ServiceとCloudEndureをインストールします。

ansible-playbook -i playbooks/hosts playbooks/aws_cli_ads_agent_install.yml

ansible-playbook -i playbooks/hosts playbooks/cloudendure_agent_install.yml

CloudEndureダッシュボードにログインすると、サーバーが表示されます。 CloudEndureはAWSへの最初のブロックレベル同期を完了する過程にあるため、テストの準備が整っている、と表示されるまでに時間がかかることがあります。

CloudEndure DashboardのINSTANCE NAMEの値は、config.ymlファイルのhosttomigrate変数に設定する必要がある値です。
CloudEndure.pyスクリプトを実行して、移行を初期化します。

python scripts/CloudEndure.py

スクリプトの出力例を見るには、READMEを見てください。

スクリプトが終了すると、Lambda関数から作成されたAMIを使用して、AutoScalingと共に高可用性Gogs環境が表示されます。

高可用性のGogs環境がヘルスチェックに合格し、ELBロードバランサの背後でサービスを受けるには数分かかりますが、最終的には、ソース環境で作成したユーザー名を使ってサインインし、RDSを使用するように設定された移行済みGogs環境にアクセス可能です。これは、DMSタスクが移行元GogsデータベースをRDSに移行するのに成功したことを証明します。

サマリー

この記事では、オンプレミス環境からAWSへの移行をスピードアップするために、自動化とテストをツールキットに組み込む方法を示しました。慎重な計画と構成では、移行シナリオ全体で再利用できる一連のツールが用意されています。これにより、ワークロードをより迅速に移行できるようになり、移行後に期待どおりアプリケーションが動作しているという確信が得られます。

 

このブログの内容は、第三者の製品を推奨するものではありません。このブログは情報提供を目的としています。

[1]このブログ記事の手順に従う際に発生した費用については、あなたが責任を負います。

(翻訳は諸岡が担当しました。原文はこちら)

 

LumberyardがGitHubで公開されました!

本日とてもエキサイティングなご報告をさせていただきます。LumberyardのソースがGitHubで公開されました。コミュニティーの皆様からの特に多いご要望の1つでしたが、ようやく実現でき大変嬉しいです。こちらのURL(www.github.com/aws/Lumberyard)をご確認ください。

ゲームを制作する事はチャレンジングですが、GitHubを活用することで2つの手法が容易になります。

 

LumberyardをGitHubから取得できます。

これまでは、Lumberyardを標準インストーラーからインストールする事がLumberyardを入手いただく唯一の方法で、ソースを含めたすべてのLumberyardが新たに別のディレクトリに保存されました。ですので継続的にLumberyardをアップグレードすることはうんざりする作業だったかもしれませんが、GitHubを活用することで劇的に変わります。

 

本日よりLumberyardソースコードをGitHubリポジトリから容易に直接取得して管理する事が可能となります。新たなバージョンのLumberyardをインテグレートすることも今までよりとてもシンプルな操作で可能です。そして、今後の新たなLumberyardのリリースは別々のブランチで提供されますので、任意のバージョンのインテグレートも可能となります。さらに!あなた自身のGitHubアカウントを作成してGitHubであなたのプロジェクトを管理したり、リモートリポジトリであなたのチームとの共同作業も容易にできるようになります。

Lumberyardの改良やバグ修正を送っていただく事も可能です。

これまでは、Lumberyardの開発者は最大50行までのLumberyardのコードをフォーラムを通して送っていただく事が可能でしたが、簡易な修正にしか適用できませんでした。(このような状況にもかかわらず、これまで修正を送っていただいた皆様に御礼を申し上げます!)本日より、GitHubを活用することで、どのようなサイズの改良やバグ修正でも容易にLumberyardチームに送っていただく事が可能となります。プルリクエストにより、必要となるコードを複数のファイルにまたがるような場合でも、正確な方法で管理できます。皆様からのフィードバックとサポートは我々を突き動かす大きな要因で、皆様とともにこのエンジンを創り上げていける事はとてもエキサイティングです。

メインブランチで安定したLumberyardを提供し続けていく事は我々にとってとても重要ですので、プルリクエストがすぐにはマージされるわけではなく、承認された変更は将来のリリースに反映される可能性があるということにご留意ください。継続的にプルリクエストは確認させていただきます。プルリクエストが採用されました皆様はリリースノートにクレジットさせていただきます!

もう一点、我々のリポジトリからフォークする事も可能です(詳しくはリポジトリ中のReadme.mdファイルをご参照ください)がLumberyardは引き続き「AWS Customer Agreement」と「Lumberyard Service Terms」の元にライセンスされております。この点にご留意いただければ公開リポジトリとすることも可能ですので、ログインせずに取得する事も可能となります。

いつでもお気軽にご意見をお聞かせください。今後の数ヶ月でScript Canvasや新たなアニメーションツール等さらにいくつかのエキサイティングな要素の提供も予定していますのでお見逃しなく!Lumberyardに関します様々な情報はチュートリアルやコミュニティフォーラム、さらにドキュメントからも得られます。

LumberyardのGitHub公開に関します詳細はこちら(www.github.com/aws/Lumberyard)をご参照ください。

本記事の作者について

Todd Gilbertsenは1980年台からゲームエンジンの制作、ビデオゲームだけでなく、様々なソフトウエア開発のプロフェッショナルとして活動を続けており、ゲーム開発者がクリエイティブに開発を進めるためのツールやテクノロジーの開発をする事に情熱を注いでおります。ToddはLumberyradのシニア・テクニカルプロダクトマネージャーです。

8/16更新 – 客様からのフィードバックを頂戴しまして、現在レポジトリへのアクセスを一時的に停止させていただいております。近々に再公開させていただきますので後日改めてアクセスいただけますと幸いです。

(翻訳は下田が担当しました。原文はこちら)

9 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー9月の配信についてご案内させて頂きます。ソリューションカットでは、AWSにおけるDDoS対策について、サービスカットでは、BlackBelt初開催となる、AppStream2.0や、多くの機能アップデートが行われたサービスを中心にお送りいたします。

 

9月の開催予定

サービスカット

9/6(水) 18:00-19:00 Amazon AppStream 2.0
9/13(水) 18:00-19:00 Amazon Aurora
9/19(火) 18:00-19:00 AWS DMS

※通常とは異なり、火曜日開催となりますのでご注意ください。
9/27(水) 18:00-19:00 Amazon CloudFront + AWS Lambda@Edge

ソリューションカット

9/5(火) 12:00-13:00 AWSでのDDoS対策

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

こんにちは、Amazon Macie: コンテンツを自動的に発見、分類、保護する

Jeffと私が初めてこのサービスを聞いたとき、私たちはMacieという名前の意味が知りたくなりました。もちろん偉大な研究者であるJeffは、Macieという名前を調べ、二つの意味があることを発見しました。フランス語とイギリス英語両方からの語源があり、典型的な少女の名前で、様々な意味を持っていました。Macieの一つめの意味は”武器”を意味する名前です。もう一つの意味は、力強く、さっぱりとした、優しい人の表す名前です。ある意味、これらの定義はふさわしいです。本日、私たちはAmazon Macieという新しいセキュリティサービスの提供開始を喜んで発表します。機械学習によって、AWS上に保存された機密情報の特定し、データ侵害、情報漏えい、Amazon Simple Storage Service (S3)への不正アクセスから保護をします。よって、Amazon Macieが、あなたの保存データを悪意のあるアクセスから保護する、”さっぱりとした”ユーザーインターフェースを備えた”優しい”サービスとして、AWS顧客にとって”力強い””武器”になることを私は想像できるのです。ふー、喋り過ぎました。たった一文でMacieの全てを表現するなんて!やはり、私はみなさんとAmazon Macieの凄さを共有するのに興奮しています。

Amazon Macieは、Amazon S3に保存されているデータを自動的に発見し分類する、機械学習を用いたサービスです。しかし、Macieはそれだけではありません。一度Macieであなたのデータが分類されれば、それらにビジネス価値が割り当てられ、継続的に監視し、アクセスパターンに基づいて疑わしい振る舞いを検知します。Macieの主要機能は以下です。

  • データセキュリティの自動化:データの分析、分類、処理し、過去のパターン、データに対するユーザー認証、データアクセス場所、アクセス時間を把握する
  • データセキュリティと監視:利用ログデータの監視して異常検知したり、CloudWatch EventsやLambdaによってレポートされる問題を自動解決する
  • プロアクティブなデータ保護のためのデータ可視性:保存データの詳細を管理者向けに可視化すると同時に、手動入力いらずで即時保護を提供する
  • データ調査とレポート:管理者向けにレポーティングやアラートを構成可能にする

どのようにAmazon Macieはこれらを実現するのか?

自然言語解析(NLP)の機械学習アルゴリズムを使って、MacieがS3バケットにあるデータの分類を自動化します。加えて、Amazon Macieはデータアクセスパターンを動的に分析する予測分類アルゴリズムも利用し、学習によって疑わしい振る舞いの可能性を知らせてくれます。Macieは個人特定情報(PII)や機密個人情報(SP)を検知するエンジンとしても動作します。MacieはAWS CloudTrailを利用しながら、継続的にS3バケットへのPUTリクエストのCloudTrailイベントを確認し、自動的に新しいオブジェクトの分類をほぼリアルタイムで行います。

MacieがAWSクラウド上のセキュリティやデータ保護にとって強力な道具であるだけでなく、ガバナンスやコンプライアンス要件、監査基準などにおいてもあなたを助けます。多くの人は既に、現時点でEUの最も厳しいプライバシー規制である、2018年5月25日に施行される一般データ保護規則(GDPR)を知っています。Amazon Macieは個人特定情報(PII)を認識し、ダッシュボードとアラート機能を提供することで、顧客にデータの暗号化や仮名化によるGDPRへの準拠を可能にします。Lambdaクエリと共に利用すると、MacieはGDPRの懸念に対応する協力な道具になります。

Amazon Macieサービスツアー

それではAmazon Macieの詳細を見るためのツアーを開始しましょう。

まず最初に、私はMacieのコンソールにログインし、Macieのセットアップ処理を始めます。Get Startedボタンを押すことで私のデータの分類と保護を開始することができます。

下画面の通り、Amazon Macieサービスを有効化するには、このサービス用の適切なIAMロールを作成しなければなりません。また、私のアカウントでAWS CloudTrailを有効化する必要があるでしょう。

私はこれらのロールを作成し、私のアカウントでAWS CloudTrailサービスを有効化しました。Macieをより簡単にセットアップするために、Macieユーザーガイドから提供されているCloudFormationのサンプルテンプレートを利用することもできます。それは、必要なIAMロールとポリシーを作成するので、あとやるべきことはCoudTrailドキュメントに記載されている通りに証跡を設定するだけです。

もしあなたが複数のAWSアカウントをもっている場合は、Macieサービスを有効化したアカウントがマスターアカウントになることに注意してください。他のアカウントもMacieサービスと連携できますが、それらはメンバーアカウントということになります。メンバーアカウントのユーザーは、Macieコンソールにアクセスするために、マスターアカウントへフェデレートアクセスするためのIAMロールを使う必要があるでしょう。

さあ、IAMロールが作られ、CloudTrailが有効化されたら、Enable MacieボタンをクリックしてMacieによるデータ監視と保護を開始しましよう。

あるアカウントで一度Macieサービスが開始すると、サービス画面が表示され、そのアカウントにおける既存アラートが表示されます。今回、私はサービスを開始した直後なので、アラートはまだ存在していません。

Macieサービスのツアーで、ここから私のS3バケットとMacieを連携していきましょう。ただし、Macieが監視を開始するだけであれば、あなたはS3バケットを指定する必要はありませんでした。なぜならサービスは既に情報の分析や処理のためのAWS CloudTrail管理APIを使用しているからです。このMacieツアーでは、私は特定のバケットにおけるCloudTrailのいくつかのオブジェクトレベルAPIイベントを監視しようと思います。

S3と連携するために、MacieコンソールのIntegrationsタブに移動します。Integrationsタブでは、二つの選択肢:AccountsServicesがあります。AccontsオプションはメンバーアカウントがMacieと連携するために使用され、あなたのデータ保存ポリシーを設定します。特定のS3バケットとMacieを連携したい時は、ServicesタブからServicesオプションをクリックします。

MacieとS3サービスを連携させると、証跡とS3バケットが作成され、S3データイベントに関するログが保存されます。始めるには、Select an accountドロップダウンを使いアカウントを選択します。アカウントが選択されると、連携可能なサービスが表示されます。Addボタンをクリックして、Amazon S3サービスを選択します。

さて、Macieに分析させたいバケットを選択したので、Review and Saveボタンを押して確認画面に行き、オブジェクトレベルロギングを行うことを確認してからSaveボタンをクリックします。

次に、このMacieツアーでは、どのようにMacieのデータ分類をカスタマイズするか見ていきましょう。

前述の通り、Macieは自動的にあなたのデータを監視し、分類します。Macieがあなたのデータを特定すると、ファイルとコンテントタイプでそのデータオブジェクトを分類します。また、Macieはサポートベクターマシン(SVM)も使用し、ファイルのメタデータに加えてS3オブジェクト内のコンテンツも分類します。深層学習/機械学習の研究分野において、サポートベクターマシンは教師あり学習モデルであり、データの分類や回帰分析のための学習アルゴリズムを持っています。Macieは、たくさんのコンテンツタイプのデータによってSVMを学習させ、あなたが書いたかもしれないソースコードが含まれていようとも、データコンテンツの正確な検知に最適化されます。

Macieはデータオブジェクトやファイルに対して一つのコンテンツタイプを割り当てますが、あなたはコンテンツタイプやファイル拡張子を有効化や無効化することもできます。それにより、それらオブジェクトをMacieサービスの分類対象に含めたり除外することができます。Macieがデータを分類したら、1から10までのリスクレベルがそのオブジェクトに割り当てられます。10が最もリスクが高く、1が最もリスクレベルが低いです。

Macieのデータ分類をカスタマイズするためには、Settingsタブに行きます。Macieの分類設定にて、有効化や無効化が可能な選択肢が表示されます。

このMacieツアーでの例として、File extensionを選んでみましょう。Macieが追跡し、分類に使用するファイル拡張子のリストが表示されます。

テストのために、Androidアプリケーションのインストールファイルであるapkファイル拡張子を編集し、ドロップダウンリストからNo – disabledを選択し、Saveボタンをクリックして、このファイルの監視を無効にします。もちろん、後でこの設定は戻します。Android開発用バイナリファイルも含めて全てのデータファイルの安全を維持したいからです。

最後に、Macieによるデータ分類に関して述べると、このサービスはあなたのデータオブジェクトがどのように分類されたかを可視化します。あなたが保存したデータ資産を、コンプライアンスにとって、個人情報にとって、ビジネスにとって、どれほど重要な情報が保存されているかの点で浮き彫りにします。

さて、今までMacieが分類し監視するデータの探検をしてきました。このサービスのツアー終着駅は、Macieダッシュボードです。

Macieダッシュボードは、Macieによるデータ監視と分類によって集められた全てのデータや活動の完全な絵を提供します。ダッシュボードはカテゴリー毎のメトリクスとビューによって、データを色々な視点から表示することができます。このダッシュボード画面の中で、メトリクス画面からResearchタブへ直接行き、メトリクスに基づいたクエリを作成し実行することも可能です。これらのクエリは、起こりうるセキュリティの課題や問題を通知するためのカスタマイズされたアラートに使用できます。ここでは、ResearchタブやAlertsタブのツアーは行いませんが、Macieユーザーガイドには、これらの機能に関するより多くの情報があります。

ダッシュボードに話を戻すと、非常にたくさんの情報源がMacieダッシュボードにはあるため、このツアーで全てのビュー、メトリクス、機能をご紹介することはしません。ここでは、ダッシュボード機能の概要をお伝えいたします。

ダッシュボードメトリクス(Dashboard Metrics) – 次のカテゴリーで監視したデータ:

  • ハイリスクS3オブジェクト(High-risk S3 objects):リスクレベル8から10のデータオブジェクト
  • 全イベント発生回数(Total event occurrences):Macieが有効化されてからの全てのイベント発生回数
  • 全ユーザーセッション(Total user sessions):CloudTrailデータの5分間スナップショット

ダッシュボードビュー(Dashboard Views) – 監視したデータや活動の様々な観点での表示ビュー:

  • S3 objects for a selected time range
  • S3 objects
  • S3 objects by personally identifiable information (PII)
  • S3 objects by ACL
  • CloudTrail events and associated users
  • CloudTrail errors and associated users
  • Activity location
  • AWS CLoudTrail events
  • Activity ISPs
  • AWS CloudTrail user identity types

まとめ

さて、ここでこの新しくエキサイティングなAmazon Macieサービスのツアーを終了します。Amazon Macieはセンセーショナルな新サービスで、機械学習と深層学習の力を使って、Amazon S3に保存されているデータを特定し保護します。自然言語解析(NLP)によって、データ分類を自動化するので、あなたはAmazon Macieを有効化するだけで、精度の高い分類と即時保護を簡単に始めることができます。インタラクティブなダッシュボードは、あなたの情報がどこで何が誰によっていつアクセスされたかを示すので、あなたの環境における大量のデータ、データアクセス、API呼び出しを分析できます。製品ページAmazon Macieユーザーガイドを参照し、Amazon Macieについてもっと知りましょう!

Tara

(翻訳はセキュリティSA桐山隼人が担当しました。原文はこちら

【確定版】8 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信について,ご案内させて頂きます。今後の配信予定について一部変更があったため,改めて最新版の配信予定についてお知らせいたします.

 

8月の開催予定

 

サービスカット

8/2(水) 18:00-19:00 AWS X-ray
8/9(水) 18:00-19:00 Amazon DynamoDB
8/23(水) 18:00-19:00 AWS MobileHub

ソリューションカット

8/22(火) 12:00-13:00 Deployment on AWS
8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

AWS Migration Hub – エンタープライズアプリケーションの移行の計画と追跡

1週間に約1回、私はシアトルのエグゼクティブブリーフィングセンターで現在の有力なAWSのお客様に話します。一般的に私はイノベーションプロセスに重点を置いていますが、アプリケーションの移行を含む他のトピックについても議論することがあります。企業がアプリケーションポートフォリオを移行する場合、企業は構造化された整然としたやり方でそれを実行したいと考えています。これらのポートフォリオは、通常、何百もの複雑なWindowsおよびLinuxアプリケーション、合理的なデータベースなどで構成されています。お客様は、進め方についてはまだ不確実であることがわかります。これらの顧客と一緒に働く時間を費やした後、彼らの課題は一般的に次の3つの主要カテゴリに分類されることがわかりました。

ディスカバリー – お客様は、各アプリケーションを動かす全ての部分について、深くて完全な理解を得たいと考えています。

サーバー&データベース移行 – オンプレミスのワークロードとデータベースのテーブルをクラウドに転送する必要があります。

追跡/管理 – 大規模なアプリケーションポートフォリオと複数の移行が並行して行われるため、アプリケーション中心の方法で進捗状況を追跡および管理する必要があります。

ここ数年、私たちは最初の2つの課題に取り組む一連のツールを立ち上げました。 AWS Application Discovery Serviceはシステム情報の検出と収集のプロセスを自動化し、AWS Server Migration Serviceはクラウドへのワークロード移行を処理し、AWS Database Migration Serviceは最小のダウンタイムでリレーショナルデータベース、NoSQLデータベース、データウェアハウスを移行します。 RacemiCloudEndureなどのパートナーは、独自の移行ツールも提供しています。

新しいAWS Migration Hub

今日、これらAWSサービスとパートナー移行ツールをAWS Migration Hubに統合しています。ハブは、前述のツールへのアクセスを提供し、移行プロセスをガイドし、Migration Acceleration Program(MAP)で説明されている方法論および原理に従って、各移行の状況を追跡します。

ここにメイン画面があります。移行プロセス(ディスカバリー、移行、および追跡)の概要を示します。

Start discovery」をクリックすると、移行プロセスのフローが表示されます。

ディスカバリー手順をスキップしてすぐに移行を開始することもできます。

AWS移行サービス(Server Migration ServiceまたはDatabase Migration Service)のデータ、パートナーツール、またはAWS Application Discovery Serviceによって収集されたデータを使用し、サーバーリストが作成されます。

自分用の最初のアプリケーションを作成するには、「Group as application」を選択することができます。

移行するアプリケーションを特定したら、そのアプリケーションをHubの「Applications」セクションで追跡できます。

移行ツールは承認されている場合、アプリケーションの移行ステータスページに表示するために、ステータスの更新と結果を自動的にMigration Hubに送信します。ここでは、Racemi DynaCenterCloudEndure Migrationが担当する部分の移行を実施したことがわかります。

Migration Hub Dashboardをチェックすると、移行のステータスを追跡できます。

Migration Hubは、AWSと移行パートナーの移行ツールと連携して動作します。詳しくは、Integrated Partner Toolのリストをご覧ください。

 

今すぐ利用可能

AWS Migration Hubは、必要となる移行ツールが利用可能な様々なAWSリージョンの移行を管理できます。Hub自体は米国西部(オレゴン州)地域で運営されています。Hubは無料です。移行の過程で消費するAWSサービスに対してのみお支払いいただきます。

クラウドへの移行を開始する準備ができていて、何らかの支援が必要な場合は、Migration Accelerationパートナーのサービスを利用してください。これらパートナーは、大規模な移行を繰り返し実践・提供することを通じて移行コンピテンシーを獲得しています。

Jeff;

(翻訳は諸岡が担当しました。原文はこちら)

新機能- CloudTrailを全てのお客様に

Amazon Web Servicesをご利用の皆様に大変喜ばしいお知らせがあります。このお知らせが出来るまで辛抱強く待っていましたが、それも終わりです。

このたびAWS CloudTrailは、全てのお客様に対してあらかじめ有効にされるようになりました。

これにより、何も設定することなく過去7日間のAWSアカウント活動の可視性が提供されます。この新しい、常時有効となる機能には閲覧、検索、後述のCloudTrail Event Historyを通してのダウンロード機能が実装されています。

AWS CloudTrailの有用性をまだ得られてないお客様のために説明させてください。操作上のトラブルシューティングとレビュー、コンプライアンス、監査、セキュリティのための重要なサービスが、全てのお客様に対して提供されていることに興奮を覚えます。

AWS CloudTrailは、サポートされているAWSサービスに対するアカウント活動とイベントを記録します。

AWS CloudTrailは、あなたのAWSアカウントにおいてサポートされたAWSサービスのアカウント活動とイベントを捕捉し、Amazon Simple Storage Service(S3)、CloudWatch logsとCloudWatch Eventsにイベント・ログファイルを送ります。CloudTrailであなたはTrailを一般的につくれますし、その設定がアカウント活動とイベントの補足を可能にします。CloudTrailはまた、AWSアカウントで起こっているAPI活動に可視性を提供することによって、操作上のセキュリティ問題を分析することを可能にさせます。CloudTrailはマルチリージョン構成をサポートします。またCloudWatchとインテグレーションさせると、あなたはモニターしたいイベントのきっかけをつくることができたり、AWS Lambdaにアクティビティの記録を送るためのsubscriptionを生成するこができます。AWSコマンドラインインターフェース(CLI)、AWS Management Console、AWS SDKから、またAWSアカウントの他のAWSサービスからの呼び出しのデータの検索可能な履歴を得られることを、CloudTrailサービスを利用することは意味します。

AWS CloudTrailの主要な機能

  • Always On: 設定をする必要がなくあらかじめ全てのAWSアカウントで有効化され、全てのアカウント活動履歴の記録
  • Event History: 閲覧、検索、直近のAWSアカウント活動履歴のダウンロード
  • Management Level Events: 詳細な管理活動情報の取得、例えば、EC2例またはS3バケツの作成、削除と修正
  • Data Level Events: Amazon S3オブジェクトにおける全てのAPIアクションとAPIアクションの詳細な情報の記録
  • Log File Integrity Validation: S3バケットに格納したログファイルの完全性の検査
  • Log File Encryption: あらかじめ、S3のサーバサイド暗号化機能を用いたS3バケットによる全てのログファイルの暗号化。オプションとしてAWS Key Management Service (AWS KMS)によるログファイルの暗号化
  • Multi-region Configuration: マルチリージョンからのログファイルの送信設定

AWS CloudTrailのさらなる機能をお知りになりたい場合は、製品詳細ページに記載があります。

私の同僚であるランダル・ハントが私に思い出させてくれました。つまり、お客様の課題の解決を援助するとき、CloudTrailは重要であるということです。ほとんどのAWSの人間、例えばテクニカル・エバンジェリスト・チームに所属する我々またはソリューションアーキテクトチームに所属する人間が言うのは、何が起きているのかという詳細を調べることができるようにCloudTrailを有効化する、ということです。ですのでこのリリースで、AWSコンソールまたはAWS CLI/APIを用いてすべてのお客様がアカウント活動を見ることができる(検索機能や、全てのサポートされたAWSサービスの活動の7日間のアカウント活動履歴をダウンロードする能力を含む)ことは、驚きに値しません。

CloudTrailはあらかじめ有効化されており、すべてのお客様は、現在CloudTrailにてログを取得することができ、またEvent Historyを閲覧することが可能です。この画面はイベントを7日分見ることが出来るだけでなく、詳細な情報を見ることも可能です。

もちろんですが、直接CloudTrailログファイルにアクセスするか、監査のためにログをアーカイブしたいならば、さらにTrailを追加でき、ログファイルの送出のためにS3バケットを指定することができます。また、Trailの生成はイベントをCloudWatch LogsとCloudWatch Eventsに届けることができ、それは非常に簡単なプロセスです。

CloudTrailコンソールにログインした後に、あなたは単に「Trailの生成」ボタンををクリックするだけです。

それから、あなたはTrail名のテキストボックスにTrail名を入れ、構成をすべてのリージョンに適用するか、現在選択のリージョンにだけ適用するかをラジオボタンで選びます。

Management Event画面で、CloudTrailにどの活動を追って欲しいかについて、Read/Writeイベント・ラジオボタン・オプションを選びます。このケースでは「全て」を選びます。

次のステップは私ケースのためですが、S3オブジェクト・レベル活動を追ういたいためにS3バケツを選択します。これはオプションのステップとなります。デフォルトでは、TrailがData Eventsを記録しない点に注意してください。よって、S3オブジェクトイベント活動を追跡したい場合は、Data Eventセクションで指定するBacketのData Eventsを追跡するためにTrailを構成することができます。ここでは、私はaws-blog-tew-posts バケットを選んで、すべてのRead/Write活動を追うために、デフォルトのままとします。

CloudTrailログを格納するためのTrail設定での最終的なステップは、コンソールのStorage LocationセクションでS3 Backetを選ぶことです。Backetは新規作成もできますし、既存のBacketを選択することも可能です。ここでは、テキストボックスにaws-blog-tew-postsのBacket名を入力し新規Backet生成を選択します。また、すぐにログを見つけられるようにしたいので、Storage LocationのAdvancedセクションを開き接頭辞を加えます。Backetに格納されているログに検索条件を加えたいとき、これは最も役に立ちます。ここでは「tew-2017」という接頭辞を加えています。そのほかのAdvancedセクションの選択肢、ログファイル暗号化、イベントログファイル検査、SNS通知送信はデフォルトのままにします。

以上です。これで、Createボタンを押すだけでTrailの生成に成功しました。

 

準備は出来ていますか?

サービス製品ページCloudTrailドキュメンテーションAWS CloudTrailFAQをご覧いただけくことでAWS CloudTrailについてより多くを学ぶことができます。Trail構成の有無にかかわらず、いま一度CloudTrailサービス・コンソールに進んで見ていただき、CloudTrailイベントを捜してみてください。

全てのお客様のためのこのCloudTrailの新しい発表を楽しんでいただけましたらと思います。そうすることでこの素晴らしいサービスのメリットを享受いただけるかと思います。

Tara

翻訳は、PartnerSA市崎が担当しました。原文はこちらです。

AWS Config アップデート – S3バケットをセキュアに管理する新しいマネージド ルール

AWS ConfigはAWSリソースの構成とそれらリソースにおけるリレーションシップの管理を行います。そうすることで、必要なリソースを選択し、そのリソースの変更管理を時系列ベースで確認することが可能になります。(詳細はこちらをご確認ください。)

またAWS Config RulesはAWS Configを更に強化し、強力なルールシステムを使用してConfigを拡張し、AWSルールの「管理」コレクションと、自分で作成したカスタムルールをサポートします。(AWS Config Rulesの詳細はAWS Config Rules – Dynamic Compliance Checking for Cloud Resourcesをご確認ください)。ルール(AWS Lambda ファンクション)では、AWSリソースのあるべき姿(適切に構成されているか、コンプライアンス準拠しているか)を定義します。構成に変更が検出された際に、必要なファンクションが呼び出され、構成がコンプライアンス要求に準拠しているかの確認を行うことができます。

すでに36のルールがAWSから提供されています。下記はEC2に関連するリソースの状態を確認するルールの一例になります。

新しく追加された2つのルール

本日、S3バケットを安全にご利用頂くために、新たに2つのマネージド ルールが追加されました。これらのルールは数クリックで有効にすることが出来ます。追加された2つのルールは以下になります。

S3-bucket-public-write-prohibited:誰でも書き込みが可能に設定されているバケットを自動的に検知します。意図的に設定をするケースも稀にありますが、そうすることで悪意のあるコンテンツを誰でも書き込めるようになり、かつ既存のコンテンツも削除(上書き)をされてしまいます。このルールはアカウント内のすべてのバケットに対し適用されます。

S3-bucket-public-read-prohibited:グローバルに公開されてれいるバケットを自動的に検知します。これにより、公開されているウェブサイトやドキュメントなどのコンテンツにフラグが立てられます。 このルールは、アカウント内のすべてのバケットもチェックします。

既存のルールと同様に、スケジュールベースでの実行も可能ですし、AWS Configによる構成変更の検知をベースに実行することも可能です。

これらの評価はミリセカンドの単位で実行され、1アカウント内の100つのバケットの評価を1分以内で実行できます。その裏では、ルールは推論エンジンにより評価され、多項式時間で判定可能な最先端の制約解決手法が活用されています(P≠NP予想の解決はされず、話が異なります)。これはAWSにおいても、大きなチャレンジでAWS re:Inventのセッションでも触れられています: Automated Formal Reasoning About AWS Systems :

 

本日から利用可能です

これら2つのルールは本日よりご利用できます。既存のルールと同様に、1つのルールあたり、1ヶ月2ドルとなります。

Jeff

翻訳はPartner SA酒徳が担当しました。(本文はこちら)

 

AWS Glue – 一般提供開始

本日、AWS Glue の一般提供開始がアナウンスされました。Glue はフルマネージドでサーバレス、そして、クラウド最適化された ETL(extract, transform, load) サービスです。Glue は他の ETL サービスやプラットフォームと、いくつかのとても重要な点で違いがあります。第1に、Glue はサーバレスです — リソースのプロビジョニングや管理を行う必要はありません。ジョブ、もしくは、クローリングを実行している間に Glue が使用したリソースに対する支払いのみで利用可能です(分単位課金) 。第2に、Glue のクローラです。 Glue のクローラは、複数のデータソース、データタイプ、そして、様々な種類のパーティションを跨いで、スキーマを自動的に検出・推測することができます。クローラは生成されるスキーマを編集・版管理・クエリ実行・分析で利用するため、一元的に Data Catalog に保存します。第3に、Glue はデータを元々のフォーマットから目的のフォーマットに変換する Python で記述された ETL スクリプトを自動的に生成することができます。最後に、Glue は開発者がお気に入りのツールセットを使用して ETL スクリプトを組み立てることができるように、開発者向けのエンドポイントを作成できるようになっています 。それでは詳細を具体的に見ていきましょう!

私は開発者向けエヴァンジェリストとしての仕事の中で、飛行機での移動に多くの時間を費やします。そこで、フライトデータで何かできたらかっこいいのではと考えました。ありがたいことに、アメリカ交通統計局(Bureau of Transportations Statistics: BTS)このサイトを利用し、全てのデータを誰にでも共有してくれます。私たちは簡単にデータをダウンロードし、Amazon Simple Storage Service (S3) に保存することができます。このデータが今回の基礎データとなります。

Crawlers

まず、私たちは S3 にあるフライトデータに対して、クローラを生成する必要があります。Glue のコンソールでクローラを選択し、画面の指示に従って進めます。最初のデータソースとして s3://crawler-public-us-east-1/flight/2016/csv/を指定します(データは必要に応じて追加か可能です)。次に、”flights” データベースを作成し、各テーブルに同様の “flights” 接頭語を付けるようにします。

クローラはデータセットを調べ、様々なフォルダーからパーティション(この例の場合は、年月)やスキーマを検出し、テーブルを構成します。クローラに別のデータソースやジョブを追加することや、同じデータベースにデータを登録する別のクローラを作成することもできますが、ここでは自動生成されたスキーマを見ていきましょう。

スキーマ変更(型を BIGINT から INT に変更する)を “year” に対して実施します。その時、必要であれば2つのスキーマバージョンを比較することができます。

これで、正しくデータをパースする方法を把握したので、次はいくつか変換処理を試してみましょう。

ETL Jobs

さあ、Job用のサブコンソール画面に移動し、”Add Job” をクリックしましょう。画面の指示に従い、Job に名前、選択するデータソース、そして、テンポラリファイルを配置する S3 ロケーションを設定します。次に、”Create tables in your data target” を指定することでターゲットを追加し、ターゲットとしてParquet フォーマットで出力されるデータを配置する S3 ロケーションを指定します。

”Next” をクリックすると、Glue によって提案される様々なデータの対応関係を表示する画面に遷移します。必要に応じてカラムのマニュアル調整を行うことができます — ここでは、必要のない幾つかのカラムを “X” ボタンを使って消していきましょう。

次の画面で提供される機能が私達を私の好きなパートに誘います。これが Glue について絶対的に好きなところです。

Glue は今までに設定してきた情報に基づき、データを変換するための PySpark スクリプトを生成します。左側のダイアグラムで、ETL ジョブのフローを確認することができます。右上には、注釈付きのデータソースやターゲット、trasnsform、spigot、そしてその他機能を追加するために使えるボタン一式が見て取れます。次の画面が、”transform” をクリックすると表示されるインタフェースです。

これら変換処理のどれか、もしくは、追加データソースを追加すると、Glueはインターフェースの左側に表示されている、データフローを確認できる便利で視覚的なダイアグラムを更新します。コンソールに独自コードを直接記述し、実行することもできます。このジョブに別のジョブやスケジュールの完了時に実行されるトリガー、もしくは、オンデマンドで実行されるトリガーを追加することができます。その方法により、より多くのフライトデータを追加する際、必要なフォーマットで S3 に戻されたデータをリロードすることができます。

ここで、なぜ、コードとして ETL ジョブが保存されることがとても有益であると私が考えているかをちょっと考えてみましょう。コードはポータブルで、テスト可能で、版管理可能、そして、人が読むことができます。私達の多くは毎日コードを書いています。私達はコードに精通しており、コードを簡単に操作できます。Glue は開発者としての私に、セットアップに費やしてきた数え切れないほどの時間を節約し、私は重要なコードを得ることができます。job コンソールのパワーと多機能性について記述することに丸一日かけてしまいましたが、Glue は対応して欲しいより多くの機能を持っています。例えば、私はスクリプトを編集するコンソールが好きな一方で、多くの人々が自分たちの開発環境やツール、IDE などを好んでいることも知っています。それでは、Glue でそれらを利用する方法を確認してみましょう。

Developer Endpoints and Notebooks

開発者エンドポイントは Glue のスクリプトを開発し、テストするために利用される環境です。Glueコンソールの “Dev endpoints” に移動し、右上にある “Add endpoint” をクリックすることで設定を開始します。次に、VPC、自分自身を参照する セキュリティグループを選択し、プロビジョンするのを待ちます。

一度開発者エンドポイントがプロビジョンされると、何回かの操作と”create notebook server” をクリックすることにより、Apache Zeppelin notebook server を作成することができます。インスタンスに IAM ロールを渡し、データソースと連携するパーミッションを持っているかどうか確認します。そうすると、インタラクティブにスクリプトを開発するために、サーバーに SSH 接続できたり、notebook に接続できます。

Pricing and Documentation

ここから利用料金情報の詳細を確認することができます。Glue のクローラ、ETLジョブ、そして、開発エンドポイントは DPU(Data Processing Unit) 時間で課金されます。米国東部(バージニア北部) では、1 DPU時間のコストは 0.44 USD となります。1 DPU あたり、4vCPU と 16GB メモリを利用できます。

ここでは Glue の持っている機能の半分ほどしか説明できていないので、blog を読み終えた皆さんに、ドキュメントサービスの FAQ を読むことを推奨します。Glue はコンソールで実施できること以上の機能を提供可能なリッチでパワフルな API も持っています。

本日、新しい2つのプロジェクトもリリースします。aws-glue-libs は Glue と接続し、連携するためのユーティリティ群を提供します。aws-glue-samples repo にはETL ジョブのサンプルコードがまとめられています。

私は Glue を使うことが、データを利用して何かを始める際に必要となる時間を削減するという事実をあなたが見出すことを期待します。AWS Glue に関する別の投稿がすぐにアップされるのをご期待下さい。なぜって、私はこの新しいサービスをいじくるのをやめられないのです!

Randall

(翻訳: SA川村/SA八木,原文:https://aws.amazon.com/blogs/aws/launch-aws-glue-now-generally-available/)

AWS CloudHSM アップデート – 重要データや規制に対応することが可能で、コスト効果の高いクラウド型のハードウェアベース キーマネージメント

AWSのお客様は、AWS上で驚くほど多様なミッションクリティカルなワークロードを実行しており、その多くは機密データを処理して保管しています。 「セキュリティプロセスの概要」のホワイトペーパーで詳しく説明しているように、AWSのお客様は、データを暗号化して保護するための方法について、複数のオプションから選択が可能です。 たとえば、Amazon Relational Database Service(RDS)は、サポートされているデータベースエンジン(MySQL、SQL Server、Oracle、MariaDB、PostgreSQL、およびAurora)ごとにオプションがあり、転送中のデータの暗号化もサポートしています。

多くのお客様がAWS Key Management Service(KMS)を使用してキーを集中管理したり、AWS CloudHSMが提供するハードウェアベースの鍵管理、暗号化、復号を利用することで、重要データと規制に対応したワークロードはコンプライアンスの要求に応えることができています。(ハードウェアセキュリティモジュール(HSM)について、詳しくは、 AWS CloudHSM – Secure Key Storage and Cryptographic Operationsを参照してください)。

 

主要なCloudHSMアップデート

今日、私たちが第1世代の製品から学んだことを踏まえて、我々はCloudHSMを大幅にアップデートしました。専門的な運用ノウハウの必要性を軽減し、ハードウェアベースのキー管理の利点をより多くのユーザーに提供できるように、改良しました。改善の要約を以下に示します。

従量課金モデル – CloudHSMは、シンプルで費用対効果の高い、初期費用なしの従量課金モデルで提供します。

フルマネージド – CloudHSMはスケーラブルな管理サービスになりました。プロビジョニング、パッチ適用、高可用性、およびバックアップはすべて組み込まれています。スケジュールされたバックアップは、(HSMハードウェアだけが知っている鍵を使用して)ハードウェアからHSMの暗号化イメージを抽出し、AWS内の同一のHSMハードウェアにのみリストアできます。耐久性のために、これらのバックアップはAmazon Simple Storage Service(S3)に保存され、AWS KMSマスターキーを使用してサーバーサイドのS3暗号化を使用して再度暗号化されたセキュリティ層が追加されます。

オープンかつ互換性を考慮 – CloudHSMはオープンで標準に準拠しており、PKCS#11Java Cryptography Extension(JCE)、および、Microsoft CryptoNG(CNG)など、複数のAPI、プログラミング言語、および暗号化拡張機能をサポートしています。 CloudHSMのオープン性により、キーを(暗号化された形式で)1つのCloudHSMから別のCloudHSMに移動するプロセスをより詳細かつ簡単に制御し、他の市販のHSMとの間で移行することができます。

より安全に – CloudHSM Classic(オリジナルモデル)は、FIPS 140-2レベル2に準拠した鍵の生成と使用をサポートしています。我々は、HSMにアクセスまたは変更するための物理的な試行を検出して対応するように設計されたセキュリティー・メカニズムを備え、FIPS 140-2レベル3を段階的にサポートしています。バーチャルプライベートクラウド(VPC)内に改ざん防止を備えたHSMに対して、排他的なシングルテナントアクセスとしており、お客様のキーは保護されます。 CloudHSMは、重要な管理機能と鍵管理機能のためのクォーラム認証をサポートします。この機能を使用すると、機能にアクセスできるN個の可能なIDのリストを定義され、少なくともM人以上がアクションを承認する必要があります。また、提供するトークンを使用したマルチファクタ認証もサポートしています。

AWS-Native – アップデートされたCloudHSMはAWSに統合されており、他のツールやサービスとうまく連携します。 AWS管理コンソール、AWSコマンドラインインターフェイス(CLI)、またはAPI呼び出しを使用して、HSMのクラスタを作成および管理できます。

 

使ってみましょう

1〜32のHSMで構成されたCloudHSMクラスターを作成できます。それぞれのクラスターは、特定のAWSリージョンの別々のアベイラビリティゾーンにあります。 AZをまたいでHSMを展開することで、高可用性(組み込みロードバランシングを含む)を実現できます。また、より多くのHSMを追加すると、スループットの向上が得られます。 クラスタ内のHSMは同期して維持されます。クラスタ内の1つのHSMでタスクまたは操作を実行すると、自動的に他のHSMが更新されます。 クラスタ内の各HSMには、独自のElastic Network Interface(ENI)を持ちます。

HSMとの連携は、AWS CloudHSMクライアントを介して行われます。 これはEC2インスタンス上で実行され、証明書ベースの相互認証を使用してHSMへのセキュア(TLS)接続を作成します。

ハードウェアレベルでは、各HSMに暗号操作とキーストレージのハードウェア強制分離が含まれています。 各お客様のHSMは、専用のプロセッサコアで動作します。

 

クラスタの設定:
CloudHSM Consoleを使ってクラスタを設定しましょう。

Create clusterをクリックして、希望のVPCとその中のサブネットを選択します(必要に応じて新しいVPCやサブネットを作成することもできます)。

私は自分の設定を確認し、Createをクリックします:

数分後、クラスタが表示されますが、まだ、初期化されていません。

初期化とは、証明書署名要求(Cluster CSR)を取得することだけです。

プライベートキーを作成し、それを使用してリクエストに署名します(これらのコマンドはInitialize Clusterドキュメントからコピーされましたが、出力は省略されています)。IDはクラスタを識別します。

 

$ openssl genrsa -out CustomerRoot.key 2048
$ openssl req -new -x509 -days 365 -key CustomerRoot.key -out CustomerRoot.crt
$ openssl x509 -req -days 365 -in ID_ClusterCsr.csr   \
                              -CA CustomerRoot.crt    \
                              -CAkey CustomerRoot.key \
                              -CAcreateserial         \
                              -out ID_CustomerHsmCertificate.crt

 

次のステップでは、コンソールまたはCLIを使用して署名付き証明書をクラスタに適用します。 これが完了したら、Crypt Officer(CO)とも呼ばれるHSMの管理ユーザーのパスワードを変更して、クラスタをアクティブにすることができます。

クラスタを作成、初期化し、アクティブ化されたら、それを使ってデータを保護することができます。アプリケーションは、AWS CloudHSM SDKのAPIを使用して、キーの管理、オブジェクトの暗号化と復号化などを行うことができます。 SDKはCloudHSMクライアントへのアクセスを提供します(アプリケーションと同じインスタンスで実行します)。 クライアントは、暗号化された接続でクラスタに接続します。

 

今日から利用可能です。

新しいHSMは、米国東部(北部バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、およびEU(アイルランド)リージョンで現在利用可能であり、それ以外にも展開予定があります。 価格は1時間のHSMあたりで1.45ドルからです。

Jeff;

(翻訳はSA瀧澤与一が担当しました。原文はこちら