Category: Intermediate (200)

AWS Configルールの使用により、リソースの構成をベストプラクティスに照らし合せて評価し、決められた構成ポリシーに従っていない場合は修正することができます。 AWS Config適合パックを使用すると、AWS Organizations全体に適用されるAWS Configルールと修復アクションのセットを単一のパックで作成できます。これにより、Configルールの集中管理と展開が可能になります。 今までは、組織全体にまたがる適合パックとConfigルールの展開は、組織のマスターアカウントのみが実施できました。しかし、マスターアカウントを一括請求にのみ使用するお客様も多数おられます。お客様がセキュリティ、監査、コンプライアンスのための専用アカウントを持っている場合、代わりにその専用アカウントを使って組織全体にわたるConfigの展開を管理したいと考えるでしょう。このようなご要望にお応えして、AWS Organizationsの非マスターアカウントからConfigルールと適合パックのデプロイができるようになりました。このAWS Config新機能を使用すると、これらのConfigリソースをAWS Organizations全体に展開し管理できる権限を委任する管理者アカウントを登録できます。 このブログ投稿では、委任された管理者アカウントにて、組織全体に適合パックを展開し、AWS Configルールと適合パックを管理する方法について示します。

あらゆる種類や規模の公益事業やエネルギー供給会社の幹部は、エネルギー使用量を予測するというニーズを複数抱えています。たとえば最高顧客責任者として、あなたのチームは家庭レベルのエネルギー使用量を予測して、そのご家庭に高額請求の可能性があると警告を送ったり、前払いや月末のエネルギー料金を予測したりすることができます。エネルギー効率化および商業エネルギープログラムの責任者として、あなたのチームはさまざまなエネルギー効率化施策を適用した際にどれくらいエネルギー消費を抑えられるのかを予測したり、最適な施策をおすすめしたりすることができます。

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。

産業用IoT（IIoT）は、産業用機器やオートメーションネットワーク（通常はOT、オペレーションズテクノロジーと呼ばれる）と情報技術（IT）の間のギャップを埋めるものです。ITでは、機械学習、クラウド、モバイル、エッジコンピューティングなどの新技術の利用が一般的になりつつあります。IIoTは、機械、クラウドコンピューティング、分析、人を結びつけ、産業プロセスのパフォーマンス、生産性、効率性を向上させます。これにより、顧客は品質予測とメンテナンスのためにIIoTアプリケーションを利用したり、どこからでも操作を遠隔監視することができます。 しかし、IIoTの価値を実現することは容易ではなく、下記のような製造業の方々を妨げる3つの要素があります。 データの収集頻度が低すぎる データにアクセスするのが難しい 個々に収集したデータをつなぎ合わせることができない この投稿では、産業企業が品質予測を使用して機器設定の調整をしたり様々な原材料を調整したり、さらには追加の労働者へのトレーニングなどを行うことによって工場の生産品質を向上していく方法について探っていきます。 AWS IoT サービスを活用することで、鉱業、エネルギー・公益事業、製造業、精密農業、石油・ガスなど、さまざまな業種の産業企業は、運用データに基づいて推論を行い、パフォーマンス、生産性、効率性を向上させることができます。 業界の現状と課題 鉱業、エネルギー、製造業、農業、石油・ガス、またはその他の産業市場セグメントのいずれであっても、過去10年、20年、あるいは30年に渡って、十分に機能してきたレガシー機器を持っています。多くの産業企業は、産業用 PC（IPC）、プログラマブルロジックコントローラ（PLC）、またはリアルタイム分散制御ネットワーク（fieldbuses）を接続した大規模分散制御システム（DCS）、および監視制御・データ収集（SCADA）システムなどの運用技術に多額の投資を行ってきました。これらの運用は、数十年続くように設計、導入され深く定着しており、置き換えることは非常に困難です。 次の図は、ISA-95 産業用エッジアーキテクチャと上記の要素がどのように関連しているかを示しています。 図1 – ISA 95モデルによる自動化ピラミッド（出典：researchgate.net） IoTや機械学習、コンピュータビジョンのような新しい技術の恩恵を受けようとすると、IoTアプリケーション用に設計されていない既存の機器やシステムを適応させなければなりません。 あらゆるIIoTアプリケーションの最初の課題は、様々な製造現場の様々なデバイス（センサー、アクチュエーター、電気モーター）からデータを収集するためにレガシー機器を接続することです。多くの場合、異なる産業プロトコルを接続したり、装置を新たに追加することで新しいテクノロジーを古いシステムに追加し、測定やリモートコントロール、接続を行なっていきます。 ２番目に、そして最も重要な課題は接続性と一緒に考える必要があるセキュリティです。デバイスとそのデータの安全性を確保しなければなりません。生産環境で機器やシステムに障害が発生すると、コストのかかるダウンタイムが発生し、ビジネスに影響が出る可能性があります。産業用の接続デバイスがクラウド接続されていない場合でも、最高のパフォーマンスで動作するようにしなければなりません。データ収集プロセスは、デバイスの操作を妨害してはならず、遠隔操作や更新操作は、許可されたオペレーターのみから安全な方法で行われるようにしなければなりません。 データの安全性を確保したら、洞察力を得るための３番目の課題がやってきます。データは工場の異なる「フロア」（ISA-95 アーキテクチャの異なるレベル）に固定されます。すべての生データから洞察を得るためには、これらのデータが異なるデバイスや製造現場、時系列、フィールドバス、システム、またはデータベースからのものであるかどうかに関わらず、データを接続することが重要です。 どのように動作するか AWS IoTは、企業がビジネス目標を達成するための課題を克服するのに役立ちます。 まず、AWS IoTを利用することで、小型のマイクロコントローラからより強力なゲートウェイデバイスまで、あらゆるタイプのデバイスを簡単に接続、管理、更新できます。既存のハードウェアをオーバーホールしたり交換したりすることなく、シンプルなセンサーを導入してプロセスを監視したり、主要なパフォーマンス指標を追跡したりすることで、プログラマブルロジックコントローラ（PLC）や監視制御・データ収集（SCADA）システムなど、製造現場にある既存のレガシー機器を統合できます。 ２番目に、AWS IoTには組み込みのデバイス認証と認証機能を提供して、IoTデータとデバイスを保護し続けます。また、デバイスに関連するセキュリティポリシーを継続的に監査したり、デバイスの異常な動作を監視したり、何かおかしいと思ったらアラートを受信したりすることができます。また、デバイスの電源を切ったり、セキュリティ修正プログラムを適用するなどの是正措置を取ることもできます。 ３番目に、AWS IoTは、接続されたデバイスが断続的なインターネット接続で動作できるようにし、予期しないダウンタイムのリスクを軽減します。インターネット接続が可能になるまでも、機械学習モデルやソフトウェアコードを実行したり、データをローカルに保存したりすることができます。 AWS IoTは「プラグアンドプレイ」機能を提供しているため、IoTアプリケーションを数千から数百万台のデバイスに拡張することができます。AWS IoTを利用することで、デバイスのインベントリの整理、デバイスの監視、デバイスソフトウェアのOTA（Over-the-Air）アップデートを含む様々な場所でのデバイスのリモート管理が可能になります。 次の図では、様々なAWS IoTサービスがどのように連携してIIoTを実現しているかを示しています。 図2 – AWS IoT産業用リファレンスアーキテクチャ デバイスが安全に設置されると、AWS IoTはIoTデータの分析を簡単に実行できます。AWS IoTは、IoTデータの収集、処理、分析を迅速かつ簡単に行うことができるため、運用に関する洞察を得ることができます。AWS IoTはAmazon SageMakerと統合されているため、産業用IoTデータに対して機械学習モデルを構築でき、これらの機械学習モデルは、クラウド上で実行したり、デバイスのローカルにデプロイできます。Amazon QuickSightを利用することで、データを可視化して探索し、チーム間で洞察を共有できます。 次のセクションでは、さまざまなAWS IoTサービスが最も重要な産業用ユースケースをサポートするためにどのように価値を提供するかについて詳しく説明します。 アセットの状態監視 予知保全 品質予測 産業用ユースケースとアーキテクチャのウォークスルー アセットの状態監視 アセットの状態監視では、機械や設備の状態を取得することで、現場や工場のアセットがどのように機能しているかを把握することができます。一般的に、温度、振動、エラーコードなどのデータは、機器の使用状況が最適かどうかを示しますが、技術者が機械を物理的に検査する必要があるため、手動で取得することは困難です。AWS […]

開発者がアプリケーションを開発・パッケージング・デプロイするための強力な手法として、コンテナ技術はその代表的な1つに挙げられます。そしてそのようなコンテナ技術における様々なユースケースをサポートすべく、AWSではAmazon Elastic Container Service (Amazon ECS) に代表される多様なサービスを提供しています。
面白法人カヤック の技術部／インフラエンジニアである 藤原 俊一郎 氏にゲスト投稿いただき、Amazon ECS をはじめとした各AWSサービスをビルディングブロックとして組み合わせて利用していく上での課題と、その解決策の実例を紹介します。

本投稿は Connect Specialist SA の Sayed Hassan による寄稿を翻訳したものです。 コンタクトセンターでは、発信者が特定のエージェント（担当者）に直接かけられるよう、各エージェントに内線番号を割り当てることが一般的に行われています（訳注：米国の場合）。これにより、各エージェントに 直通電話番号（ダイヤルイン） を割り当てる必要性が低減されます。応答可能なエージェントに顧客がランダムに割り当てられるのではなく、希望するエージェントと直接話したいアカウント管理シナリオでは、顧客がエージェントに直接かけられるようにするのが一般的です。本投稿では、このようなビジネス上のユースケースを解決するために、Amazon Connect を使った内線番号ベースのダイヤリングの仕組みを見ていきます。 内線番号ベースのダイヤルソリューションを構築するには、Amazon Connect、AWS Identity and Access Management (IAM) ロール、Amazon DynamoDB テーブル、AWS Lambda 関数を含む AWS サービスを使用します。 概要 このソリューションを構築するには、次のステップを実行します。 1.   内線番号とエージェントID間のマッピングを保持する DynamoDB テーブルを作成します。 2.   Lambda 関数が DynamoDB 内のエージェント ID を参照できる IAM ロールを作成します。 3.   実際の検索用の Lambda 関数を作成します。 4.   Amazon Connect に Lambda 関数を追加します。 5.   Lambda 関数を実行する問い合わせフローを作成します。 前提条件 このソリューションを構築するには、Amazon Connect インスタンスをプロビジョニングし、エージェントを作成する必要があります。詳細については、Amazon […]

AWS は、AWS クラウドで実行する Payment Card Industry (PCI) Data Security Standard (DSS) のワークロードの適用範囲を適切に定義するためのガイドとして、PCI DSS スコーピングおよび AWS 上でのセグメンテーションのためのアーキテクチャの設計の日本語版のホワイトペーパーを公開しました。このホワイトペーパーは、クラウドネイティブの AWS サービスを利用するスコープ内のリソースとスコープ外のリソース間のセグメンテーションの境界を定義する方法について説明しています。 このホワイトペーパーの対象読者は技術者とソリューション開発者ですが、認定審査機関 (Qualified Security Assessors、QSA) および認定内部監査人(Internal Security Assessors、ISA) が AWS の製品とサービスで使用できる様々なセグメンテーション制御およびそれに関連するスコープ設定の考慮事項に関する理解を深めるガイドとしても利用できます。 AWS のソフトウェアで定義されたネットワークでは、ネットワークのセグメンテーションを超えた追加のセグメンテーション制御が可能なので、アプリケーションのスコープ設定プロセスがオンプレミス環境の場合と異なります。アプリケーションの設計およびセキュリティに影響するサービスの選択を慎重に考慮して必要な制御を実装すれば、カード会員データ環境 (Cardholder Data Environment、CDE) のシステム数とサービス数を減らせます。 このホワイトペーパーは PCI 協議会の Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation に基づいています。 Avik Mukherjee Avik は IT ガバナンス、セキュリティ、リスク、コンプライアンスの分野で 10 […]

 データのソースが増えると、新しく接続されたデータを保存する必要性が高まります。企業のお客様は、オンプレミス Hadoop アプリケーションのデータレイクストレージリポジトリとして Hadoop 分散ファイルシステム (HDFS) を使用しています。お客様は、より安全で、スケーラブルで、アジャイルで、費用対効果の高いソリューションを求めて、データレイクを AWS に移行しています。 AWS への高速転送速度が妥当ではない HDFS 移行には、AWS は AWS Snowball Edge サービスを提供しています。AWS Snowball Edge を使用した HDFS 移行のベストプラクティスは、ファイル転送に中間ステージングマシンを使用することです。このブログ記事では、移行中に中間ステージングマシンを使用する方法を詳しく説明します。 AWS Snowball Edge がお客様に出荷するのは、物理的なデータ移行およびエッジコンピューティングデバイスです (図 1)。デバイスは大量のデータを Amazon Simple Storage Service (Amazon S3) に転送するために使用します。 Amazon S3 は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。バルク取り込みの場合、データレイクのエントリポイントが Amazon S3 です。99.999999999％ (9 が 11 個) の耐久性を持つオブジェクトストアである Amazon S3 は、10,000 データレイク以上をホストします。 AWS のデータレイクストレージの基盤として、Amazon S3 […]

Amazon Elastic File System (EFS) を他の AWS のサービスで使用するベストプラクティスや統合について過去に投稿したところすばらしいフィードバックが寄せられており、さらなる投稿へのご要望をいただいています。そこで今回は、Amazon EFS ファイルシステムを EC2 インスタンス起動ウィザードから直接 EC2 インスタンスにマウントする流れを単純化、自動化する方法についてご説明します。ぜひ、先月の EFS を用いた Amazon Sagemaker でのモデルトレーニングの加速と単純化や Amazon Elastic Container Service (ECS)、Elastic Kubernetes Service (EKS) でのコンテナストレージ用 EFS 使用方法に関するベストプラクティスと併せて、皆様の EFS クックブックに加えていただけたらと思います。 Amazon EFS は、AWS クラウドサービスとオンプレミスリソースで使用するための Linux ベースのワークロードに対し、単純でスケーラブルかつ伸縮自在な NFS ファイルシステムを、わずか 0.08 USD/GB-月* の実効料金で提供します。EFS ファイルシステムのマウントとファイルデータの共有は何千という数の EC2 インスタンスで行うことができます。このたび、EC2 インスタンス起動ウィザードを使い、Amazon EC2 インスタンスを構成して Amazon EFS ファイルシステムをマウント可能になりました。これにより、EC2 インスタンスを構成し、起動時に推奨されるマウントオプションで EFS ファイルシステムをマウントするプロセスが単純になります。ここからは、EC2 […]