Amazon Web Services ブログ

Category: Technical How-to

フリートプロビジョニングを用いて、IoTデバイスとAWS IoT Coreの初期セットアップを自動化する方法

お客様は AWS IoT を使用してIoTデバイスによって生成されたデータを分析し、ビジネスに関する有意義な洞察をすばやく得ることができます。これにより、製造プロセスに必要な改善点の特定、デバイス障害の予測、デバイス問題の迅速な診断とトラブルシューティングなど、さまざまな問題を解決するのに役立ちます。ただし、 IoT デバイスがクラウドに接続して有用な作業を行う前に、デバイスをプロビジョニングする必要があります。 IoT デバイスのプロビジョニングとは、 AWS IoT およびその他のクラウドベースのアプリケーションをセキュアに接続するために、デバイスのユニークな ID ( X.509 証明書や秘密鍵など)を作成し、これらの ID を AWS IoT エンドポイントに登録し、必要なアクセス許可( IoT ポリシーなど)を関連付けるプロセスを指します。 今日、多くのお客様は、Just-In-Time-Registration( JITR )やJust-In-Time-Provisioning( JITP )などの AWS IoT Core 機能を使用して、デバイスアイデンティティをAWSクラウドに登録し、必要な権限を関連付けるプロセスを自動化し、かつスケーリングしています。ただし、一意の ID を安全に生成してデバイスに書き込むことは、依然としてお客様の責任です。多くの方にとって、特に多数のデバイスを製造している OEM ベンダーにとって、このプロセスは依然として手作業で時間のかかる作業です。 新たに追加された AWS IoT Core のフリートプロビジョニングの機能を使用すると、エンドツーエンドのデバイスオンボードのプロセスを安全に自動化できます。さらに、キー属性をデバイスから送信し、 AWS Lambda 関数で検証して整合性を高めることができます。 フリートプロビジョニングは、一意のデジタル ID を各デバイスに安全に配信し、 Lambda 関数を介してデバイスのペイロードを検証し、 ID を顧客の AWS アカウントに登録し、必要なすべてのアクセス許可とレジストリメタデータ(モノ、モノのグループなど)をデバイスに設定します。これはすべて、デバイスが AWS IoT Core […]

Read More

Amazon FSx for Lustre による高パフォーマンスワークロード用の永続的ストレージ

 高パフォーマンスなファイルシステムは、しばしばスクラッチファイルシステムと永続的ファイルシステムの 2 種類に分類されます。スクラッチファイルシステムとは、一時的な高性能のストレージを提供するためのものです。その性能は、1 ミリ秒未満のレイテンシーで、スループットは最大で毎秒数百ギガバイト、そして短時間のワークロード用に数百万の IOPS を実現します。対照的に、永続的ファイルシステムでは、スクラッチファイルシステムに備わったパフォーマンスレベルに、より長期にわたるデータ処理で必要となる耐久性と可用性を組み合わせるよう設計されています。AWS は、re:Invent 2018 において、世界でも最もよく使用されている高パフォーマンスファイルシステムである Lustre をベースとしたスクラッチファイルシステム Amazon FSx for Lustre (FSx for Lustre) を発表しました。最近リリースした FSx for Lustre の永続的ファイルシステムデプロイオプションでは、可用性と耐久性およびパフォーマンスが高く、POSIX 互換のファイルシステムの、AWS による完全マネージド型でのデプロイを可能にしています。 これによりお客様は、ワークロードの要件に基づき、永続的ファイルシステムまたはスクラッチファイルシステムを柔軟に選択できるようになります。 今回のブログでは、この FSx for Lustre の永続的ファイルシステムデプロイオプションについて一通り説明し、一般的なユースケースを示すと共に、当社が推奨するいくつかのベストプラクティスもご紹介していきます。さらに、FSx for Lustre の永続的ファイルシステムを新規で作成し、マウントも行ってみます。 FSx for Lustre での永続的ファイルシステム FSx for Lustre の永続的ファイルシステムは、実行時間が長め、もしくは永続的なワークロードに対し、高可用性で耐久性のあるストレージを提供します。スクラッチファイルシステム上のデータは複製が行われないため、ファイルシステムが使用するファイルサーバーに障害が発生した場合は保持されません。一方、永続的ファイルシステムにある高可用性のファイルサーバーでは、そのデータは同じアベイラビリティゾーン内で自動的に複製されます。 永続的ファイルシステムのファイルサーバーが使用不能になると、その障害から数分以内に自動的な置き換えが実行されます。この時間中は、サーバー上のデータに対するクライアントからのリクエストは透過的に再試行され、最終的にファイルサーバーの置き換えが完了した時点でそちらに継承されます。永続的ファイルシステムのデータはディスク上で複製が作られているので、障害が起きたディスクはすべて自動的かつ透過的に置き換えられます。 Amazon FSx for Lustre の永続的ファイルシステムが適した用途とは? 耐久性と可用性が高いストレージが要求される処理が重いワークロードに対しては、永続的ファイルシステムの使用を検討します。 次に、FSx for Lustre の永続的ファイルシステムにおいて、最も一般的なユースケースのいくつかを示します。 SAS Grid: […]

Read More

AWS CLI を使用した既存の Amazon S3 オブジェクトの暗号化

 業界のプロトコル、政府の規制、組織内部のセキュリティ標準が変化する中、保存データの暗号化がますます必要とされています。暗号化は、不正アクセスやその他のセキュリティリスクから保存データを保護するためのものです。 Amazon S3 のデフォルトの暗号化を使用しても、バケット内の新しいオブジェクトを自動で暗号化できます。しかし、デフォルトの暗号化では、同じバケット内の既存のオブジェクトの暗号は変更されません。暗号化が必要な既存のオブジェクトが Amazon S3 バケットにある場合や、使用しているサーバー側の暗号化 (SSE) 設定を変更したい場合があります。S3 バケット内の既存のオブジェクトを暗号化する最も簡単な方法について、お客様から質問されることがよくあります。 この投稿では、コピーオブジェクト API を使用する際に考慮すべき重要事項について説明します。次に、AWS コマンドラインインターフェイス (AWS CLI) を使用して、データを安全に保つためにバケット内の既存のオブジェクトを暗号化する例をご紹介します。さらに、プレフィックスまたはバケット内のすべての S3 オブジェクトを暗号化する例も示します。最後に、コピーと暗号化に関する一般的な質問について回答します。 前提条件 この投稿で説明しているコマンドを実行するには、次のものが必要です。 AWS アカウント 少なくとも 1 つの Amazon S3 バケット AWS CLI 知っておくべきこと 重要なことから先に言っておきます。慎重に作業を進めてください。 SSE を使って既存のオブジェクトを暗号化するため、オブジェクトを置き換えます。既存のオブジェクトを適切に暗号化するには、コピーオブジェクトまたはコピーパート API を使用できます。これで、同じ名前のオブジェクトをコピーし、サーバー側で暗号化することでオブジェクトデータを暗号化します。コピーオブジェクト API を使用する前に、次の点を考慮してください。 LastModified タイムスタンプは、コピーのタイムスタンプに変更されます。オブジェクトのタイムスタンプに依存するアプリケーションは、元のアップロードのタイムスタンプではなく、コピーのタイムスタンプを参照するようになりました。たとえば、S3 ライフサイクルは新しいオブジェクトの日付を使用します。 S3 イベント通知は PUT または COPY イベントで有効にでき、既存のオブジェクトをコピーして暗号化するとトリガーされます。たとえば、Lambda 関数がもう一度トリガーされることがあります。 S3 クロスリージョンレプリケーション (CRR) は、オブジェクトの新しいバージョンをレプリケーションします。 次のいずれかを使用している場合、メタデータのレプリケーションの利用を検討してください。 […]

Read More

AWS Snowball Edge と Amazon EC2 を使用して Linux エッジコンピューティングソリューションを構築する

 データソースの近くでデータ推論を実行しなければならない状況は数多くあります。多くの場合、これらはリモートであり、接続がない場所で生じます。次の例を考えてみましょう。 リモートの石油掘削プラットフォームには、データを生成する多数のセンサーがあります。重要なコンポーネントについては、摩耗や破損、または故障がないか監視する必要があり、交換は先を見越して行う必要があります。 土壌の水分、湿度、PH 値を監視するさまざまなセンサーを備えた農場では、推論を使用して、健康と成長を最大化できる適切なタイミングで水と栄養素を供給する必要があります。 接続がない前線基地に軍隊が配備されるときには、供給と物流を自動化しなければなりません。 自動運転車両は毎日大量のデータを生成します。これらは、一元化された場所で毎日、オフロードされ、タグが付けられ、異常に対応するために前処理される必要があります。 現代の工場の組立ラインでは、部品を効率的に移動し、その配送を最適化する必要があります。 コンサート会場では、制作会社は複数のカメラからの映像を集約し、異なるフォーマットに変換する必要があります。 これらすべてのシナリオでは、データソースの近くでコンピューティング、ストレージ、ネットワークを実行することを要します。これらの問題は、実行のために構築されたデータセンタースペースを必要としない高耐久性デバイスである AWS Snowball Edge デバイスを使用して解決できます。Amazon S3、Amazon EC2、Amazon EBS、AWS IoT Greengrass などのクラウドネイティブなサービスや、データを取り込むために Network File System (NFS) インターフェイスを実行できます。 このブログ投稿では、AWS Snowball Edge デバイスを使用した Linux ベースのエッジコンピューティングソリューションを開始する方法について説明します。特に、Snowball Edge Compute Optimized デバイスに焦点を当てています。 注文プロセス Snowball Edge デバイスでコンピューティングインスタンスを使用するには、ジョブを作成し、AMI を指定します。AWS Snowball マネジメントコンソールから、AWS コマンドラインインターフェイス (AWS CLI) で、またはいずれかの AWS SDK を使用して、これを行うことができます。通常、ジョブを作成する前に実行する必要があるいくつかの前提条件があります。 AWS マネジメントコンソールにログインし、文書化された手順を使用して Amazon マシンイメージ (AMI) を作成し、それを […]

Read More

Okta を使用した Amazon Connect のシングルサインオン設定

IT リソースへのアクセスを保護することは非常に重要です。従業員が使用するウェブベースのアプリケーションの数が増えるにつれて、ログイン認証情報を記憶しておくことは困難になります。多くの企業では、リソースへのアクセスを合理化し、従業員のルーチンを簡素化するために、さまざまな ID プロバイダーによるシングルサインオンを採用しています。Amazon Connectは、SAML 2.0準拠のIDプロバイダーを使用したコンタクトセンターへの認証を提供可能です。このBlogでは、OktaをAmazon ConnectのIDプロバイダーとして使用するために必要な手順についてご説明します。 Oktaは、SAML 2.0認証を使用したSingle Single-Onサービスとして、最も一般的に使用されているプロバイダーの1つです。Oktaのセットアップ方法は他のSAML プロバイダーの設定とほとんど同じですが、本投稿ではOktaを使用するためのステップを具体的にご説明します。これは、一般的なガイダンスであるAmazon ConnectでのID管理用にSAMLを設定するを簡略化したものになっています。

Read More

AWS IoT Core を用いた認可ポリシーのスケーリング

はじめに IoTソリューションを構築するソリューションアーキテクト、開発者、およびシステム設計者は、ソリューション全体において、データとデータを操作する機能を適切に保護する必要があります。この投稿では、 AWS IoT Core を使用したマルチユーザーおよびマルチデバイスのユースケースに焦点を当て、認可ポリシーのスケーリングのためのいくつかの設計手法について説明します。デバイス、ユーザー間のカーディナリティやスケールのレベルに応じたパターンを紹介します。 AWS IoT サービス上にソリューションを構築する際のセキュリティ設計やアーキテクチャ検討時に活用頂ければと思います。 IoT デバイス、ネットワークパス、エンドユーザーデバイス、データベース、バックエンドシステムなど、データのやり取りが発生するあらゆるコンポーネントにおいてセキュリティ対策が必要です。IT セキュリティにおいて、セキュアなアーキテクチャを検討する際には、「AAA」と言われる3つのAを考慮する必要があります。 それぞれ、 Authentication (認証)、 Autorization (認可)、 Accounting (アカウンティング)または Auditing (監査)です。 AAA は、セキュリティ要件を整理し、それらの要件とソリューションアーキテクチャを対応付ける方法です。この方法により、ソリューションの利害関係者、エンドユーザー、およびコンプライアンスの専門家は、関連する重要な要件を満たすために、どのようにソリューションが設計されているかを把握することができます。 IoT ソリューションは、固有の設計要素をもつ分散システムアーキテクチャを意味します。分散システムアーキテクチャでは、補完的な分散セキュリティソリューションが必要になります。多くのお客様は、クラウド内の分散システムや、クラウドとオンプレミスのエンタープライズシステムを統合するハイブリッドアーキテクチャの ID (認証)機能を実現するために、 ID フェデレーション( ID 連携)を使用しています。この手法は IoT のデータと機能の保護にも利用できます。 AWS ID フェデレーションオプションの詳細については、 ID フェデレーションの記事をご覧ください。 ID の強固なソリューションを導入すれば、2番目の「A」である認可の要件への対応に集中できます。 IoT ソリューションの開発者が直面する一般的な認可のユースケースに焦点を当てます。一般的に、ユーザー、デバイス間の構成は 1:1 、もしくは 1:多となることが多いため、以降ではそれらのケースについて例をご紹介します。 単純なユースケース: 1 ユーザー 1 デバイス(1:1) 1 ユーザーが 1 つのデバイスを利用するケースは、最も理解しやすく、 IoT […]

Read More

オンラインの方法を使用して、Amazon DocumentDB に移行する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 MongoDB から Amazon DocumentDB に移行するには、オフライン、オンライン、ハイブリッドの 3 つの主なアプローチがあります。詳細については、Amazon DocumentDB への移行を参照してください。 この投稿では、オンラインアプローチを使用して、オンプレミス、あるいは EC2 にホストされた自己管理型の MongoDB クラスターを Amazon DocumentDB に移行する方法について説明します。オンラインのアプローチがダウンタイムを最小限に抑えます。これは、DMS が移行元の MongoDB の oplog から継続的に読み込み、ソース の Amazon DocumentDB クラスターにほぼリアルタイムでそれらの変更を適用するからです。オンラインの方法のデモについては、Video: Live migration to Amazon DocumentDBをご覧ください。 ダウンタイムを最小限に抑え、ソースデータセットが小さい (1 TB 未満) 場合は、オンライン方法が最適です。データセットが 1 TB より大きい場合は、ハイブリッドまたはオフラインのアプローチを使用して、mongorestore […]

Read More

Amazon EKS ワーカーノードの謎を解くクラスターネットワーク

AWS で Kubernetes を実行するには、AWS のネットワーク設定と Kubernetes のネットワーク要件の両方を理解する必要があります。デフォルトの Amazon Elastic Kubernetes Service (Amazon EKS) の AWS CloudFormation テンプレートを使用して、Amazon Virtual Private Cloud (Amazon VPC) と Amazon EC2 ワーカーノードをデプロイすると、通常の場合、すべて機能します。しかし、設定に小さな問題があると、エラーが発生してイライラさせられることがあります。 このブログでは、Amazon VPC を設定するさまざまな方法を見ながら、Amazon EKS が管理する Kubernetes クラスターの EC2 ワーカーノードを実行します。ノードがクラスターコントロールプレーンに接続できるようにサブネットが適切に設定されていることを確認する方法について、特に注目します。 このブログでは、VPC CNI、サブネットのサイズ設定、ポッドの IP アドレス割り当てなどのポッドネットワーキングの概念については取り上げません。これらのトピックの詳細については、EKS ドキュメントをご覧ください。 注 – VPC とノードの Cloudformation テンプレート、および EK が管理するノードグループがパブリック IP アドレスをノードに割り当てる方法を変更しています。詳しくは ブログをご覧ください。 EKS クラスターのアーキテクチャ EKS クラスターは […]

Read More