Amazon Web Services ブログ

IoTデバイスを管理する上で、プロビジョニングは一つの重要な事項です。プロビジョニングとは、IoTデバイスをプラットフォームあるいはシステムに登録するプロセスです。デバイスのブートストラップ処理において、中間者攻撃などを防止するために、デバイスとIoTエンドポイントの間で相互認証を確立することが大事です。デバイス認証で現状最もセキュアな方法はデバイス証明書を使用することであり、一般的にデバイスアイデンティティ管理の第一選択肢でもあります。 このブログでは、AWS IoT CoreとAWS IoT Device Managementでブートストラップ証明書を使ったプロビジョニング方法について深掘りしていきます。AWS IoT Coreは、接続されたデバイスがクラウドのアプリケーションや他のデバイスとセキュアかつ簡単に通信することを実現するマネージド型のクラウドサービスです。AWS IoT Device Managementは大規模なIoTデバイスのセキュアなオンボード、管理、モニタリング、遠隔操作を実現するサービスです。 ブートストラップ証明書とは？なぜ必要なのか？ 今回は、WiFi接続が可能な歯ブラシを取り扱う”SmartTeeth”という架空な会社のユースケースについて考えていきましょう。SmartTeethは歯ブラシの生産をサードパーティに委託しています。サードパーティの生産会社は、歯ブラシがクラウドと繋がる際のデバイス証明書を歯ブラシに組み込む必要があります。ただし、SmartTeethは歯ブラシが顧客の手元に届いてから、クラウドとどのような通信を許可するか制限したいと考えています。 初期の証明書は、歯ブラシがクラウドに繋がって自分自身を登録し、必要な権限一式が付与された証明書をリクエストすることのみを許可している状況が理想的です。さらに、このプロセスが自動化されており、SmartTeethの顧客からは透過的であること、そして歯ブラシが初めて接続する時、クラウドで必要なリソースが全て作成され、初期の証明書と実用フェーズの証明書を入れ替える部分をファシリテートする形が理想的です。 以下の図は歯ブラシの購入後に初期クレデンシャルを実用フェーズのクレデンシャルに置き換えるフローを示しています。     とあるSmartTeethの顧客がブートストラップ証明書をインストールするとします。ブートストラップ証明書は、デバイスの生産段階で各デバイスに実装される一意で低レベルの権限を持つ証明書です。この証明書には、デバイスがIoT Coreに接続し、最終的な証明書を取得するための特定のMQTTトピックとやりとりをする権限のみが定義されたAWS IoTポリシーが紐づいています。 デバイスプロビジョニングワークフロー ブートストラップ証明書を利用したデバイスプロビジョニングには3つのステップが含まれます: デバイス組立 デバイス登録 デバイスアクティベーション デバイス組立 デバイス組立とはデバイス生産プロセスにおいてサプライヤーが証明書をデバイスに埋め込むタイミングを指しています。このタイミングで一意なブートストラップ証明書がデバイスに格納されます。 このアプローチでは以下の条件を満たす必要があります: CA証明書がAWS IoT Coreに登録されており、デバイス証明書の自動登録が有効化されている デバイスには登録されたCA証明書によって署名されたデバイス証明書が生産時に格納されている デバイス登録 デバイス登録とはAWS IoT Coreのモノ(thing)としてデバイスを登録することを指しています。このプロセスでは以下の項目を実施する必要があります: AWS IoT Coreでモノとブートストラップ証明書を登録する IoTポリシーを作成し、ブートストラップ証明書にアタッチする ブートストラップ証明書とモノを関連づける 実用フェーズの証明書を(inactive状態で)AWS IoT Coreでプロビジョンする モノをAWS IoT モノのグループに、またはタイプを追加する ただし、これらを実施する前に、一つ重要なステップがあります。デバイスのサプライヤーは許可されたデバイスのリストを提供する必要があります(これをホワイトリストとも呼びます)。このファイルはデバイスIDのリストのみ、または他の属性情報を含んでいても構いません： cat ./allowed-device-list.txt demo001 demo002 demo003 デバイス登録プロセスでは、許可されたデバイスのリストに照会し、そのデバイスがサプライヤーにより保証されていることを確認します。また、ブートストラップ証明書が顧客指定のCAによって署名されていることも確認します。 […]

トレーニングと推論は、機械学習 (ML) 開発サイクルの重要な要素です。トレーニングの段階で、特定の問題に対処するためのモデルを教えます。このプロセスを通じて、本番稼働で使用する準備ができたバイナリモデルファイルを入手できます。 推論については、TensorFlow Serving や Model Server for Apache MXNet (MMS) など、モデルデプロイ用のフレームワーク固有のいくつかのソリューションから選択することができます。PyTorch は、PyTorch でモデルサービングを実行するためのさまざまな方法を提供します。 このブログ記事では、MMS を使用して PyTorch モデルをサーブする方法を説明します。 MMS はオープンソースのモデルサービングフレームワークであり、大規模な推論のための深層学習モデルをサーブするように設計されています。MMS は、本番稼働での ML モデルのライフサイクルを完全に管理します。MMS は、コントロールプレーンの REST ベースの API と共に、ロギングやメトリクスの生成など、本番ホストのサービスに必要な重要な機能も提供します。 以下のセクションでは、MMS を使用して PyTorch モデルを本番環境にデプロイする方法について説明します。 MMS による PyTorch モデルのサービング MMS は、ML フレームワークに依存しないように設計されています。言い換えれば、MMS はあらゆるフレームワークのバックエンドエンジンとして機能するのに十分な柔軟性を備えています。この記事では、PyTorch で MMS を使用した、堅牢な本番稼働レベルの推論について説明します。 アーキテクチャ 次の図に示すように、MMS はモデルをモデルアーカイブの形式で使用します。 モデルアーカイブは、Amazon S3 バケットに配置することも、MMS が実行されているローカルホストに配置することもできます。モデルアーカイブには、推論を実行するためのすべてのロジックとアーティファクトが含まれています。 また、MMS では、ML フレームワークおよびその他の必要なシステムライブラリを事前にホストにインストールする必要もあります。MMS は ML […]

 AWS クラウドのデータベースやデータストアの暗号化をデフォルトで選択するお客様の数は、ますます増えています。この流れは、さまざまな規制の枠組みにおいて機密データ (個人特定可能な情報 [PII、Personally Identifiable Information] など) の意味が発展していくのにともなって、勢いを増すばかりです。最新のデータベース暗号化の中から、パフォーマンスや各製品での迅速な反復を維持したまま最適なものを選ぶ方法について教えてほしい、というお客様からの要望も AWS に寄せられています。 そこで今回の記事では、Amazon RDS MySQL、MariaDB、Amazon Aurora MySQL の各データベースエンジンで使用できる、暗号化の方法をご紹介します。この記事は、ワークロードやビジネスのニーズに最も適した暗号化の方法を見つける一助となることを目指しています。なお簡略化のため、上記のエンジンをここでは “RDS MySQL 関連” のエンジン、または “MySQL 関連” のエンジンと呼びます。 概要 RDS で利用できる暗号化の方法は、次の 3 つのカテゴリーに分けることができます。 保存時のデータの暗号化。これには、プラットフォーム全般の機能およびデータベースエンジンそれ自体の機能が含まれます。 送信中のデータの暗号化。これは、データベースとクライアント間のネットワークを移動するデータを確実に保護する方法です。 レプリケーション中に送信されるデータの暗号化。ひとつ前のカテゴリーと大きな違いはありませんが、こちらはデータベースサーバー間のデータレプリケーションのトラフィックに用いられる方法です。 次に、それぞれのカテゴリーを詳しく見ていき、ニーズに合わせて最も効果的に実装する方法をご紹介します。 保存時のデータの暗号化 RDS MySQL 関連のデータベースエンジンを使用している AWS の多くのお客様は、RDS リソースの暗号化に依存しています。RDS により暗号化されたリソースを使うと、データは保存時に、データベース (DB、Database) インスタンスの基盤となるストレージ、その自動バックアップ、リードレプリカ、スナップショットを含めて暗号化されます。この機能は、データの暗号化にオープン標準の AES-256 暗号化アルゴリズムを使用しています。このアルゴリズムはデータベースエンジンに対して透過的です。 Amazon EBS では、RDS MySQL と MariaDB 向けに、基盤となるストレージとスナップショット機能が提供されます。Aurora では、専用の、分散されたログ構造のストレージサービスが使用されています。暗号化された Aurora DB […]

大規模なデータセットに対して予測を実行するときは、実行前にいくつかの入力属性を削除することをお勧めします。これは、これらの属性が信号を伝達しない、または機械学習 (ML) モデルのトレーニングに使用するデータセットの一部ではなかったという理由からです。ジョブの完了後、予測結果をすべてまたは一部の入力データに分析用としてマッピングすることにも役立ちます。 たとえば、ID 属性を持つデータセットを考えてみましょう。一般に、観測 ID は特定の ML 問題に対する信号を伝送しないランダムに生成した番号か連続番号です。このため通常、観測 ID はトレーニングデータ属性の一部ではありません。しかし、バッチ予測を行う場合は、出力に観測 ID と予測結果の両方を 1 つのレコードとして含めることもできます。 バッチ変換機能は Amazon SageMakerで、Amazon S3 に格納されているデータセットに対して予測を実行します。以前はバッチ変換ジョブの作成前に入力データをフィルター処理し、ジョブの完了後に予測結果を目的の入力フィールドに結合する必要がありました。Amazon SageMaker のバッチ変換を使えば、予測を実行する前に属性を除外できるようになりました。CSV、テキスト、JSON 形式のデータを使用すると、予測結果を部分的または全体の入力データ属性と結合することもできます。このため、追加の前処理や後処理が不要となり、ML プロセス全体が高速化します。 この投稿では、この新しい機能を使用して Amazon SageMaker のバッチ変換ジョブの入力データをフィルター処理し、予測結果を入力データセットの属性と結合する方法を説明します。 背景 Amazon SageMaker は ML のワークフロー全体を対象にした完全マネージド型サービスです。このサービスは、データにラベルを付けてデータを準備し、アルゴリズムを選択して、モデルのトレーニングを行い、デプロイ用にモデルを調整および最適化を行い、予測を行い、実行します。 Amazon SageMaker はバッチ変換ジョブの開始時に、リソースのプロビジョニングを管理します。ジョブが完了するとリソースを解放するので、ジョブの実行中に使用したリソースに対してのみ支払うことになります。ジョブが完了すると、Amazon SageMaker は指定された S3 バケットに予測結果を保存します。 バッチ変換の例 UCI の乳がん検出のためのパブリックデータセットを使って、特定の腫瘍が悪性 (1) または良性 (0) である可能性があるかどうかを検出するバイナリ分類モデルをトレーニングします。このデータセットには各腫瘍の ID 属性が付属しています。これらはトレーニングと予測の際に除外されます。ただし、バッチ変換ジョブからの各腫瘍の悪性腫瘍について予測した確率を使用して、ID 属性を最終的なアウトプットに戻し、記録します。 手引きとなる Jupyter ノートブックもダウンロードできます。この記事の以下の各セクションはノートブックのセクションに対応していますので、読みながら各ステップのコードを実行してください。 設定 […]

Apache MXNet は ディープニューラルネットワークのトレーニングとデプロイに使用するオープンソースの深層学習ソフトウェアフレームワークです。 データサイエンティストや機械学習 (ML) の開発者の多くが深層学習モデルの構築の際、その柔軟性と効率性から MXNet を好んで使用しています。 Amazon SageMaker では MXNet を含むすべての ML フレームワークとライブラリにおいて、カスタマーエクスペリエンスの向上に取り組んでいます。MXNet 1.4 の最新リリースでは、インターネット無料モードで MXNet コンテナを使用したり、Model Server for Apache MXNet (MMS) を使った深層学習モデルを推論用にデプロイしたりできるようになりました。 Model Server for Apache MXNet (MMS) は深層学習モデルを推論用にデプロイする作業を簡素化するオープンソースのツールセットです。MMS を使用すると、MXNet やその他のフレームワークモデルを簡単に、素早く、そして大きな規模で提供できます。詳細については、「Model Server for Apache MXNet v1.0 release」をご参照ください。 MXNet 1.4 の更新には、ネットワークの分離、Julia バインディング、実験的な制御フロー演算子、JVM メモリ管理、グラフの最適化と量子化、使いやすさの向上など、いくつかの新機能が含まれています。変更ログ情報については、「Apache MXNet (incubating) 1.4.0」をご参照ください。 Amazon SageMaker のトレーニングとデプロイ済み推論コンテナは、デフォルトでインターネットに対応しています。新しい MXNet コンテナを使用すると、インターネット無料モードでコンテナを使用できます。そのため、セキュアかつ隔離された環境内でトレーニングジョブを実行できます。 Amazon SageMaker をトレーニングまたは推論コンテナへの外部ネットワークにアクセスさせたくない場合は、トレーニングジョブやモデルの作成時にネットワークの分離を有効にできます。 MXNet […]

Amazon S3 にデータレイクを構築することは、組織に無数のメリットをもたらします。多様なデータソースへのアクセスし、ユニークな関係の決定、カスタマイズされたカスタマーエクスペリエンスを提供するための AI / ML モデルの構築、消費のための新しいデータセットのキュレーションの加速などを可能にします。ただし、オンプレミスであれ AWS であれ、運用データストアから継続的に変化する更新をキャプチャしてデータレイクに読み込むと、時間がかかり管理が困難になる可能性があります。 この投稿では、Oracle、SQL Server、PostgreSQL、MySQL などの定評があるデータベースソースから進行中の変更をデータレイクに読み込むソリューションをデプロイする方法を示します。このソリューションは、新規および変更されたデータを Amazon S3 にストリーミングします。また、適切なデータレイクオブジェクトを作成および更新し、設定したスケジュールに基づいてソースに似たデータのビューを提供します。その後、AWS Glue Data Catalog は、分析サービスが使用するために、新しく更新され重複除外されたデータを公開します。 ソリューションの概要 このソリューションを 2 つの AWS CloudFormation スタックに分割します。この投稿で参照する AWS CloudFormation テンプレートは、パブリックの S3 バケットからダウンロードすることもできますし、後で紹介するリンクを使用して起動することもできます。同様に、この投稿の後半で参照されている AWS Glue ジョブもダウンロードできます。 最初のスタックには、再利用可能なコンポーネントが含まれています。一度だけそれをデプロイする必要があります。以下の AWS リソースを起動します。 AWS Glue ジョブ: 未処理の S3 ファイルから重複排除され最適化された parquet ファイルへの読み込みプロセスのワークフローを管理します。 Amazon DynamoDB テーブル: それぞれのデータレイクテーブルのデータ読み込み状態を保持します。 IAM ロール: これらのサービスを実行して、S3 にアクセスします。このロールには、昇格された権限を持つポリシーが含まれています。これらのサービスにだけこのロールを割り当て、IAM ユーザーまたはグループには割り当てないでください。 AWS […]

長期にわたって稼働する Amazon EMR クラスターを使用している開発者またはデータサイエンティストであれば、急激に変化するワークロードに直面します。これらの変化では、クラスターで最適に実行するために、異なるアプリケーションの構成をしばしば必要とします。 再構成機能を使用して、EMR クラスターを実行するときに、構成を変更することができるようになりました。EMR リリース emr-5.21.0 から、この機能を使用すると、新しいクラスターを作成せずに、または各ノードに SSH で手動で接続せずに、構成を変更できるようになりました。 この記事では、次のトピックについて取り上げます。 再構成の使用 インスタンスグループの状態、構成バージョン、イベント 再構成例の使用事例 再構成の利点 再構成の使用 以下のタスクは、EMR release emr-5.21.0 で更新されます。 再構成の提出 構成の変更 構成レベルの定義 再構成の提出 EMR コンソール、SDK、または AWS CLI を通じて認識を送信できます。詳細については、認識の送信と追加情報を参照してください。. 構成の変更 再構成を送信するときに、クラスターに適用する構成のすべてを含まなければなりません。更新のみがこれらの項目に適用され、ほかのすべてを削除します。構成を変更すると、EMR コンソールはまた前のクラスター構成も追跡します。 構成レベルの定義 アプリケーションのクラスターレベルとインスタンスグループレベルの構成を定義します。クラスターを作成するため、クラスターレベルの構成を提供します。これらの構成は、クラスターが開始し実行中となった後で追加された場合でも、その後自動的にすべてのインスタンスグループに適用されます。構成が開始した後で、クラスターレベルの構成を変更できません。しかし、再構成リクエストを通じて、インスタンスグループレベルでこれらの構成を補足またはオーバーライドできます。インスタンスグループの再構成要求を送信するたびに、これらの新しいインスタンスグループレベルの構成は継承されたクラスターレベルの構成よりも優先されます。 インスタンスグループでクラスタレベルとインスタンスグループレベルの設定がどのように連携して機能するかをよりよく理解するために、EMRコンソールで簡単なデモを見てください。 [構成] タブで、[フィルター] ドロップダウンリストのインスタンスグループを選択します。該当するインスタンスグループの構成表に移動します。構成表の [ソース] 列は、構成のレベルを示します。 このクラスターは、次のクラスターレベルの構成セットで始まります。 [ { “Classification”: “core-site”, “Properties”: { “Key-A”: “Value-1”, “Key-B”: “Value-2” } } ] […]

私たちは、州や地方の自治体、コミュニティ組織、教育機関が、ミッションクリティカルな IT システムを運用する能力に影響を及ぼす、自然災害や人為的災害への備えを改善するように支援したいです。 今日、私たちは AWS Project Resilience を立ち上げました。既存の災害対応プログラムでのこの新しい要素は、上で述べたタイプの組織に最大 2,000 USD の AWS クレジットを提供します。このプログラムは、新規および既存のお客様に開放されています。それぞれに対して次のような利点があります。 新規のお客様 – 適格な新規のお客様は、Amazon Simple Storage Service (S3) に重要なデータセットを保存するときに発生するコストを相殺するために使用できる AWS Project Resilience クレジットで、最大 2,000 USD までリクエストを送信できます。 既存のお客様 – 適格な既存のお客様は、CloudEndure と AWS Disaster Response のエキスパートが既存の事業継続性アーキテクチャを深く掘り下げるときに発生するコストを相殺するために、AWS Project Resilience クレジットで最大 2,000 USD までリクエストを送信できます。 今月初め、私は同僚の Ana Visneski と話し合い、災害対策、災害復旧、そして AWS Project Resilience について学びました。こちらがそのビデオです。 詳細やプログラムへの適用については、AWS Project Resilience のページをご覧ください。 — […]

AWS チームは常にお客様の声に耳を傾け、お客様の生産性向上のためにどのように私たちのサービスを改善すればよいかを考えています。こうした弊社のアプローチを実証するべく、OpsCenter という AWS Systems Manager の新しい機能を開発し、お客様がサービス上での問題、イベント、アラートを一体化できるようにしました。この新機能により、1 か所にアクセスすれば問題を表示、調査、修正することが可能となり、複数の異なる AWS サービス間を移動する手間を減らしました。 問題、イベント、アラートはこの新しいコンソールに操作項目 (OpsItem) として表示され、コンテキスト情報、履歴のガイダンス、迅速な解決手順を提供します。この機能では、主要な調査データを 1 か所で入手できるようにすることで、ソリューションに到達するまでの平均時間を短縮し、エンジニアの生産性を向上させることを目的としています。 OpsItem 担当エンジニアは、次のような情報にアクセスできます。 イベント、リソース、アカウントの詳細 類似の特性を持つ過去の OpsItem 関連する AWS Config の変更と関係性 AWS CloudTrail ログ Amazon CloudWatch アラーム AWS CloudFormation スタック情報 ログやメトリクスにアクセスするためのその他のクイックリンク Runbook と 推奨 Runbook の一覧 AWS サービスを通じて OpsCenter に渡される追加情報 この情報はエンジニアが運用上の問題をより迅速に調査し、修正するのに役立ちます。エンジニアは OpsCenter を使うと、Systems Manager コンソールを介してまたは Systems Manager OpsCenter API を使用して問題を表示し、対処することができるようになります。 このブログの残りの部分では、この新機能について解説します。まず最初に Systems […]

本投稿は AWS コンテナサービスのプリンシパルディベロッパーアドボケートである Massimo Re Ferreによる寄稿です クラウドのセキュリティはAWSの最優先事項であり、コンテナチームの取り組みがその証でもあります。およそ1か月前、私たちは AWS Secrets Manager や AWS Systems Manager パラメータストアと、AWS Fargate タスクの統合機能を発表しました。 これにより Fargate のお客様は、ご自身のタスク定義から秘密情報を安全に、パラメータを透過的に利用することができます。 この記事では、秘密情報を確実に保護しつつ Secrets Manager と Fargate の統合を利用する方法の例を紹介します。 概要 AWS は複数の重要なセキュリティ上の基準を以って Fargate を高度にセキュアに設計しました。その 1つは、各Fargate タスクはそれぞれに分離境界があり、下層のカーネル、CPUリソース、メモリリソース、またはElastic Network Interface（ENI）を他のタスクと共有していないところです。 セキュリティに重点を置くもう 1 つの領域は、Amazon VPC ネットワーキング統合です。これにより、ネットワーキングの観点から Amazon EC2 インスタンスを保護する手法で Fargate タスクを保護できます。 この発表は、責任共有モデルの観点でも重要です。例えば、AWSのプラットフォーム上でソリューションを構築して実行するようなDevOpsチームは、アプリケーションコードの実行時に秘密情報、パスワード、機密パラメータをセキュアに管理する適切な仕組みや機能を必要とします。そして、プラットフォームの機能によって彼ら/彼女らがまさにそのようなことを可能な限り簡単に実行できるようにすることが私たちの役割なのです。 私たちは、時に一部のユーザーがセキュリティ面をトレードオフとして俊敏性を得るために、ソースコードに AWS 認証情報を埋め込んだままパブリックリポジトリにプッシュしたり、プライベートに格納された設定ファイルに平文でパスワードを埋め込んでいるのを見てきました。私たちは、さまざまなAWSサービスを利用している開発者が IAM ロールを Fargate タスクに割り当てることができるようし、AWS 認証情報を透過的に取り扱えるようにすることで、この課題を解決しました。 これはネイティブな […]