Amazon Web Services ブログ

Tag: AWS Lambda

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More

AWS CloudTrail にAWS Lambda 関数の実行ログ機能を追加

AWS CloudTrail Lambda データイベント機能を利用することで、AWS Lambda関数の実行ログを取得できます。今まではLambda管理イベントだけが記録されていましたが、この機能により、関数がいつ誰によって作成、変更、削除されたかという情報も提供します。そしてこれにより、Lambdaデータイベントを記録したり、どの関数が実行されたか、そしていつ誰がどのAPIコールを呼び出したのかという詳細情報も得ることができます。全てのLambdaデータイベントはAmazon S3バケットやAmazon CloudWatch Eventsに送られ、CloudTrailによってイベント記録されたときに応答させることが出来ます。例えば、過去3日間に実行された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市崎

Read More

AWS Serverless Application Repository が登場します

私が想像していた以上に早くサーバレスアプリケーションはメインストリームになりました。毎日毎秒、数え切れないほどの AWS Lambda ファンクションが起動され、ビジネスクリティカルな処理を実行しています。ユーザの皆さんは その柔軟性、安定性、コスト効率の良さを好きだと言ってくれます。 私たちはすべてのAWSのお客様がサーバレスな未来へ向かえるようにしたいと考えています。AWS Lambdaのサービス提供開始後、サーバレスアプリケーションのデプロイおよび管理プロセスを簡素化するため Serverless Application Model (SAM) を提供しました。さらにサーバレスのリファレンスアーキテクチャを公開しました。現在、Web アプリケーション、モバイルバックエンド、画像認識&処理、リアルタイムファイル処理、IoTバックエンド、MapReduce、リアルタイムストリーミング処理、そしてチャットボット向けの画像加工 を公開しています。 2017年11月30日、私たちは次のステップをお伝えします。AWS コンソールからサーバレスアプリケーションを可能な限り容易に探し、見つけ、デプロイできるようにします。加えて Lambda、SAM、サーバレスアプリケーションに関するオープンソースコミュニティをサポートするため、誰もが共有し、参加し、メリットを得られる場を提供します。

Read More

オートメーションを活用したCloudEndureによるAWSへの容易な移行

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

Read More