Category: Intermediate (200)

開発者がアプリケーションを開発・パッケージング・デプロイするための強力な手法として、コンテナ技術はその代表的な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 […]