Category: Management Tools

Amazon RDSは、トラブルシューティングなどの目的にお使い頂けるように、DBインスタンスで生成されたログを表示およびダウンロードする機能を提供してきました。Amazon Relational Database Service(Amazon RDS) for MySQLとAmazon RDS for MariaDBでは、DBインスタンスのログイベントをAmazon CloudWatch Logsに直接保存出来るようになりました。これにより、AWSサービスを使用して、よりシームレスにDBインスタンスログを扱うことができます。 DBインスタンスログのニアリアルタイム分析 Amazon CloudWatch Logsを使用すると、アプリケーションの様々なコンポーネントからのログを集中的かつ永続的に保存できます。また、特定のフレーズ、値、パターン(メトリック)について、ニアリアルタイムでログを監視することもできます。さらに、設定した状態が発生したときに警告するアラームを設定することもできます。Amazon CloudWatchは他の様々なAWSサービスと統合することが可能です。これにより、以下のような幅広いユースケースでログを利用する価値を向上できます: 通常デジではありえない大量のスロークエリや接続の失敗など、異常な状態を検知するためのアラーム設定 他のアプリケーションログと関連させる セキュリティおよびコンプライアンスの目的でログを保持する ログデータの傾向を分析する 以下の図がアーキテクチャの概要です: ログエクスポートの概念 新しいログエクスポート機能は、MySQLおよびMariaDBの次のログタイプをサポートしています: Error log – 起動および停止にデータベースエンジンによって生成された診断メッセージが含まれています General query log – クライアントから受け取ったすべてのSQLステートメントのレコードと、クライアントの接続および切断時間を含みます Slow query log – 設定された時間よりも実行に時間かかったクエリや、定義された行数を超える行を走査したSQL文のレコードが含まれています。 両方の閾値は設定可能です Audit log – MariaDB Audit Pluginを使用して提供されるこのログは、監査目的でデータベースアクティビティを記録します これらのソースからのログイベントは、Amazon CloudWatchのロググループにログストリーム(ログイベントのシーケンス)の形式で保存されます。 各DBインスタンスとログの種類に応じて、DBインスタンスと同じAWS Region内に別のグループを次の命名パターンで作成します: /aws/rds/instance/<db-instance-id>/<log-type> ログデータは耐久性のあるCloudWatch Logsに保存され、透過的に暗号化されます。ただし、ログには機密情報が含まれている可能性があります。データを保護するために、アカウント内の適切なユーザーにアクセスを制限する必要があります。そのために、データベースログを含むロググループに対して適切なIAMアクセスポリシーを設定することが重要です。 Amazon RDSはDBインスタンスと同じアカウント内のロググループにservice-linked roleを使用してログを送信します。これにより、Amazon RDSはアカウント内の関連するロググループにアクセスできます。ログの送信を有効にすると、AWSServiceRoleForRDSという追加のIAMロールが表示されることがあります。 CloudWatch Logsへログの送信を有効にするには、以下のように設定を行います。 […]

WindowsとLinuxのインスタンスやオンプレミスサーバから、Amazon CloudWatchにメトリクスやログファイルを送信するために利用できる、いくつものエージェント、デーモン、そしてスクリプトをこれまで紹介してきました。こうした異なるツールから収集されたデータによって、計算リソースの状態や挙動を可視化することができ、値が正常域を外れた時や問題のある可能性が見られた時にアクションを起こすこともできます。CloudWatch Dashboardsでどんな欲しいメトリクスもグラフにすることができ、CloudWatch Alarmsでアクションを起こすこともでき、CloudWatch Logsでエラーメッセージを見つけるために検索もでき、カスタムの高解像度メトリクスサポートの利点も享受することができます。 新しい統一エージェント 2017年12月14日に、我々はさらに一歩進めて、新しい統一されたCloudWatch Agentをリリースしました。これはクラウドでもオンプレミスでも、LinuxでもWindowsでも実行でき、メトリクスとログファイルを取り扱えます。デプロイするにはAWS Systems Manager (SSM) Run Command、SSM State Manager、またはCLIを利用できます。以下が、いくつかの最も重要な機能になります: 単一のエージェント – メトリクスとログの両方を単一のエージェントで収集できます。これによって、セットアップ手順を簡略化でき複雑さを減らすことができます。 複数プラットフォーム / 複数環境 – 新しいエージェントはクラウドでもオンプレミスでも実行可能で、64-bit Linuxと64-bit Windows上で動かせ、HTTPプロキシもサポートしています。 設定可能 – 新しいエージェントは自動的に最も役に立つシステムメトリクスを取得します。さらに、CPUスレッド、マウントしたファイルシステム、そしてネットワークインタフェースといった、より詳細なメトリクスやサブリソースを数百集めることもできます。 CloudWatch親和性 – 新しいエージェントは標準の1分間隔メトリクスも、新しい1秒間隔の高解像度メトリクスもサポートしています。インスタンスID、イメージID、Auto Scaling Group名等のEC2のディメンジョンを自動的に含めてくれますし、カスタムディメンジョンの利用もサポートしています。全てのディメンジョンを使って、Auto Scaling Groupやアプリケーションにまたがった集約が可能です。 移行 – 既存のAWS SSMとEC2Configの設定から、簡単に新しいエージェントを使う様に移行することができます。 エージェントをインストールする CloudWatch AgentはEC2インスタンスで動く場合にはIAM roleを使い、オンプレミスサーバで動く場合にはIAM userを使います。roleもしくはuserはAmazonSSMFullAccessとAmazonEC2ReadOnlyAccessポリシーを持っている必要があります。以下が私のroleです: これを既に実行中のインスタンスに簡単に追加できます (これは比較的新しいEC2の非常に便利な機能です): SSM Agentをインスタンス上で既に実行しています。もしまだであれば、SSM エージェント をインストールし設定するの手順に従ってセットアップします。 次に、AWS Systems Managerを使ってCloudWatch Agentをインストールします: これは数秒で終わります。これで、簡単なウィザードを使ってエージェントの設定ファイルをセットアップします: […]

AWS CloudTrail Lambda データイベント機能を利用することで、AWS Lambda関数の実行ログを取得できます。今まではLambda管理イベントだけが記録されていましたが、この機能により、関数がいつ誰によって作成、変更、削除されたかという情報も提供します。そしてこれにより、Lambdaデータイベントを記録したり、どの関数が実行されたか、そしていつ誰がどのAPIコールを呼び出したのかという詳細情報も得ることができます。全てのLambdaデータイベントはAmazon S3バケットやAmazon CloudWatch Eventsに送られ、CloudTrailによってイベント記録されたときに応答させることが出来ます。例えば、過去３日間に実行されたLambda関数をすぐに特定することができ、また、それらのAPIコールのソースを特定することもできます。また、不適切なLambda実行を検出した際、不明なユーザーやロールによるAPIコールの制限を迅速に実施することも可能です。 AWS CloudTrailコンソールやAWS CLI、SDKを使うことで、AWS Lambdaデータイベント機能を有効にすることが可能です。新しいトレールを作成するか既存のトレールを編集することで、どのLambda関数のログを取得するかを表示したり選択したりすることが可能です。 AWS CloudTrail Lambdaデータイベントは現在、全てのパブリックリージョン、AWS GovCloud (米国）、中国（北京）で利用可能です。ぜひこちらにてサポートされる全リージョンをご確認ください。   AWS CloudTrail のさらなる詳細情報： ・製品ページ（日本語） ・サポートされるサービス（日本語） ・ドキュメント（日本語） ・リリースノート（英語） — 原文：　AWS CloudTrail Adds Logging of Execution Activity for AWS Lambda Functions  (Posted On: Nov 30, 2017) 翻訳担当：　PSA市崎

私たちはここでWindows AMIを稼働させるAmazon EC2におけるMicrosoftボリュームシャドウコピー(VSS)のサポートをアナウンスできることを嬉しく思います。VSSはMicrosoft Windows(主要なSQL ServerやExchange Serverなどのマイクロソフトアプリケーションを含む互換性のある)環境における非常に一般的なボリュームバックアップ技術です。VSSはファイルの書き込みなどのディスク処理をバックアップ処理実行中も適切に管理するため、アプリケーション一貫性を持ったバックアップが可能となります。 アプリケーション一貫性バックアップは、マシンまたはインスタンスに接続されたボリュームのバックアップと同時に実行され、メモリ内のすべてのデータと処理中のすべてのトランザクションをキャプチャします。 VSSが有効なAmazon EBSボリュームのスナップショット(以降、”VSS有効化スナップショット”と表記) は、Amazon EC2 Systems ManagerのRun Commandから使用可能です。AWSEC2-CreateVssSnapshot コマンドによってWindowsインスタンスのEC2にアタッチされたEBSボリュームを、バックアップ処理の間トランザクションデータの一貫性を失うことなく、アプリケーション一貫性を持ったスナップショットを取得可能です。この機能によってSQL Backupや、カスタムスクリプトなどによって提供されたアプリケーション固有のバックアップソリューションは不要となります。さらに、イメージレベルバックアップにおけるアプリケーション一貫性を維持するためのサードパーティ製ツールも不要になります。 AWSEC2-CreateVssSnapshotの使用方法 VSS有効化スナップショットは、Windowsが稼働するEC2インスタンスに対してAWSEC2-CreateVssSnapshotコマンドをEC2 Systems Manager Run Commandから呼び出すことで実行します。AWS管理コンソールやAWS CLIから実行したり、PowerShellスクリプトやLambda関数から呼び出すことも可能です。本ブログではEC2コンソールからコマンドで実行する例を示します。 EC2管理コンソールで、AWSEC2-CreateVssSnapshotコマンドのドキュメントを選択し、VSS有効化スナップショットを取得したいEBSボリュームを持つインスタンスを選択します。 インスタンスを選択した後、スナップショットに追加したい説明やタグを設定します。ブートボリュームをスナップショット処理から除外することも可能です。 起動されるとRun CommandはVSSコンポーネント(詳細については後述)に対して、EC2 Windowsインスタンス上のVSS対応アプリケーションのすべての処理中のI/Oをコーディネーションするよう指示します。これによってI/OバッファはEBSボリュームに対してフラッシュされ、すべてのI/Oはスナップショット取得が完了するまでフリーズされます。この結果アプリケーション一貫性が維持されます。スナップショットが取得された後、I/Oフリーズが解除され通常処理に復帰します。 Run Commandやスクリプトから取得したスナップショットは、EC2コンソール左側のEBSスナップショットメニューで確認できます。 このプロセスで正常に取得された全てのVSS有効化スナップショットには “AppConsistent:True”というタグが付与されます。本機能についてのより詳細についてはこちらAWSEC2-CreateVssSnapshot のドキュメントを参照してください。 VSS有効化スナップショットを取得するためのEC2インスタンスの準備 インスタンスへのスナップショット許可 : IAMコンソールを開き、”Amazon EC2″サービスに対する以下の権限を許可する新しいポリシーを作成します。 DescribeInstances CreateTags CreateSnapshot またIAMコンソールからAmazon EC2ロールAmazonEC2RoleForSSMに対して上記で作成したポリシーを適用します。さらにこのロールを直接EC2 Windowsインスタンスにアタッチします。 VSSコンポーネントのインストール : VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。 より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。 AWSEC2-CreateVssSnapshot使用する際には、対象のEC2インスタンスに対してEBSスナップショット作成およびタグ書き込み許可のIAM許可が必要となります。コンプライアンスやポリシーの理由から追加のIAM許諾をインスタンスに付与したくない場合には、カスタム可能なサンプルのスクリプトを活用可能です。このスクリプトの詳細についてはこちらAWSEC2-ManageVssIOに関するドキュメントを参照して下さい。 VSS有効化スナップショットのリストアプロセスは通常のEBSスナップショットと同様です。こちらのリストアのサンプルスクリプトも使用できます。このリストア用スクリプトで、指定されたEBSスナップショットからEC2 Windowsインスタンスにリストアすることが可能です。 […]

Carmen PuccioとMandus Mombergによる記事。 CarmenとMandusは、AWSパートナーソリューションアーキテクトで、移行に注力しています。 オンプレミス環境からクラウドへのソフトウェアやサービスの移行は、独自の考慮事項と要件を伴うことは明らかです。移行結果に自信を持たせるには、容易に拡張できる移行戦略が必要です。つまり、ワークフローの大部分を自動化する必要があります。なぜクラウド内の自動化が重要であるのかに関する文書が不足しているわけではありません。この記事では、AWSアドバンスト・テクノロジーパートナーであるCloudEndureを使用して自動化された移行を実行する方法を説明し、自動化されたテストを組み込むことに重点を置いて、アプリケーションが移行後に期待どおりに動作することを確信できます。 オンプレミスからAWSへのワークロードの移行には、慎重な計画と正確な実行が必要です。クラウドに移行するにはさまざまな戦略がありますが、移行を容易にするツールも数多くあります。すべての移行ツールは、ダウンタイムとアプリケーションワークロードの影響を最小限に抑え、AWSへの移行を容易にし、データ損失を最小限に抑える、という共通の目標を持っています。 ワークロードをクラウドにすばやく移動したい場合、通常リホスト方式（リフト＆シフト）に従います。リホスト実行時の課題の1つは、移行されたアプリケーションが期待どおりに実行されていることを手動で確認するのにかかる時間です。適切な移行を検証するための自動化および迅速なテストパイプラインを組み込んだ移行は、成功する可能性が高いだけでなく、反復可能なプロセスを活用し、手動検証時間を短縮することで効率を向上させます。 ソリューションの概要 このブログ記事で説明するソリューションでは、CloudEndureとAWS Database Migration Service（AWS DMS）を使用し、ソースAmazon VPCから目的のAmazon VPCへ、オンプレミスからAWSへの、Go Gitサービス（Gogs）の移行について説明します。このデモのために2つの異なるVPCを使用していますが、このブログポストで使用しているツールの自動化と組合せによって、オンプレミスからAWSへの移行を容易に実現することができます。CentOS 7が稼働するモックソース環境の設定では、AWS CloudFormationとAnsibleの組合せを選択しましたので、あなたのテスト用AWS環境でご確認することができます。 CloudEndureはアプリケーションサーバの移行を担当し、AWS DMSはEC2インスタンス上で実行されているMySQLサーバからGogs DBを、完全に管理されたAmazon RDSデータベースに再構築する役目を負います。このデモンストレーションのためDMSを活用し、RDSへのデータベースのレプリケート方法を示しました。もう1つの選択肢として、データベース移行において、CloudEndureによるEC2へのリホストを行うことができます。 CloudEndureは起動時に、移行後のインスタンスでカスタム後処理スクリプトを呼び出す機能があります。この機能を使用すると、カスタム構成を実行し、自動化された承認テストを実行して、移行されたサーバでアプリケーションが正常に動作していることを確認できます。 移行の信頼性のため、AWS Lambda、AWS SNS、AWS SQS、CloudEndureの後処理機能を活用して、一連のテストを実行するための自動テストパイプラインを構築しています。すべてのテストが正常に完了すると、ソース環境から構築されたイメージを使用して高可用性Gogs環境をデプロイするAWS CloudFormationテンプレートが自動的に起動されます。 次の図は、この記事で取り上げる移行プロセスを示しています。 プロセスの仕組みは次のとおりです。 Ansibleは、AWS Application Discovery Service、CloudEndureエージェント、およびGogsソースサーバの再設定およびテストに使用されるスクリプトをインストールします。 AWS DMSは、GogsソースDBサーバを宛先RDSインスタンスに移行します。 CloudEndureエージェントが実行されると、ブロックレベルのコピーが開始され、GogsソースサーバとAWSの初期同期が実行されます。 CloudEndureが初期同期を完了すると、Continuous Data Protection（CDP）エンジンは新しいデータのリアルタイム同期を開始し、サーバはAWSでのテスト準備完了としてマークされます。 CloudEndure.pyスクリプトはconfig.ymlファイルのhosttomigrate変数に基づいて移行を開始します。 （この変数は、CloudEndureダッシュボードにインスタンス名として表示されます）。 CloudEndure.pyスクリプトはCloudEndure APIを呼び出し、ソースインスタンスの最新のスナップショットからテストインスタンスを開始します。 CloudEndureは、最新のスナップショットから宛先に新しいインスタンスを起動し、CloudEndure.shポストプロビジョニングスクリプトを実行します。このスクリプトは次の処理を行います。 DMSが複製しているRDSインスタンスを指すようにGogsを再構成し、Gogsサービスを再起動します。 Gogsサービスが稼動しているかどうかを確認します。稼働している場合、CloudEndure.shポストプロビジョニングスクリプトはCloudEndure_PostProcessing.pyスクリプトを呼び出します。このスクリプトはCloudEndure Pass / Fail SNSトピックに成功通知を送信します。メッセージの例は次のようになります。 “Message”: “{“instanceId”: ” i-0bb669daff4b1eea1″,”Pass”: […]

Amazon Web Servicesをご利用の皆様に大変喜ばしいお知らせがあります。このお知らせが出来るまで辛抱強く待っていましたが、それも終わりです。 このたびAWS CloudTrailは、全てのお客様に対してあらかじめ有効にされるようになりました。 これにより、何も設定することなく過去7日間のAWSアカウント活動の可視性が提供されます。この新しい、常時有効となる機能には閲覧、検索、後述のCloudTrail Event Historyを通してのダウンロード機能が実装されています。 AWS CloudTrailの有用性をまだ得られてないお客様のために説明させてください。操作上のトラブルシューティングとレビュー、コンプライアンス、監査、セキュリティのための重要なサービスが、全てのお客様に対して提供されていることに興奮を覚えます。 AWS CloudTrailは、サポートされているAWSサービスに対するアカウント活動とイベントを記録します。 AWS CloudTrailは、あなたのAWSアカウントにおいてサポートされたAWSサービスのアカウント活動とイベントを捕捉し、Amazon Simple Storage Service(S3)、CloudWatch logsとCloudWatch Eventsにイベント・ログファイルを送ります。CloudTrailであなたはTrailを一般的につくれますし、その設定がアカウント活動とイベントの補足を可能にします。CloudTrailはまた、AWSアカウントで起こっているAPI活動に可視性を提供することによって、操作上のセキュリティ問題を分析することを可能にさせます。CloudTrailはマルチリージョン構成をサポートします。またCloudWatchとインテグレーションさせると、あなたはモニターしたいイベントのきっかけをつくることができたり、AWS Lambdaにアクティビティの記録を送るためのsubscriptionを生成するこができます。AWSコマンドラインインターフェース(CLI)、AWS Management Console、AWS SDKから、またAWSアカウントの他のAWSサービスからの呼び出しのデータの検索可能な履歴を得られることを、CloudTrailサービスを利用することは意味します。 AWS CloudTrailの主要な機能 Always On：　設定をする必要がなくあらかじめ全てのAWSアカウントで有効化され、全てのアカウント活動履歴の記録 Event History：　閲覧、検索、直近のAWSアカウント活動履歴のダウンロード Management Level Events：　詳細な管理活動情報の取得、例えば、EC2例またはS3バケツの作成、削除と修正 Data Level Events：　Amazon S3オブジェクトにおける全てのAPIアクションとAPIアクションの詳細な情報の記録 Log File Integrity Validation：　S3バケットに格納したログファイルの完全性の検査 Log File Encryption：　あらかじめ、S3のサーバサイド暗号化機能を用いたS3バケットによる全てのログファイルの暗号化。オプションとしてAWS Key Management Service (AWS KMS)によるログファイルの暗号化 Multi-region Configuration：　マルチリージョンからのログファイルの送信設定 AWS CloudTrailのさらなる機能をお知りになりたい場合は、製品詳細ページに記載があります。 私の同僚であるランダル・ハントが私に思い出させてくれました。つまり、お客様の課題の解決を援助するとき、CloudTrailは重要であるということです。ほとんどのAWSの人間、例えばテクニカル・エバンジェリスト・チームに所属する我々またはソリューションアーキテクトチームに所属する人間が言うのは、何が起きているのかという詳細を調べることができるようにCloudTrailを有効化する、ということです。ですのでこのリリースで、AWSコンソールまたはAWS CLI/APIを用いてすべてのお客様がアカウント活動を見ることができる（検索機能や、全てのサポートされたAWSサービスの活動の7日間のアカウント活動履歴をダウンロードする能力を含む）ことは、驚きに値しません。 CloudTrailはあらかじめ有効化されており、すべてのお客様は、現在CloudTrailにてログを取得することができ、またEvent […]

AWS ConfigはAWSリソースの構成とそれらリソースにおけるリレーションシップの管理を行います。そうすることで、必要なリソースを選択し、そのリソースの変更管理を時系列ベースで確認することが可能になります。(詳細はこちらをご確認ください。) またAWS Config RulesはAWS Configを更に強化し、強力なルールシステムを使用してConfigを拡張し、AWSルールの「管理」コレクションと、自分で作成したカスタムルールをサポートします。(AWS Config Rulesの詳細はAWS Config Rules – Dynamic Compliance Checking for Cloud Resourcesをご確認ください)。ルール(AWS Lambda ファンクション)では、AWSリソースのあるべき姿(適切に構成されているか、コンプライアンス準拠しているか)を定義します。構成に変更が検出された際に、必要なファンクションが呼び出され、構成がコンプライアンス要求に準拠しているかの確認を行うことができます。 すでに36のルールがAWSから提供されています。下記はEC2に関連するリソースの状態を確認するルールの一例になります。 新しく追加された２つのルール 本日、S3バケットを安全にご利用頂くために、新たに2つのマネージド ルールが追加されました。これらのルールは数クリックで有効にすることが出来ます。追加された2つのルールは以下になります。 S3-bucket-public-write-prohibited：誰でも書き込みが可能に設定されているバケットを自動的に検知します。意図的に設定をするケースも稀にありますが、そうすることで悪意のあるコンテンツを誰でも書き込めるようになり、かつ既存のコンテンツも削除(上書き)をされてしまいます。このルールはアカウント内のすべてのバケットに対し適用されます。 S3-bucket-public-read-prohibited：グローバルに公開されてれいるバケットを自動的に検知します。これにより、公開されているウェブサイトやドキュメントなどのコンテンツにフラグが立てられます。 このルールは、アカウント内のすべてのバケットもチェックします。 既存のルールと同様に、スケジュールベースでの実行も可能ですし、AWS Configによる構成変更の検知をベースに実行することも可能です。 これらの評価はミリセカンドの単位で実行され、1アカウント内の100つのバケットの評価を1分以内で実行できます。その裏では、ルールは推論エンジンにより評価され、多項式時間で判定可能な最先端の制約解決手法が活用されています（P≠NP予想の解決はされず、話が異なります）。これはAWSにおいても、大きなチャレンジでAWS re:Inventのセッションでも触れられています： Automated Formal Reasoning About AWS Systems :   本日から利用可能です これら２つのルールは本日よりご利用できます。既存のルールと同様に、1つのルールあたり、1ヶ月2ドルとなります。 –Jeff 翻訳はPartner SA酒徳が担当しました。(本文はこちら)

このポストはアマゾンウェブサービスのソフトウェア デベロッパーエンジニアであるLusha Zhang によって書かれました。   Amazon EC2 Sysmtes Mangager の一部であるパラメータストアは、平文データ（データベース文字列）または秘密情報データ（パスワード、APIキーなど）を問わず、設定データを管理するための集中化された暗号化ストアを提供します。パラメータストアはAWS CLI、API、およびSDKを介して利用できるため、AWSラムダやAmazon ECSなどのAWSサービス間でパラメータを簡単に参照できます。   パラメータストアのその他の記事については、以下を参照してください： Managing Secrets for Amazon ECS Applications Using Parameter Store and IAM Roles for Tasks Use Parameter Store to Securely Access Secrets and Config Data in AWS CodeDeploy   パラメータストアは最近、階層化サポートとパラメータのタグ付け、及びCloudWatchイベント サポートをローンチしました。これらの機能によって大規模にパラメータを組織化し、管理することが可能になりました。このポストでは、これらの新しい機能を使ってセキュリティ機能を拡張し改善する方法を示します。   階層化パラメータ パラメータストアの階層化サポートによって、組織構造に基づいたパラータの構造化が可能となります。これはパラメータの編成、クエリ、および権限管理のための強力なツールを提供します。   一般的なDevOpsのシナリオでは、開発、ベータ、本番の異なる環境に対してソフトウェアの展開を自動化します。例えば、デプロイメント設定を作成する時に、設定を保存するためにパラメータストアを利用できます。おそらく各デプロイメント環境に最低限の健全なホスト数やパーセンテージを設定しなければならず、それらを環境ごとに異なる値でパラメータストアに保存したいと思うでしょう。   Step1. デプロイメント設定のパスを作成する 次のコマンドを使用して、保存するパスとパラメータを作成します： aws ssm […]

AWS CloudFormation は、AWS を利用するお客様の Infrastructure as Code モデルの実現に役立ちます。環境やアプリケーションを手作業でセットアップする代わりに、テンプレートを構築しそれを使用することで必要な全てのリソース ― これら一連のリソースは CloudFormation スタックと呼ばれます ― を作成します。このモデルでは、手作業に起因する失敗が発生する可能性が排除され、効率性が増し、時間が経過しても一貫した設定が保証されます。 本日、CloudFormation がよりいっそう便利になる新機能についてご紹介したいと思います。この新機能は、複数の AWS アカウントおよび/または複数のリージョンを利用する状況において Infrastructure as Code を実践するときにお客様が直面する課題の解決に役立つように設計されています。 アカウント ― 以前お話したように、多くの組織で多数の AWS アカウントが使用されます。AWS アカウントを階層化し、組織単位、あるいはOU（詳しく知りたい場合は「AWS Organizations – 複数の AWS アカウントのポリシーベースの管理」をお読みください）へグルーピングするために AWS Organizations が利用されています。事業、アプリケーション、そしてデベロッパーに対して複数のアカウントが運用されます。またアプリケーション毎に、開発、テスティング、ステージング、そして本番のそれぞれに対して別々のアカウントが作成されることもあります。 リージョン ― 巨大な（かつ今なお成長し続ける）AWS のリージョンもまた大いに活用されています。2つかあるいはそれ以上のリージョンにまたがるグローバルアプリケーションが構築され、洗練されたマルチリージョン・ディザスタリカバリ・モデルが実装されています。また、S3、Aurora、PostgreSQL、そして MySQL のデータをリアルタイムにレプリケートし、国や地域の規制にしたがって機密データを保管および処理するための場所を選択します。 複数のアカウントやリージョンへのこのような展開は、ガバナンスと一貫性に関していくつかの新しい課題をともないます。新しく作成される各アカウントが社内の標準に従って設定されていることを確認したいと、お客様は言われます。とりわけ、IAM ユーザーと IAM ロール、VPC と VPC サブネット、セキュリティグループ、コンフィグルール、ロギング、そして AWS Lambda 関数を、信頼性があり一貫した方法でセットアップしたいと望まれます。 スタックセットのご紹介 これらの重要なご要望を解決するために、本日 CloudFormation […]

Amazon CloudWatch は 2009 年以来 AWS の重要な要素となっています。3 つの同時リリース (Auto Scaling、Elastic Load Balancing) の 1 つとして公開された CloudWatch は、AWS リソースや AWS クラウドで実行するアプリケーションをモニタリングする非常に強力なサービスに進化しました。CloudWatch カスタムメトリクス (2011 年にリリース) は CloudWatch でビジネスおよびアプリケーションメトリクスを保存できるようにし、グラフ表示や CloudWatch アラームをベースにアクションを開始することができます。数年間に渡り CloudWatch にいくつもの強化点を施してきたことは言うまでもありません。最近ではメトリクス保存期間の延長 (およびユーザーインターフェイスの更新)、ダッシュボード、ダッシュボードでの API/CloudFormation のサポート、ダッシュボードにアラームなどを追加してきました。 最初はメトリクスを 5 分間隔で保存していましたが、ユーザーから寄せられたリクエストに応え、2010 年にこれを 1 分間隔に変更しました (詳細モニタリング)。これについては高い評価を頂きましたが、そろそろレベルアップさせる時期が来ました。AWS をご利用されているお客様は 1 日に多数の動画をストリーミングしたり、フラッシュセールを行ったり、コードをいくつもデプロイしたりしています。さらに、状況が変わるに連れてすばやくスケールインまたはスケールアウトするアプリケーションも実行しています。こうした様々な状況において 1 分間隔では詳細性に欠けることになります。また、重要で一時的な増加を見逃してしまう可能性もあります。異種 (でありながら関連性のある) イベントを時間と関連付けるのは困難です。何か支障があった場合の MTTR (mean time to repair – 平均修復時間) に時間が掛かることもあるでしょう。 […]