Category: Networking & Content Delivery

学術情報ネットワークSINETは、国立情報学研究所(NII)が構築、運用している日本全国の大学や研究機関などの教育研究機関が接続された情報通信ネットワークです。このたび 学術情報ネットワーク (SINET) 大阪 DC 経由でのSINETクラウド接続サービスが利用可能となりました。これまでも SINET 東京 DC1 経由で複数の10Gbps 回線で接続されておりましたが、このたび協賛企業様のご協力もいただき SINET 大阪 DC 経由においても複数の 10Gbps 回線で接続されました。 今回の SINET 大阪 DC 経由の追加により、いわゆるSINET経由での SINET 利用形態として、 SINET クラウド接続サービス利用での SINET 東京1 DC 経由や SINET 大阪 DC 経由、通常の SINET-IX ピアリングでの利用の経路がそれぞれ利用可能となります。 SINET クラウド接続サービスと通常利用( IX 経由)での接続についての説明は以前ブログにてご紹介いたしました内容をご覧ください。 SINET 大阪 DC 経由の SINET クラウド接続サービスの利用についても、お客様が利用される際の負担は、これまでと同じくAWS側から見でdata outとなるデータ転送料金だけとなります。物理回線費、ポート占有にかかる費用に関してはお客様の負担なくご利用いただけます。 SINETならびにSINETクラウド接続サービス自体が基本的にベストエフォートであり、SLA等が規定されてるわけでは無い点を理解した上で、例えば東京リージョンで基幹系システムをご利用の場合、東京リージョンとの接続をSINETクラウド接続サービスのSINET東京1DC、SINET大阪DC経由の両方を利用することでSINET-AWS間を冗長化するなどが考えられます。 これまでと同様、SINETクラウド接続サービスに関しましては、国立情報学研究所のSINET担当、AWS側の両方へ申請が必要となります。AWS側の申請に関しましては　sinet@amazon.com までお問い合わせください。尚、研究でSINETクラウド接続サービスを利用されている場合には、データ転送料金を低減するプログラムに参加可能な場合がございますので営業 (aws-jpps-er@amazon.com) までお問い合わせください。 — パブリックセクター ソリューションアーキテクト […]

先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか？それとも、ある程度の規模になってから導入するべきでしょうか？ A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、当初から導入することを検討いただければと思います。一方で、規模が小さい間からマイクロサービスアーキテクチャで構築するべきか？といった観点も必要になります。最初はモノリスで開発し、ある程度の規模になって運用の中でシステムのコンテキスト境界が見えてきた段階でマイクロサービスをサービスメッシュと合わせて検討する、といった例もございます。 Q. アプリケーション間の直接通信からサービスメッシュへ移行するためのコスト・タスク量について知りたいです。 A. サービスメッシュへ移行するためのマイグレーション手段はいくつか考えられますが、Envoy を導入したアプリケーションを別途作成し、既存のアプリケーションを縮退させる方法などが考えられます。上記の作業に関して、アプリケーションの規模や通信方式によって移行コストやタスク量が異なってきますので、まず、検証環境でマイグレーションを実施し、事前にコストやタスク量を見積もるよう推奨いたします。 Q. AppMesh と Istio の互換性について教えて下さい A. App Mesh と Istio は、サービスメッシュとしてのモデルや API に互換性はありません。 Q. AWS Lambda のネットワーク通信でも App Mesh は適用可能でしょうか?それとも、もともとの Lambda の設定を見直すだけでApp Meshの機能の一部でも実現可能でしょうか? […]

“undifferentiated heavy lifting”という言葉をしばしば聞くことがあると思います。これは、競合他社との差別化にはなりえない作業にリソースを大量に消費することを言います。たとえば、サーバを構築し、OS にセキュリティパッチを適用するようなことです。このような作業は、より付加価値が高い製品やサービスを生み出すための活動から、ヒト・モノ・カネを奪い去ります。AWS では、お客様起点の重要な役割として、作業を簡素化し、自動化できるクラウドによるソリューションによって、開発者を”undifferentiated heavy lifting”から解放できるように支援しています。 金融業界では、過去20年間で大きな進歩を遂げています。たとえば、キャピタルマーケットの領域では、クラウドによるマーケットデータの活用により、トレーディングチームはリアルタイムでより良い洞察を導き出し、増え続けるデータからリスクをより効率的に計算できるようになりました。 しかしながら、いくつかの企業にとって、”undifferentiated heavy lifting”はまだ存在しています。それらの1つは、金融機関が規制機関や取引所によって設定された規制や業界ルールを遵守しなければならないことに関連しています。市場参加者は、これらの市場ルールを遵守する必要があり、遵守しない場合はペナルティを受ける場合もあります。 金融業界は、進化し続ける要件の複雑さと細分性が高まっている世界で最も規制の厳しい業界の1つです。しかし、金融機関がコンプライアンスに投資するすべてのリソースについて、多くは義務から機会への移行を行えていません。言い換えれば、ほとんどの金融機関では、同業他社との差別化を図るのではなく、ビジネスを行うためのコストとして、依然として規制やコンプライアンスを捉えています。 野球で例えるならば、プレイヤーはゲームのルールに従わなければなりませんが、優れたプレイヤーは、常に個人とチームの両方のレベルでパフォーマンスを改善するために戦略と戦術を使用しています。同様に、企業は規制要件に対応する必要がありますが、合理化、自動化、コスト効率の高い方法でそれに対応する必要があります。 このブログでは、日本取引所グループ (JPX) が AWS でどのように市場参加者にとってより良い顧客体験を生み出しているかをお話します。JPXは、これまでネットワークへのアクセスに関連していた”undifferentiated heavy lifting”を排除することで、市場参加者が新しいサービスのテスト、構築、立ち上げに向けてリソースを再利用できるようにしています。 JPXは、メンバー企業のクラウドでの市場アクセスを強化 2020年5月、JPX は市場参加者が AWS Direct Connect を介して、売買システムや清算決済システムなどにつながる高信頼ネットワークである arrownet にアクセスできるようにしました。 以前は、会員企業がarrownetに接続したい場合、JPXと自社のオフィスやデータセンター間に専用線を注文し、そのうえでネットワーク構築やセキュリティ対策を実施する必要がありました。このネットワーク構成は、変動する市場に迅速に対応するための信頼性と安定性が必要で、さらに十分な通信容量を提供する必要がありました。回線が接続されると、市場参加者は24時間365日体制で監視し、ハードウェア障害に対応するために人的リソースも投下する必要がありました。また専用線ベンダー側の監視にも、これらの重要なタスクのための人件費とサポート費も付属しています。つまり、arrownetへの接続は、利用者が長年にわたって対応してきた”undifferentiated heavy lifting”とも言えます。 JPXは、市場参加者からフィードバックを取り入れ、arrownetをクラウドに拡大し、市場参加者のアクセスを簡素化しました。市場投入までの時間が短縮され、マーケットからのデータを AWS 環境で扱うことで、マーケットの変動に対してオンデマンドで拡張できるようになります。 JPX は AWS Direct Connect の仮想インターフェイスを提供します。これにより、会員企業は短い期間でarrownetに接続して、テストすることができます。その結果、AWS の利用者は、以前は専用回線接続で直面していた”undifferentiated heavy lifting”な作業をすることなく、クラウド環境でマーケットからのデータを受け取ることができます。 現在の会員企業がこの合理化されたマーケットアクセスの恩恵を受けるだけでなく、FinTech スタートアップも恩恵を受けることができます。多くの Fintech スタートアップは AWS のサービスを使用しているため、彼らの既存の環境をより効果的に活用するには、クラウドネイティブ接続が必要でした。マーケットへの迅速なアクセスができるようになったFintech スタートアップは、新製品やサービスの市場投入までの時間をさらに短縮することができるでしょう。 現在、AWS Direct Connect により、JPX […]

Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転送できるようになります。ヘッダー、Cookie、およびクエリ文字列パラメータの任意の組み合わせを設定して、キャッシュキーとして考慮するよう含めたり、除外したり、必要に応じて転送したりできます。 基本的な設定の柔軟性の向上に加えて、これらのオプションは “ポリシー” を使用して設定されるようになりました。ポリシーでは、同様の設定の組み合わせを任意の数のディストリビューションに適用できます。これによりセットアップ時間が短縮され、複雑さが軽減されてチームは全体の設定にわたって一貫性を管理できます。

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。

Amazon CloudFront は、キャッシュ機能によるオリジンサーバー（CloudFront がコンテンツを取得する元のウェブサーバー）の負荷軽減とコンテンツ配信のパフォーマンス向上を実現できますが、可用性の向上もCloudFrontを活用することで得られる大きなメリットの1つです。CloudFront を利用する対象のウェブサイトのオリジンサーバーがAWS 上に存在する場合、オリジンサーバー側でもELB の活用や複数のアベイラビリティーゾーンの活用など可用性向上の為の様々なアプローチがありますが、CloudFront を利用することで更に高い可用性をウェブサイトにもたらすことが出来ます。 ウェブサイトの可用性を向上することは、ウェブサイトの応答速度の向上と同様にウェブサイトを運営する上で非常に重要な要素です。ウェブサイトの停止は、E コマースサイトでは売り上げに直接影響を及ぼしますし、コーポレートサイトや製品を扱うウェブサイトではブランドイメージや製品そのもののイメージ低下につながりかねません。 ウェブサイトの可用性に影響を及ぼす原因は様々なものがあります。例えば予期せぬハードウェア故障やネットワークの障害が原因となり、ウェブサイトが停止するリスクがあります。全てのコンポーネントを完全に冗長化することでリスクを軽減することが出来ますが、一般的なオンプレミス環境では冗長化の箇所が増える度にコストが大幅に増加する可能性があります。またウェブサイトオーナーは様々なキャンペーンなどの施策により、ウェブサイトのアクセス数の向上を目指しますが、予測を上回るアクセス増により、ウェブサーバーやネットワークが高負荷状態となりウェブサイトが停止するリスクがあります。 さらに外部からのDDoS 攻撃が原因となり、ウェブサイトの可用性に影響を及ぼすリスクがあります。攻撃者は複数のリソース (マルウェアに感染したコンピュータ、ルーター、IoT デバイスなどのエンドポイントで構成される分散グループ) を利用して、ターゲットのウェブサイトへの攻撃を実行します。攻撃者は侵害されたホストで構成されたネットワーク等を利用することにより、大量のパケットやリクエストを生成してターゲットのウェブサイトに過剰な負荷をかけます。たとえ正規のユーザーを想定したサイジングがきちんと出来ていても、悪意のあるトラフィックによる影響で、サーバーやネットワークのキャパシティが埋め尽くされ、ウェブサイトが停止してしまうリスクがあります。 今回はこのような予期せぬ障害やDDoS 攻撃による影響を回避し、ウェブサイトの可用性向上に役立つCloudFront の機能をまとめてご紹介致します。

AWS Transit Gateway (TGW)は徹底的に進化することにより、クラウドネットワーキングを簡素化しました。本記事では、複数Amazon Virtual Private Cloud(VPC)とオンプレミスの接続パターンを紹介します。 AWSでは、オンプレミスのネットワークとの接続にはAWS Direct Connect(DX)を使います。DX接続は様々な形態がありますが、日本のお客様に多い“共有型”DX接続ではTGWを直接使うことができません。TGWを使うことができることが“専有型”DX接続の優位点の一つですが、本記事では”共有型”DX接続でTGWを使った接続実現する方法を含めて、いくつかの接続パターンを解説します。 TGWのメリット TGWを使用すれば、一貫した信頼性の高いネットワークパフォーマンス を実現しながら、複数のVPCおよびDXを使ってオンプレミスネットワークを相互接続するのはお手の物です。TGWは各VPC、VPN、DXの間のすべてのトラッフィクを一箇所で制御することができます。 専有型が利用できる場合にはTGWとDXをつなぐと、AWSを経由してインターネット接続することもできます。 上の例では、TGWがAWS Direct Connect Gateway(DXGW)にアタッチされています。 DXの複数VPCでの利用は典型的なユースケースです。一方で、DXは1Gbps以上の接続につきTGWのためのトランジット仮想インターフェースは１つだけという制限があります。つまり、日本のお客様に多い、“共有型”DX接続ではTGWを直接使うことができません。 ここでは、複数VPCとオンプレミスの接続パターンを以下４つに整理してみます。1つ目だけが、“専有型または1Gbps以上のホスト型接続”のみ実現可能です。 TGWにDXをつける DX用のVPCにNetwork Load Balancer(NLB)を配置。VPC間はTGW 通信方向に合わせてエンドポイントサービス（NLBとインターフェイスエンドポイントのペア）を配置 DXGWにVPCをつける 1. TGWにDXをつける この場合、すべてのトラフィックはTGWで管理できます。AWSを経由したインターネット接続もProxyなしで実現できます。また、全トラフィックを”監査用アプライアンス”に通すことで全トラフィックの記録 / 制限 / 監査も可能ですので、セキュリティ面でも有利です。 2. DX用のVPCにNLBを配置。VPC間はTGW DXにつながるVPCとして“DX用VPC”1つが現れました。このとき、DXからみれば1つの”DX用VPC”がつながるだけですので、”共有型”でも問題ありません。VPC間の通信はTGWで設定制御ができます。 オンプレミス↔VPC間で通信をしなければならない特定のサーバのフロントにはDX用VPCにNLBを設置することで通信できるようにします。サーバの数だけNLBを設定するため、サーバ数が増えるとNLBの時間あたり費用がかさむことに注意してください。 3. 通信方向に合わせてエンドポイントサービス（NLBとインターフェイスエンドポイントのペア）を配置 このパターンでは、PrivateLinkが重要です。マイクロサービスなど、VPCを自由にいくつも使っている場合には、IPアドレスブロックが重複することはよくあることです。2つ目のパターンでは、TGWをつかってVPC間の通信を制御していました。TGWではアドレス重複の答えにはなりません。PrivateLinkはその解決策です。 VPC間およびオンプレミスとの特定の通信はPrivateLinkで設定します。VPCからオンプレミス上のサーバにアクセスするためにも使うことができます。 4. DXGWにVPCをつけたとき VPCとオンプレミスの間の通信はあるけれども、VPC同士の通信が無いのであれば、TGWは実は必要なかったのかもしれません。なお、一つのDXGWに接続できるVPCは10までですので、スケーラビリティにもやや難があるかもしれません。VPCの数が10以上になった場合、2つめの共有型Private VIFを利用する事により、多くのVPCと接続することができます。ただし、共有型VIFを増やし続けると、”1.”でご紹介した専有型接続の方が結果的に安価となる分岐点に到達します。詳細な見積もりが必要な場合は、利用するパートナー様にご確認ください。 比較 比較の一覧を追加しておきます。料金試算は、東京リージョンで、3つのサービス用VPCと1つのオンプレミスのネットワークを接続し、サービスするVPCひとつあたり月間10TB通信があり、DXのIn/Outの比率が1:1の場合です。（詳細は最後に） 案1: TGWにDXをつけたとき 案2: DX用のVPCにNLBを配置。VPC間はTGW 案3: 通信方向に合わせてエンドポイントサービス（NLBとインターフェイスエンドポイントのペア）を配置 案4: DXGWにVPCをつけたとき […]

 このゲスト投稿では、AWS アカウントや Amazon Virtual Private Cloud (Amazon VPC) の枠を越えて AWS PrivateLink を使用して、Amazon Managed Streaming for Apache Kafka にアクセスする方法をご紹介します。さらに、ゴールドマンサックスのトランザクションバンキングチーム (TxB) がクロスアカウントへのアクセスに選んだ方法、その選択の理由、TxB が Amazon MSK でセキュリティ要件を満たす方法についても解説します。この投稿はゴールドマンサックスの実装をユースケースとして使用し、Amazon MSK 環境の実装時における一般的なガイダンスを目的としています。 概要 Amazon MSK は、Apache Kafka を使ってストリーミングデータを処理するアプリケーションを、簡単に構築および実行できるようにする完全マネージドサービスです。MSK クラスターを作成すると、同じ Amazon VPC 内の参加者がクラスターリソースを利用できます。このため、VPC の特定のサブネット内でクラスターを起動し、クラスターをセキュリティグループに関連付け、Elastic Network Interface (ENI) を介して VPC のアドレススペースから IP アドレスを添付できます。クライアントとクラスター間のネットワークトラフィックは AWS ネットワーク内に留まり、デフォルトではクラスターへのインターネットアクセスはできません。 同じまたは異なる AWS アカウント内の別の VPC にある MSK クラスターへのクライアントアクセスを許可する必要がある場合があります。VPC […]

金融機関の皆様においては、社会を取り巻く状況の急変に伴い、お客様及び従業員の皆様を保護しつつサービスレベルや業務効率を維持されるためのさまざまな対策を講じられていることと存じます。そして金融庁からも4月13日に「出勤者7割削減」の要請が周知され、テレワーク環境の構築は、金融業界全体としても喫緊の課題として認識されているものと思います。 欧米各国においては、金融機関の事業継続に向けて、AWS のサービスを活用したテレワーク対応を進めて頂いている事例があります。例えば、ある大手金融機関では、在宅オペレーター数を数百人から数千人に拡張したり、また、別の金融機関では、FAQ におけるチャットボットの活用を促進しています。また、従業員及びその顧客を対象に数千席規模の仮想デスクトップ環境を提供することで業務の継続を図っているケースもあります。 日本でも多くの金融機関のお客様から、テレワークのソリューションに関する問合せ・ご相談を頂いています。既に日本の金融機関でも、AWS  のテレワークを支援するサービスを活用して、数週間でコンタクトセンターのオペレーターの在宅勤務環境を構築したり、仮想デスクトップ端末を短期間で数千台規模に拡大させて社員のテレワーク対応に取組んでいる事例が出てきています。 AWS では、お客様のテレワークを支援するサービスとして、在宅コンタクトセンターの迅速な構築をご支援するフルクラウド型のコンタクトセンター Amazon Connect、社内システムへのリモート環境からのアクセスを実現する仮想デスクトップソリューション　Amazon WorkSpaces、フルマネージド型のコンテンツコラボレーションサービス　Amazon WorkDocs、リモートでのコミュニケーションやコラボレーションを支援する Amazon Chime、スケーラブルなリモートネットワークアクセスを可能とする AWS Client VPN などを提供しています。　いずれの AWS サービスも、クラウドならではの俊敏性と拡張性を備えており、今回のように急遽テレワーク環境構築が必要とされているケースにご活用いただけるものです。そして、AWSでは、クラウドのセキュリティが最優先事項です。AWSは、高いセキュリティ及びコンプライアンス要件を持つ金融機関のお客様に、テレワークを支援するサービスを安心してご利用いただけるよう、アーキテクチャーの設計をご支援します。 本 Blog では、AWS のテレワークを支援するサービスの中でも、お客様からの問い合わせが多い Amazon Connect と Amazon WorkSpaces について概要をご紹介したいと思います。また、これらのサービスの詳細をご紹介するオンラインセミナーを5月22日に開催する予定です。こちらも是非お申込み頂ければと思います。

AWS for Industries 本投稿はアマゾンウェブサービス (AWS) のグローバル金融領域の市場開発を担当するマネージングディレクターの Scott Mullins による寄稿を翻訳したものです。 「ディスラプション」。 これは、金融業界でよく耳にする言葉です。確立された規範、マーケットリーダー、あるいは製品に取って代わる可能性のある、新しい市場やバリューネットワークを生み出すイノベーションについて述べる際によく使われます。今世界が直面している前代未聞の健康上の難題は、世界経済そして世界中の人々に、上記とは異なる種類のディスラプション（混乱）をもたらしています。これは、今ある金融サービスの提供方法に直接影響し、将来的には金融業界の仕組みや利用者とのやり取りの形を変えていくことになるでしょう。 COVID-19 は、金融機関や利用者の通常のビジネスのやり方を根底から覆し、両者それぞれが対処すべき独自の懸念事項や要求を抱えることとなりました。事業の存続可能性を判断したり、財務的なコミットメントを達成する能力を維持したりする上で、スピードが非常に重要視されているときには、金融サービスの利用者は資本に到達できるかどうかに注目しています。金融機関は、安全性、セキュリティ、回復力、拡張性、および業務の継続的な健全性を重視しています。金融規制当局は、経済の回復を重視し、資金を必要とする企業が資金調達できるようにし、国内および世界の金融システムの安定性の確保に務めています。技術的な観点では、これらの懸念や要求の高まりは金融システムの負担に変換されていきます。この病気は、レガシーなアプリケーションやインフラストラクチャーが利用者と主にデジタルでやり取りを行う体制へ即座に移行する能力、そして世界市場が直面している異常な取引量と変動の凄まじさへも対応する能力を持ち合わせているかどうかを試しています。 AWS は世界中の金融機関、政府、規制当局と協力して、COVID-19 がもたらす世界経済の課題への取組みを支援しています。リモートワークの実現、ミッションクリティカルなアプリケーションの業務回復力の維持、桁外れの取引量を捌くための世界規模の市場システムの拡張性、充実した機能で使いやすい顧客体験を提供するデジタルでの関わり方の実現、費用対効果を改善するためのアプリケーションおよび環境の最適化など、世界経済を動かしている人々やシステムが継続して動き続けられるよう、AWS は金融サービスのお客様と協働しながら取り組んでいます。本投稿では、私たちがお客様と共に積極的に取り組んでいるいくつかの主要な取組みをご紹介します。（実現できることやどのように AWS が支援できるかといった点に焦点を当てるため、具体的な金融機関名にはあえて言及しておりません。）主要な取組みには以下のようなものがあります： 金融サービスを動かしている人々が働き続けられるようにする COVID-19 が世界中の人々に影響を与えている状況下で、日々の生産性への影響を最小限に抑え、従業員の健康と安全を確保するため、金融機関は業務手順をすばやく変更し、リモートワークに切り替えました。パンデミックが継続するにつれて、企業は従業員が場所を問わず安全に働くための選択肢をさらに検討し始めています。場所を問わず働けるようサポートする方法、世界中にいる従業員間のコラボレーションを促進する方法、状況に応じて変更できる接続ポイントを管理する方法、あるいは災害発生時にビジネスの継続性を確保する方法といった信頼できるリモートワークソリューションを金融機関は求めています。AWS は、従業員、契約社員、学生、そしてコンタクトセンターの従業員がリモートワークをすばやく行えるよう、一連のソリューションを構築し、提供しています。 例えば、Amazon WorkSpaces はマネージド型のセキュアな Desktop-as-a-Service (DaaS) ソリューションで、外勤および在宅勤務の従業員が必要なアプリケーションへのアクセスを支援します。Amazon WorkSpaces を使用すると、外勤者はインターネット接続が可能であればいつでもどこからでもサポートされているデバイスを使用して、自身で選択した応答速度が速いデスクトップ環境を手にすることができます。金融機関は、デスクトップアプリケーションおよび外勤者に対するセキュリティとデータ統制の要件を満たす必要があります。エンドユーザーデバイスは、非常に重要なデータが攻撃、損失、または盗難に晒されるといったリスクがある接続ポイントになりうるという課題をもたらします。AWS では、お客様は接続ポイントを一元管理することで、セキュリティを向上させ、コンプライアンスを維持できます。この対策のために、オンプレミスソリューションで発生するような費用や複雑さはありません。COVID-19 への対応策として、あるグローバル投資管理会社のお客様は、数千人のユーザーに対し在宅勤務ソリューションを 1 週間以内に展開しました。セキュリティを最優先としながら、このお客様は従業員 1 人あたり複数の Amazon WorkSpace を提供しました。 Amazon Connect を使うと、完全に機能するコンタクトセンターをわずか数分で立ち上げ、事実上どこからでも運用できます。エージェント、スーパーバイザー (SV)、マネージャー、管理者は自宅で働きながら、通常の業務をすべて実行できます。エージェントは受電・架電を行えます。SV は、同じオフィスにいるかのように、エージェントをリアルタイムでモニタリングし、コーチングすることができます。管理者は、ダッシュボードの表示、レポートの作成、サービスレベルの監視、通話履歴の聴き取り、パフォーマンスの追跡といった作業をすべて自宅で行うことができます。ある欧州のグローバルなシステム上重要な銀行 (G-SIB) は、COVID-19 へ対処するために迅速に Amazon Connect を展開し、サービスを中断することなく、エージェントが自宅から銀行の顧客をサポートできるようにしました。 AWS Client VPN は、数千人のリモートユーザーをサポートするように伸縮自在にスケール可能な、完全マネージド型の従量制 […]