Amazon Web Services ブログ

Category: Amazon Simple Storage Services (S3)

サーバーレス LAMP スタック – Part 4: サーバーレス Laravel アプリの構築

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプローチで Laravel アプリケーションをデプロイする方法を学びます。 これは「サーバーレス LAMP スタック」シリーズの4番目の投稿になります。過去の投稿はこちらです。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え Laravel は PHP 用のオープンソースの Web アプリケーションフレームワークです。フレームワークを使用すると、開発者は一般的なコンポーネントとモジュールを再利用することで、より速く構築できます。また、開発標準に準拠することにより、長期的なメンテナンスにも役立ちます。ただし、従来の LAMP スタックを使用して PHP フレームワークをスケーリングする場合は、まだ課題があります。サーバーレスアプローチを使用してフレームワークをデプロイすると、これらの課題の解決に役立ちます。 Laravel アプリケーションのサーバーレスインフラストラクチャへの展開を簡素化する方法は数多くあります。ここで紹介する方法では、AWSサーバーレスアプリケーションモデル(AWS SAM)テンプレートを使用しています。これによって、Laravel アプリケーションが単一の Lambda 関数にデプロイされます。この関数は、Bref FPM カスタムランタイムレイヤーを使用して PHP を実行します。AWS SAMテンプレートは、「サーバーレス LAMP スタック – パート3: […]

Read More

ご利用のポストプロダクションアプリケーションをAWS仮想デスクトップ インフラストラクチャにデプロイするために

今や仮想化は、クリエイティブな専門家が在宅勤務で仕事をする上で必要な環境となりました。本ブログでは、AWSクラウド上でポストプロダクションアプリケーションを実行する場合に重要な考慮事項を説明します。 お客様から「編集ソフトウェアをAWSで実行できるか」というお問い合わせが頻繁にあります。これらの問い合わせから使用パターンを、典型的なユースケースまたはユーザー想定モデルと呼ばれる形式で説明できます。最も一般的な想定モデルには、ニュース/スポーツ、クリエイティブ、プロモ―ションがあります。想定モデルを識別する目的は、一般的なユースケースの周囲に十分な柔軟性を提供して、ロングフォームおよびショートフォームのプロダクション、コンフォーム編集、マニュアルの品質管理など、さまざまな追加のユースケースに簡単に適用できるようにすることです。想定モデルには、ストレージ、ネットワーク帯域幅、ディスクI / O、CPU、メモリの点で異なる要求があります。もちろん、クラウドでは、カラーグレーディング、カラーフィデリティ(色再現)、マルチチャンネル オーディオ サポートなど、いくつかのワークフローで課題がまだあります。しかし、仮想デスクトップインフラストラクチャ(VDI)プロトコルが進化して、10ビットカラーやより多くのオーディオチャネルなどの機能をサポートするようになると、これらのワークフローを実現することができます。AWSは、将来の機能改善に対応できるように柔軟性を考慮してテンプレートを設計しました。 クリエイティブプロフェッショナル向けクラウドベースワークフローにおける重要な考慮事項 ネットワーク遅延を最小化するとワークステーションのインタラクティブ性が上がり、物理的にAWSリージョンに近いほどユーザーエクスペリエンスが向上することはこの領域では特に重要です。さらに、ロサンゼルスなどの場所には専用の AWS Local Zonesがあり、AWSのコンピューティング、ストレージ、データベース、その他の選択されたサービスを大規模な人口、産業、ITセンターの近くに配置することでレイテンシーを削減します。最後に、制作施設、スタジオ、クリエイティブオフィスで運用する場合、AWS Direct Connect 専用帯域を強化するだけでなく、パブリックインターネットパスを抽象化するセキュリティの層を追加します。デプロイメントの場所またはリージョンを選択する場合、目標レイテンシーが約30ミリ秒以下であれば、最適なエクスペリエンスが提供されます。レイテンシーが長くなると、ジョグ/シャトル操作などの周辺機器のインタラクティブ性、または一般的な再生やGUIアクティビティに遅れが生じる可能性があります。 AWSの利点 クリエイティブワークフローをAWSに移行するには多くの利点があります。その1つは、容量に厳密な計画を立てることなく、需要に基づいてシステムを拡張できることです。コンピューティング、ストレージ、ネットワーキング、その他のAWSサービスはすべて従量課金制ですので、ストレージを拡張したり、多数のワークステーションを調達するために多額の設備投資を計画する必要がなくなります。ワークステーションのアップグレード、パッチ適用、およびイメージングも簡単で、AWS System Mangerを介して自動化できます。インフラストラクチャを一元的に配置して保護できるため、全ユーザーにコンテンツを転送するという、時間とコストのかかるモデルではなく、リソースとアセットのシングルプールを使用して、クリエイティブユーザーがコラボレーションできます。さらに、AWSは現在、グローバルな分散型なワークフローの運用を実現するため、23の地理的リージョン内の73のアベイラビリティーゾーンにまたがっており、これによってインフラストラクチャをローカルで確保している人材の近くに配置できます。例として、動的インフラストラクチャとAWSテクノロジーを採用すると、ワールドカップサッカーなどのライブイベントで、リモート編集やハイライト制作が可能になります。これらの利点を活用してクリエイティブワークフローを最適化すると、コストが削減され、セキュリティとストレージの要件が一元化、時間のかかるデータと人員の移動が排除され、クリエイティブワークフローの市場投入までの時間が短縮されます。 セキュリティ AWSは、ワークステーションとコンテンツへのアクセスを安全に制御、監視、監査するためのきめ細かなアクセスを提供します。AWSのセキュリティは最優先事項であり、AWS Artifactを通じてインフラストラクチャとコンテンツを保護するための多くのリソースを見つけることができます、コンプライアンス関連情報の中心的なリソースであり、AWSマネジメントコンソールから利用できます。Artifactは、アセット管理やクラウドレンダリングなどのユースケースを中心に、AWSで安全でエンドツーエンドの本番環境対応システムを構築する方法を示す詳細な導入ガイドを提供します。より詳細な観点から見ると、監査可能性と追跡可能性はクラウドベースの編集ワークフローを構築する際に考慮すべき重要な要素です。AWSでは、仮想編集ステーションの管理のセキュリティ負担を軽減するサービスを提供しています。AWS CloudTrail、Amazon GuardDuty、Amazon Simple Storage Service(Amazon S3)サーバーアクセスログなどのサービスを使用して、インフラストラクチャを完全に監査できます。さらに、AWS Security Hubサービス全体のセキュリティ状況の包括的かつ集約されたビューを提供します。高価値なアセットとコンテンツに関しては、Amazon Elastic Block Store(Amazon EBS)やAmazon S3などのサービス全体で、保管時および転送時に暗号化を提供できます。AWS Key Management Service (KMS)を使用すれば、顧客管理とサービス管理の両方のコンテンツ暗号化とキー管理できます。 最後に、そして最も重要なこととして、編集ステーションの表示プロトコルは適切なレベルのセキュリティを採用する必要があります。 TeradiciのPCoIPディスプレイプロトコルは、FIPS 140-2レベルで常時オンのAES256暗号化を提供し、クライアントにストリーミングするデータを安全に保ちます。さらに高いレベルのセキュリティが必要な場合は、低遅延用に最適化されたソリューションといった、AWSまたはパートナーのさまざまなVPNソリューションでディスプレイプロトコルを保護できます。 AWS G4 GPUとTeradiciのPCoIPプロトコルおよびAmazon Elastic Compute Cloud(Amazon EC2)上のクラウドアクセスソフトウェアを使用することで、デスクトップを自宅またはオフィスにストリーミングできます。TeradiciのPCoIPプロトコルには、Mac、Windows、およびLinuxシステムのゼロまたはシンクライアント(ハードウェア専用アプライアンス、HP、10ZiGおよびその他のパートナーから入手可能)またはソフトウェアクライアントで実行するオプションがあり、クリエイティブユーザーは、選択したローカルオペレーティングシステムに関係なく同じ編集エクスペリエンスを楽しむことができます。VDIワークステーションとプロトコルの将来を見据えた進化と同様に、AWSには、最適化されたビットレートと4K/UHDをサポートする「PCoIP Ultra」という、Teradiciの新しい拡張プロトコルに適応できるソリューションテンプレートがあります。 マルチモニター編集ワークフローでは、より強力なマルチGPU G4ファミリーインスタンスで最大4台のモニターを使用でき、個別のプレビュー、タイムライン、およびアセット管理モニターを使用して、オンプレミスとほぼ同じエクスペリエンスを提供します。Teradiciは、USBパススルー経由でWacomタブレットなどの一般的なUSB HIDベースの周辺機器もサポートしています。互換性のあるデバイスをローカルに接続するだけで、リモートワークステーションですぐに使用できます。これとその他の一般的なTeradiciのデプロイおよび操作関連の質問の詳細については、コンテンツ作成用AWSワークステーションガイドを参照してください。 アーキテクチャ アーキテクチャについて考えるときは、ワークフローを考慮することが重要です。メディア アセット マネージメント ソリューションの中には、クラウドでこのワークフローをサポートし、Adobe […]

Read More

Amazon S3 への Amazon RDS Snapshot Export によるデータレイクの構築とデータ保持ポリシーの実装

 Amazon Relational Database Service (RDS) は、クラウドでリレーショナルデータベースを簡単に作成、運用、およびスケールするために役立ちます。2020 年 1 月、AWS は Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB、Amazon Aurora PostgreSQL、および Amazon Aurora MySQL からのスナップショットを Apache Parquet 形式で Amazon S3 にエクスポートする機能を発表しました。これで、主要なトランザクションアプリケーションに影響を及ぼすことなく、ダウンストリームのレポート作成および分析アプリケーションが本番データベースからのデータを利用できるようになります。 データベース管理者とデータ所有者は、ビジネスインテリジェンスレポートの作成者、機械学習開発者、またはエンタープライズダッシュボード作成者から、データベーステーブルへのアクセス提供のリクエストを絶えず受け取っています。ここでの課題は、データ上で動作するビジネスクリティカルなアプリケーションに影響を及ぼさない方法でデータにアクセスできるようにすることです。リードレプリカを作成することもソリューションのひとつですが、ダウンストリームアプリケーションリクエストに対応するためにプロビジョニングされたコンピューティング性能を維持しなければなりません。 さらに厄介なことに、レポート作成システムには以前のタイムスタンプ時点でのデータのコピーを必要とするものもあります。これまでは、スナップショットから復元することで新しい RDS インスタンスを作成し、レポート作成システムがこの新しいインスタンスにアクセスできるようにすることが、これを実行する唯一の方法でしたが、 Amazon S3 への Amazon RDS Snapshot Export のローンチにより、リクエストされたテーブルを適切なスナップショットから S3 バケットにエクスポートするプロセスを作成し、ダウンストリームアプリケーションに Parquet ファイルへのアクセスを提供するだけで実行できるようになりました。 この記事では、Amazon RDS のスナップショットから Amazon S3 にエクスポートファイル […]

Read More

クラウドにおける安全なデータの廃棄

クラウドにおける統制をお客様が考慮する場合、基本的な考え方は大きく異なるものではありません。ただし、クラウドならではの統制を考慮すべきケースがあることも事実です。その際には、従来のオンプレミスのやり方を無理にクラウドに当てはめようとしてもうまくは行きません。大事なことはその統制が何を目的としていたのかに立ち返り、その上で、New normal(新しい常識)にあった考え方や実装をすすめる必要性を理解し、実践することです。この投稿では、メディアやデータの廃棄を例として、セキュリティのNew normalを考えていきます。 メディア廃棄における環境の変化 データのライフサイクルに応じた情報資産の管理は多くのお客様の関心事項です。 オンプレミスの統制との変更という観点では、メディア廃棄時の統制は従来のオンプレミス環境とクラウド環境では異なります。オンプレミス環境の利用者はハードウェアの消磁や破砕などを実行することでデータの保全を実行してきました。また、メディア廃棄をサードーパーティに委託し、その廃棄証明の提出をもって“確実な廃棄の証跡”として管理しているケースもありました。 AWSの環境ではセキュリティ責任共有モデルに基づき、クラウドのインフラストラクチャの管理はAWSの統制となるため、お客様はその統制が実施されるていることを評価していく必要があります。お客様はAWSが管理するハードウェアデバイスに物理的にアクセスすることはできないため、従来であれば自組織、場合によってはサードパーティに委託していたメディアの廃棄を自組織の統制範囲として行うことはありません。また、仮想環境のストレージは物理的なハードウェアと異なり、特定の利用者が占有しているとは限らないため、廃棄時に利用者に紐付けた管理や通知を行うことは現実的ではありません。 AWSにおけるメディアの廃棄 AWS データセンターは、セキュリティを念頭に置いて設計されており、統制により具体的なセキュリティが実現されています。ユーザーデータの保存に使用されるメディアストレージデバイスは AWS によって「クリティカル」と分類され、そのライフサイクルを通じて非常に重要な要素として適切に取り扱われます。AWS では、デバイスの設置、修理、および破棄 (最終的に不要になった場合) の方法について厳格な基準が設けられています。ストレージデバイスが製品寿命に達した場合、NIST 800-88 に詳細が説明されている方法を使用してメディアを廃棄します。ユーザーデータを保存したメディアは、安全に停止するまで AWS の統制から除外されることはありません。AWSで扱われるメディアはワイプ処理もしくは消磁処理され、AWSのセキュアゾーンを離れる前に物理的に破壊されます。AWS の第三者レポートに文書化されているように、AWS データセンターに対する第三者の検証によって、AWS がセキュリティ認証取得に必要となるルールを確立するためのセキュリティ対策を適切に実装していることが保証されます。お客様はこうした第三者のレポートをAWS Artifactから入手することが可能です。 AWSにおけるサードパーティの管理 AWSにおいては、本投稿執筆時点(2019年12月19日)においてお客様のコンテンツにアクセス可能なサードパーティーのプロバイダはありません。こうした事実は第三者の検証において評価を得るとともに、AWSのサードパーティアクセスページにおいて公表しており、また、変更がある場合にお客様は通知を受けることも可能です。 目的に立ち返る:なんのために”メディア廃棄”を行うか そもそもメディア廃棄の統制を行う目的は何でしょうか。脅威を踏まえて考えれば、組織の所有する(およびしていた)データが許可なく第三者に漏洩することを防ぐことにあります。メディア廃棄の証明をとることは、メディアの廃棄後も、データが第三者により許可なくアクセスされないことを評価するための手段にほかなりません。お客様にとって重要なことはデータがライフサイクルを通じて確実に保護されることです。メディアの廃棄の証明はその手段のうちの一つ(適切に処理されたことの保証手段)にすぎません。お客様の統制を離れたデータが保護されることを確実にすることに焦点をあてることで、環境がクラウドに変わったとしてもお客様の求める管理目的を達成することが出来るのです。 暗号化を活用したデータの保護と廃棄記録 AWSはお客様に重要なデータやトラフィックの暗号化による保護を推奨しており、そのための機能を提供しています。利用終了後もデータを保護する有効な手段として、暗号化による予防的な統制、そして処理の実行を確実に記録することは強く推奨されます。 暗号化がなぜ有効なのでしょうか。暗号化されたデータはそれを復号するための鍵がなければデータとして復元することが出来ません。暗号化に利用する鍵と暗号化されたデータへのアクセスを分離することで権限のない第三者によるデータへのアクセスを予防することが出来ます。このように暗号化を行い、その鍵を消去することはCryptographic Erase(CE:暗号化消去)としてNIST SP800-88においても紹介されています。 AWSのストレージサービスでは利用開始時にデフォルトで暗号化を行う機能を提供(Amazon EBS, Amazon S3)しています。また、Amazon Key Management Services (KMS)によりお客様の鍵によりデータを暗号化することが可能です。これによりお客様が定義したポリシーで鍵へのアクセスを統制しながら利用状況の証跡を取得することが可能となります。また、AWS Configにより意図しない設定の変更や設定ミスの検知および修正を自動化するといった発見的および是正的な統制を組み込むことも容易です。こうした統制を実施することでAWS上のお客様のデータに対して、ライフサイクルに応じた保護を行うことがより容易になりました。 お客様によるデータ廃棄の統制例 統制の一例として、ストレージ領域をデフォルトで暗号化を行う設定とすることで第三者によるアクセスへの保護を実現します。そしてEBSやS3 Bucketを削除する際には、あわせて当該領域の暗号化に用いた鍵をAWS Lambdaを使用してKMSより削除します。これにより従来行っていた当該データの復号が困難になるとともに廃棄証明の代わりとして、暗号化による保護を実施した記録をお客様自身で自動的に取得、管理することができるようになります。鍵へのアクセスが無くなることで、当然AWSによっても、またお客様も廃棄されたデータへのアクセスはできなくなります。   情報セキュリティを管理するためには目的にあわせた管理策を実施する必要があります。しかし一方で、手段自体が目的化してしまい、それを無理に新しい環境であるクラウドにあてはめてしまうアンチパータンが発生することがあります。本投稿ではメディアの廃棄を一つの例示としてとりあげましたが、セキュリティの管理策を実施するうえでの目的に立ち返り、クラウド上で行う上での妥当性、効果や効率性、そして何よりもクラウドの特性を生かしたさらなるセキュリティの向上を実現することでNew Normalに前向きに取り組むことができます。   このブログの著者 松本 照吾(Matsumoto, Shogo) セキュリティ アシュアランス本部 本部長 […]

Read More

研究データ管理基盤でのAmazon S3の活用

学術研究機関においては研究不正対策なども含め、研究データや関連資料の長期保存が必要となってきています。日本学術会議から公開された文章においても論文の実験データ等の資料は原則論文発表後10年保存することが必要であるとされています。 研究データや関連資料の保存のための基盤は多くの機関で必要となりますが、その際に考えるべきことは何でしょうか? 様々なことを考える必要はありますが、例えば、 メンバー管理・アクセスコントロール ファイル等のバージョン管理 研究証跡の記録 ファイル保管 高い耐久性でかつ大容量のストレージ 長期保管 のようなことを考える必要があるでしょう。 この1〜4の部分に関しては 米国NPOである Center for Open Science  (COS)のOpen Science Framework  (OSF) など研究データ管理用のオープンソースソフトウェア等の開発が進み、国内でも国立情報学研究所などがこれらをGakuNinRDMとしてカスタマイズして提供するなど、研究データ管理基盤の利用が開始されはじめています。 研究データ管理基盤としてこのようなソフトウェア等を利用していくためには、ストレージについて考えておく必要があります。研究データは年々増える一方ですので、各機関にてストレージを確保しておく必要があります。その際に前述の5〜6についても考える必要があります。 まず高い耐久性を持つためにには、オブジェクトのコピーを複数分散して配置するなどして耐久性を高める必要があります。ストレージの容量ですが、実際に研究を進めてみなければ必要な容量が分かってきません。急激に研究が進み、保存すべきデータが急増することもあるでしょう。あまりに大きく容量を見積もりすぎてしまうと、実際にはそこまで使用しなかった場合にその分のコストが無駄になってしまいます。また長期保存の場合、サービスの永続性が重要になってきます。論文を公開してから10年ということは、論文を発表し続ける研究者にとって、常にそこから10年ということになり、永続的にストレージを確保し続けて行く必要があることを意味します(図1)。 図1 研究が継続している場合のデータ保管期間 ストレージをオンプレミスで確保しようと考えた場合、データの耐久性を確保するために、複数拠点に冗長化されたストレージを用意する必要が出てきます。運用中はディスク等の故障時の交換やハードウェアの保守期限に合わせて後継となる機器の調達、またそれに伴うデータをコピーの手間も発生します。またオンプレミスで用意する多くの場合、最初にストレージ容量を決めておかなくてはならないため、過剰な容量を確保する傾向にもなってしまいコストが増大します。 現在、SINET5とAWSはInternet Exchange(IX)でピアリングもしているため※1、各機関からAWS上に構築されているシステムへアクセスするとSINET5の出口であるIXから直接AWS入る形となり、いわゆる一般に言うインターネットには出て行くことなく通信が可能となります。 また機関で用意されるストレージ はAmazon S3※2を利用頂くことで、標準で耐久性の高いストレージを利用でき、使用した分だけの支払いとなるため、スモールスタートが可能で、研究データや関連資料の量など将来を見積もり事が難しいものを長期間保管するのに適しており、前述の5〜6に対処することができると考えられます。 さまなざな機関や組織においてクラウドを利用する機会が増えています。利用形態もいくつか選択肢があり、AWSに直接サインアップしてご利用いただくケースやAPNパートナーの請求代行サービスを利用しアカウント管理と日本円での支払いを選択いただくことも可能です。各機関に合わせた幅広い選択肢があります。一方で入札による一括でしか調達できないような場合には、単価契約での調達や、図2のように例えば「Amazon S3で月あたりの積み上げで総計T[GB]のストレージをNヶ月以上利用出来、月あたり最大M[GB]以上利用できる環境を提供すること」などとして調達することが考えられます。このようにすることで、オンプレミスのように最初から最大の容量を調達することなく、徐々に増えていくストレージを調達することが可能であると考えられます。この際機関側と契約する企業間で総計容量の上限に達した場合にどのような扱いとするのかをあらかじめ決めておくことも重要です。 図2 時間軸とストレージの容量 他方、法令やデータの置き場所を気にされるお客様もいらっしゃいますが、お客様自身でAWS カスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更※3することができます。AWS ではコンテンツの所有権と管理権をお客様にお渡ししていますので、例えば東京リージョンを選択し、そこにデータを置いている場合はデータは日本国内に留まります。詳しくはAWSのデータプライバシー※4をお読みください。 まとめ 研究データ保管のための基盤としてが研究データ管理用のオープンソースソフトウェア等の開発がすすんでいます 研究データを置くための機関側ストレージとしてAmazon S3を利用頂くことができます Amazon S3は標準で耐久性が高く、使用した分だけの課金となるため、スモールスタートが可能で、研究データや関連資料の長期保存にも向いています   ※1  Amazon Web Services ブログ「学術研究機関でのSINET5を経由したAWSの利用」: https://aws.amazon.com/jp/blogs/news/sinet5-aws-explain/ ※2  Amazon Simple Storage Service (Amazon […]

Read More

Amazon S3 アップデート — SigV2 の廃止時期、延期と変更

Amazon S3 API に対して行うすべてのリクエストは、それが本物であることを確認するために署名する必要があります。初期の AWS では、署名バージョン2 または SigV2 と呼ばれる署名モデルを使用していました。2012年には、より柔軟な署名方法である SigV4 を発表し、2013年以降に開始されたすべてのリージョンでは、こちらを唯一の署名方法としました。また、その時点で、すべての新しい S3 アプリケーションにこちらのSigV4を使用することをお勧めしました。 2018年に、我々はSigV2のサポート終了を2019年6月後半とするという発表をしました。多くのお客様がアプリケーションを更新してくださいました(多くのケースで単純にSDKのアップデートを行うだけです)が、SigV4を使用するために、サポートを延期してもらえないかという多くのご要望をいただきました。 新しい日付、新しいプラン オリジナルのプランに関するフィードバックに応じて、重要な変更を行っていきます。概要は次のとおりです。 オリジナルのプラン — SigV2のサポートは2019年6月24日に終了します。 改訂されたプラン — 2020年6月24日以降に作成された新しいバケットは SigV2 署名付きリクエストはサポートされません。ただし、既存のバケットについて引き続き SigV2 がサポートされますが、我々はお客様が古いリクエスト署名方法から移行するよう働きかけます。 既存のバケット、それは SigV2 をサポートする一部のAWSリージョンにおいて、SigV2 を引き続き使用することはできますが、SigV4 に移行することを強くお勧めします。そのことで重要なセキュリティ上のメリットと効率性のメリットが得られます。この新しい署名方法では、長期のAWSアクセスキーから派生した、別途これに特化した署名キーを使用します。このキーは、サービス、地域、および日付に固有です。これにより、サービスとリージョン間の分離が強化され、キーの再利用に対する保護が強化されます。内部的に、SigV4 実装では認証チェックの結果を安全にキャッシュすることができます。これにより、レイテンシーが改善され、アプリケーションの全体的な堅牢性向上が期待できます。詳細については、「署名バージョン4の変更点」を参照してください。 SigV2 を使っているかどうかの判断方法 S3 は 2006年以来からのAWSサービスです。あなたやあなたの前任者が書いたコードの一部はまだまだ現役で利用されている可能性があり、SigV2で署名された要求を忠実に行っているかもしれません。CloudTrailのデータイベントまたは S3 サーバーアクセスログを使用して、この古風なリクエストを見つけることができますので、そのアプリケーションを更新対象にしてください。 CloudTrailのデータイベント — 各 CloudTrail イベントエントリの additionalDataElement 内で SignatureVersion 要素を探します(詳細については、「AWS CloudTrail を使用して Amazon S3 署名バージョン2リクエストを識別する」を参照してください)。 S3 サーバーアクセスログ […]

Read More

Amazon Connect S3バケットへのアクセスを制限する

このブログでは、Amazon S3へのカスタマーアクセスポリシーを作成する方法について説明します。 これらのバケットはデフォルトでは公開されていません。このブログではさらに踏み込んで、Amazon Connectのレポートと通話録音が保存されているバケットをAmazon Connectにロックします。 Amazon Connectアカウントに割り当てられた適切な権限を使用することで、スケジュールされたレポートと保存されたレポートを表示したり、Amazon Connectインターフェイスから通話録音を再生したりできます。 セキュリティとデータのプライバシーは多くの顧客にとって最優先事項であるため、組織やプライバシーの要件を遵守することが重要です。 そのためには、IAMポリシーを使用して、Amazon S3に格納されているAmazon Connectアーティファクトのセキュリティをさらに強化することができます。 これは、顧客情報を危険にさらす可能性があるデータ漏洩または侵害を回避するのに役立ちます。 これにより、顧客のプライバシーを維持するためのセキュリティが強化され、ローカルの規制を遵守するのに役立ちます。 警告 セキュリティ設定を変更するときは注意してください。 これらの変更は恒久的なものであり、あなた自身のアクセスを制限してしまうかもしれません。まずはテストバケットで試すことをお勧めします。 もし間違えると、管理しようとしているリソースへのすべてのアクセスが失われるかもしれません。 これは、Amazon Connectインスタンスの動作に悪影響を及ぼす可能性があります。本番環境で行う前に、テストS3バケットでアクセス制限を試してみることを検討してください。 この記事で説明する次の手順は、S3バケットへのアクセスを制限するために必要です。 インスタンスに使用されているS3バケットを特定する Connectに使用されているIAMロールを特定する コマンドラインを使ってロールIDを特定する S3バケットポリシーを作成する S3バケットへのアクセスを確認する それでは始めましょう。 S3バケットを特定する Amazon Connectインスタンスに関連付けられているバケットを特定します。 インスタンスの作成時に既存のS3バケットを使用しなかった場合は、新しいバケットが作成されています。 次の例に示すように、Amazon Connectダッシュボードで、Amazon Connectに使用されているバケットを見つけることができます。 私のインスタンスの例で使用されているバケット名は、connect-25fd0a3be3ef です。 IAMロールを特定する Amazon Connectサービスに使用されているIAMロールを特定します。Amazon Connectインスタンスでの権限は、IAMロールにより許可されています。 注:Amazon ConnectはService-linkedロールを導入しました 。 この記事の手順は、2018年10月17日にService-linkedロールが導入される前に作成されたAmazon Connectインスタンスに適用されます。 近日中に、この記事をService-linkedロールに関する情報で更新する予定です。 Amazon ConnectサービスのIAMロールを見つけるには IAMコンソールを開きます。 Amazon Connectインスタンスを作成したときに作成されたロールを見つけます。 複数のインスタンスを作成した場合は、作成時間を確認することで、どのロールが各インスタンスに関連付けられているかを判断できます。 作成時間の列が表示されていない場合は、ページの右上隅にある歯車のアイコンから追加できます。 どのロールがどのインスタンスに対応しているか判断できない場合は、ロールがアクセス権を持つS3バケットが、そのインスタンスで使用されるバケットと一致するかを確認します。 正しいロールを使用していることを確認する […]

Read More

EMRFS S3 最適化コミッターを使用して、Apache Parquet 形式での Apache Spark 書き込みパフォーマンスを向上させる

 EMRFS S3 最適化コミッターは、Amazon EMR 5.19.0 以降の Apache Spark ジョブで使用可能な新しい出力コミッターです。このコミッターは、EMR ファイルシステム (EMRFS) を使用して Apache Parquet ファイルを Amazon S3 に書き込む際のパフォーマンスを向上させます。この記事では、この新しい最適化されたコミッターを既存のコミッターアルゴリズム、つまり FileOutputCommitter アルゴリズムのバージョン 1 および 2 と比較するためにパフォーマンスベンチマークを実行します。最後に、新しいコミッターに対する現在の制限について検討し、可能な限り回避策を提供します。 FileOutputCommitter との比較 Amazon EMR バージョン 5.19.0 以前では、Parquet を Amazon S3 に書き込む Spark ジョブは、デフォルトで FileOutputCommitter という Hadoop コミットアルゴリズムを使用していました。このアルゴリズムには、バージョン 1 と 2 の 2 つのバージョンがあります。どちらのバージョンも、中間タスクの出力を一時的な場所に書き込むことに依存しています。その後、名前変更操作を実行して、タスクまたはジョブの完了時にデータが表示されるようにします。 アルゴリズムバージョン 1 には、2 つのフェーズの名前変更があります。1 つは個々のタスク出力をコミットするため、もう 1 つは完了/成功したタスクからのジョブ全体の出力をコミットするためです。タスクは名前変更ファイルを直接最終出力場所にコミットするので、アルゴリズムバージョン 2 […]

Read More

AWS クラウドへの移行時にデータベースコストを削減して可用性を向上させる

従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。

Read More