Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

AWS HIPAA 対応サービス発表についての詳細情報

では、HIPAA 対応サービスの発表がいくつかありました。AWS ヘルスケアおよびライフサイエンスグローバルテクニカルリーダーの Patrick Combes、および AWS ヘルスケアおよびライフサイエンスパートナーソリューションアーキテクトの Aaron Friedman が、その全貌についてお知らせするためにこの投稿を書いています。 -Ana ここ数週間の間に、次の AWS のサービスが BAA に追加されたことをお知らせいたします。 Amazon API Gateway、AWS Direct Connect、AWS Database Migration Service、Amazon SQS。これら 4 つのサービスはすべて AWS へのおよび AWS を通じてのデータの移動を容易にするため、お客様がこれらのサービスを使用してヘルスケアにおけるソリューションをどのように促進できるか楽しみです。これらのサービスのそれぞれのユースケースは膨大なので、お客様が Protected Health Information (PHI) でこれらのサービスを使用できるいくつかの方法を取り上げます。 AWS の事業提携の追補 (BAA) の適用を受けるすべての HIPAA の対象サービスと同様に、PHI は、保管時または転送時に暗号化される必要があります。HIPAA のホワイトペーパー を参照することをお勧めします。これは、PHI を保存、処理、および転送するための AWS の HIPAA 対応サービスの設定方法について説明しています。そしてもちろん、PHI に該当しないアプリケーション部分については、90 以上のサービスを使用して、ユーザーに最適なエクスペリエンスを提供することができます。HIPAA のアーキテクチャに関するアイデアは、ウェブサイトでご覧いただけます。 Amazon API […]

Read More

New – Amazon Simple Queue Service (SQS) でサーバー側の暗号化を導入

AWS シリーズの中でも尊敬に値するサービスの 1 つ、 は多くのアプリケーションにおいて欠かせない一部を担っています。「Amazon SQS でより優れたアーキテクチャを実現 (Amazon SQS for Better Architecture)」や「Amazon SQS と Amazon DynamoDB で大量のメッセージを処理する (Massive Message Processing with Amazon SQS and Amazon DynamoDB)」などのプレゼンテーションは、SQS をどのように使用すれば復元力とスケーラブルが高いアプリケーションを構築できるのか説明しています。そして今回、サーバー側の暗号化をサポートすることでその SQS がさらに便利になりました。今後は による暗号化キーを使用して、スタンダードと FIFO キューの両方で SQS 暗号化済みメッセージを保存するオプションが提供されます。このオプションはキューの作成時に選ぶことができます。また、同時に既存のキューで設定することも可能です。SSE はメッセージ本文を暗号化しますが、キューのメタデータやメッセージのメタデータまたはキューごとのメトリクスは対象外になります。既存のキューに暗号化を追加しても、過去のメッセージは暗号化の対象にはなりません。同様に、暗号化を解除しても過去のメッセージの暗号化がキャンセルされることはありません。 暗号化したキューを作成 新しいバージョンの では、便利なグラフィックを使用してスタンダードと FIFO キューのどちらかを選択できます。 キューとオプションの Dead Letter Queue に属性を設定することができます。 Use SSE を確認し希望のキーを選択できるようになりました。 各顧客やリージョン独自の AWS マネージド型カスタマーマスターキー (CMK) を使用したり、ご自分のキーを作成して管理することができます。ご自分のキーを使用する場合は、メッセージの暗号化や複合化を許可するため、KMS キーポリシーを必ず更新してください。データ再利用期間を設定することもできます。この間隔は SQS […]

Read More

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

春到来に伴い Tina Barr のスタートアップ企業を紹介するブログです。お楽しみください! -Ana 今月も引き続き、AWS を利用しているホットなスタートアップ企業を紹介していきます。今回は 3 つの新しいスタートアップ企業を紹介します。 Beekeeper – 社員同士のコミュニケーションをよりシンプルに Betterment – 誰でも簡単に投資をスタート ClearSlide – 業界をリードするセールスエンゲージメントプラットフォームを提供 3 月のホットスタートアップを見逃しましたか? 大丈夫、こちら からご覧いただけます。 Beekeeper (スイス、チューリッヒ) チューリッヒ工科大学 (ETH Zurich) 卒業の Flavio Pfaffhauser と Christian Grossmann は、人々を結び付けるためのテクノロジーを構築することに熱心です。学生のソーシャルコミュニティから始まったそれは、すぐに Beekeeper になりました。Beekeeper は、仕事場において社員がどこからでもコミュニケーションを取り合うことを可能にするプラットフォームです。Flavio と Christian は自分達の目的に適った方法で、人々がエンゲージするソーシャルプラットフォームの構築方法を学びました。すると、様々なビジネスから各社の特別なプロセスとニーズに対応できるプラットフォームをリクエストされるようになりました。このプラットフォームは、デスクに向かっていたり出先にいたとしても、まるですぐ隣に相手が座っているかのように感じられるものを作りたいというコンセプトから始まりました。2012 年に創設された Beekeeper は、情報交換、コミュニケーション、ピアコラボレーションの改善に焦点を当てています。そして組織にとって、社員の声に耳を傾けることが非常に大切であると考えています。「まずはモバイル、デスクトップも OK (“Mobile First, Desktop Friendly”)」なプラットフォームは、シンプルかつ直観的なインターフェイスで、複数のオペレーティングシステムを簡単に 1 つのエコシステムにすることができます。インターフェイスは企業のブランドやアイデンティティに合わせてスタイルしたりカスタマイズすることができます。社員はいつでもどこにいても、プライベートチャットやグループチャット、ビデオ、ファイル共有、フィードバックに関するアンケート調査などを通じて同僚とコミュニケーションを取り合うことができます。Beekeeper の分析ダッシュボードで、リーダーシップチームはディスカッションで何がトレンディングトピックになっているのか確認したり、社員のエンゲージメントやアプリ使用をリアルタイムでトラッキングすることができます。Beekeeper は現在 137 か国に渡り、サービス業や建設業、運送業そしてその他の業界で利用されています。Beekeeper は同社のエンジニア達が顧客サービスの問題に集中できるようにする […]

Read More

ローカルのMosquitto MQTT BrokerをブリッジにAWS IoTを使う

AWS SDKまたはAWS IoT Device SDKを使用して、数百万のオブジェクトをAWS IoTに安全に接続できます。 製造業におけるIoTの場合、オブジェクトは複数の理由でゲートウェイに接続されます。 センサーは非常に制約され、クラウドに直接接続できないことや、センサーはプロトコルとしてMQTTが使えないまたは、 ゲートウェイ上でローカルに分析と処理を実行する必要があります。 ローカルMQTTブローカーの1つの機能は「ブリッジ」と呼ばれ、MQTTメッセージを交換できるように、ローカルMQTTブローカーをAWS IoTに接続することができます。 これにより、オブジェクトがAWS IoTと双方向で通信し、AWSクラウドの恩恵を受けることができます。 この記事では、この機能が非常に便利で、実装方法を示すユースケースについて説明します。   MQTTブローカーをAWS IoTにブリッジする理由 IoTではセキュリティが最も重要であり、AWS IoTブローカーには、クライアント証明書付きのTLS 1.2などに基づいてデバイスを認証および認可する高度なセキュリティビルトインが組み込まれています。 従来のIoTデプロイメントを使用している場合は、MQTTブローカーにユーザー名やパスワードなどの他の認証メカニズムを使用してオブジェクトをすでに接続している可能性があります。 MQTTブローカーは、センサーがデプロイされる非常に近い場所(ローカルMQTTブローカー)もしくはクラウドの中に構築されています。 現在のセキュリティ標準をAWS IoTのものに合わせてアップグレードする予定で、AWS IoTのスケーラビリティとルールエンジンの恩恵を受けるには、従来のMQTTブローカーをAWS IoTにブリッジすることができます。これは、現在のシステムのアップグレードを待たずにすばやく導入できる簡単な一時的なソリューションです。単一のブローカーを超えるスケーリングはこの記事の範囲には含まれていませんが、Mosquitto MQTT Brokerのブリッジ機能に焦点を当てます。 MosquittoのようなオープンソースのMQTTブローカーは、Linuxのような多くのオペレーティングシステムにインストールすることができます。ローカルデバイスにMosquittoをインストールすると、Mosquitto bokerの機能(ローカルでのメッセージの永続化、ローカルでのログのアクティビティ)をローカルで有効にするだけでなく、ローカルデバイスにMosquittoをインストールすることで、AWS IoTにデータを送信するための特別なコードを開発する必要がありません。

Read More

AWS Storage Gateway でファイルインターフェイス

「 のレビュー」といったブログカテゴリを追加した方がいいかもしれませんね。去年の 11 月、 に重要な機能を追加しましたが、忙しすぎてその調査やブログを書く時間を取れずにいました。 は既存のアプリケーションと の間に位置するマルチプロトコルストレージアプライアンスです。お使いのアプリケーションやクライアントオペレーティングシステムは (設定によりますが) ゲートウェイをファイルサーバー、ローカルディスクボリュームまたは仮想テープライブラリ (VTL) と見なします。その背景でゲートウェイはコスト効率が良く耐久性のある安全なストレージに を使用しています。 はデータをローカルでキャッシュし、帯域幅の管理機能を使用してデータ転送を最適化します。 はインストールや設定そして実行が簡単な自己完結型の仮想アプライアンスとして提供されています (詳細は「Storage Gateway のユーザーガイド (Storage Gateway User Guide) 」をご覧ください)。既存の環境でクラウドストレージのスケールや耐久性そしてコスト面におけるメリットを活用できます。既存のファイルやディレクトリを S3 に移動するプロセスを減らし、ドラッグアンドドロップ (または CLI ベースのコピー) でシンプルに移動できます。その他多くの AWS サービスと同様に、2012 年にリリースされてから にいくつもの機能が追加されてきました (「AWS Storage Gateway – AWS クラウドストレージと既存のオンプレミスアプリケーションを統合 (The AWS Storage Gateway – Integrate Your Existing On-Premises Applications with AWS Cloud Storage)」)。 をリリースした時点で、ストレージボリュームの作成や iSCSI デバイスにアタッチできたほか、ボリュームすべてを保存したり、ゲートウェイでもっとも頻繁にアクセスされているデータのキャッシュを保存するオプションを提供します。そして、これらはすべて […]

Read More

新しい Samsung DeX と Samsung Galaxy S8/S8+ で Amazon WorkSpaces を使用

テクノロジーの進化とその改良を見るのは実に面白いものです。たとえば、最近の携帯電話にはハイエンドなデスクトップが備えるほどの解像度を持つ画面が使用されているほか、接続性や携帯性においても複数のオプションが提供されています。今週初めに、最新の Samsung Galaxy S8+ スマートフォンと、独自の新しいコンパニオンデバイス、Samsung DeX Station を試す機会に恵まれました。まず、スマートフォンに Android 向けの Amazon WorkSpaces クライアントをインストールし、WorkSpace の登録コードを入力してログインしてみました。これら一連の操作は、こちらの新しいビデオでご覧いただけます。 DeX にはキーボードとマウス用の USB コネクターが含まれています。Bluetooth で操作することもできます。冷却ファン、時間を短縮できるスマートフォンの充電器、HDMI とイーサネットポートも含まれています (スマートフォンのデータ通信または Wi-Fi 接続の使用も可)。すべて一緒にすれば、どこにいてもクラウドベースのデスクトップにアクセスできます。滞在先のテレビやモニターを使用すれば、企業ネットワークのフルアクセスでファイルやその他のリソースにアクセスできるので、旅先の荷物も軽くなります。 PS – 私の WorkSpace についてもう少し詳しく知りたければ「Amazon WorkSpace が大活躍 (I Love my Amazon WorkSpace)」をご覧ください。

Read More

Now Available – Lumberyard Beta 1.9

本日、最大リリースであるLumberyard Beta 1.9がリリースされたことをお知らせします。 473以上に及ぶ改良、修正、および機能のリリースには、30分以下でプレーヤー認証を実装するための新しい Player Account  Cloud Gemが含まれ、複雑なコンテンツをより迅速に構築するためのComponent Entity workflow のアップデート、particle editorの新しいGPU機能とエミッタタイプ、視覚的に素晴らしい効果でゲーム世界を満たすことができ、そしてより多くの機能が追加されました。Lumberyard Beta 1.9 はこちらからダウンロードできます。 これらの改善は皆様の直接のフィードバックのお陰です。以前、私たちのチームの中核的哲学の1つである「continuous improvement(継続的改善)」の日本語であるカイゼンについて話しました。先月のGDCの素晴らしい提案とアイデアのおかげで、我々はLumberyardのいくつかの主要分野でのカイゼンへのコミットメントを強化することができました。ここにいくつかあります: New Player Account Cloud Gem 私たちがGDCで得た最も一般的なリクエストの1つは、より多くのCloud Gemsを提供することでした。2月にリリースされた当社独自のCloud Gems Frameworkにより、開発者は、1人のエンジニアとわずか30分で、ネットワーク通信が必要なゲーム要素(dynamic content、leaderboards、live messagesなど)を構築し、起動することが簡単になりました。今回のリリースでは、Player Account Cloud GemをLumberyardの成長し続けるGemコレクションに追加し、プレイヤーの認証と管理のためのカスタマイズ可能なスタンドアロンのソリューションを提供しています。プレイヤーがゲームに登録したときにゲームキーを要求したり、クラウドのプレーヤーのために追加のメタデータを保存したい場合、Player Account Cloud Gemを利用するとその時間と労力を節約できます。 理由は次のとおりです。これまではプレーヤーアカウントシステムを自分で実装するには、アカウント情報を保存するデータベースサービスをセットアップし、プレーヤー情報を安全なハッシュで保護をするための実装をし、サービスと電子メールシステムを実装する必要があります。 ID。また、ログイン・フロー、アイデンティティ・キャッシング、および期限切れの認証トークン更新プロセスをゲーム・クライアントでセットアップする必要があります。2〜3人のエンジニアがこの作業を行うには数カ月かかることがあります。何か間違ったことがあれば、プレイヤーがゲームに参加できないという危険性があります。Player Account Cloud Gemを使用すると、ほんの数ステップで実行できるように簡略化されているので、1人のエンジニアは約30分ですべてを実行できます。その結果、Cloud Gem Portal dashboardからプレーヤーのデータを管理し更新することができます。 Component Entity Workflows また、今年はGDCでComponent Entityシステムの最新のワークフローをデビューしました。皆様のご意見のおかげで、このリリースでゲームとエンジンの要素を構築するためのモジュラーで直感的な方法を提供する、いくつかの重要な改善を行う事ができました。新しいComponent Entityシステムの目標は、小規模なゲーム、カジュアルゲーム、大規模なAAAエクスペリエンスのいずれを構築しているかに関係なく、複雑で実用的なエンティティを短時間で最小限の労力で作成するのに役立てます。私たちが最近Component Entityシステムを改善したいくつかの方法を見てみましょう。 第1に新しいComponent Entityシステムでは、リフレクション、シリアライゼーション、およびメッセージングを使用して、エンジニアリングを必要とせずにコンポーネントの機能をデザイナーに自動的に公開します。これは、Lumberyard Editorでコンポーネントのプロパティをドラッグ&ドロップして編集できることを意味し、わずか数回のクリックで「スライス」と呼ばれる完全にカスケード化されたプレハブを作成します。 第2に、努力を減らしイテレーションを加速するために、働かないエンティティを作成することは困難でした。たとえば、同じエンティティ(複数の静的メッシュなど)に重複するコンポーネントを追加しようとすると、システムは間違いを犯さないようにします。コンポーネントが機能するために別のコンポーネントを必要とする場合(単純なアニメーションコンポーネントではスキンメッシュが機能する必要があります)、依存関係を自動的に追加し、そうする必要はありません。 第3に、新しいComponent Entityシステムが欠落した構成や誤った構成をどのように処理するかについて、より柔軟に作成したいと考えました。エンティティに無効なコンポーネントや互換性のないコンポーネントが含まれるようになったときに、新しい警告システムでサービスの問題が表示されます。この警告は、問題を修正し、不足している依存関係をすばやく解決するのに役立ちます。たとえば、最初にシェイプを追加せずにプリミティブコライダーを追加すると、プリミティブコライダーはシェイプを追加することを提案します。ワンクリックで必要なシェイプのタイプを選択できます。シェイプが追加されるまで、プリミティブコライダーは登録されないため、シェイプを選択する前にゲームを実行すると実行時の問題を防ぐことができます。 最後に、皆様のフィードバックのおかげで、エンティティインスペクタの新しい使いやすさが改善されました。インスペクタでコンポーネントが追加された順序を覚えることができ、右クリックメニューからコンポーネントをより簡単に並べ替えることができます。(今後のリリースでドラッグ&ドロップを追加する予定です)また、エンティティ間でコンポーネントの切り取り、コピー、貼り付けを可能にし、検索機能を改善して大量のコンテンツをナビゲートし、コンポーネントのUIを見直して読みやすくしました。 Particle […]

Read More

AWS でコンソーシアムサイエンスを活用し科学的発見を促進

同僚の Mia Champion は科学者 (彼女が発表した記事) であり、AWS 認定ソリューションアーキテクト そして AWS 認定開発者でもあります。今回は、彼女が大量なデータのデータセットリサーチを行っている際に、バイオインフォマティクスにおけるクラウドコンピューティングの価値に気付いた時のことについてブログを投稿いただきました。 科学研究における技術の進歩は、そのコンテンツにおいても複雑性を増し、日々急増しているデータセットのコレクションに可能性を与えています。世界中で加速化するイノベーションは、最近のクラウドコンピューティング革命によっても活気付けられ、一見したところ無限でスケーラブルそして迅速なインフラストラクチャを研究者に提供しています。現在では、研究者が独自のシーケンサー、マイクロスコープ、コンピューティングクラスターなどを所有するための障害を排除しています。クラウドを使用することで、科学者はギガバイトにも及ぶ何百万人という患者のサンプルのデータセットや各患者のその他の情報を簡単に保存、管理、処理そして共有することができます。アメリカの物理学者である John Bardeen はこのように言っています。「科学というものは協同して取り組むものです。数人の科学者が共に努力し出し合った結果を組み合わせることで、1 人の科学者が行うよりも効率よく研究を進めることができるのです (Science is a collaborative effort. The combined results of several people working together is much more effective than could be that of an individual scientist working alone)」 再現性のイノベーション、一般化、データ保護の優先 これまでにないスケールで、安全性を備えたクラウドを有効にしたデータ共有を活用する研究者や組織は日々増え、AWS クラウドを使用して革新的でカスタマイズした分析ソリューションを作り出しています。しかし、そうしたスケールの共同作業環境において、対象分野そして科学における従来の方法を根本的に変え、安全なデータ共有と分析を行うことは可能でしょうか?クラウドを有効にしたリソースの共同体を構築することで、研究結果の説明やその影響において問題となり、再現性の下落に繋げた分析変動性を排除することはできるのでしょうか? こうした疑問への答えは「イエス」です。Neuro Cloud Consortium、The Global Alliance for Genomics and Health (GA4GH)、The […]

Read More

Kinesis Firehoseを使用してApache WebログをAmazon Elasticsearch Serviceに送信する

Elasticsearch、Logstash、および、Kibana(ELK)スタックを所有して運用する多くのお客様が、他の種類のログの中でもApache Webログを読み込んで可視化しています。 Amazon Elasticsearch Serviceは、AWSクラウドにElasticsearchとKibanaを提供しており、セットアップと運用が簡単です。 Amazon Kinesis Firehoseは、Amazon Elasticsearch ServiceにApache Webログ(またはその他のログデータ)をサーバーレスで確実に配信します。 Firehoseを使用すると、Firehose内のレコードを変換するAWS Lambda関数への自動呼び出しを追加できます。これらの2つのテクノロジーを使用すると、既存のELKスタックを効果的かつ簡単に管理することができます。 この記事では、最初にAmazon Elasticsearch Serviceドメインを設定する方法を説明します。次に、事前ビルドされたLambda関数を使用してApache Webログを解析するFirehoseストリームを作成して接続する方法を示します。最後に、Amazon Kinesis Agentでデータをロードし、Kibanaで可視化する方法を示します。

Read More

AWS上でApache Flinkを使用してリアルタイムストリーム処理パイプラインを構築する

今日のビジネス環境では、多様なデータソースが着実に増加していく中で、データが継続的に生成されています。したがって、このデータを継続的にキャプチャ、格納、および処理して、大量の生データストリームを実用的な洞察に素早く繋げることは、組織にとって大きな競争上のメリットになっています。 Apache Flinkは、このようなストリーム処理パイプラインの基礎を形成するのに適したオープンソースプロジェクトです。ストリーミングデータの継続的な分析に合わせたユニークな機能を提供しています。しかし、Flinkを基にしたパイプラインの構築と維持には、物理​​的なリソースと運用上の努力に加え、かなりの専門知識が必要になることがよくあります。 この記事では、Amazon EMR、Amazon Kinesis、Amazon Elasticsearch Serviceを使用してApache Flinkを基にした、一貫性のあるスケーラブルで信頼性の高いストリーム処理パイプラインの参照アーキテクチャの概要を説明します。 AWSLabs GitHubリポジトリは、実際に参照アーキテクチャを深く理解するために必要なアーティファクトを提供します。リソースには、サンプルデータをAmazon Kinesisストリームに取り込むプロデューサアプリケーションと、リアルタイムでデータを分析し、その結果をAmazon ESに可視化するためのFlinkプログラムが含まれています。

Read More