Amazon Web Services ブログ

AWS Config  適合パック（コンフォーマンスパック）を紹介できることを大変嬉しく思います。適合パックは、共通のフレームワークとパッケージモデルを用いて、ポリシー定義から監査、集計レポートに至るまで、大規模なAWS リソースのコンプライアンス設定を管理するのに役立ちます。 注：本記事の原文は2019年12月に公開されていますが、2020年4月に適合パックの追加（AWS Control Tower ガードレール適合パック、CIS コンプライアンスパック）が行われたことに伴い、今回改めて翻訳を実施致しました。 適合パックとは 適合パックを使用すると、コンプライアンスルールのパッケージを作成することができます。このパッケージはAWS Config ルールと修復アクションの両方を単一のエンティティにまとめたもので、大規模な展開を容易にします。そして、これらを組織全体に展開し、顧客や他のユーザーと共有できます。さらに、適合パックによりコンプライアンス・レポートも簡素化されます。これからは適合パックレベルでのレポートが可能になり、そこから従来通り個別のルールやリソースのレベルへ詳細化していくことも可能です。既存のレポート機能はすべてそのまま機能したままで、異なるチーム、異なるコンプライアンス体制、もしくは異なるガバナンス体制によって管理されたコンプライアンスセットを論理的にグルーピングすることができます。 適合パックは、AWS CloudFormation と同様にマークアップを使用して記述されます。必要なのはルールをResourcesセクション内で宣言するのみです。残りは AWS Config によって行われます。オプションで、AWS CloudFormation と同じようにParameters セクションを用いることで、より柔軟な適合パックを構築することもできます。なお、適合パックは YAML 形式のファイルで記述されます。 注意:適合パックの特徴は、それらが不変 (immutable)であることです。個々のルールは、アクセス権限やアカウントの権限に関係なく、デプロイされたパックを外部から変更することはできません。さらに、パックが組織のマスターアカウントによって展開されている場合、組織のメンバーアカウントによって変更することはできません。これにより、企業全体のコンプライアンスを管理する際に、セキュリティと確実性がさらに高まります。

クラウドのメリットの概要はすでにご存知かと思います。IT インフラストラクチャの維持とは対照的なコアビジネス、向上した俊敏性と革新性、および収益の拡大に注力しましょう。AWS のフルマネージド型のファイルサービスポートフォリオは、ストレージの面でも、これらのメリットを実現するのに役立ちます。 この点をもう少し詳しく見ていきましょう。当社は、これを「他との差別化に繋がらない重労働の排除」と呼ぶこともあります。 おそらく、ファイルサーバーの実行は、コアコンピテンシーではないでしょう。そうではなく、ほとんどの場合、ファイルサーバーは、お客様が実行するアプリケーション、または顧客のためにホスティングしているサービスをサポートするために必要です。オンプレミスで実行している場合、ファイルサーバーの管理においては、いくつかの対応が必要となります。これらには、ハードウェアの調達、フロアスペースと施設の契約の調整、キャパシティーのプロビジョニング (おそらくピークデマンドに対応するための過剰なプロビジョニング)、およびストレージレイヤーでのビジネス継続性と災害復旧のための計画が含まれます。 この投稿では、クラウド内のマネージド型ストレージに移行するためのビジネスドライバーについて説明します。また、フルマネージド型のデータ転送サービスである AWS DataSync の使用を開始する方法についても説明します。 クラウド内のフルマネージド型のストレージ クラウドで独自のファイルサーバーを実行することにより、インフラストラクチャをオンデマンドでプロビジョニングできるため、調達やデータセンターの物理的なスペースの負担が軽減されます。しかし、キャパシティーとインフラストラクチャの管理は複雑であり、クラウドストレージのビルディングブロックを最大限に活用し、規模に応じたアーキテクチャを実現するという課題もあります。 フルマネージド型のストレージサービスに移行することで、キャパシティープランニング、インフラストラクチャとオペレーティングシステムのメンテナンス、スケールと高可用性のためのアーキテクチャの構築などに必要な労力をさらに削減できます。フルマネージド型のファイルシステムを使用すると、アプリケーションを書き直したり、環境をリファクタリングしたりする必要がないため、アプリケーションの Time-to-Value を最大化できます。アプリケーションが期待する形式でデータをロードし、その使用を開始するだけなので、とても簡単です。さらに良いことに、キャパシティープランニングなどのアクティビティ、バックアップ、高可用性といった機能は、すぐに使用できます。 当社の金融サービス分野のお客様の 1 社である LoanLogics は、マネージド型のストレージへの移行について次のように述べていました。 「当社では、多数ご参加いただいている新規顧客に対応するため、即刻、ストレージキャパシティーを拡大する必要がありました。AWS のファイルストレージサービスでは、アプリケーションのコードの変更は一切必要なく、数日の内にインフラストラクチャの拡大が可能でした。」 –Terrell Cassada 氏、CIO、LoanLogics アプリケーションのニーズに対応する AWS ファイルおよびデータ転送サービス AWS は、ビジネスクリティカルなアプリケーション向けに、フルマネージド型のファイルシステムサービスをいくつか提供しています。これらのうちの 2 つには、NFS を介してシンプルでスケーラブルかつ伸縮自在なファイルシステムを提供する Amazon Elastic File System (Amazon EFS) と、SMB を介してマネージド型のファイルシステムを提供する Amazon FSx for Windows ファイルサーバー (Amazon FSx) が含まれます。パフォーマンス、料金、マネージド型のストレージに移行した後にアプリケーションを最大限に活用する方法などのトピックに関する詳細情報については、re:Invent 2019 の次のプレゼンテーションをご覧ください。 データをオンプレミスから AWS に移動するため、当社は、EFS と […]

本日、Amazon Elasticsearch Service の UltraWarm の一般提供を開始しました。 この新しい低コストのストーレジ層は、現在の Amazon Elasticsearch Service ストーレジ層の 10 分の 1 のコストで、最大 3 ペタバイトのログデータについて高速かつインタラクティブなアナリティクスを提供します。 UltraWarm は、古いデータやアクセス頻度の低いデータに安価なストーレジを提供することで、既存の Amazon Elasticsearch Service ホットストーレジ層を補完します。同時に Amazon Elasticsearch Service のお客様が期待するような、てきぱきしたインタラクティブなエクスペリエンスを提供します。Amazon Elasticsearch Service は、Amazon S3 にデータを保存し、AWS Nitro System 上で専用に構築された高度に最適化されたカスタムノードを使用して、そのデータをキャッシュ、プリフェッチ、クエリします。 Amazon Elasticsearch Service には、ウェブサイトの検索システムの構築、アプリケーションログまたはインフラログからのデータの保存と分析など、多くのユースケースがあります。この新しいストーレジ層は、大量のログデータを保存しているお客様に特に適していると考えています。 Amazon Elasticsearch Service は、大量のログデータを取り込み、対話的に分析できるため、ログアナリティクスによく利用されています。マイクロサービスとコンテナを使用してアプリケーションを構築する開発者が増えると、ログデータが爆発的に増加します。数ヵ月または数年分のデータを保存して分析することは、コストがかかりすぎるため、お客様は複数のアナリティクスツールを使用したり、貴重なデータを削除したりして、長期的なデータがもたらす重要な知見を得ることができませんでした。 AWSは、この問題を解決するために UltraWarm を構築しました。開発者、DevOps エンジニア、InfoSec の専門家は、アーカイブからアクティブで検索可能な状態にデータを復元するために、Amazon Elasticsearch Service クラスター内で数日を費やすことなく、最近の長期的な運用データを分析することができます。 それでは、AWS マネジメントコンソールで新しいドメインを作成して、この新しいストーレジ層をどのように使用するかを見てみましょう。 最初に Amazon […]

AWS ストレージブログの以前の投稿で説明したように、Bristol Myers Squibb は、多くの AWS ストレージサービスを利用して、さまざまなライフサイエンスのワークフローでペタバイト規模のデータを管理しています。ゲノミクスと臨床データは指数関数的に増加しており、データの処理における信頼性が高く、スケーラブルで安全なサービスを利用することが重要となっています。そのため、当社の組織では、Amazon Simple Storage Service (Amazon S3)、Amazon Elastic Block Store (Amazon EBS)、AWS Storage Gateway などの AWS ストレージサービスが中心的な役割を果たします。 以前言及したように、Amazon S3 が非常に成功し、Bristol Myers Squibb で広く採用された主な理由の 1 つに、AWS がアクセス管理とセキュリティに注力していることが挙げられます。この結果、組織がアクセス許可のないユーザーから何百万ものファイルを保護することが可能となりましたが、それだけでなく、複数の適正なアプリケーションやチームとの共有も行うこともできます。途中で権限を与えられた関係者に対し、データ暗号化を透過的に維持できます。 このブログの目標は、AWS ストレージサービスのアーキテクチャと技術の側面を共有することです。これらのサービスに関する私たちの知識は、Amazon S3 と AWS Storage Gateway の多くの実装の使用、コスト削減の機会の調査、さまざまな機能とアーキテクチャの調査から得た学びに基づいています。当社は、オンプレミスアプリケーションのストレージへの低レイテンシーでのアクセスが必要となった際に、EC2 インスタンスとして、および環境内のハードウェアアプライアンスとして、Storage Gateway を導入しました。このブログ投稿では、さまざまな EC2 設定における Storage Gateway のパフォーマンスに焦点を当て、この素晴らしい AWS のサービスに適用できるいくつかの潜在的なコスト最適化を提案します。クラウド内アプリケーションを Storage Gateway とインタラクションさせる予定で、データへのアクセスに関するオンプレミスの要件がわかっている場合、当社は EC2 に Storage […]

数万人ものお客様が Amazon Redshift を使用してワークロードを強化し、ビジネスインテリジェンス、予測分析、リアルタイムストリーミング分析などの最新の分析ユースケースを実現しています。管理者やデータエンジニアにとって、データアナリストや BI プロフェッショナルなどのユーザーが最適なパフォーマンスを得ることは重要です。Amazon Redshift コンソールで、クエリのパフォーマンスに関する問題をモニタリングおよび診断できます。 Amazon Redshift マネジメントコンソールには、Amazon Redshift クラスターを作成、管理、モニタリングするためのダッシュボードや更新したフローをモニタリングする機能があります。詳細については、「Simplify management of Amazon Redshift clusters with the Redshift console」をご参照ください。 この投稿では、新しい Amazon Redshift コンソールを使用してユーザークエリをモニタリングし、低速クエリを特定し、暴走するクエリを終了する方法について説明します。クエリプラン、クエリの実行の詳細、低速クエリを最適化するためのインプレースでの推奨事項、Advisor による推奨事項を使用してクエリのパフォーマンスを向上させる方法などの詳細も解説します。 ユーザークエリと書き換えられたクエリ ユーザーが Amazon Redshift に送信するクエリはすべてユーザークエリです。アナリストがユーザークエリを作成するか、Amazon QuickSight や Tableau などの BI ツールがクエリを生成するかのいずれかです。Amazon Redshift は通常、最適化のためにクエリを書き換えます。Amazon Redshift で、ユーザークエリを単一のクエリに書き換えたり、複数のクエリに分割したりできます。これらのクエリは書き換えられたクエリです。 次の手順は、Amazon Redshift が各クエリに対して実行します。 リーダーノードがクエリを受信して​​解析します。 パーサーは元のクエリの論理表現である最初のクエリツリーを生成します。Amazon Redshift はこのクエリツリーをクエリオプティマイザに入力します。 オプティマイザはクエリを評価し、必要に応じてクエリを書き換えて効率を最大化します。このプロセスにより、単一のクエリを置き換える複数のクエリが作成されることがあります。 クエリの書き換えは自動的に行われるので、ユーザーが気づくことはありません。 元の Amazon Redshift コンソールとシステムテーブルを使用したクエリモニタリング […]

この記事は、Marcel ToerpeとKenny Rajanによる投稿です。 Amazon Web Services (AWS)でミッションクリティカルなSAPワークロードを稼働するビジネス上の利点は、既に十分に証明されています。AWSでは、AWSサービスを使用してSAP環境を移行、そしてモダナイズするために、お客様と協力することを大切にしています。実際、私たちは、SAPブログで触れたAWSのモメンタムにあるように、SAPワークロードを稼働するためにAWSを採用し、SAP環境におけるイノベーションを加速させるために追加のAWSサービスを使用する方法について話し合いました。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン シニアエバンジェリストの亀田です。 コスト削減を主題としたオンデマンドウェビナー皆さんご覧になられましたでしょうか。興味のある方は覗いてみてください。 https://pages.awscloud.com/costdown-tips_2020_LandingPage_reg-event_CP.html 前回、前々回とこちらのブログ記事でAWSのコストを削減する方法をお届けしました。今回は最終回としてその7からその9までをお届けします。 #1　未使用状態のAmazon EC2やAmazon RDS インスタンスへの支払いを止める #2　未使用状態の Amazon Redshift クラスターへの支払いを止める #3　Amazon S3 Intelligent-Tieringを有効にする #4　Amazon DynamoDB にはオンデマンドのキャパシティーモードを利用する #5　十分に活用されていないEC2 インスタンスへの支払いを止める #6　十分に活用されていないネットワークリソースを削除する #7　EC2 スポットインスタンス を利用する #8　Compute Savings Plans を利用する #9　リザーブドインスタンスを利用する #7 Amazon EC2 スポットインスタンスを利用する スポットに適したワークロードを実行していて、現在オンデマンドの料金を支払っている場合は、これらのワークロードにEC2 スポットの利用を検討してください。EC2 スポットインスタンスを使用すると、AWS クラウドにおいて利用されていないEC2インスタンスを低コストで利用できます。 現時点においても、将来のアプリケーションを構築する場合においても、適用可能なすべてのワークロードにスポットを使用することを検討してください。スタンドアロンの EC2 インスタンスにスポットを使用することもできます。 ステートレス、フォールトトレラント、疎結合のワークロードに対してスポットインスタンスを選択することをお勧めします。また、新しいワークロードを開発する際には、スポット適用をまず考慮して検討することをお勧めします。すでにスポットが適しているワークロードの場合においては、数時間または数日程度で実装が可能となります。また、環境の複雑さによっては、数週間かかる場合もあります。スポットインスタンスは、オンデマンド価格と比較して最大で90% の割引でご利用いただけます。今すぐ導入すれば、コスト削減を開始できます。 ビッグデータ、コンテナ(ECS/EKS/Fargate)、CI/CD、ウェブサーバー、ハイパフォーマンスコンピューティング、その他のテストおよび開発ワークロードなどのスポットに適したワークロードをすでに実行している場合は、スポットの導入を加速するのに役立つワークショップや各リンク先の資料をご覧ください。 #8 Compute Savings Plansを利用する EC2インスタンス、Fargate、Lambdaといったコンピュートリソースの使用量が一貫して継続的に利用されており、オンデマンド料金を支払っている場合、Compute Savings Plansによりコストを削減することが可能となります。Compute Savings […]

こんにちは、アナリティクスソリューションアーキテクトの志村です。本日公開した、Amazon Elasticsearch Service (Amazon ES) の初心者向けワークショップについてご紹介します。 Amazon ES は 2015 年にリリースされた、オープンソースの Elasticsearch を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。ストリームデータの分析を行いたい、全文検索エンジンを構築したい、といったときに手軽にご利用いただけます。ただ実際に Amazon ES を試そうとしたときによく当たるのが、ログ分析に適したストリームデータを生成するのが意外に面倒ということです。また権限管理周りをきちんと設定しないと、ただしく Kibana や Elasticsearch API にアクセスしたり，ログを挿入したりもできません．今回ご紹介する Amazon Elasticsearch Service Intro Workshop は、こうした問題を解消しながら、ハンズオン形式で Amazon ES をお試しいただけるような構成となっています。 ワークショップの構成 ワークショップで構築する仕組みは、以下の図のようになっています。Amazon Kinesis Data Generator (KDG)というデータ生成ツールを使って、Amazon Kinesis Data Firehose 経由でデータを Amazon ES に挿入します。挿入したデータを Kibana で分析・可視化します。KDG については、Amazon Kinesis Data Generatorを使用してストリーミングデータソリューションをテストするというブログ記事を参照ください。 ワークショップの中では Kibana の基本的な使い方についても触れていますので、初めての方でもダッシュボードの仕組みを理解し、自分で新しいグラフを作成できるようになります。ダッシュボードの作成法については、Kibana ダッシュボードの設定と作成というブログ記事にもまとまっていますので、こちらもご確認ください。 ワークショップで試せるいろいろな新機能 また、本ワークショップでは初心者向けのベーシックな内容だけではなく，ここ […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 Amazon Auroraのマルチマスタークラスター機能が東京リージョンに対応しましたのでお知らせいたします。 Amazon Auroraは、MySQL および PostgreSQL と互換性のあるクラウド向けのリレーショナルデータベースであり、従来のエンタープライズデータベースのパフォーマンスと可用性に加え、オープンソースデータベースのシンプルさとコスト効率性も兼ね備えたAWSにより設計されたデータベースです。標準的な MySQL データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速です。また、商用データベースと同等のセキュリティ、可用性、信頼性を、10 分の 1 のコストで実現します。 マルチマスター機能は、複数のアベイラビリティーゾーンにわたってAuroraデータベースの複数の読み書きインスタンスを作成できる単一のデータベースであり、稼働時間に敏感なアプリケーションがインスタンス障害を通じて継続的な書き込み可用性を実現できるようにします。この機能のご利用には、MySQL 5.6 と互換性のある Aurora MySQL バージョン 1 が必要です。 マルチマスタークラスターでは、すべての DB インスタンスで書き込みオペレーションを実行できます。単一の読み書きプライマリインスタンスと、複数の読み取り専用 Aurora レプリカの概念は適用されません。別の書き込み DB インスタンスを使用して、失敗したインスタンスの作業を引き継ぐことができるため、書き込み DB インスタンスが利用できなくなっても、フェイルオーバーが発生することのない、継続的な可用性を実現可能です。 その一方で従来のAuroraと動作が異なる点が多くあるため、利用には事前の検証を推奨しています。また他のAuroraやRDSでサポートしているインスタンスのStop（一時停止）には対応していません。 考慮すべき事項や制限事項などはこちらにまとまっていますのでご覧ください。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html また以下のブログもマルチマスター機能の基本概要をご理解いただくうえで非常に役に立ちますので合わせてご参考ください。 https://aws.amazon.com/jp/blogs/news/building-highly-available-mysql-applications-using-amazon-aurora-mmsr/ – シニアエバンジェリスト 亀田    

SAP Single Sign-Onにより、ユーザーは、システムがオンプレミスであろうとクラウドであろうと、集中認証を使用してSAPと非SAPシステムに安全に接続できます。SAP Single Sign-Onは、ユーザー認証と安全なデータ通信を管理し、2要素認証とリスクベース認証を統合するシンプルさを提供します。これには、携帯電話とRSA SecurIDカードの連携も含みます。さらに、SAP Single Sign-Onは、Kerberos/SPNEGO、X.509証明書やセキュリティ・アサーション・マークアップ言語 (SAML)など、様々な種類の認証方法をサポートしています。このブログでは、Kerberos/SPNEGOを基盤としたSAP Single Sign-On (*)をAmazon WorkSpacesと統合する方法を説明します。また、世界中の従業員に対して数千のデスクトップを迅速に提供するために、クラウド、あるいはオンプレミス環境にある既存のActive Directoryサービスを使用する方法についても説明します。