Amazon Web Services ブログ

【確定版】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瀧澤与一が担当しました。原文はこちら

 

 

新機能 − Amazon Elastic Filesystem(EFS)で保管データの暗号化をサポート

我々は、1年と少し前にAmazon Elastic File Systemを本番ローンチしました。(詳細は Amazon Elastic File System – Production Ready in Three Regionsを確認ください)。そしてその年の後半には、Direct Connec経由でのオンプレミスアクセスを追加し、今年になって米国東部(オハイオ)、欧州(フランクフルト)、アジア・パシフィック(シドニー)リージョンでも利用可能となりました。

保管データの暗号化

本日、保管データの暗号化サポートを加えることにより、EFSがより利用しやすくなりました。ファイルシステムの作成時に、ファイルシステム上に保管するコンテンツを暗号化するための鍵を選択することが可能です。AWSが管理するビルトインの鍵、あるいは、AWS Key Management Service(KMS)を利用して自身で作成した鍵がご利用可能です。ファイルのメタデータ(ファイル名、ディレクトリ名、ディレクトリの内容)はAWSが管理する鍵で暗号化されます。どちらの暗号化の形式も、業界標準のAES−256アルゴリズムを利用して実装されています。

新しいファイルシステムを作成するときにすぐにセットアップ可能です。シンプルにビルトイン鍵(aws/elasticfilesystem)、あるいは自分の鍵を選択するだけです:

EFSが残りをすべて行います! コンソールでファイルシステムを選択することで、望みどおり暗号化されているかどうかを確認できます:

データをメタデータの暗号化には、FIPS 140-2の承認に適合した暗号化アルゴリズムが利用されます。暗号化は透過的に行われ、全体のパフォーマンスへの影響は最小限です。

AWS Identitiy and Access Management(IAM)を利用して、Customer Master Key(CMK)へのアクセスを制御することができます。CMKは、ファイルシステムへアクセスするために有効化されていなければいけません。鍵を無効化すると、新しいファイルシステムの作成に使用できなくなり、保護対象の既存のファイルシステムへのアクセスが(一定期間後)ブロックされます。詳細については、Managing Access to Encrypted File Systemsをご参照ください。

すぐにご利用可能

保管データの暗号化はEFSがサポートされている全てのリージョンでご利用可能です。追加料金は発生しません。

Jeff; (翻訳はSA布目が担当しました。原文はこちら

ASP.NET CoreとAWS CodeStarのDeep Dive

AWS CodeStar チームは最近、2つのASP.NET Coreプロジェクト テンプレートの追加を発表しました。ご存知かもしれませんが、AWS CodeStarは継続的インテグレーションと継続的デプロイメント(CI/CD)パイプラインを開発者に代わって作成し、それによって開発者は貴重な時間をインフラの構築の代わりにアプリケーションの構築に費やすことができます。新しいASP.NET Coreプロジェクトテンプレートを使用することで、.NET開発者は初日からAWSアプリケーションを構築し、展開することができます。Tara Walkerの優れたブログ記事では、AWS CodeStarでASP.NET Core アプリケーションを作成する方法について説明しています。このブログ記事では、AWS CodeStarのASP.NET Coreプロジェクトにテストを追加する方法を学ぶ中で、背後で何が起こっているのかを詳しく見ていきます。

 

Unit Test プロジェクトの追加

私たちの目標は、HelloControllerの機能を実行するシンプルなテストケースを追加することです。私はあなたが全く新しいASP.Net Core Web Service プロジェクトを持っていると仮定しています。もし、まだプロジェクトを持っていない場合は、Taraのブログ記事(上記)をたどってプロジェクトを作成することができます。ASP.NET Core Web Service テンプレートを選択していることを確認してください。ASP.NET Core for AWS CodeStarプロジェクトを作成後、Team Explorer でプロジェクト リポジトリをクローンし、AspNetCoreWebServiceソリューションをロードしたら、残りのブログ記事に沿って後を追えるようになります。Team Explorer でリポジトリをセットアップするためのガイドが必要な場合は、5月のSteve RobertのVisual StudioとCodeCommitのインテグレーションについての発表をご覧ください。

最初に、AspNetCoreWebServiceTestという名前の新しいxUnitプロジェクトをAspNetCoreWebServiceソリューションに追加します。私たちの新しいテストプロジェクトはHelloControllerクラスとJsonResultを参照するので、AspNetCoreWebServiceをプロジェクト参照として追加し、Microsoft.AspNetCore.MvcをNuGet参照として追加する必要があります。それらをテストプロジェクトに追加すると、AspNetCoreWebServiceTest.csprojに次の追加情報が表示されます。

 

<ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
    ...
</ItemGroup>
...
<ItemGroup>
    <ProjectReference Include="..\AspNetCoreWebService\AspNetCoreWebService.csproj" />
</ItemGroup>

 

これにより、HelloControllerクラスを直接参照し、JsonResultを展開することができます。次のように簡単なテストケースを追加しましょう。

using System;
using Xunit;
using Microsoft.AspNetCore.Mvc;
using AspNetCoreWebService.Controllers;

namespace AspNetCoreWebServiceTest
{
    public class HelloControllerTest
    {
        [Fact]
        public void SimpleTest()
        {
            HelloController controller = new HelloController();
            var response = controller.Get("AWS").Value as Response;
            Assert.Equal(response.output, "Hello AWS!");
        }
    }
}

 

ファイル名、名前空間、クラス名、およびメソッド名を変更したことに注意してください。テストを実行し、テストが合格することを確認します。ソリューション エクスプローラで次のように表示されます。

動作するテストプロジェクトを手に入れたので、アプリケーションをデプロイする前にテストをビルドして実行するようにパイプラインを更新します。

 

AWS CodeBuildジョブの更新

最初にプロジェクトの構築方法を見てみましょう。あなた、もしくはチームのメンバーがリポジトリに変更をプッシュすると、パイプラインは自動的に最新の変更に対してビルドプロセスを開始します。このステップでは、AWS CodeBuildはビルドプロセスを実行するためにリポジトリのルートにあるbuildspec.ymlファイルを使用します。

version: 0.2
phases:
  pre_build:
    commands:
      - echo Restore started on `date`
      - dotnet restore AspNetCoreWebService/AspNetCoreWebService.csproj
  build:
    commands:
      - echo Build started on `date`
      - dotnet publish -c release -o ./build_output AspNetCoreWebService/AspNetCoreWebService.csproj
artifacts:
  files:
    - AspNetCoreWebService/build_output/**/*
    - scripts/**/*
    - appspec.yml

 

AWS CodeBuildジョブは、AWS CodeBuildに.NET Coreイメージを使用します。これには buildspec.ymlで呼び出す.NET Core SDKとCLIが含まれています。このプロジェクトは1つのWebサービスで構成されているため、1つのbuildspec.ymlファイルで十分です。プロジェクトが拡大しビルドプロセスの複雑さが増すにつれて、いずれはシェルスクリプトまたはMSBuildの.projファイルを使用してシンプルにbuildspec.ymlでscript / buildファイルを呼び出すように、ビルドプロセスを外部で駆動したいと思うかもしれません。

 

ここでは dotnet publishコマンドに注目したいと思います。この発行のステップは、すべての依存関係をパッケージ化してホストマシン上ですぐに利用できるようにするために重要です。上記のbuildspec.ymlファイルのartifactsセクションで定義されているように、AWS CodeDeployがホストにアプリケーションを配置するために使用するファイル群が、Amazon S3バケットに格納されます。scripts/**/* には、appsec.ymlが依存するすべてのスクリプトが含まれています。appsec.ymlに慣れていない方や詳細を知りたい方のために次のセクションで説明します。

前のセクションでは、AWS CodeCommitリポジトリにテストプロジェクトを追加しました。今度は、新しいテストプロジェクトをビルドするためにbuildspec.ymlを更新する必要があります。ビルド ステージの一部として、単にdotnet vstestを実行することができますが、このエクササイズではベストプラクティスに従ってビルドとテストのステージを分けて構築します。 buildspec.ymlを修正してテスト バイナリをビルドし、その成果物をAspNetCoreWebServiceTest/test_outputディレクトリに発行しましょう。

pre_build:
    commands:
        ...
        - dotnet restore AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj
post_build:
    commands:
        ...
        - dotnet publish -c release -o ./test_output AspNetCoreWebServiceTest/AspNetCoreWebServiceTest.csproj  
artifacts:
    files:
        ...
        - AspNetCoreWebServiceTest/test_output/**/*

 

アーティファクトとしてAspNetCoreWebServiceTest/test_output/**/* を追加したことに注意してください。実際には、これは発行されたテストバイナリをAmazon S3にアップロードするようにAWS CodeBuildサービスに指示することになります。これにより、次に作成するテスト ジョブでそれらを参照できるようになります。

 

AWS CodePipelineの更新

前のセクションでは、テストを実行するために必要なバイナリをビルドして保存するために、新しいテストプロジェクトを追加し、buildspec.ymlを修正しました。次にテストステージをパイプラインに追加する方法について説明します。まずTestステージとUnitTestアクションをコンソールからパイプラインに追加しましょう。

残りのUIも以下のパラメータで埋めます:

  • Action category: Test
  • Action name: UnitTest
  • Test provider: AWS CodeBuild
  • Create a new build project を選択
  • Project name: <プロジェクト名>-test
  • Operating system: Ubuntu
  • Runtime: .NET Core
  • Version: aws/codebuild/dot-net:core-1
  • Build specificationInsert build Commands を選択
  • Build command: dotnet vstest AspNetCoreWebServiceTest/test_output/AspNetCoreWebServiceTest.dll
  • Role nameCodeStarWorker-<プロジェクト名>-CodeBuild をリストから選択
  • Input artifacts #1 は, <プロジェクト名>-BuildArtifact をリストから選択

 

ここでの重要な情報は、ビルドコマンドです。私たちのテストジョブは前のステージでビルドされたtest.dllに対してdotnet vstestを実行します。あなたのパイプラインはこのようになります。

これでほぼ完成です!「Release Change」を押してこのパイプラインを実行すると、パイプラインのテストステージで Error Code: AccessDeniedException  のメッセージを伴って実行が失敗します。これは、AWS CodeStarサービスに新しいテストステージを実行する権限がないためです。ここではAWS CodeStarプロジェクトへの適切なアクセスを許可する方法を確認しましょう。

 

Role ポリシーの更新

AWS CodeStarプロジェクトでは、さまざまなサービスやワーカーがアプリケーションを同期、ビルド、およびデプロイするための最小限のアクセス許可のポリシーを作成します。新しいAWS CodeBuildジョブを追加したので、新しいリソースへのアクセスをCodeStarWorkerCodePipelinePolicyで許可する必要があります。この変更を行うためにIAMコンソールに移動します。 [Role]タブで、 “codebuild”キーワードを使用して検索します。ロールはCodeStarWorker- <プロジェクト名> -CodePipelineの形式である必要があります。次に、ロールにアタッチされているポリシーを編集します。以下に示します。

変更したい内容は、ポリシー内にAWS CodeBuildアクションに関連付けられている新しいcodebuildリソースである arn:aws:codebuild:us-east-1:532345249509:project/<プロジェクト名>-test を追加することです。

{
    "Action": [
        "codebuild:StartBuild",
        "codebuild:BatchGetBuilds",
        "codebuild:StopBuild"
    ],
    "Resource": [
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>"
        "arn:aws:codebuild:us-east-1:532345249509:project/<your project name>-test"
    ],
    "Effect": "Allow"
}

 

以上です。AWS CodeStarプロジェクトは新しいジョブを構築するための適切な権限を持ちました。[Release Change] を押して試してみてください。

 

ASP.NET Core アプリケーションのデプロイメント

ここまでAWS CodeStarがプロジェクトをビルドしテストする方法を見てきました。このセクションでは、デプロイメントプロセスを詳しく見ていきます。AWS CodeStarプロジェクトの作成の一部として、AWS CodeStarサービスはアプリケーションをホストするAmazon EC2インスタンスを作成します。またappspec.ymlの指示に従って、そのインスタンスにデプロイメントプロセスを実行するcode-deploy-agentもインストールされます。appspec.ymlを見てみましょう。

version: 0.0
os: linux
files:
  - source: AspNetCoreWebService/build_output
    destination: /home/ubuntu/aspnetcoreservice
  - source: scripts/virtualhost.conf
    destination: /home/ubuntu/aspnetcoreservice 
hooks:
  ApplicationStop:
    - location: scripts/stop_service
      timeout: 300
      runas: root

  BeforeInstall:
    - location: scripts/remove_application
      timeout: 300
      runas: root

  AfterInstall:
    - location: scripts/install_dotnetcore
      timeout: 500
      runas: root

    - location: scripts/install_httpd
      timeout: 300
      runas: root

  ApplicationStart:
    - location: scripts/start_service
      timeout: 300
      runas: root

 

各スクリプトは、デプロイメントプロセスのさまざまなステージで実行されます:

  • install_dotnetcore – もしまだインストールされていなければ .NET Core をインストールし、最初の実行時にパッケージ キャッシュをアップデートします。これはMicrosoftのUbuntuへの.NET Coreインストールの推奨方法です。
  • install_httpd – HTTPDデーモンとmodsをインストールし、HTTPD設定ファイルを上書きしてリバースプロキシを有効化します。
  • start_service – HTTPDサービスを再起動し、既存のASP.NETアプリケーション/サービス プロセスを再起動します。
  • scripts/stop_service – HTTPDサービスを停止し、既に実行している場合、ASP.NETアプリケーション/サービスを停止します。
  • remove_application – インスタンスからデプロイされているアプリケーションを削除します。

 

インスタンス上のcode-deploy-agentは、アプリケーションのデプロイ時にこれらのフックを実行して、サービスをインストールして開始します。イベントのアクティビティはAWS CodeDeployコンソールで監視でき、EC2インスタンスから詳細なログを取得できます。インスタンスへのSSH接続を開いたら、デプロイメントログを見るために /var/log/aws/codedeploy-agentに移動してください。

 

結論

このブログ記事では、アプリケーションのパイプラインにテストステージを追加する例を使用して、AWS CodeStarのASP.NET Core プロジェクトの構築とデプロイメントを学びました。この記事がAWS CodeStarの下で完全なCI / CDシステムを提供するために、さまざまなコンポーネントとAWSサービスがどのように相互作用するかを理解する助けになることを願っています。詳細については、AWS CodeStarユーザーガイドをご覧ください。AWS CodeStarに固有の問題が発生した場合は、AWS CodeStarのトラブルシューティング ガイドを参照してください。

 

(翻訳はSA 福井が担当しました。原文はこちらです。)

 

LLAPを使用してAmazon EMRでのApache Hiveクエリをターボチャージ!

Apache Hiveは、SQLを使用してHadoopクラスタに格納された大規模なデータセットを分析するための最も一般的なツールの1つです。データアナリストやデータサイエンティストは、大きなデータのクエリ、要約、探索、および分析にHiveを使用します。

Hive LLAP(Low Latency Analytical Processing)の導入により、Hiveが単なるバッチ処理ツールであるという考え方が変わりました。 LLAPは、インテリジェントなインメモリキャッシュを使用して長期実行デーモンを使用し、バッチ指向のレイテンシを覆し、1秒未満のクエリ応答時間を提供します。

この記事では、Hive LLAPのアーキテクチャと、クエリパフォーマンスを向上させるための一般的な使用例など、Hive LLAPの概要を示します。 Amazon EMRクラスタにHive LLAPをインストールして設定し、LLAPデーモンでクエリを実行する方法を学習します。

(more…)

AWS re:Invent 2017 の準備

2017 年 11 月 27 日まであとわずか 110 日となった今、私と私の同僚は re:Invent 2017 の準備を懸命に行っています。まだブログ投稿の作成や新しい LEGO の作成は開始していませんが、非常に暫定的な発表リストを確認済みで、これからの非常に多忙な 1~2 か月に向けて既に準備中です。

これまでにないほど、より多くの会場、より大きな展示ホール、より多くのコンテンツ (1,000 以上のセッション)、ハッカソン、ブートキャンプ、ワークショップ、認定のチャンスが用意されています。Tatonka チャレンジre:PLAY パーティーといった恒例の人気行事に加えて、ブルームボール (Amazon の長期にわたる伝統行事) やオールスターフィットネスアクティビティも追加されました。

毎年、長い間ご無沙汰している知り合いからチケットを求めるぎりぎりの手紙、電話、E メールをもらいますが、すべてお断りしなければなりません (「たしか 1 年生のときに一緒でしたね」というような連絡を待っていますが、どうなるかはおわかりですね)。毎年キャパシティーは増やしていますが、多くのお客様に対して売り切れになることが予想されるため、取り残されないよう、今すぐ予約することを今一度お勧めいたします。

ベガスでお会いしましょう。

Jeff;