Category: Management Tools*

この度、AWS のサービス全てが GDPR (EU 一般データ保護規則) に準拠しましたことをご報告致します。この準拠によって、お客様は、AWS がサービスのセキュリティを維持する目的で、すでに講じているさまざまな対策から得られるメリットに加え、GDPR に準拠する計画の重要な構成要素として AWS のサービスを導入できるようになります。 この発表は、GDPR サービス準備状況に対する監査がすべて完了したことを示しており、これはすなわち、GDPR がデータ処理者に要求するプライバシーに関する高いハードルとデータ保護基準に対し、一般的に利用可能な AWS のすべてのサービスと機能が準拠したことを示しています。この作業は、GDPR の施行開始日となる 2018 年 5 月 25 日の 2 か月前に完了しています。これにより、独自の GDPR 準拠の製品、サービス、ソリューションを、自信を持って構築できる環境をお客様や APN パートナーの皆様に提供するものです。 AWS が GDPR サービスの準備を完了したことは、今回の発表内容の一部に過ぎません。私たちは GDPR への準拠を支援するため、お客様と APN (AWS Partner Network) の皆様との協力を継続していきます。この発表に加え、お客様自身が GDPR 準拠への取り組みを加速するために AWS がどのようにお役に立てるかについて、以下に例を挙げ、ご紹介いたします。 個人データのセキュリティ GDPR サービス準備状況に対する監査では、AWS が GDPR に従って個人データを保護する目的でデータ処理者に対し技術的および組織的措置を効果的に講じていることを、私たちのセキュリティと法令遵守の専門家が確認しています。私たちにとってセキュリティは依然として最優先事項であり、イノベーションを継続させ、あらゆるグローバルオペレーションにおいてセキュリティと法令遵守のための高い基準を達成できるように投資していきます。私たちが持つ業界最高レベルの機能では、国際的に認知されているさまざまな認証や認定の基盤を提供し、厳しい国際規格に準拠できることを実証しています。準拠している国際規格には、技術的な対策に関する ISO 27001、クラウドセキュリティに関する ISO 27017、クラウドプライバシーに関する ISO 27018、SOC […]

AWS Cloud9 は 2017年11月の AWS re:Invent で発表されました。Cloud9 はブラウザベースの IDE で、サーバレスアプリケーションも含め、数多くのクラウド上の開発ユースケースに適しています。AWS CloudFormation を使うことで AWS CodeCommit と連携した AWS Cloud9 の開発環境を迅速に構築することができます。このブログでは、CloudFormation を使った Cloud9 環境の構築手順を説明します。さらに Cloud9 の環境で Python と Boto3 のコードを書き、 Troposphere を使って CloudFormation の YAML テンプレートを生成する方法についても説明します。

多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか？ 画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか？ Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。

AWS CloudTrail ログを簡単に視覚化できることは、AWS インフラストラクチャがどのように使用されているかについてより良い理解を提供してくれます。また、AWS API コールの監査とレビューを行って、AWS アカウント内のセキュリティ異常を検知するためにも役立ちます。これを行うには、CloudTrail ログに基づいた分析を実行できる必要があります。 この記事では、Amazon S3 内の AWS CloudTrail ログを JSON 形式からクエリ用に最適化された形式のデータセットに変換するための AWS Glue と AWS Lambda の使用について詳しく説明します。その後、Amazon Athena と Amazon QuickSight を使用してデータをクエリし、視覚化します。 ソリューションの概要 CloudTrail ログを処理するには、以下のアーキテクチャを実装する必要があります。 CloudTrail は Amazon S3 バケットフォルダにログファイルを配信します。これらのログを正しくクロールするには、S3 バケットの単一フォルダ内に変換済みファイルを格納する Amazon S3 によってトリガーされる Lambda 関数を使ってファイルコンテンツとフォルダ構造を変更します。ファイルが単一のフォルダ内にある場合、AWS Glue はデータをスキャンし、それを Apache Parquet フォーマットに変換して、Amazon Athena と Amazon QuickSight を使用したクエリと視覚化を可能にするためにカタログ登録します。   チュートリアル ソリューションを構築するために必要なステップを見て行きましょう。 CloudTrail ログのセットアップ 最初に、S3 バケットにログファイルを配信する証跡をセットアップする必要があります。CloudTrail […]

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コンポーネントのインストール : 2017年11月以降のMicrosoft Windows Server AMIイメージにはVSSコンポーネントはプリインストールされています。もし使用しているWindowsインスタンスのパッケージが最新でない場合は、VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。 より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。 […]

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 […]