Amazon Web Services ブログ

Amazon Transcribe Medical を使用して COVID-19 関連用語の音声テキストの精度を向上させる

世界中がパンデミックの進行具合に合わせて対応しているため、COVID-19 に関連する情報に正確にアクセスし、その情報を利用して分析することは、これまで以上に重要になりました。医療危機に関するトピックは、ニュースレポート、ソーシャルメディア、ビジネス会議、ラジオとポッドキャスト、カスタマーサポートコール、特に臨床医と患者の会話などのさまざまなチャネルを通じて、私生活や仕事におけるさまざまな側面に浸透しています。より多くのデータ分析アプリケーションビルダーが求める医療用音声認識機能では、COVID-19 用語を含む動画と音声をダウンストリーム分析用のテキストに効率的かつ正確に文字起こしすることができます。この記事は、Amazon Transcribe Medical でカスタム語彙を使用して COVID-19 用語をよりよく認識する方法を示しています。 Amazon Transcribe Medical は、音声テキスト変換機能をアプリケーションに追加することを容易にする完全マネージド型の音声認識サービス (ASR) です。深層学習を利用したこのサービスは、すぐに使用できる医療用音声認識モデルを提供しています。このモデルを医療およびライフサイエンスドメインのさまざまな音声アプリケーションに統合できます。これで、カスタム語彙機能を使用して、薬の名前、製品ブランド、医療処置、病気など、より具体的な医療用語を正確に文字起こしできます。文字起こしをしたい用語を入力して、各用語を対応する発音と表示フォームに関連付けることができます。カスタム語彙は、Amazon Transcribe Medical が利用可能なすべての AWS リージョンでご利用いただけます。 COVID-19 固有用語の文字起こし バッチ (非同期) 文字起こし API とストリーミング (同期) 文字起こし API はどちらもカスタム語彙をサポートしています。この記事では、前者を使用してカスタム語彙のメリットをお見せします。 この使用例では、Amazon Simple Storage Service (Amazon S3) バケットに保存されたオーディオファイル (covid-19.wav) を使用します。Amazon S3 の使用については、Amazon Simple Storage Service の使用開始を参照してください。以下は、音声ファイルの文字起こしです。 「COVID-19 としても知られている 2019 年度コロナウイルス病は、重症急性呼吸器症候群コロナウイルス 2 によって引き起こされる感染症です。略して SARS-CoV-2 です。この病気は、2019 年 12 […]

Read More

Amazon AI サービスを使用して Veeva Vault PromoMats に保存されているアセットを分析してタグ付けする

Veeva Systems は、グローバルなライフサイエンス業界向けのクラウドベースソフトウェアのプロバイダーであり、臨床、規制、品質など、複数の領域に対応する製品を提供しています。Veeva の Vault Platform は、単一のプラットフォームでコンテンツとデータの両方を管理します。これにより、コンテンツ、データ、およびワークフローを使用してエンドツーエンドのプロセスを管理する強力なアプリケーションをデプロイできます。Vault Platform は、ビジネスアプリケーションの迅速な設定と変更によるカスタマイズのほか、他のシステムとのシームレスな統合により、Veeva Vault 機能を拡張し、データを移行し、または処理を自動化することを可能にする、オープンアーキテクチャと包括的な API を提供します。 商業空間におけるそのような製品の 1 つが Veeva Vault PromoMats です。165 を超える国の 400 を超えるライフサイエンス企業が、Veeva Vault PromoMats で商用コンテンツとデジタルアセット管理を行っています。 Veeva Vault PromoMats は、デジタルアセット管理とレビューおよび配信機能を組み合わせ、簡単なレビューと承認に加えて、チャネル全体での自動コンテンツ配信と配信停止を提供し、すべてのデジタル資産と資料の完全な可視性と制御を提供します。Veeva Vault PromoMats は、準拠コンテンツの信頼できる唯一の情報源を提供します。これにより、ローカルの製品マネージャーは、自らが必要とするものにすばやくアクセスし、検索し、見つけることができます。 典型的なデジタルマーケティングチームは、Veeva Vault PromoMats を使用して、世界中の従業員のために、マーケティングアセットを保存、検索、キュレート、レビュー、および配布します。これらのアセットは、電子メール、ウェブページ、画像、動画、オーディオファイルなど、さまざまです。再利用を促進するために、マーケティングチームは通常、グローバルに配された人のチームを使用して、これらのアセットを分析してタグ付けし、簡単に検索できるようにします。この現在のプロセスは、不正確で、一貫性がなく、非効率的なタグ付けの影響を受けやすく、人のチームが特定のアセットを見つけるために貴重な工数を費やすことにつながります。組織は通常、コンテンツを正確かつ簡単に検索できるようにレビュアーのチームを設けます。これにより、コストが増加するだけでなく、チームに付加価値を生まない膨大な作業に集中することを余儀なくさせるため、有能な人員がもたらすことのできる付加価値が減少することになります。 お客様から遡って解決法を考えるとき、これらの手動プロセスを自動化するには、次のことが可能なソリューションが必要です。 コンテンツタイプ (電子メール、テキスト、画像、メディアファイルなど) を識別する コンテンツを区別し、識別されたコンテンツタイプに対応する分類に基づく値の付与を自動化する アセットへのタグ付けの自動化を有効にし、これらのアセットを簡単に検索するソリューションを提供する タグ付けのための機械学習 (ML) 値などを使用して、継続的に強化する この投稿では、Amazon AI サービスを使用して、Veeva Vault に格納されているリッチコンテンツを迅速かつ確実に、コスト効率よく、大規模に分析する方法を紹介します。この投稿では、全体的なアーキテクチャ、ソリューションとダッシュボードをデプロイする手順、およびアセットメタデータのタグ付けのユースケースについて説明します。このユースケースの概念実証コードベースの詳細については、GitHub リポジトリをご覧ください。 ソリューションの概要 次の図は、ソリューションのアーキテクチャを示しています。 Veeva […]

Read More

AWS SAM を使用した Kubernetes のサーバーレスアドミッションウェブフックの構築

著者: Simon Woldemichael、アソシエイトソリューションアーキテクト、WWPS ソリューションアーキテクチャ Josh Jiang、アソシエイトクラウド開発者、プロフェッショナルサービス共有配信チーム 学習レベル: 300 Kubernete クラスターでリソースデプロイを制御すると、難しい課題に直面することがあります。たとえば、本番環境に変更をプッシュすると、互換性のないパッケージやサービスをクラッシュさせる脆弱な依存関係をインストールする危険性があります。 Kubernetes のカスタムアドミッションウェブフックを作成すると、規制を厳格に定義し、承認済みリソースをクラスターでのみ起動できます。 次の図は、サンプルのウェブフックのアーキテクチャを示しています。 このブログでは、Kubernetes の開発者とクラスター管理者に向けて、AWS サーバーレスアプリケーションモデル (SAM) を使用してサーバーレスアドミッションウェブフックを作成する方法を解説します。ウェブフックの有用性を示すために、Amazon Elastic Kubernetes Service (EKS) のデプロイを、Amazon Elastic Container Registry (ECR) のイメージに対して検証するようにウェブフックを設定します。 サーバーレスアドミッションウェブフックは、このユースケースに適しています。ですが、Kubernetes リソースの作成、削除、更新に機能を拡張することもできます (Pod など)。最初に、Kubernetes で作成できるウェブフックのタイプについて説明します。次に、構築済みウェブフックをデプロイします。最後に、カスタムウェブフックを作成する方法について説明します。 バックグラウンド Kubernetes クラスターの動的受付制御 Kubernetes がどのように新しいクラスターリソースを内部で調整するかを理解することは、独自のルールを構築するために重要です。Kubernetes ではいくつかのアドミッションコントローラーを使用して、クラスター内のリソースが特定の予想に一致するようにします。これらのアドミッションコントローラーは、有効な作成、更新、削除操作のみを実行できることを保証します。たとえば、存在しないクラスター名前空間に Deployment を作成しようとすると、NamespaceExists アドミッションコントローラーは作成を拒否します。 Kubernetes バージョン 1.9 以降、カスタムプラグインを作成できる 2 つのコードパッケージ (ValidatingAdmissionWebhook と MutatingAdmissionWebhook) が導入されました。これらのプラグインを使用すると、リソースの受付処理に直接統合できます。 ValidatingAdmissionWebhook で、リソースが予想基準に一致するかどうかを検証 できます。たとえば、作成中の Pod には正しいラベルがあり、制限された量の CPU […]

Read More

Amazon EKS コンソールの改善により、クラスターの作成と管理が容易に

先日、AWS は Amazon EKS コンソールにおけるクラスターの作成機能、管理機能、およびサポートドキュメントの使用感を改善したことを発表しました。このブログ記事では、どのような改善が施されたか、またお客様やクラスターの管理者が Amazon EKS コンソールを使用してクラスターを作成する際に、今回の改善がどう役立つかについて詳しく説明します。 1.複数ステップのクラスター作成フロー EKS のコンソールには、複数ステップのクラスター作成フローが追加され、ネットワーキング、ログ記録、タグやシークレットの暗号化といった追加の設定で、クラスターを簡単に作成できるようになりました。今回のアップデートでは、上図や下記のとおり、4 ステップのクラスター作成プロセスが導入されました。 クラスターの設定 ネットワーキングの指定 ログ記録の設定 レビューと作成 2.情報リンクと画面移動のない参照 クラスター作成中に画面を移動しなくてもドキュメントを参照できるよう、入力フィールドに情報リンクが追加されました。リンクをクリックすると、同じページのタブ内に情報が表示されるので、クラスター管理者は情報を参照しやすくなります。クラスター作成フロー中に表示できる新しい情報パネルの一覧を次に示します。 一般的なクラスター設定 (ステップ 1) Kubernetes のバージョン (ステップ 1) クラスターサービスロール (ステップ 1) シークレットの暗号化 (ステップ 1) タグ (ステップ 1) VPC、サブネット、セキュリティグループ (ステップ 2) クラスターエンドポイントアクセス (ステップ 2) コントロールプレーンのログ記録 (ステップ 3) 3.設定の「コンソール内」リフレッシュ クラスター作成の各ステップにおいて、ページ全体をリロードしなくても設定フィールドが動的に更新されるようになりました。また、入力フィールドの横に導入された更新ボタンにより、VPC、サブネット、セキュリティグループ、クラスターサービスロール、KMS キーなど、EKS 外で定義した設定を動的に反映させることができます。この動的更新機能により、コンソールページをリフレッシュすることなしに利用可能なリソースの最新リストをロードできます。 その他のマイナーアップデート クラスター作成後に設定を更新する際に、コンソールから更新タブに移動し、現在のステータスをモニタリングしたり、以前の更新履歴を確認したりできるようになりました。 エンドポイントアクセスを選択するためのトグルボタンがラジオボタンに変更され、クラスターに対して現在どのエンドポイントアクセスオプションが選択されているかが分かりやすくなりました。 複数ステップの設定を反映して、ステップ 4 のクラスターレビューページの編成が変更されました。 クラスター作成レビューページでは、設定情報を失うことなく、各ステップ内で動的に編集できるようになりました。 サブネット/セキュリティグループの選択が、大きなテーブルからコンパクトな複数選択リストになりました。 […]

Read More

Amazon CloudWatch Logs を使用して Amazon Managed Blockchain のアクティビティを追跡する

AWS は最近、Amazon Managed Blockchain と Amazon CloudWatch 間の新しい統合の提供を開始しました。メンバー認証局 (CA)、Hyperledger Fabric ピアノード、およびチェーンコードでのアクティビティなど、ブロックチェーンネットワークでの重要なアクティビティを示す詳細なログを利用できるようになりました。 この投稿では、これらの新機能を使用して、分散型アプリのブロックチェーンアクティビティを追跡する方法を示します。また、Amazon CloudWatch でアラームを作成してブロックチェーンのアクティビティを通知する方法についても説明します。 Amazon Managed Blockchain でロギングを有効化する 始める前に、Amazon CloudWatch Logs でログを有効にして、ブロックチェーンネットワークと Fabric クライアントをセットアップします。詳細については、CloudWatch Logs を使用したブロックチェーンアクティビティのモニタリングを参照してください。 ロギングを有効にできる場所は 2 つあります。メンバーをブロックチェーンネットワークに追加すると、メンバーの認証局 (CA) サービスへのログオンを有効にするオプションが利用できるようになります。次のスクリーンショットを参照してください。 ロギングオプションのいずれかを有効にすると、/aws/managedblockchain/<NetworkID>/<MemberID> という名前のロググループが作成されます。CA ロギングを有効にすると、ca というこのグループの下にログストリームが表示されます。このログストリームには、CA に関連するすべてのアクティビティの詳細なログが含まれています。 ピアノードを作成するときにロギングを有効にすることもできます。ノード上のすべてのアクティビティを表示する詳細なログ (ピアノードログ) またはチェーンコードによって作成されたログを有効にするオプションがあります。次のスクリーンショットを参照してください。 チェーンコードログは、ビジネスワークフローにおける重要なアクティビティを追跡するのに役立ちます。CA およびピアノードのログは、Fabric コンポーネント間の複雑なインタラクションのトラブルシューティングに役立ち、特定のワークロードに関する洞察を得ることができます。 チェーンコードにログメッセージを追加する チェーンコードログ機能は、ビジネスワークフローにおける重要なアクティビティを追跡するのに特に役立ちます。この投稿では、ログを使用して、適切なアクセス許可を持つユーザーのみがチェーンコードの呼び出しを実行できることを確認し、ユーザーが不正なアクセスを試みたときにアラートを発生させる方法を示します。これらの機能をテストし、CloudWatch アラームを有効にして、不正アクセス試行について通知するには、ネットワークに次のコードをデプロイします。/home/ec2-user/permissions-example/index.js の Fabric クライアントのホームフォルダに次のコードを保存します。 ///////////////////////////////////////////////////////// // ROLE-BASED ACCESS CONTROL EXAMPLE // […]

Read More

Amazon RDS for SQL Server での Microsoft SQL Server Reporting Services の設定

Microsoft SQL Server Reporting Services (SSRS) を Amazon Relational Database Service (RDS) for SQL Server DB インスタンスで直接実行できるようになりました。SSRS は、SQL Server 2017 Standard または Enterprise エディションの シングル AZ またはマルチ AZ インスタンスでアクティブ化できます。SSRS を Amazon Elastic Compute Cloud (Amazon EC2) で実行する場合は、SSRS を Amazon RDS for SQL Server で直接実行することによってコストを節約できるようになります。Amazon RDS for SQL Server は、SQL Server データベースと同じ RDS DB インスタンスで Report […]

Read More

Amazon S3 で削除マーカーレプリケーションを管理する

お客様は、同じ AWS リージョン内または別の AWS リージョン内にデータのコピーを作成して、コンプライアンス、レイテンシーの短縮、またはアカウント間でのデータの共有を実現するために、Amazon S3 レプリケーションを使用します。データが絶えず変化している環境では、多くのお客様が、削除されるオブジェクトに対するレプリケーションのニーズが異なります。このブログでは、V1 と V2 の 2 つの設定のレプリケーション動作、および特定のコンプライアンスとガバナンスのニーズを満たす設定を選択する方法について説明します。 S3 レプリケーションの概要 S3 レプリケーションは、あらゆる Amazon S3 ストレージクラスに、低コストで伸縮自在なフルマネージド型のエンタープライズ対応レプリケーション機能を提供し、誤った削除から保護するとともに、異なるリージョンにまたがってデータを保護します。Amazon S3 レプリケーションを使用すると、同じまたは異なる AWS リージョン内のバケット間でデータを自動的かつ非同期にレプリケートできます。 Same-Region Replication (SRR) および Cross-Region Replication (CRR) を使用して、さまざまなユースケースに対応できます。たとえば、CRR は、地理的に異なる場所にデータのコピーを保持することにより、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。SRR は、開発者アカウントとテストアカウント間のレプリケーションを設定し、データ主権の要件を満たすために使用できます。どちらの設定でも、Amazon S3 はソースバケット内のすべてのオブジェクトを宛先バケットにレプリケートします。オプションで、レプリケートされるオブジェクトを制御するために、プレフィックスとタグを使用してオブジェクトのサブセットをレプリケートできます。 ソフト削除操作と削除マーカー S3 レプリケーションでは、ソースバケットと宛先バケットの両方でバージョニングを有効にする必要があります。バージョニングされているバケットについて、バージョン ID を指定せずにオブジェクトを削除する場合、この削除操作は、一般に「論理削除」と呼ばれます。 論理削除の結果、「削除マーカー」と呼ばれる新しい null オブジェクトバージョンが生成されます。 オブジェクトは、ライフサイクルの有効期限ポリシーのために削除される場合もあることに留意してください。現在のオブジェクトバージョンが期限切れになると、削除マーカーが追加されます。対照的に、最新でないオブジェクトのバージョンが期限切れになると、永久に削除されます。 ここで興味深い質問が頭に浮かぶことでしょう。すなわち、オブジェクトが論理削除されたときのレプリケーション動作はどうなるのか、ということです。 この場合、2 つの結果があり得ます。 削除マーカーがレプリケートされます (V1 設定)。ソースバケットと宛先バケットの両方で削除されたオブジェクトに対する後続の GET リクエストは、オブジェクトを返しません。 削除マーカーはレプリケートされません (V2 設定)。削除されたオブジェクトに対する後続の […]

Read More

PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離

Software as a Service (SaaS) プロバイダーには、基本的にテナントデータの分離を適用する責任があります。テナントの 1 つが別のテナントのデータにアクセスした場合、信頼はなくなり、ビジネスのブランドに永久的な損害を与える可能性があるだけでなく、さらにひどい場合には、ビジネスを失う可能性があります。 リスクが非常に大きいため、効果的なデータの分離を計画することが重要です。マルチテナントアーキテクチャは、各テナントのリソースをレプリケートするのではなく、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストを節約します。しかし、共有モデルで分離を適用することは難しいため、マルチテナントデータモデルで妥協して、テナントごとにコストがかかるデータベースのオプションに戻すことが可能です。 多くの場合、共有データベースモデルはソフトウェア開発者に依存しているため、記述してあるすべての SQL ステートメントで適切なチェックを実装することが唯一の選択となります。他のセキュリティ上の懸念事項と同様に、日常的なソースコードの変動性にあまり依存しないより一元的な方法で、テナントデータの分離ポリシーを適用するのがよいでしょう。 この投稿は SaaS アーキテクトと開発者を対象としており、テナントの共有データベースの利点を享受しながら一元型分離の適用を実現する方法について解説しています。 データパーティション分割のオプション マルチテナントシステムで使用する一般的なデータパーティション分割モデルには、サイロ、ブリッジ、プールの 3 つがあります。各モデルの分離方法には、それぞれ長所と短所があります。 サイロ – テナントごとに個別のデータベースインスタンスを使用すると、分離はたいていインフラストラクチャコストが高くなるだけでなく、テナントのセットアップがより複雑になります。これは、SaaS のサービスにオンボードする各テナントに、新しいデータベースインスタンスを作成および管理する必要があるためです。 ブリッジ – テナントデータをパーティション分割する 2 つ目のアプローチは、同じデータベースインスタンスを共有しながら、テナントごとに異なるスキーマを使用する方法です。リソースを共有することでモデルのコストを削減できますが、メンテナンスとテナントのセットアップはかなり複雑になる可能性があります。 プール – 3 つ目のパーティション分割モデルは、共有データベースインスタンスと名前空間の両方を使用するものです。この設計ではすべてのテナントデータを並べて表示しますが、各テーブルまたはビューには、データのフィルターに使用するパーティション分割キー (通常はテナント ID) が含まれています。 プールモデルは運用コストが最も節約でき、インフラストラクチャコードとメンテナンスのオーバーヘッドを削減します。ただし、このモデルはデータアクセスポリシーを適用するのが難しい場合があり、通常は、すべての SQL ステートメントに正しい WHERE 句を実装することが望まれます。 マルチテナントデータのパーティション分割の詳細については、次の AWS SaaS Factory ホワイトペーパーをご参照ください。 行レベルのセキュリティ RDBMS 分離ポリシーの適用をデータベースレベルで一元化することにより、ソフトウェア開発者の負担を軽減できます。このため、プールモデルの利点を活用し、かつテナント間のデータアクセスのリスクを軽減できます。 PostgreSQL 9.5 以降には、行レベルセキュリティ (RLS) と呼ばれる機能が含まれています。テーブルにセキュリティポリシーを定義すると、これらのポリシーが、SELECT クエリによって返されるそのテーブルの行、または INSERT、UPDATE、DELETE […]

Read More

Amazon DocumentDB (MongoDB 互換) について知っておくべき 12 のこと

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 AWS は、可用性、信頼性、耐久性、スケーラビリティ、バックアップなどに関するお客様の課題を独自の方法を用いて解決するために Amazon DocumentDB を構築しました。その過程において、当社は、付加価値を生まない手間のかかる作業を取り除き、コストを削減するために、いくつかの斬新でユニークな機能を構築しました。この投稿では、Amazon DocumentDB で MongoDB ワークロードを構築およびスケーリングするのに役立つ、まだ認識されていないかもしれない 12 の Amazon DocumentDB 機能を紹介します。 1.最新のクラウドネイティブアーキテクチャ Amazon DocumentDB は、クラウドネイティブのデータベースアーキテクチャを使用してゼロから構築されました。独自のアーキテクチャによりストレージとコンピューティングが分離されているため、各レイヤーを個別に拡張できます。Amazon DocumentDB は、3 つの AWSアベイラビリティーゾーン (AZ) にまたがって 6 つの方法でデータをレプリケートすることで高可用性と耐久性を備えた、フォールトトレラントな分散型の専用自己修復ストレージシステムを使用しています。詳細については、YouTube のAWS re:Invent 2019: Amazon DocumentDB の詳細の動画をご覧ください。次の図は、Amazon DocumentDB アーキテクチャにおけるコンピューティングとストレージの分離、およびデータが 3 つの AZ にまたがって 6 […]

Read More

LAMP ベースの多層ウェブアプリケーションを AWS Snowball Edge にデプロイする

遠隔地でアプリケーションを構築していて、モニタリングカメラや検出システムなど、ローカルで生成されたデータに基づいて処理および決定を行う必要があるころを想像してみてください。ネットワークのレイテンシーが長い場合、このようなアプリケーションをクラウドで実行してデータをリアルタイムで処理することはできません。 また、災害から復旧する状況で作業していることもあるでしょう。この場合、クラウドでデータを転送し、処理するのに十分な帯域幅がない可能性があります。また、コンピューティング、ストレージ、ネットワーク、アプリケーションを短時間でデプロイするという制約も加わります。インターネット接続が利用できない場合は、オフラインで実行し、ネットワーク接続が利用できるようになったときにデータをクラウドと同期できるはずです。 AWS Snowball Edge はローカル環境とクラウド間でデータ転送が行える高耐久化されたエッジコンピューティングソリューションです。これは、ネットワークに断続的に接続または切断された環境でコンピューティングインスタンスを実行するのに利用できます。Snowball Edge の運用に必要なインフラストラクチャは最低限でよく、特に専用のデータセンターは必要ありません。Snowball Edge では、さまざまな vCPU とメモリオプションを備えた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成し、アプリケーションをホストできます。これらのユニークな機能により、Snowball Edge は前述のユースケースの理想的なソリューションになっています。 このブログ記事では、Snowball Edge で EC2 インスタンスを起動し、ウェブアプリケーションを起ち上げる方法を詳しく見ていきます。Apache、MySQL、PHP (LAMP)、および人気のあるコンテンツ管理システム (CMS) である Drupal をインストールします。Drupal の動画モジュールを活用して、ここで説明したメディアワークフローの一部を実装できます。このモジュールにより、動画を任意の形式でアップロードし、動画を H.246、Theora、VP8 (ウェブ互換形式) にトランスコードし、サムネイルを作成できます。動画モジュールは、Amazon Simple Storage Service (Amazon S3) を活用するクラウドトランスコーディングサービスである Zencoder、またはサーバーでオープンソースの FFMPEG を使用します。 AWS Snowball Edge の機能 Snowball Edge により、さまざまな vCPU およびメモリオプションを備えた EC2 インスタンスを作成し、アプリケーションをホストできます。Amazon […]

Read More