Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

AWS Server Migration Service – クラウドへのサーバー移行が簡単に!

これはAhmed Omranのゲストポストです。 AhmedはAWSのMigration Solutions Architectです。 大規模構成におけるオンプレミスサーバーの移行は、自動化、スケジューリング、少ない帯域幅の消費や移行時間の短縮を調整することなしに行うことはできません。 この記事では、AWS Server Migration Service(AWS SMS)を使用して、オンプレミスのワークロードをAWSに効率的に移行する方法を段階的に説明します。 AWS Server Migration Serviceとは何ですか? 2016年10月、エンドツーエンドのサーバー移行プロセスを簡素化する目的でAWS SMS を紹介しました。 AWS SMS は現在、仮想アプライアンスを使用したエージェントレスサービスとしてのオンプレミス仮想マシン(VMs)の移行をサポートしています。 AWS SMSには、次の主要な利点があります: ライブサーバーボリュームのAWSへのレプリケーションを順次自動化することにより、カットオーバー時のサーバーダウンタイムを削減します。 費用対効果の高い方法で大規模サーバーの移行を行います。 広く使用されている多くのオペレーティングシステムをサポートします。 使いやすいUIを使用して、サーバー移行の進捗状況を管理および追跡します。 AWS SMSは、VMware 環境からAWSへの大規模マイグレーションを計画している場合に重要な考慮事項となる、ダウンタイム、エージェントレスツール、順次レプリケーション、およびカットオーバー前のアプリケーションテストなどに対する理想的なソリューションです。 AWS SMSは、サーバーの移行に使用する無料のサービスです。 Amazon EBS スナップショットやAmazon S3など、移行プロセス中に使用されたストレージリソースにのみ支払います。 現在、米国東部(米国バージニア州)、米国西部(オレゴン州)、米国東部(オハイオ州)、EU(アイルランド)、アジア太平洋(シドニー)、アジア太平洋(東京)、アジア太平洋(ソウル) 、アジア太平洋地域(ムンバイ)でサービスが利用可能です。 どのように機能するのですか? AWS SMS を使用してワークロードを移行する手順を説明する前に、移行プロセス自体とAWS SMS がどのように処理するかについて詳しく説明します。 移行プロセスは、次の図に示すように、4つの段階に分かれています。 AWS SMS 移行プロセスの概要 AWS SMS の最終出力はAmazon Machine Image(AMI)です。移行プロセスは、ジョブが終了されるまで(あなたが消去するか、または90日後に自動的に終了するまで)、各レプリケーションの実行ごとにAMIを生成します。 移行段階は、調整された複製頻度で反復されます。各レプリケーションの実行間隔の最短時間は12時間で、最大時間は24時間です。この反復サイクルの有効期間は90日です。その後、レプリケーションジョブは終了します。 移行するVMのグループを選択できます。 […]

Read More

Amazon Redshift のデータ圧縮の強化で圧縮率が最大 4 倍に

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。 -Ana Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (Scholastic、King.com、Electronic Arts、TripAdvisor、Yelp など) は、Amazon Redshift に移行して機敏性を実現し、洞察が得られるまでにかかる時間を短縮して、同時にコストも大幅に削減しています。 列指向の圧縮は、Amazon Redshift の重要なテクノロジーです。このテクノロジーにより、ノードの効果的なストレージ容量を増やしてコストを削減し、SQL リクエストの処理に必要な I/O を削減してパフォーマンスを向上させることができます。I/O の効率を高めることは、データウェアハウスに非常に重要です。昨年、I/O の向上に伴ってクエリスループットは倍増しました。この度、Amazon Redshift に新しい圧縮の強化機能が追加されました。以下に、いくつかをご紹介します。 まず、Zstandard 圧縮アルゴリズムのサポートが追加されました。このアルゴリズムは、ビルド 1.0.1172 での高い圧縮率とスピードを適切なバランスに維持します。標準の TPC-DS、3 TB ベンチマークで raw データに適用した場合、Zstandard はディスク容量の 65% を節減します。Zstandard は幅広く適用できます。SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ のいずれのデータ型にも使用できます。 2 番目として、CREATE TABLE AS、CREATE TABLE、ALTER TABLE ADD COLUMN の各コマンドで作成されたテーブルに対する圧縮の自動化が強化されました。Amazon Redshift のビルド 1.0.1161 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 […]

Read More

新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート

昨年、新しい AWS Application Load Balancer (Elastic Load Balancing の重要な一部) をご紹介し、リクエストの URL のパス要素に基づいて受信 HTTP および HTTPS トラフィックをルーティングするための設定方法について説明しました。このパスベースのルーティングにより、たとえば /api へのリクエストをサーバーのセット (ターゲットグループとも呼ばれます) にルーティングし、/mobile へのリクエストを別のセットにルーティングすることができます。このようにトラフィックをセグメント化することで、リクエストのカテゴリ別に処理環境を制御できます。たとえば、最適な処理環境として、/api リクエストにはコンピューティング最適化インスタンスを指定し、/mobile リクエストにはメモリ最適化インスタンスを指定できます。 ホストベースのルーティングと追加のルール この度、別のルーティングオプションが利用可能になりました。Host ヘッダーに指定したドメイン名に基づいて受信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました。api.example.com へのリクエストは 1 つのターゲットグループに送信し、mobile.example.com へのリクエストは別のターゲットグループに送信して、他のすべてのリクエストは (デフォルトルールで) 3 番目のターゲットグループに送信することができます。ホストベースのルーティングとパスベースのルーティングを組み合わせたルールを作成することもできます。これにより、api.example.com/production へのリクエストと api.example.com/sandbox へのリクエストを別々のターゲットグループにルーティングできます。これまでは、一部のお客様はプロキシサーバー群を設定して実行し、ホストベースのルーティングに使用していました。今回のリリースにより、ルーティングは Application Load Balancer によって行われるため、プロキシサーバー群は必要なくなりました。この処理レイヤーの省略により、アーキテクチャが簡素化され、運用のオーバーヘッドが削減されます。Application Load Balancer は、ポートマッピング、ヘルスチェック、サービス検出などのコンテナベースのアプリケーションをサポートする複数の機能を既に提供しています。ホストとパスの両方でルーティングできるようになると、複数のマイクロサービスをそれぞれ異なる コンテナで実行するアプリケーションを構築し、効率的にスケールすることができます。ホストベースのルーティングを使用すると、サービス名とコンテナ名を合致させることで、これまで以上にサービス検出機構を簡素化できます。今回のリリースでは、Application Load Balancer あたりの最大ルール数が 10 から 75 に増え、新しいルールエディタも導入されます。例として、以下のターゲットグループを使用してみましょう。 […]

Read More

SAP on AWSにおけるVPCサブネットのゾーニングパターン

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 企業のファイアウォール内に存在する必要があるSAPランドスケープの設計は比較的簡単ですが、内部からも外部からも接続する必要があるSAPアプリケーションの場合はそうではありません。これらのシナリオでは、必要なコンポーネントとその配置場所について悩むことがよくあります。 この一連のブログ記事では、SAPアプリケーションにおけるAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンを紹介し、例を用いてその使用方法を説明します。セキュリティグループ、ルートテーブルおよびネットワークアクセスコントロールリスト(ACL)の構成と合わせて、よくあるお客様シナリオに基づいた詳細な図で補足しながら、接続経路ごとにいくつかのアーキテクチャ設計パターンを説明します。 アプリケーションを配置するサブネットを正しく見極めるには、アプリケーションへの接続方法を理解することが必要です。SAPアプリケーションに接続する方法をいくつか見てみましょう。 内部専用接続: これらのアプリケーションは内部的にのみ接続します。SAPサポートチームを除き、外部からの接続は許可されていません。この場合、ユーザーまたはアプリケーションは、専用線または仮想プライベートネットワーク(VPN)を介して接続された企業ネットワーク内に存在する必要があります。SAP Enterprise Resource Planning(ERP)、SAP S/4HANA、SAP Business Warehouse(BW)およびSAP BW/4HANAはほとんどの組織で内部専用接続が必要なアプリケーションです。 内部および管理された外部接続: これらのアプリケーションは内部的に接続しますが、既知の外部の関係者に限定した接続も提供します。例えば、内部プロセスからSAP PI(Process Integration)やSAP PO(Process Process Orchestration)を使用することができますし、既知の外部の関係者もホワイトリストに登録されたIPアドレスからソフトウェアのインターフェースに接続することができます。さらに、SAP SuccessFactors、SAP Cloud Platform、SAP AribaなどのSaaS(Software as a Service)ソリューションとの統合は、AWS上で実行されるSAPソリューションに機能を追加する場合にも望まれます。 内部および管理されていない外部接続: SAP hybrisや社外に公開するSAP Enterprise Portalなどのアプリケーションがこのカテゴリーに分類されます。これらのアプリケーションには一般に外部接続が可能ですが、管理、構成および他の内部アプリケーションとの統合のためのコンポーネントなど、内部接続用のコンポーネントがあります。 外部専用接続: ほとんどのコンポーネントが外部から接続可能であっても、アプリケーションにはバックアップ、接続制御、インターフェースなどの基本的な管理タスクのために内部から接続できる必要があるため、稀なシナリオです。このシナリオは滅多にないため、この一連のブログ記事では説明しません。 このブログ記事では、最初のカテゴリーのアプリケーション(内部でのみ接続可能なアプリケーション)で取り得るアーキテクチャパターンについて説明します。今後の記事で、残りの2つのシナリオについて説明します。3つすべてのシナリオにおいて、パッチ、更新プログラムの適用およびその他の関連するシナリオに対処するために、ネットワークアドレス変換(NAT)デバイス(IPv4の場合)、Egress-Onlyインターネットゲートウェイ(IPv6の場合)を使用して、AWSリソースからインターネットに接続すると仮定します。さらに、この接続は、インバウンド(インターネットからAWSクラウドへの)接続要求を制限または排除する方法で管理します。 内部専用接続におけるアーキテクチャ設計パターン このカテゴリーのSAPアプリケーションについて、データベースとアプリケーションサーバーを同じプライベートサブネットまたは分離したプライベートサブネットに配置する2つの設計パターンを見ていきます。 単一のプライベートサブネットにあるデータベースとアプリケーションサーバー この構成には3つのサブネットがあります。 パブリックサブネット: SAProuterとNATゲートウェイまたはNATインスタンスをこのサブネットに配置します。SAPから指定されたパブリックIPアドレスのみがSAProuterに接続できます。詳細は、SAPノート28976 – リモート接続データシートを参照してください。(SAPノートの閲覧にはSAPサポートポータルへの接続が必要です)。 管理用のプライベートサブネット: Microsoft System Center […]

Read More

AWS Organizationsを利用したアカウント作成の自動化

こんにちは、ソリューションアーキテクトの千葉です。 本日はを利用したAWSアカウントの作成・管理の自動化方法についてご紹介します。 AWS Organizationsは、組織内のAWSアカウントを統合管理し、セキュリティを高めることができるサービスです。サービスコントロールポリシー (SCP)を利用することで、組織内のAWSアカウントに実行を許可するサービスとアクションを一元的に管理することができます。 AWS Organizationsのもう一つの特徴は、APIを通じて組織配下に新しいAWSアカウントを作成することができることです。これまでは、AWSアカウントを新たに作るにあたって、AWSアカウント作成、連絡先情報入力、お支払情報入力、(必要に応じて)一括請求設定といった手順をマニュアルで実施する必要がありましたが、AWS Organizationsを利用すればこれらの操作はCreateAccountというたった一つのAPIに置換えられます。 AWS Organizationsで作成されたメンバーアカウントには、マスターアカウントのユーザーからアクセス可能なIAMロールが自動作成されます。AWS Security Token Service (STS)を利用してこのIAMロールにアクセスする一時的なセキュリティ認証情報を取得し、やを使って作成したメンバーアカウントに対して共通設定を施したり、定期的な環境チェックを実行したりすることができます。 それでは、アカウント作成およびSTSを利用したアカウント環境設定の手順を説明していきます。   メンバーアカウントの作成 まずは組織配下にメンバーアカウントを作成します。操作を実行するIAMユーザーまたはIAMロールには、以下のようにOrganizationsを操作する権限を与えておきます。 { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “organizations:*” ], “Resource”: [ “*” ] } ] } CreateAccountのパラメーターには、アカウント名およびEmailアドレスを指定する必要があります。IamUserAccessToBillingパラメーターはメンバーアカウントのIAMユーザーにBilling情報へのアクセスを許可するかどうかの設定で、デフォルトでALLOWになっています。RoleNameパラメーターはメンバーアカウントに作成されるIAMロールの名前で、何も指定しなければOrganizationAccountAccessRoleという名前が割り当てられます。 import boto3 orgs = boto3.client(‘organizations’,region_name=’us-east-1′) createAccountRequest = orgs.create_account( “AccountName”: “string”, “Email”: “string”, “IamUserAccessToBilling”: “string”, “RoleName”: “string” ) […]

Read More

Amazon EC2インスタンスにホストベースの侵入検知システムアラートの監視方法

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。 このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service(Amazon ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL(Access Control List)またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。 ソリューションの概要 次の図は、この記事のソリューションの概要を示しています。 ソリューションの仕組みは次のとおりです。 1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。 2. CloudWatch Logs グループはにアラートがイベントとして送信されます。 3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。 4. Amazon ESにはログに記録されたアラートデータがロードされます。 5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。 デプロイ時の考慮事項 この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC(Virtual Private Cloud)サブネットを識別する必要があります。 デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。 Cloud […]

Read More

AWS ホットスタートアップ – 2017 年 3 月

あわただしい 3 月が過ぎたので、バスケットボールのことは忘れて、Tina Barr が紹介する今月のクールなスタートアップに注目しましょう。-Ana 今月は春の到来にふさわしい新しいスタートアップ 5 社を紹介します。 Amino Apps – 数十万のコミュニティのソーシャルネットワークを提供します。 Appboy – ブランドの顧客関係を強化します。 Arterys – 医用イメージ産業を変革します。 Protenus – 医療組織の患者データを保護します。 Syapse – 標的がん治療に役立つ全国のデータを共有します。 2 月のホッとスタートアップをお見逃しの場合は、こちらをご覧ください。 Amino Apps (ニューヨーク州ニューヨーク) Amino Apps は、興味ベースのコミュニティが、特にモバイルの面で、未発達で時代遅れであるという認識に基づいて設立されました。CEO の Ben Anderson と CTO の Yin Wang は、特定のトピックを専門に扱う独立したソーシャルネットワークを数十万も集めて、これらのコミュニティへのアクセスをユーザーに提供するアプリを作成しました。そのうち、最大級のコミュニティは 100 万を超す会員を擁しており、人気の高い TV 番組、ビデオゲーム、スポーツ、その他さまざまな趣味や興味などのトピックに基づいて構築されています。Amino は、世界中のコミュニティをホストし、現在 6 か国語で利用可能であり、今後サポート言語の数は増える予定です。Amino アプリの操作は簡単です。アプリ (iOS または Android) をダウンロードして、有効な E メールアドレスでサインアップし、プロフィール写真を選択して使用を開始するだけです。ユーザーは、コミュニティを検索して、興味があるものに参加できます。各コミュニティには、チャットルーム、メルチメディアコンテンツ、クイズ、シームレスなコメントシステムがあります。コミュニティがまだ存在していない場合は、Amino […]

Read More

新しい AWS コミュニティヒーロー (2017 年春)

新しい AWS コミュニティヒーローをご紹介します。 Mark Nunnikhoven SangUk Park James Hall Drew Firment AWS コミュニティヒーローは、さまざまな方法で AWS に関する知識を広め、情熱を伝えます。ソーシャルメディア、ブログ投稿、オープンソースプロジェクト、個人的なイベント、ユーザーグループ、ワークショップなど、あらゆる手段を駆使して AWS から得た洞察を共有します。 Mark Nunnikhoven Mark Nunnikhoven は、個人、組織、コミュニティへのテクノロジーの影響について、特にプライバシーとセキュリティの観点から検討しています。「情報の守りを固める方法」を求めて、サイバー犯罪について調査し、デジタル世界に対するリスクと脅威の理解を深めようとしています。Mark は、Trend Micro の Cloud Research 担当副社長であり、長年に渡るアマゾン ウェブ サービスのアドバンストテクノロジーパートナーおよび AWS クラウドのセキュリティツールのプロバイダーでもあります。これまでに培った知識に基づいて、AWS クラウドを活用してセキュリティ環境の最新化を図る世界中の組織をサポートしています。特に自動化に注目し、寄稿、講演、指導、AWS コミュニティへの参加を通じて DevOps と従来のセキュリティの橋渡し役を務めています。 SangUk Park SangUk Park は、Megazone のチーフソリューションアーキテクトです。Megazone は、2012 年に韓国初の AWS パートナーとなり、韓国で AWS サポートを提供する唯一の AWS プレミアコンサルティングパートナーです。SungUk は、KT のパブリッククラウドおよび VDI 設計のシステムアーキテクトを務め、YDオンラインおよびネクソンジャパン (大手オンラインゲーム会社の […]

Read More

S3 ストレージ管理アップデート – 分析、オブジェクトのタグ付け、インベントリ、メトリクス

本日、皆様がお持ちのストレージとそのアクセスパターンを詳しく知るための 4 つの S3 機能についてご説明したいと思います。何をどのくらい保管しているのか、どのように使用しているのかを知ることができ、その結果として、S3 ストレージクラスの使用に関する情報に基づいた意思決定を行うことができます。これらの機能は、バケットに何十万、何千、何百万、何十億というオブジェクトを持っていても、S3 を使用するすべての人にとって価値があります。 以下が概要です: S3 分析 – オブジェクトの格納状況と取得パターンを分析し、その結果を使って、最適なストレージクラスを選択することができます。あなたは S3 コンソールで表示される分析の結果を検査したり、お好みの BI ツールにロードし深掘りしても良いでしょう。そうすることで、ストレージの利用傾向を見て、それらが使い方や成長度合いにどのように関連しているのかがつかめます。 S3 オブジェクトのタグ付け – 複数のキーと値のペア(タグ)をそれぞれの S3 オブジェクトに関連付けることができ、いつでも変更することができます。タグは、アクセスの管理と制御、S3 ライフサイクルポリシーの設定、S3 分析のカスタマイズ、CloudWatch メトリクスのフィルタリングに使用できます。バケットをデータレイクと考えることができ、タグを使用してそのデータレイクの中のオブジェクトの分類を作成できます。これは、バケットとプレフィックスを使用するよりも柔軟性があり、オブジェクトの名前を変更、移動、またはコピーせずに意味付けの変更を行うことができます。 S3 インベントリ – S3 インベントリを使用して、ビジネスワークフローやビッグデータのジョブを加速できます。この機能は、毎日または毎週の単位で、バケットの全部または一部の内容(プレフィックスによって識別される)の CSV 形式のフラットファイル表現を提供します。 S3 CloudWatch メトリクス – 13 種類の Amazon CloudWatch メトリクスを監視やアラームを設定することで、S3 を活用するアプリケーションのパフォーマンスを向上させる可能性があります。 詳細を見てみましょう。 S3 分析 S3 のユーザは、標準、標準 IA (標準低頻度アクセス)、Glacier と 3 つのストレージクラスを選択することができます。S3 のオブジェクトライフサイクル管理を使用して、オブジェクトが期限切れになるか、標準 IA もしくは […]

Read More

Amazon CloudWatch がダッシュボードにアラームを追加

Amazon CloudWatch は、AWS のリソースに関するメトリックス、ログ、イベントをリアルタイムで提供および収集することで、アマゾン ウェブ サービスで実行しているアプリケーション、システム、ソリューションをモニタリングできるサービスです。CloudWatch では、リソースのレイテンシー、エラー発生率、CPU 使用率などの主要メトリックスが自動的に測定されます。さらにお客様から提供されたログやシステムデータに基づくカスタムメトリックスのモニタリングも可能です。昨年 11 月、Amazon CloudWatch に新しいダッシュボードウィジェットが追加され、すべてのメトリックスのデータを視覚化できるようになりました。CloudWatch に追加されたダッシュボードのアラームにより、お客様は AWS で実行しているソリューションやリソースの状態を把握しやすくなりました。このアラームの追加により、アラームとメトリックスを同じダッシュボードウィジェットで確認して、データに基づくトラブルシューティングと分析を行うことができます。 CloudWatch のダッシュボードは、複数のリージョンにまたがる AWS リソースを統合されたビューでモニタリングする際の可視性を高めるためのものです。CloudWatch のダッシュボードは高度にカスタマイズ可能であるため、ユーザーは独自のダッシュボードを作成して使用率、パフォーマンス、請求予定額、そして今回のアラーム状態など、さまざまなメトリックスのデータをグラフィカルに表示できます。アラームは、各メトリックスの値と指定したしきい値の関係を経時的に追跡します。アラームの状態が変わると、Auto Scaling ポリシーなどのアクションが実行されます。または、Amazon SNS に通知が送信されます。ダッシュボードにアラームを追加するという新たな方法により、CloudWatch のユーザーは、複数のリージョンにまたがって AWS のリソースやアプリケーションをモニタリングして事前にアラートを受け取る手段が増えました。さらに、ダッシュボードに追加されたアラームでは、メトリックスのデータをグラフで確認できます。アラームには次の 3 つの状態があります。 OK: アラームのメトリックス値はしきい値に達していない INSUFFICIENT DATA: データ不足。最初にトリガされたアラームのメトリックス値は、データ不足のため、[OK] 状態か [ALARM] 状態か判定できない ALARM: アラームのメトリックス値はしきい値に達している ダッシュボードでは、[ALARM] 状態は赤、[INSUFFICIENT DATA] 状態はグレイ、[OK] 状態は無色で表示されます。ダッシュボードのアラームは、Line、Number、Stacked area の各ウィジェットで表示できます。 Number ウィジェット: 目的のメトリックスの最新の値をすばやく効率的に確認できます。最新のメトリックスデータに応じてアラームの状態が変わるたびに背景色が変わります。 Line ウィジェット: 選択したメトリックスのコレクションの実値を線グラフで表示します。ダッシュボードにアラームのしきい値と状態が水平線で示されます。この水平線を境に、しきい値に達しているかどうかが一目でわかります。 Stacked area ウィジェット: […]

Read More