Amazon Web Services ブログ

Category: *Post Types

フリートプロビジョニングを用いて、IoTデバイスとAWS IoT Coreの初期セットアップを自動化する方法

お客様は AWS IoT を使用してIoTデバイスによって生成されたデータを分析し、ビジネスに関する有意義な洞察をすばやく得ることができます。これにより、製造プロセスに必要な改善点の特定、デバイス障害の予測、デバイス問題の迅速な診断とトラブルシューティングなど、さまざまな問題を解決するのに役立ちます。ただし、 IoT デバイスがクラウドに接続して有用な作業を行う前に、デバイスをプロビジョニングする必要があります。 IoT デバイスのプロビジョニングとは、 AWS IoT およびその他のクラウドベースのアプリケーションをセキュアに接続するために、デバイスのユニークな ID ( X.509 証明書や秘密鍵など)を作成し、これらの ID を AWS IoT エンドポイントに登録し、必要なアクセス許可( IoT ポリシーなど)を関連付けるプロセスを指します。 今日、多くのお客様は、Just-In-Time-Registration( JITR )やJust-In-Time-Provisioning( JITP )などの AWS IoT Core 機能を使用して、デバイスアイデンティティをAWSクラウドに登録し、必要な権限を関連付けるプロセスを自動化し、かつスケーリングしています。ただし、一意の ID を安全に生成してデバイスに書き込むことは、依然としてお客様の責任です。多くの方にとって、特に多数のデバイスを製造している OEM ベンダーにとって、このプロセスは依然として手作業で時間のかかる作業です。 新たに追加された AWS IoT Core のフリートプロビジョニングの機能を使用すると、エンドツーエンドのデバイスオンボードのプロセスを安全に自動化できます。さらに、キー属性をデバイスから送信し、 AWS Lambda 関数で検証して整合性を高めることができます。 フリートプロビジョニングは、一意のデジタル ID を各デバイスに安全に配信し、 Lambda 関数を介してデバイスのペイロードを検証し、 ID を顧客の AWS アカウントに登録し、必要なすべてのアクセス許可とレジストリメタデータ(モノ、モノのグループなど)をデバイスに設定します。これはすべて、デバイスが AWS IoT Core […]

Read More

Amazon FSx for Lustre による高パフォーマンスワークロード用の永続的ストレージ

 高パフォーマンスなファイルシステムは、しばしばスクラッチファイルシステムと永続的ファイルシステムの 2 種類に分類されます。スクラッチファイルシステムとは、一時的な高性能のストレージを提供するためのものです。その性能は、1 ミリ秒未満のレイテンシーで、スループットは最大で毎秒数百ギガバイト、そして短時間のワークロード用に数百万の IOPS を実現します。対照的に、永続的ファイルシステムでは、スクラッチファイルシステムに備わったパフォーマンスレベルに、より長期にわたるデータ処理で必要となる耐久性と可用性を組み合わせるよう設計されています。AWS は、re:Invent 2018 において、世界でも最もよく使用されている高パフォーマンスファイルシステムである Lustre をベースとしたスクラッチファイルシステム Amazon FSx for Lustre (FSx for Lustre) を発表しました。最近リリースした FSx for Lustre の永続的ファイルシステムデプロイオプションでは、可用性と耐久性およびパフォーマンスが高く、POSIX 互換のファイルシステムの、AWS による完全マネージド型でのデプロイを可能にしています。 これによりお客様は、ワークロードの要件に基づき、永続的ファイルシステムまたはスクラッチファイルシステムを柔軟に選択できるようになります。 今回のブログでは、この FSx for Lustre の永続的ファイルシステムデプロイオプションについて一通り説明し、一般的なユースケースを示すと共に、当社が推奨するいくつかのベストプラクティスもご紹介していきます。さらに、FSx for Lustre の永続的ファイルシステムを新規で作成し、マウントも行ってみます。 FSx for Lustre での永続的ファイルシステム FSx for Lustre の永続的ファイルシステムは、実行時間が長め、もしくは永続的なワークロードに対し、高可用性で耐久性のあるストレージを提供します。スクラッチファイルシステム上のデータは複製が行われないため、ファイルシステムが使用するファイルサーバーに障害が発生した場合は保持されません。一方、永続的ファイルシステムにある高可用性のファイルサーバーでは、そのデータは同じアベイラビリティゾーン内で自動的に複製されます。 永続的ファイルシステムのファイルサーバーが使用不能になると、その障害から数分以内に自動的な置き換えが実行されます。この時間中は、サーバー上のデータに対するクライアントからのリクエストは透過的に再試行され、最終的にファイルサーバーの置き換えが完了した時点でそちらに継承されます。永続的ファイルシステムのデータはディスク上で複製が作られているので、障害が起きたディスクはすべて自動的かつ透過的に置き換えられます。 Amazon FSx for Lustre の永続的ファイルシステムが適した用途とは? 耐久性と可用性が高いストレージが要求される処理が重いワークロードに対しては、永続的ファイルシステムの使用を検討します。 次に、FSx for Lustre の永続的ファイルシステムにおいて、最も一般的なユースケースのいくつかを示します。 SAS Grid: […]

Read More

AWS CLI を使用した既存の Amazon S3 オブジェクトの暗号化

 業界のプロトコル、政府の規制、組織内部のセキュリティ標準が変化する中、保存データの暗号化がますます必要とされています。暗号化は、不正アクセスやその他のセキュリティリスクから保存データを保護するためのものです。 Amazon S3 のデフォルトの暗号化を使用しても、バケット内の新しいオブジェクトを自動で暗号化できます。しかし、デフォルトの暗号化では、同じバケット内の既存のオブジェクトの暗号は変更されません。暗号化が必要な既存のオブジェクトが Amazon S3 バケットにある場合や、使用しているサーバー側の暗号化 (SSE) 設定を変更したい場合があります。S3 バケット内の既存のオブジェクトを暗号化する最も簡単な方法について、お客様から質問されることがよくあります。 この投稿では、コピーオブジェクト API を使用する際に考慮すべき重要事項について説明します。次に、AWS コマンドラインインターフェイス (AWS CLI) を使用して、データを安全に保つためにバケット内の既存のオブジェクトを暗号化する例をご紹介します。さらに、プレフィックスまたはバケット内のすべての S3 オブジェクトを暗号化する例も示します。最後に、コピーと暗号化に関する一般的な質問について回答します。 前提条件 この投稿で説明しているコマンドを実行するには、次のものが必要です。 AWS アカウント 少なくとも 1 つの Amazon S3 バケット AWS CLI 知っておくべきこと 重要なことから先に言っておきます。慎重に作業を進めてください。 SSE を使って既存のオブジェクトを暗号化するため、オブジェクトを置き換えます。既存のオブジェクトを適切に暗号化するには、コピーオブジェクトまたはコピーパート API を使用できます。これで、同じ名前のオブジェクトをコピーし、サーバー側で暗号化することでオブジェクトデータを暗号化します。コピーオブジェクト API を使用する前に、次の点を考慮してください。 LastModified タイムスタンプは、コピーのタイムスタンプに変更されます。オブジェクトのタイムスタンプに依存するアプリケーションは、元のアップロードのタイムスタンプではなく、コピーのタイムスタンプを参照するようになりました。たとえば、S3 ライフサイクルは新しいオブジェクトの日付を使用します。 S3 イベント通知は PUT または COPY イベントで有効にでき、既存のオブジェクトをコピーして暗号化するとトリガーされます。たとえば、Lambda 関数がもう一度トリガーされることがあります。 S3 クロスリージョンレプリケーション (CRR) は、オブジェクトの新しいバージョンをレプリケーションします。 次のいずれかを使用している場合、メタデータのレプリケーションの利用を検討してください。 […]

Read More

AWS Snowball Edge と Amazon EC2 を使用して Linux エッジコンピューティングソリューションを構築する

 データソースの近くでデータ推論を実行しなければならない状況は数多くあります。多くの場合、これらはリモートであり、接続がない場所で生じます。次の例を考えてみましょう。 リモートの石油掘削プラットフォームには、データを生成する多数のセンサーがあります。重要なコンポーネントについては、摩耗や破損、または故障がないか監視する必要があり、交換は先を見越して行う必要があります。 土壌の水分、湿度、PH 値を監視するさまざまなセンサーを備えた農場では、推論を使用して、健康と成長を最大化できる適切なタイミングで水と栄養素を供給する必要があります。 接続がない前線基地に軍隊が配備されるときには、供給と物流を自動化しなければなりません。 自動運転車両は毎日大量のデータを生成します。これらは、一元化された場所で毎日、オフロードされ、タグが付けられ、異常に対応するために前処理される必要があります。 現代の工場の組立ラインでは、部品を効率的に移動し、その配送を最適化する必要があります。 コンサート会場では、制作会社は複数のカメラからの映像を集約し、異なるフォーマットに変換する必要があります。 これらすべてのシナリオでは、データソースの近くでコンピューティング、ストレージ、ネットワークを実行することを要します。これらの問題は、実行のために構築されたデータセンタースペースを必要としない高耐久性デバイスである AWS Snowball Edge デバイスを使用して解決できます。Amazon S3、Amazon EC2、Amazon EBS、AWS IoT Greengrass などのクラウドネイティブなサービスや、データを取り込むために Network File System (NFS) インターフェイスを実行できます。 このブログ投稿では、AWS Snowball Edge デバイスを使用した Linux ベースのエッジコンピューティングソリューションを開始する方法について説明します。特に、Snowball Edge Compute Optimized デバイスに焦点を当てています。 注文プロセス Snowball Edge デバイスでコンピューティングインスタンスを使用するには、ジョブを作成し、AMI を指定します。AWS Snowball マネジメントコンソールから、AWS コマンドラインインターフェイス (AWS CLI) で、またはいずれかの AWS SDK を使用して、これを行うことができます。通常、ジョブを作成する前に実行する必要があるいくつかの前提条件があります。 AWS マネジメントコンソールにログインし、文書化された手順を使用して Amazon マシンイメージ (AMI) を作成し、それを […]

Read More

ディスラプションへの対応 : 金融機関がクラウドテクノロジーを使用して COVID-19に対応し、業界を変革する方法

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 は、数千人のリモートユーザーをサポートするように伸縮自在にスケール可能な、完全マネージド型の従量制 […]

Read More

クラウドを展開する上で確立すべきガバナンス、リスク、コンプライアンス

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。

Read More

Okta を使用した Amazon Connect のシングルサインオン設定

IT リソースへのアクセスを保護することは非常に重要です。従業員が使用するウェブベースのアプリケーションの数が増えるにつれて、ログイン認証情報を記憶しておくことは困難になります。多くの企業では、リソースへのアクセスを合理化し、従業員のルーチンを簡素化するために、さまざまな ID プロバイダーによるシングルサインオンを採用しています。Amazon Connectは、SAML 2.0準拠のIDプロバイダーを使用したコンタクトセンターへの認証を提供可能です。このBlogでは、OktaをAmazon ConnectのIDプロバイダーとして使用するために必要な手順についてご説明します。 Oktaは、SAML 2.0認証を使用したSingle Single-Onサービスとして、最も一般的に使用されているプロバイダーの1つです。Oktaのセットアップ方法は他のSAML プロバイダーの設定とほとんど同じですが、本投稿ではOktaを使用するためのステップを具体的にご説明します。これは、一般的なガイダンスであるAmazon ConnectでのID管理用にSAMLを設定するを簡略化したものになっています。

Read More

AWS IoT Core を用いた認可ポリシーのスケーリング

はじめに IoTソリューションを構築するソリューションアーキテクト、開発者、およびシステム設計者は、ソリューション全体において、データとデータを操作する機能を適切に保護する必要があります。この投稿では、 AWS IoT Core を使用したマルチユーザーおよびマルチデバイスのユースケースに焦点を当て、認可ポリシーのスケーリングのためのいくつかの設計手法について説明します。デバイス、ユーザー間のカーディナリティやスケールのレベルに応じたパターンを紹介します。 AWS IoT サービス上にソリューションを構築する際のセキュリティ設計やアーキテクチャ検討時に活用頂ければと思います。 IoT デバイス、ネットワークパス、エンドユーザーデバイス、データベース、バックエンドシステムなど、データのやり取りが発生するあらゆるコンポーネントにおいてセキュリティ対策が必要です。IT セキュリティにおいて、セキュアなアーキテクチャを検討する際には、「AAA」と言われる3つのAを考慮する必要があります。 それぞれ、 Authentication (認証)、 Autorization (認可)、 Accounting (アカウンティング)または Auditing (監査)です。 AAA は、セキュリティ要件を整理し、それらの要件とソリューションアーキテクチャを対応付ける方法です。この方法により、ソリューションの利害関係者、エンドユーザー、およびコンプライアンスの専門家は、関連する重要な要件を満たすために、どのようにソリューションが設計されているかを把握することができます。 IoT ソリューションは、固有の設計要素をもつ分散システムアーキテクチャを意味します。分散システムアーキテクチャでは、補完的な分散セキュリティソリューションが必要になります。多くのお客様は、クラウド内の分散システムや、クラウドとオンプレミスのエンタープライズシステムを統合するハイブリッドアーキテクチャの ID (認証)機能を実現するために、 ID フェデレーション( ID 連携)を使用しています。この手法は IoT のデータと機能の保護にも利用できます。 AWS ID フェデレーションオプションの詳細については、 ID フェデレーションの記事をご覧ください。 ID の強固なソリューションを導入すれば、2番目の「A」である認可の要件への対応に集中できます。 IoT ソリューションの開発者が直面する一般的な認可のユースケースに焦点を当てます。一般的に、ユーザー、デバイス間の構成は 1:1 、もしくは 1:多となることが多いため、以降ではそれらのケースについて例をご紹介します。 単純なユースケース: 1 ユーザー 1 デバイス(1:1) 1 ユーザーが 1 つのデバイスを利用するケースは、最も理解しやすく、 IoT […]

Read More

Amazon Neptune T3 インスタンスを使用して、グラフアプリの構築コストを最大 76% 削減する

グラフアプリケーションを構築する場合、Apache TinkerPop または RDF/SPARQL グラフアプリケーションを構築するために反復する際、高速で費用効果の高いインスタンスが必要です。Amazon Neptune では、固定パフォーマンスインスタンス (R5 および R4) に加えて、バースト可能なパフォーマンスインスタンス (T3) を選択できるようになりました。Amazon Neptune db.t3.medium のバースト可能なパフォーマンスインスタンスは、このようなユースケース用に特別に設計されており、最小の固定パフォーマンスインスタンスよりも 76% 低い料金でご利用いただけます。本番環境に入る準備ができているか、データベースの本番環境ワークロードで常に高い CPU パフォーマンスが必要な場合は、AWS マネジメントコンソール、AWS SDK、または AWS CLI を使って、固定パフォーマンスインスタンスを既存のクラスターにすばやく追加できます。 この記事では、Amazon Neptune T3 バースト可能なパフォーマンスインスタンスと、このインスタンスタイプでデータベースクラスターを作成する方法について説明します。 バースト可能なパフォーマンスインスタンスについて バースト可能なパフォーマンスインスタンスは、ベースラインレベルの CPU パフォーマンスを提供し、ベースラインを超えてバーストする機能を備えています。Neptune T3 インスタンスは、ワークロードが必要とする限り、高い CPU パフォーマンスを維持できます。ほとんどの開発およびテストワークロードでは、T3 インスタンスは低コストで優れたパフォーマンスを実現します。T3 インスタンスの平均 CPU 使用率が、24 時間を超えてベースラインよりも低い場合は、T3 インスタンスの時間料金で使用時のすべての一時的なスパイクがカバーされます。 T3 インスタンスのベースラインパフォーマンスとバースト能力は、CPU クレジットによって決まります。CPU クレジットは、フル CPU コアのパフォーマンスを 1 分間提供します。vCPU の数、使用率、および時間の他の組み合わせも、1 つの CPU クレジットに相当します。たとえば、1 […]

Read More

SaaS アプリケーションの、Amazon EFS を使ったより迅速かつ低コストなデプロイ

これまで当社には、独立系ソフトウェアベンダー (ISV) であるお客様たちから、SaaS アプリケーションをデプロイする際に存在する、複数の検討事項についてのお話しが届いていました。これらの考慮事項の範囲は、総保有コスト (TCO) に関するものから、運用や俊敏性への影響などにまで及びます。また、セキュリティ、監査性、可用性の高さ、データ保護などに対処する必要もあり、それらはすべて、ブランド力やマーケットでの認知度に影響を与える要素である、というお話しも聞いています。オンプレミスでもクラウドの場合でも、セルフマネージドの共有ファイルストレージを必要とするアプリケーションでは、上記の基準を満足する技術的ソリューションを決定し維持することは簡単ではありません。 今回のブログでは、マネージド型ストレージへの移行、そして完全マネージド型でクラウドネイティブな Amazon Elastic File System (Amazon EFS) の活用に関し、当社が ISV であるお客様からうかがってきた事項のいくつかをご紹介していきます。 総所有コスト (TCO) ISV のお客様からは、セルフマネージド型ストレージのプロビジョニングとキャパシティ管理に関連し、TCO に影響を与える複数の要素についてうかがっています。これらの要素には、管理上のオーバーヘッド、利用されないキャパシティ、コロケーション (施設、異なる使用条件、別々の契約) 、ハードウェア、そして帯域の問題などが含まれます。Amazon EFS をご利用になるお客様では、セルフマネージド型ファイルストレージのソリューションと比較して最大 90% の節約が可能です*。 Amazon EFS は伸縮自在にスケーリングするため、お客様はファイルの追加や削除に合わせ、自動的に利用量を拡大や縮小することができます。プロビジョニングや管理用のキャパシティを確保する必要はありません。さらに、ストレージボリューム管理の複雑さから逃れられ、実際に必要な分だけを支払えば良い、という別の利点もあります。EFS ライフサイクル管理では、毎日アクセスしないファイルを、EFS Infrequent Access ストレージクラスに透過的に移動することで、コスト削減幅のさらなる調整が可能です。このストレージクラスのコストは 0.025 USD/GB (毎月) だけです (料金は米国東部 (バージニア北部) リージョン) 。 さらに言えば、EFS には、マルチアベイラビリティゾーンアーキテクチャにより提供される追加的なコスト削減手法もあります。これにより、お客様がアプリケーションをスケールアウトする際、コンピューティングに合わせて、よりコストの低い EC2 スポットインスタンスを選択することが可能です。 運用上のシンプルさ ISV のお客様は、予測が不可能な顧客数の増大に合わせスケーリングするために、ビジネスが俊敏さを備えることの重要性についても、お話しくださっています。この課題に関係する要素は、アプリケーション向けにストレージの信頼性を確保することから、新たなマーケットに移動することの煩雑さにまで及びます。また、タイミングを見計らって市場投入することや、コロケーション、ハードウェア、および帯域などの調達リスクについても考慮する必要があります。加えて、セルフマネージド型ストレージソリューションでは、貴重な資本と開発リソースが、インフラストラクチャのデプロイと維持により拘束されるというご意見もありました。 Amazon EFS では、完全マネージド型のストレージソリューションをご利用いただけます。つまり、キャパシティを保持するために、ハードウェアもしくはインフラストラクチャの管理を気にする必要がないということです。さらに、利用量の最適化などを気にする必要もありません。このサービスは、一切の関与を必要とせずに自動で拡大および縮小するので、支払いは実際に利用した分のみです。全体的に見て最も優れている点は、インフラストラクチャの管理から開発リソースを解放できる点であり、アプリケーションに付加価値を追加する作業に注力できるようになります。Faculty 社のデータエンジニアである Scott Stevenson 氏は次のように言います。「偉大なテクノロジーの証しとは、その存在を忘れることができるということです。Amazon […]

Read More