Category: Intermediate (200)

現在、新規アカウントの作成やプロビジョニングに、AWS Control Towerをご利用になっているお客様が多く見受けられます。こういったお客様は、環境の作成に、AWS のネイティブなソリューションの使用をご希望されます。それが明文化された AWS のベストプラクティスに則っていることをご存知だからです。お客様は、作成したアカウントのスケーリングを行う際に、アカウントをさらに強化できる Control Tower の追加的な機能を利用することもできます。今回の記事では、ライフサイクルイベントの使用方法をご紹介していきます。これは、Control Tower’s Account Factory を使用して新しいアカウントを作成するなどのアクションが完了したことを追跡できるようにする、Control Tower における機能の 1 つです。今回は、このライフサイクルイベントで、自動化したワークフローをトリガーする方法についても、合わせてご紹介します。この記事では、次のようなサービスを使用しています。 AWS Control Tower AWS Service Catalog AWS CloudTrail Amazon CloudWatch Events Amazon SNS 背景 AWS Control Tower では、Well-Architected なマルチアカウントの AWS 環境構築のために、AWS Organizations、AWS IAM、AWS Config、AWS CloudTrail、および AWS Service Catalog などの AWS のサービスを複数使用します。これにより、組織単位 (OU) の中のアカウントでガードレールを有効化するなどのアクションを Control Tower が実行する際には、多くのプロセスが実行され、各サービスに対しては膨大な数の API 呼び出しが送られることになります。 […]

AWS SaaS Factory で Principal Partner Solutions Architect を務める Tod Golding による記事です。 SaaS (Software-as-a-Service) モデルへの移行は多くの企業にとって魅力的ですが、新しいマルチテナントアーキテクチャへの移行に必要な時間、労力、投資は大きな障壁となる場合があります。 多くの企業にとって、SaaS への移行には、新しいテクノロジーの習得、マルチテナント構造の実装、新しい運用ツールの作成、新しい課金体型の採用、といった作業を伴います。 こういった障壁は、SaaS への移行がビジネスを成長させ将来の成功の鍵になると考えている企業にとって、特に深刻な問題になる可能性があります。そのような企業の多くは、わざわざアプリケーションの再構築やコードの書き換えを行うことなく、そして時間やコストも奪われることなく、SaaS への移行を加速する方法を模索しています。 そういったニーズに対応するために、アマゾンウェブサービス (AWS) では、AWS SaaS Boost をリリースしました。

みなさん、こんにちは。セキュリティ ソリューション アーキテクトの中島です。先日(2020年10月23日)にオープンソースで公開した SIEM on Amazon Elasticsearch Service (Amazon ES) をご紹介します。SIEM on Amazon ES は、セキュリティインシデントを調査するためのソリューションです。AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化をすることができます。 SIEM on Amazon ES とは SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。Amazon ES は、オープンソースの Elasticsearch と Kibana を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。Amazon ES の環境に SIEM として必要な機能を実装したのが SIEM on Amazon ES です。

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 […]