Amazon Web Services ブログ

 AWS re:Invent 2019 で AWS Wavelength を発表しました。簡単にまとめると、当社は複数の 5G 通信プロバイダーと提携して、AWS のハードウェアとソフトウェアをデータセンターに組み込んでいます。目標は、デベロッパーが 1 桁のミリ秒のレイテンシーのメリットを享受できるアプリケーションを構築して提供できるようにすることです。 発表以来、私たちはパートナーや幅広いパイロット顧客 (企業、スタートアップ、アプリデベロッパー) と協力してきました。パートナーもお客様も、Wavelength がもたらす可能性にワクワクする一方で、AWS と EC2 について持っているほとんどの知識がまだ活かせることを知って興奮しています。 Wavelength Zone がオープン 最初の 2 つの Wavelength Zone がオープンしました。1 つはボストンに、もう 1 つはサンフランシスコにあります。Wavelength Zone は、これらの大都市圏で Verizon Wireless の顧客にサービスを提供するアプリを構築したいデベロッパーの要望に応じてアクセスできるようになりました。 初期段階では、デベロッパーは、ゲーム、メディア処理、e コマース、ソーシャルメディア、医用画像分析、機械学習推論アプリに注力することが期待されています。最も説得力があり、関連性が高いユースケースはまだ発見されておらず、この分野には革新的思考を持ち込む余地が大いにあるのではないかと思われます。 Wavelength Zone の使用 先に述べたように、AWS と EC2 についてのすべての知識がまだ活かせます。Wavelength Zone にアクセスすると、最初の EC2 インスタンスを数分で起動できます。この短い [サインアップフォーム] に記入することで、オンボーディングプロセスを開始できます。準備を整えられるようにこちらで最善を尽くします。 各 WZ は、親リージョンと呼ばれる特定の […]

先日(2020/7/28)開催しましたオンラインセミナー
「 RDS+Lambda が始まる。過去のアンチパターンはどう変わるのか」
の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

内閣官房と総務省より「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」（以下、『報告書』）が発行されました（令和２年８月５日付）。   今回の『報告書』は、内閣官房IT総合戦略室・総務省行政管理局の２府省により構成される「政府共通プラットフォームの構築・活用推進及び政府におけるクラウドサービス利用検討」プロジェクトチーム、クラウド利用戦略・企画担当の皆様より、作成・取りまとめをいただいた報告書となります。　後述の引用部分の記載のとおり、今回の『報告書』は、第一号の政府重点プロジェクトに指定された政府共通プラットフォームにおける「クラウドサービス調達」に関して、２府省共同で組成されたプロジェクトチームが調達方法（契約内容を含む）を検討し、実際の調達手続を行った”事例紹介”として執筆されています。 なお、『報告書』中で複数回「AWS」への言及がありますが、その理由に関しましては、 ”＞「第二期政府共通プラットフォームの設計・開発等業務の請負」の調達においては、採用するクラウドサービス事業者を問わず、一般競争入札・総合評価落札方式により審査及び入札を実施し、平成31年3月に設計開発事業者が決定した。その際、Amazon Web Services（以下、「AWS」という。）を前提とした提案が採用されたことから、本プラットフォームについてAWS前提での設計開発を開始することとなった（p.2）” ──旨、『報告書』において説明いただいております。 ２万字近い『報告書』のなかでは、これまで政府調達・公共調達において、クラウドサービスを調達する際に直面しがちだった幾つかの典型的な課題に関し、先進的な整理が試みられており、いくつもの有益な提言が含まれています。 今回のブログでは、AWSジャパン・パブリックセクターより『報告書』の概要と、読み取られるべきインパクトについて解説します。 調達の背景と、事例紹介の『報告書』 今回の『報告書』の冒頭では、報告書作成の「背景」が記載されています（「１．背景等」）。クラウドに期待されるメリット、政府情報システムにとってのクラウドの重要性、そして調達・契約に至る検討の経緯が仔細に記載されており、少々長文となりますが重要な導入部分であるため、以下に引用します（着色強調は、ブログ筆者。他の引用箇所も同様）。 　”近年、急速に進化し発展したクラウドサービスは、正しい選択を行えば、コスト削減に加えて、情報システムの迅速な整備、柔軟なリソースの増減、自動化された運用による高度な信頼性、災害対策、テレワーク環境の実現等に寄与する可能性が大きく、政府情報システムにおいても、クラウドサービスを利用することで様々な課題が解決されることが期待される。 　このことから、現在、多方面にわたり、クラウドサービスの利用が増加してきている状況において、政府情報システムにおけるクラウドサービスの利用に係る基本方針[脚注1]が決定され、クラウド・バイ・デフォルトの原則を具体化し、各府省が、クラウドサービスを採用し、かつ、クラウドサービスを効果的に利用するための基本的な考え方が示されたところである。また、政府情報システムにおける予算要求から執行までの一元的なプロジェクト管理[脚注2]において、政府情報システムの一元的な管理体制の構築により、クラウドサービスの経費の合理化やサービスレベルの向上を実現するため、内閣官房IT総合戦略室が各府省を牽引してクラウド化を強力に推し進めるとともに、政府全体を代表してクラウドサービス事業者（以下「CSP」という。）と交渉し、政府が本来有する巨大な調達主体としてのバイイング・パワーを発揮してスケールメリットを確保することが不可欠とされたところである。 　本報告は、この一元的プロジェクト管理の第一号として政府重点プロジェクトに指定された政府共通プラットフォーム（以下「政府共通PF」という。）における第二期政府共通PFのクラウドサービス調達に関して、「政府共通プラットフォームの構築・活用推進及び政府におけるクラウドサービス利用検討」プロジェクトチームのクラウド利用戦略・企画担当（以下「PFPJ」という。）が調達方法（契約内容を含む）を検討し、総務省において実際の調達手続を行った事例として紹介するものである。 [脚注1] ｢政府情報システムにおけるクラウドサービスの利用に係る基本方針｣（2018年（平成30年）6月7日各府省情報化統括責任者（CIO）連絡会議決定） [脚注2] ｢政府情報システムの予算要求から執行の各段階における一元的なプロジェクト管理の強化について｣（令和元年6月4日デジタル・ガバメント閣僚会議） ❖「クラウド × 政府調達」の各論点に指針を提示 以下、AWSの理解による今回の『報告書』の要点・ハイライトをご紹介させていただきます。 ❖再掲：『報告書』の要点（『報告書』本体へのリンクはこちら）   要点①：クラウドサービスの「分離調達」を実施 『報告書』では、「＞クラウドサービスの調達では、システムの設計開発とクラウドサービスをセットで調達する場合やシステムの設計開発と分離して、クラウドサービスの提供をメインとして調達する場合などが考えられる」との２パターンを理論的に想定しています。　従来の公共調達においては、圧倒的に前者、つまりはシステムの設計開発とクラウドサービスとを”セット”で調達する「一括調達」が圧倒的に多く観察される調達形態でした。 しかしながら、今回の「＞政府共通PFにおいては、後者の分離したクラウドサービスの提供とこれに関連したアカウント管理のための役務提供を含む調達」の方式が選定され、調達が実施されています。（「システムの設計開発」を担う事業者等は、後続の別個の調達単位にて選定される立て付けとなっています。） 要点②：随意契約ではなく「一般競争契約」を選定 政府調達においては「競争性」をどのように担保するか、つまりは、一般競争契約を行うか／随意契約を行うか──の判断分岐が生じます。 今回の調達においては、「＞クラウドサービスの調達方法に関して、国内外様々なCSPが提供しており、現行の会計法令からすれば、原則、一般競争契約による調達を検討することが望まし」いものと整理され、調達が実施されました。 要点③：最低価格ではなく「総合評価」方式で調達 『報告書』において詳述されているとおり、政府調達においては「落札方式については、最低価格落札方式か総合評価落札方式かを検討する必要がある」とされています（＊登場する調達・会計法令関連の用語に関しても『報告書』本体に詳細な脚注が付されているので、ご参照ください）。 今回の調達では、「＞クラウドサービスの安全性やサービス・レベル・アグリーメント（以下「SLA」という。）等に関する要求要件を調達仕様に明記する場合や役務提供などの複合的な要素がある場合は、クラウドサービスの内容、種類等から総合的に判断する必要があるため、総合評価落札方式によることが適当」と整理をし、「最低価格落札方式」ではなく、「総合評価落札方式」を選定した旨、経緯が記載されています。 要点④：直接契約ではなく「間接契約」を締結 一般の商流を考えた場合、大きく分けて「＞クラウドサービスの契約方法については、CSPと直接契約する場合と中間事業者を介して、クラウドサービスの提供を受ける間接契約」の２パターンが想定されます（『報告書』では、これらの中間に位置するような契約形態に関しても言及があります点、ご留意ください）。 今回の『報告書』では、直接契約・間接契約のメリットをそれぞれ比較考慮したうえで、「＞支払業務について国内の中間事業者を活用することで、サービス毎の支払を取りまとめ、従来どおりの請求書をベースにして支払ができるため、直接契約に比べ支払業務を円滑に行えるメリットが発揮されるケースがある」と整理し、間接契約を締結するに至った経緯が説明されています。なお、将来的に「直接契約」を選択する場合の論点に関しても『報告書』では記載されており、CSPとしても直接・間接契約のどちらをもお選びいただける商流スキームを提供しております。 要点⑤：CSPと中間事業者に課す「サービス提供条件」を分離 従来の公共調達では、プライムとして提案する応札企業が、提供する役務に関して主たる責任を専一的に負う慣行、およびそれを求める契約書上の記載が続いてきました。しかし、One to Many、多くの顧客に均一なサービス利用条件を提供するビジネスモデルに基づくCSPにとって、個別の調達案件ごとにカスタムされた利用条件・契約条件を提示することは至難の業であり、政府調達と言えども「責任共有モデル」の境界を踏み越え、役務受託に伴う責任を調達者側はCSPに求めるべきではありませんし、CSP側もそうした責任の受任を確約することができません。では、公共調達において調達者側が求めたい”責任”と、CSP側が負い切れる”責任”とのギャップを、どのように埋めることができるでしょうか？今回の『報告書』では、要点④で述べた「中間事業者」に対して求める”責任”とのコンビネーションにおいて、このギャップを乗り越える工夫が行われ、応札者にとっての参入機会の拡大も図られた旨、記載されています。 ”当該クラウドサービスの利用に関する約款等に基づき、契約の相手方である中間事業者の負うべき責任の範囲等についてあらかじめ承諾を受けることを求める旨の追加的な条項を設定した。この条項は、本来クラウドサービスの利用者がCSPの約款等に基づき、利用に関する条件等を容認した上で利用するものであるが、国の契約においては、中間事業者が契約の相手方となる場合、委託先となる中間事業者が、すべての責任を負うことで、量的にも質的にも負いきれない筋違いの責任を求められる可能性があると判断し、結果として入札不調を招く恐れがあることからこのような条項を設定した。 　 　 例えば、国の契約の場合、一般的には損害賠償請求の上限など示されていないことが多いが、CSPが提供するサービスの約款等において一定の上限が決められている場合、中間事業者が、契約の相手先である国に対して、すべての責任を負うことになるため、中間事業者が負うクラウドサービス提供における責任範囲等に関して、契約段階で発注者側に承諾を得ることで調達に参加する中間事業者の不安を解消し、参入機会の拡大にも繋がるものと考えられる ”。 上記の発想を踏まえ、今回の『報告書』では、”＞CSPと中間事業者それぞれの役割分担に照らして責務や安全性の水準を「クラウドサービスの条件」及び「請負者のサービス提供条件」とに分割し調達仕様書上で求め”る工夫を行った旨、調達の経緯が説明されています。 要点⑥：従量課金を「単価契約」で実現 クラウドの特徴でありメリットの一つとして挙げられることの多い「従量課金」。従来の公共調達においては、固定額で契約を取り結ぶ「総価契約（固定価額での契約）」が支配的な契約類型であり、「従量課金」、ひいてはクラウドとの相性が悪いのでは？────との疑問が提起されてきました。 今回の『報告書』では、「＞国の契約においては、総額をもって契約する総価契約が原則であるが、特例として、契約上の数量が確定できないものについて、単価を契約の主目的とし、期間を定めてその供給を受けた実績数量を乗じて得た金額の代価を支払うことができる契約形態として、単価契約が認められている」との解釈をベースとし、クラウド採用に伴う“従量課金”への対応を、総価契約でも概算契約でもなく、「単価契約」で実現しています。具体的な入札時の応札価格の試算の手法等に関しては、『報告書』本体をぜひご覧ください。 要点⑦：利用サービスの種類を限定せず、随時の追加が可能と整理 政府予算からの支出が行われる以上、予算要求時点での精確な利用サービスの「種類」、その「ボリューム」が積算根拠として明記されることが、日本の公共調達では長らく求められてきました。『報告書』においても、上記の原則に関し、「＞単価契約も総価契約と同様に、歳出予算の制限を前提とすることから、単価のほか契約期間に対応したクラウドサービスの利用量を予定しておくことが必要であり、調達時には歳出予算の範囲内でクラウドサービスの契約ができるようにする必要がある」と、上記の原則を踏襲する整理を行っています。 他方で、今回の『報告書』ではもう一歩踏み込み、以下のような記載をもって、利用するクラウドサービスの追加が調達実施の時点以降も可能となる整理を行うことで、各利用機関にとって提供される柔軟性・迅速性が大幅に高まっています。（強調は、ブログ筆者） ”ただし、クラウドサービスの調達を単価契約とする場合は、クラウドサービスの種類を調達仕様書に明記できることやサービス毎に単価が、契約書の内訳として明記できることが重要となるため、契約期間中に単価が変動した場合や新たなサービスが追加される場合は、原則として、変更契約が必要となる。しかし、利用開始前に迅速に変更契約することは現実的には困難であり、サービスの継続的な提供に大きな影響が発生する。そのため、単価が公表されていることや利用量が確認できること等の条件を満たし、請求金額を検証できることを前提とするが、契約変更に係る事務負担軽減のため、例えば、契約書において、変更契約の条件に「単価変動やサービス追加の際は、契約時と同等の割引率や割増率を適用するものとする。」などと明記し、毎回変更契約せずに効率的に契約事務を行う工夫も考えられる。今般、政府共通PFでは、このような方法により、クラウドサービスの価格変動や追加サービスに柔軟に対応した契約方法として単価契約を採用した。” 要点⑧：複数年契約のメリットを認識しつつも「単年度契約」を実施 […]

1 年と少し前に、私は LearnGeek の創業者兼プリンシパルである JD Dillon と一緒に人材開発 (Learning and Development: L&D) カンファレンスのエキスポホールでチャットボット、予測学習管理システム、ゲーム化されたコースのデモを見学していました。各ベンダーがそれぞれの人工知能 (Artificial Intelligence: AI) ソリューションを「未来の働き方」を推進する「AI 対応」と宣伝するにつけ、 AI という売り文句の滑稽さにジョークを飛ばし、決してまだ万能ではない現在の AIに対する認識が間違ってひとり歩きするさまを笑いものにしていました。 ただしそれでも、AI が職場学習における次の重要な話題になってきていることまでは否定しませんでした。AI がビジネスにもたらした影響を考えれば、驚くまでもないことです。IDC の予測ではエンタープライズアプリケーションの 75% が 2021 年までに AI を使用し、自動認識および AI 関連の支出は 522 億ドルに増加するとされています。最近 JD と私は L&D 分野における AI 活用の議論を進めることを目的として「人工知能で進化する人材開発」と題した共同プレゼンテーションを行いました。今こそ L&D が多岐にわたる AI の可能性や実務の発展に求められる具体的なステップを模索し、それによって AI 活用を段階的に推し進める時です。   AI とは 機械がある課題を解決する一連の規定されたルール (アルゴリズム) に基づいてタスクを実行するとき、この「インテリジェントな」一連の動作を AI と呼びます。ほとんどのエキスパートは AI の現在と未来を説明する際の便宜上、 […]

Amazon QuickSight は最近、埋め込みオーサリング、マルチテナンシーの名前空間、カスタムユーザーアクセス許可、アカウントレベルのカスタマイズという 4 つの新機能を導入しました。Enterprise Edition で利用できる既存の ダッシュボード埋め込み 機能および API 機能と併用することにより、高度なダッシュボード機能と分析機能を SaaS アプリケーションに統合できるようになりました。これらのアプリケーションを構築する開発者や独立系ソフトウェアベンダー (ISV) は、組み込みの事前設定済み(予め用意された)ダッシュボードをすべてのエンドユーザーに提供できるようになり、高度なアドホック探索機能やダッシュボード構築機能もユーザーに提供できるようになりました。 本記事では、架空の ISV のユースケースとして、QuickSight を使うことで、インフラストラクチャのデプロイまたは管理を行うことなく、アプリケーションに簡単に分析を組み込み、数十万人のユーザーにスケールする方法を説明します。

先日 (2020/07/22) 開催しました AWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用 from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS Single Sign-On (SSO) のアクセス権限セットですが、IAM ロールやグループ、ポリシーとは独立したものという認識で正しいですか？AWS Single Sign-On (SSO) の管理者がメンテする必要があるのかと思っています。 A. はい。アクセス権限セットは AWS Organizations マスターアカウントの IAM ロールやグループ、ポリシーとは独立したものになります。AWS Single Sign-On (SSO) の管理画面を通じて管理者が設定したアクセス権限セットに基づいて、メンバーアカウントのロールやポリシーが構成されます。 Q. AWS Organizations のマスターアカウントではなくメンバーアカウントで AWS Single Sign-On […]

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

この記事でお知らせしたとおり、Amazon Macie で以前からご利用いただいていた Amazon Simple Storage Service (S3) アクティビティのための異常および脅威検知が Amazon GuardDuty の一部として強化され、コストも 80% 以上削減されました。これにより、GuardDuty の脅威検出の範囲がワークロードと AWS アカウントの枠を越えて拡大され、S3 に保存されるデータの保護にも役立つようになります。 この新しい機能は、通常とは異なる地理的場所から来るリクエスト、S3 ブロックパブリックアクセスなどの予防的な制御の無効化、または誤設定されたバケットアクセス許可を発見する試みと一致する API コールパターンなどの疑わしいアクティビティを検知するために、GuardDuty が S3 のデータアクセスイベント (通常データプレーンオペレーションと呼ばれます) と S3 設定 (コントロールプレーン API) のモニタリングとプロファイリングを継続的に行うことを可能にします。悪意があると思われる動作を検知するため、GuardDuty は異常検知、機械学習、および絶えず更新される脅威インテリジェンスの組み合わせを使用します。ご参考までに、GuardDuty S3 脅威検知の完全なリストをご覧ください。 脅威が検知されると、GuardDuty がコンソールと Amazon EventBridge に詳細なセキュリティ結果を生成します。これは、アラートをすぐに利用できるようにするとともに、アラートの既存イベント管理およびワークフローシステムへの統合、またはアラートによる AWS Lambda を使用した自動化された是正アクションのトリガーを容易にします。オプションとして、複数のリージョンからの結果を集約する、およびサードパーティーのセキュリティ分析ツールと統合するために、結果を S3 バケットに送信することもできます。 まだ GuardDuty をお使いではない場合は、サービスを有効にするときに S3 保護がデフォルトでオンになります。GuardDuty をお使いの場合は、GuardDuty コンソールで 1 回クリックする、または API […]

AWSに興味をお持ちのみなさん、こんにちは。ソリューションアーキテクトの小林です。 ついに梅雨も明け8月に入りました。素麺がおいしい時期がやってきましたね。毎年書いている気がしますが私は素麺が好きなので、この時期は素麺をヘビーローテーションすることになります。例年は「我が家の定番」的なめんつゆをカスタマイズすることにこっていたのですが、今年は趣向を変えてめんつゆ自体にこだわってみようと思います。同僚に聞いて見たりwebで調べたりするのですが、本当にたくさんの種類があり良さそうなものを選び出すのも一苦労ですね。めんつゆはそれなりの量で買うしか無いので、1食分だけ試すことが出来ないのが悩みです。めんつゆ試食セミナーとか、めんつゆトライアルセットとかがあれば良いなぁと思いながら、今日も素麺を茹でることでしょう。 それでは、先週の主なアップデートについて振り返っていきましょう。

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