Category: Storage

 AWS のセキュリティは単なる機能ではありません。考え方です。本日、私たちは S3 の Access Analyzer を発表しました。これは、ユーザーの代わりにリソースポリシーを監視する新機能です。デフォルトでは、S3 で作成されたすべてのバケットとオブジェクトはプライベートに設定されています。AWS では、アクセスコントロールリスト (ACL) やバケットポリシーなどのメカニズムを使用して、詳細なアクセスレベルを設定できます。S3 の Access Analyzer はアクセスポリシーを監視する新しい機能です。これにより、ポリシーは S3 リソースへの意図したアクセスのみを提供するようになります。S3 の Access Analyzer がバケットアクセスポリシーを評価することで、ユーザーは不正アクセスの可能性があるバケットを見つけ、迅速に修正できるようになります。 組織やワークロードが大きくなると、S3 の Access Analyzer はすべてのポリシーを評価し、AWS アカウントの外部で共有され、不正アクセスの危険にさらされているパケットについて警告します。この投稿では、Amazon S3 の Access Analyzer を有効にする方法を順を追って説明します。また、この新機能を使用することによって、S3 バケットへのアクセスが意図したものであり、それだけに過ぎないことを確認できるユースケースについて考察します。 バケットへのアクセスが共有アクセスである可能性を示す結果が確認された場合、S3 マネジメントコンソールでワンクリックするだけでバケットへのすべてのパブリックアクセスをブロックでき、必要に応じてより詳細なアクセス許可を設定することもできます。静的なウェブサイトホスティングなど、パブリックアクセスを必要とする特定の検証済みのユースケースについては、バケットの解析結果を承認およびアーカイブして、バケットをパブリックまたは共有のままにするつもりであることを記録できます。これらのバケット設定は、いつでも確認および変更できます。監査の目的で、S3 の Access Analyzer の解析結果を CSV レポートとしてダウンロードできます。 S3 マネジメントコンソールを開始する前に、IAM コンソールにアクセスして、AWS Identity and Access Management (IAM) Access Analyzer を有効にします。こうすることで自動的に、S3 の Access Analyzer が S3 マネジメントコンソールの中に表示されるようになります。S3 の Access Analyzer は、re:Invent 2019 にて本日リリースされた IAM Access Analyzer に基づいています。 […]

最近、Amazon EFS では 7 日間ファイルへのアクセスがなかった場合に、そのファイルを EFS 低頻度アクセスストレージクラス (EFS IA) へ移行するライフサイクル管理のための新ポリシーの提供開始を発表しました。ストレージブログを定期的にご覧になっている方は既にご存知かもしれませんが、多数のお客様が数ペタバイトに及ぶ大量のデータを EFS 上で、月額 0.08/GB* というコスト効率の良い価格で保存しています。この保存方法により、本サービスをご利用のお客様は、年間数百万ドルもの処理費用を節約しています。 *米国東部 (バージニア北部) リージョンの料金であり、EFS IA のストレージの 80% を想定しています。他のリージョンでの料金については、Amazon EFS の料金ページをご参照ください。 それでは、提供されているより長い期間の他のポリシーとは対照的に、この新しい 7 日間ポリシーを選択するのが推奨されるのはどのような場合でしょう? 最も明白な答えは、より短期間に、多くのお金を節約するためです。それ以外では、7 日間 EFS IA ポリシー (データベースバックアップと ETL) を使用する一般的なユースケースが 2 つあります。 データベースのバックアップ データベースアプリケーションではファイルシステムストレージとバックアップ/復元プロセスがファイルネイティブであることを想定しているため、EFS がデータベースのバックアップにいかに適しているかについての記事を投稿しました。EFS の提供するビルトインデータ保護と EFS の特徴と言える高可用性/高耐久性により、ユーザーは自分のバックアップが必要なときにいつでも取り出せるという安心を得ることができます。EFS IA では、ユーザーは実質的にコンソール上で 1 つのチェックボックスをオンにするだけで費用を節約できるため、DB バックアップのためのシンプルなコスト最適化策であると言えます。ユーザーはファイルシステムにそのままバックアップを保存することで、復元時間目標 (RTO) を短縮できます。言い換えれば、ストレージプラットフォーム間でファイルを移動するために時間や手間をかける必要がありません。万一のとき、また、バックアップからデータベースを復元する必要が生じたときには、復元コマンドを実行するだけです。EFS と EFS IA を使用することで、すべてのファイルが同じファイルシステムの名前空間に存在し、いつでもアクセスできるようになります。 新しい 7 […]

 この記事では、コンプライアンス、災害復旧、データ主権などのユースケースについて、Amazon S3 レプリケーションのコストと使用の詳細をモニタリングする方法を確認します。 Amazon Simple Storage Service (Amazon S3) では、Cross-Region Replication (CRR) を使用して別の AWS リージョンの異なるバケットに、または Same-Region Replication (SRR) を使用して同じ AWS リージョン内部のバケット全体にデータを自動的かつ非同期に複製できます。SRR と CRR が連携して Amazon S3 レプリケーションを形成し、クロスアカウントレプリケーションなどのエンタープライズクラスのレプリケーション機能を提供し、偶発的な削除や Amazon S3 ストレージクラスへのレプリケーションを防ぎます。 CRR は、地理的に異なる場所にデータのコピーを保持することにより、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。SRR は、開発者アカウントとテストアカウント間のライブレプリケーションを設定し、データの主権に関する法律を遵守するのに役立ちます。どちらの設定でも、Amazon S3 はソースバケット内のすべてのオブジェクトを宛先バケットに複製するか、オプションでオブジェクトのサブセットを複製します。CRR または SRR の両方で、プレフィックスとタグを使用して、複製可能なデータを制御できます。 大きなプロジェクトまたは特定のユースケース (コンプライアンス、災害復旧など) の一部として Amazon S3 レプリケーションに固有のコストと使用状況をモニタリングする方法に課題が生じます。 ユーザーは AWS のコストと使用状況レポートを使用して、アカウントおよびその AWS Identity and Access Management (IAM) ユーザーが使用する各サービスカテゴリーの […]

 データ暗号化は、データセキュリティを強化するための効果的なソリューションです。データを暗号化し、暗号化キーへのアクセスを管理することにより、許可されたユーザーまたはアプリケーションのみが機密データを読み取るようにすることができます。医療や金融などの規制された業界の顧客が Amazon EMR を選択する主な理由の 1 つは、データを安全に保存およびアクセスするための準拠環境を提供するためです。 この投稿では、機密データを処理する EMR クラスターのセキュリティ保護に役立つ 2 つの新しい暗号化オプションの詳細なチュートリアルを提供します。最初のオプションは、EMR クラスターに接続されたボリュームを暗号化するネイティブ EBS 暗号化です。2 番目のオプションは Amazon S3 暗号化で使用すると、Amazon EMR で個々の S3 バケットにさまざまな暗号化モードとカスタマーマスターキー (CMK) を使用できます。

業界や業種を問わず、お客様にとってコスト管理は最優先事項の1つです。 EBSボリュームのライフサイクルの可視性が十分でないと、未使用のリソースに対してコストが発生する可能性があります。 AWSはコスト管理のサービスを提供しており、コスト情報へのアクセス、コストの理解、コストの制御、およびコストの最適化を行えるようにしています。 未使用、および管理が行き届いていないAmazon EBSボリュームは、AWS のコストに影響します。 EBSボリュームのライフサイクルは、Amazon EC2 コンピューティングインスタンスから独立して管理可能です。そのため、EBS ボリュームに関連付けられている EC2インスタンスが終了しても、EC2起動時に「終了時に削除」 オプションを選択しない限り、EBS ボリュームは削除されません。 また、開発とテストのサイクルの中でEC2インスタンスの起動停止を繰り返す際、自動的にEBSボリュームを削除する処理がないと、 EBS ボリュームが残る可能性があります。 EC2にアタッチされておらず孤立したEBS ボリュームは、アタッチされていない間も料金が発生します。 この記事では、OpsCenter を活用した自動化プロセスについて説明します。OpsCenter は、AWS Systems Manager の一機能として最近発表されたもので、OpsCenterを使えば、EC2 インスタンスにアタッチされておらず、未使用なEBS ボリュームを識別および管理できるようになります。

Amazon Elastic Block Store (EBS) は Amazon EBS ボリュームの暗号化ソリューションを提供するため、ブロックストレージの暗号化キーを管理するための独自のインフラストラクチャを構築、維持、保護する必要はありません。Amazon EBS 暗号化は、暗号化されたの Amazon EBS ボリュームを作成するときにAWS Key Management Service (AWS KMS) のカスタマーマスターキー (CMK) を使用し、AWS KMS の使用に関連する 利点をすべて提供します。Amazon EBS ボリュームを暗号化するには、AWS 管理型 CMK またはカスタマー管理型 CMK のいずれかを指定できます。カスタマー管理型 CMK を使用する場合、AWS KMSでの CMK を毎年ローテーションするなど、暗号化キーをきめ細かく制御できます。CMK の作成の詳細については、のキーの作成を参照してください。 この投稿では、EC2 コンソール、AWS CLI、AWS SDK から EC2 インスタンスを起動するときに、カスタマー管理型 CMK を使用して暗号化された Amazon EBS ボリュームを作成する方法を示します。 EC2 コンソールから暗号化された Amazon EBS ボリュームを作成する […]

アクティブなアプリケーションで、Amazon EC2 インスタンスの Amazon EBS ボリューム使用率がプロビジョニング済み容量に達してしまうことがあります。どのアプリケーションを使用しているかによって異なりますが、プロビジョニング済み容量が使い果たされると、アプリケーション停止のリスクが生じ、お客様に影響を与えることがあります。これに対するソリューションの 1 つに、アプリケーションへのフェールオーバーメカニズムの設計がありますが、オーケストレーションの負担になる可能性があります。より簡単なソリューションは、EBS ボリュームのサイズを自動的に変更することです。 Infor では、本番環境での数千に及ぶ EC2 インスタンス (Windows と Linux) を管理しています。当社はこうした停止を防ぐ予防的アプローチが必要であったため、特定のしきい値に達したときボリュームが自動的に増加するように、本投稿で説明するソリューションを開発しました。このアプローチには 2 つの利点があります。 異常が発生し、ボリュームのスペースが非常に少なくなると、プロビジョニング済み容量が枯渇する前に自動的にボリュームを拡張します。このアクションにより、根本原因を調査し解決するまで、問題に対処できます。 そのため、ボリュームを過剰にプロビジョニングする必要がなくなりました。このソリューションは、より多くのスペースが必要になると、徐々に自動的にボリューム容量を増やし、EBS コストを削減します。 この投稿では、Infor で開発した自動 EBS ボリュームサイズ変更プロセスを順を追って説明します。さらに、そのアーキテクチャを確認し、ベストプラクティスをいくつか学びます。 概要 AWS は Amazon EBS Elastic Volumes を 2017 年に発表しました。この機能では、ダウンタイムなしでシンプルな API 呼び出しで、ボリュームのサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプをその場で変更したりできます。 ボリュームの変更は比較的簡単ですが、ファイルシステムを拡張して、追加のストレージを活用しようとすると一筋縄ではいきません。これは通常、OS 上で手動で行いますが、AWS Systems Manager がインスタンスを管理している場合には、AWS Lambda を使用して OS レベルのスクリプトを実行する Systems Manager コマンドを送信できます。 次のリストは、このワークフローの手順を示しています。 ボリュームが 80％ に達することをモニタリングし、自動化をトリガーします。 特定のシステムが除外されたため、続行する前に一連のチェックを実行します。フリートの […]

 Amazon Elastic File System (Amazon EFS) が AWS GovCloud (米国) で FedRAMP High 暫定承認を達成したことをお知らせできるのは大変な喜びです。この成果により、米国政府機関は、個人識別情報 (PII)、機密患者記録、財務データ、法執行データ、およびその他の管理すべき重要情報 (CUI) を含む機密ファイルを Amazon EFS に簡単かつコスト効率よく保存できるようになりました。 ストレージブログで前に述べたように、数万のお客様が Amazon EFS が提供するシンプルさ、拡張性、費用対効果の恩恵をすでに受けています。昨年後半に AWS GovCloud (米国) で EFS が開始され、FedRAMP High 認定を受けた政府機関のお客様向けに、機密性の高いミッションクリティカルなワークロードのブロックを正式に解除できることを誇りに思います。AWS GovCloud (米国) の FedRAMP High ベースラインの詳細については、こちらをご覧ください。 お客様はさまざまなユースケースで EFS を使用していますが、この機会に、政府機関のお客様とその規制対象アプリケーションに見られるメリットを考えて、2 つの特定の機能を強調したいと考えています。何よりもまず、EFS ライフサイクル管理を使用して、使用頻度の低いデータを EFS 低頻度アクセスストレージクラス (EFS IA) に透過的に移動することにより、アクセスパターンの変化に応じて自動的に費用を節約できます。EFS を使用すると、政府機関のお客様は、アプリケーションを変更することなく、ワークロードをリフトアンドシフトするだけで、クラウドで簡単に開始できます。ライフサイクル管理を有効にすると、時間の経過とともにファイルへのアクセスが自然に少なくなるので、自動的にお金を節約できますが、引き続き同じファイルシステムのネームスペースでアクティブに使用されるデータとともに完全にアクセス可能のままになります。また、クラウドへの移行およびデータの Amazon EFS への読み込みを迅速かつ簡単に強化するために、AWS DataSync もお勧めします。 […]

AWS のお客様は 10 年以上にわたり、SQL Server などのミッションクリティカルな Windows を実行しています。この投稿では、Amazon EBS ストレージを使用して SQL Server のパフォーマンスを最大化する方法について説明します。 永続ブロックストレージはリレーショナルデータベース管理システム (RDBMS) の重要なコンポーネントであり、重要なデータの速度、セキュリティ、耐久性の最終的な責任を担います。AWS は SQL Server のニーズに合わせて、EBS を通じて、高性能で使いやすいブロックストレージを提供しています。 この投稿は、SQL Server データベースアーキテクト、管理者、および開発者に関連した内容です。AWS プラットフォームでの最適なストレージ構成の概要を説明しています。現在 AWS を使用している、またはオンプレミスのワークロードをクラウドに移行しようとしているのであれば、EBS についてのより詳しい情報と基本的な理解を得ることができます。 Amazon EBS の概要 EBS はすべての AWS リージョンで利用可能な、高性能のブロックストレージサービスです。EBS を使用すると、わずか数回のクリックで SQL Server インスタンスにボリュームを作成し接続が可能です。ホストバスアダプター (HBA)、スイッチ、ネットワーク帯域幅、ディスクキャッシュ、コントローラー、ストレージエリアネットワークなどを構成する必要がなくなります。 EBS ボリュームは専用ストレージネットワークを使用してインスタンスに接続し、高速で信頼性の高いボリュームを柔軟にプロビジョニングするため、SQL Server の重要なワークロードにも対応できます。 EBS ボリュームは伸縮自在です。ワークロードを中断することなく、次のような変更を実行できます。 ボリュームサイズを最大 16 TiB まで増やす。 最大 64,000 IOPS までボリュームパフォーマンスを改善する。 SSD […]

数万社におよぶ企業がペタバイト規模のデータを Amazon Elastic File System (Amazon EFS) に保存しており、その多くが EFS を使ってコンテナ化したアプリケーションのデータです。Amazon EFS ファイルシステムは、Amazon Elastic Container Service (ECS) と Elastic Kubernetes Service (EKS) の両方で起動したコンテナに接続できます。Amazon EFS はコンテナインフラストラクチャと同様に、データの追加や削除の際に設定が簡単でかつ柔軟なスケーリングが可能な完全マネージド型のサービスであるため、コンテナストレージにうってつけの選択肢です。さらに、ペタバイト級のデータだけでなく、1 秒あたりのギガバイトの総スループットや数千の IOPS にも拡張が可能です。このブログでは、コンテナ化したアプリケーションで EFS を使用するためのベストプラクティスに関する、よくある質問をいくつかご紹介します。 コンテナには共有ストレージが必要ですか? 一般に、共有ファイルストレージは、障害に対する回復力が必要な長期にわたって実行するコンテナや、データを相互に共有する必要があるコンテナに適しています。よく目にする例をいくつか挙げましょう。 WordPress や Drupal などのコンテンツ管理アプリケーションは、パフォーマンスと冗長性を確保するために複数のインスタンスにスケールアウトしたり、複数のインスタンス間でアップロード、プラグイン、テンプレートを共有することで利点を享受します。 JIRA、Artifactory、Git などの開発者ツールでは高可用性を実現するためインスタンス間でデータを共有します。これは、永続性のために複数の AWS アベイラビリティゾーンに保持されているコードとアーティファクトを使って行われます。 MXNet や Tensorflow のような機械学習フレームワークは、ファイルシステムインターフェイスを介してデータにアクセスする必要があります。永続的な共有ストレージを使用すると、複数のユーザーとジョブを同じデータセットで並行して実行できます。 Jupyter や Jupyterhub などの共有ノートブックシステムには、ノートブックやユーザーワークスペース用の耐久性のあるストレージが必要です。共有ストレージを使用すれば、データサイエンティストの間で簡単に共同作業が行うことができます。 コンテナデータを永続化する別のオプションとしては、Amazon Elastic Block Storage (EBS) があります。これは MySQL、あるいは Kafka […]