Amazon Web Services ブログ

Category: Compute

新機能 – DynamoDB VPCエンドポイントが出ました

今日(翻訳元記事2017年8月16日)からAmazon Virtual Private Cloud(VPC)でAmazon DynamoDB用エンドポイントがすべてのAWSのリージョンでご利用いただけます。AWS Management ConsoleまたはAWS Command Line Interface(CLI  コマンドラインインターフェイス)を使用して、すぐにエンドポイントをプロビジョニングできます。DynamoDBのVPCエンドポイントには追加費用はかかりません。 多くのAWSをお使い頂いているお客様は、セキュリティまたは分離の理由からAmazon Virtual Private Cloud(VPC)内でアプリケーションを実行します。以前は、VPC内のEC2インスタンスがDynamoDBにアクセスできるようにするには、2つのオプションがありました。インターネットゲートウェイ(NATゲートウェイを使用するかインスタンスの公開IPを割り当てる)を使用するか、すべてのトラフィックをVPNまたはAWS Direct Connect経由でローカルインフラストラクチャにルーティングしてからDynamoDBに戻すことができます。これらのソリューションには両方ともセキュリティとスループットの関係があり、NACLまたはセキュリティグループを構成してDynamoDBだけへのアクセスを制限することは困難でした。下の画像は上記のパターンのアーキテクチャです。 エンドポイントの作成 DynamoDBのVPCエンドポイントを作成しましょう。DescribeVpcEndpointServices APIコールを使用して、指定したリージョンでエンドポイントがサポートされていることを確認できます。 aws ec2 describe-vpc-endpoint-services –region us-east-1 { “ServiceNames”: [ “com.amazonaws.us-east-1.dynamodb”, “com.amazonaws.us-east-1.s3” ] } 上記の結果により、これらのエンドポイントをサポートしていることを確認出来ました。私は自分のVPCの1つを指定して、CLIまたはコンソールからの操作で簡単にエンドポイントをプロビジョニングできます。コンソールの使い方はこれから説明します。 最初に、VPCコンソールに移動し、サイドバーの[Endpoint]を選択します。そこから「Create Endpoint」をクリックして、この便利なコンソールに遷移します。 エンドポイントのAWS Identity and Access Management (IAM) ポリシーセクションに気づくでしょう。これは、通常のIAMポリシーでDynamoDBがサポートする詳細なアクセス制御をすべてサポートし、IAMポリシー条件に基づいてアクセスを制限できます。 今の例ではこのVPC内のインスタンスはフルアクセスし出来るようにして、「次のステップ」をクリックします。 これは私のVPC内のルートテーブルのリストに、これらのルートテーブルのどれに私のエンドポイントを割り当てるかを尋ねています。いずれかを選択して[Create Endpoint]をクリックします。 コンソールの警告メッセージに注意してください。パブリックIPアドレスに基づいてDynamoDBにソース制限がある場合、DynamoDBにアクセスするインスタンスのソースIPはプライベートIPアドレスになります。 DynamoDBのVPCエンドポイントをVPCに追加した後のアーキテクチャは次のようになります。 これでおしまいです!とても簡単で無料で利用する事ができます。是非利用してみて下さい。詳細が必要な場合は、ここでドキュメントを読むことができます。 (SA 成田が翻訳しました。元記事はこちら)

Read More

Lambda@Edge – エッジで HTTP リクエストを”賢く”処理する

昨年、Lambda@Edge のプレビューをアナウンスし、お客様に近いロケーションでHTTPリクエストを”賢く”処理する方法を説明しました。プレビューに応募しアクセスを許可された開発者は Lambda@Edge を有効に活用し、非常に有用な多くのフィードバックをいただきました。プレビュー中に HTTP レスポンスの生成、CloudWatch Logs のサポートを追加し、フィードバックに基いてロードマップを更新しました。 一般提供の開始 本日、 Lambda@Edge の一般提供を開始できることを嬉しく思います。次のように利用できます: A/B テストを行うために cookie を検査し、 URL を書き換える ユーザーエージェントヘッダに基づいて、特別なオブジェクトを返す オリジンにリクエストを許可する前に、特定のヘッダを検索することでアクセスコントロールを実装する ヘッダを追加、削除または変更して様々なキャッシュ済オブジェクトに誘導する HTTP レスポンスを生成する 古い URL 形式のサポート ヘッダや URL を変更または簡略化して、キャッシュ使用率を改善する 他のインターネットリソースへ HTTP リクエストを行い、その結果を使用してレスポンスをカスタマイズする

Read More

新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー

先日DynamoDBのAuto Scalingについてお伝えし、そこでDynamoDBテーブルのキャパシティ管理を自動化するためにどのように複数のCloudWatchアラームを利用しているかをお見せしました。その裏では、これからいくつかの異なるAWSサービスに渡って利用が予定されている、もっと一般化されたApplication Auto Scalingのモデルを使うことでこの機能を実現しています。 新しいAuto Scalingのモデルはターゲットトラッキングと呼ばれる重要な新しい機能を含んでいます。ターゲットトラッキングを使ってAuto Scalingのポリシーを作成する時には、特定のCloudWatchメトリクスに対してターゲットとなる値を選択します。Auto Scalingはそのメトリクスがターゲットに向かう様に適切な(スピーカーで言う)つまみを回し、合わせて関連するCloudWatchアラームも調整します。どういったメトリクスであれアプリケーションにとって意味のあるもので必要なターゲットを指定するという方法は、元々あるステップスケーリングポリシーの様に手動でメトリクスのレンジと閾値を設定するよりも、一般的にはより簡単で直接的なやりかたです。しかし、より高度なスケーリング戦略を実装するために、ターゲットトラッキングとステップスケーリングを組み合わせることも可能です。例えば、スケールアウトにはターゲットトラッキングを使い、スケールインにはステップスケーリングを使う等が考えられます。 EC2に新しい機能 本日、EC2 Auto Scalingにターゲットトラッキングのサポートを追加しました。Application Load Balancerのリクエスト数、CPU負荷、ネットワークトラフィック、またはカスタムメトリクスによるスケーリングポリシーを作成することができます(ターゲット毎のリクエスト数というメトリクスは新しいもので本日のリリースの一部になります)。 これらメトリクスは重要な特徴が共通しています: EC2インスタンスを追加することで(全体の負荷が変化していない時に)、メトリクスを下げることになります。もしくはその逆もです。 ターゲットトラッキングを使ったAuto Scaling Groupを作るのは簡単で、ポリシーの名前を入力し、メトリクスを選択し、希望するターゲットの値を設定するだけです: スケールイン側のポリシーを無効にすることもできます。その場合、手動でスケールインしたり、別のポリシーを使うことができます。 ターゲットトラッキングポリシーは、AWS Management Console、AWS Command Line Interface (CLI)、またはAWS SDKでも作成することができます。 以下は、ターゲットトラッキングを使おうとする時に頭にいれておくべき項目になります: 1つのAuto Scaling Groupに対して、異なるメトリクスを参照している複数のターゲットを設定することができます。スケーリングは常に一番高いキャパシティを求めるポリシーに従います。 メトリクスのデータが不十分な時はスケーリングは発動しません。 Auto Scalingはメトリクスの急速で一時的な変動を補い、関連するキャパシティの急激な変動を最小化しようと努力します。 カスタムメトリクスでのターゲットトラッキングはAuto Scaling APIやAWS Command Line Interface (CLI)で設定することができます。 多くのケースで、1分間隔で入ってくるメトリクス(詳細モニタリングとも言われます)に応じてスケールするように選択すべきです。5分間隔のメトリクスをスケーリングの基本にすると、反応時間が遅くなってしまいます。 本日から利用可能です この新しい機能は本日から利用可能で、追加料金無しに使い始められます。より詳しくは、Auto Scalingユーザガイドのターゲットトラッキングスケーリングをご覧ください。 — Jeff; 原文: New – Target Tracking Policies for EC2 […]

Read More

コンテナやサーバレスアプリのデプロイツールとしてのAWS CloudFormation

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか?については多様なやり方が考えられますが、今日はAWS CloudFormationを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にAmazon ECSやAWS LambdaといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはAWS Command Line Interface (CLI)やSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。 デプロイツールとしてのCloudFormationのメリット 最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 宣言的にデプロイが定義・実行できる アプリケーションに関連する他のAWSリソースも合わせて管理可能 現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。 CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。 もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。 宣言的にデプロイが定義・実行できる AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。 CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。 アプリケーションに関連する他のAWSリソースも合わせて管理可能 ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、AWS Identity and Access Management (IAM)のRoleは良く使われますし、データベースとしてAmazon DynamoDBを使ったり、ECSのコンテナへの負荷分散にElastic Load Balancingを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。 CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。 CloudFormationを使ったECSのデプロイ例 こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。 AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、AWS CodePipelineがデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。 参考のために、Task DefinitionとServiceとIAM […]

Read More

AWS 料金値下げ – EC2 の SQL Server Standard Edition

AWS は 62 回目となる値下げを発表いたします。今回の対象は EC2 の Microsoft SQL Server Standard Edition です。多くのエンタープライズワークロード (特にオンプレミスまたは企業データセンター) は、Microsoft Windows で実行されています。そのグローバルな展開およびパートナーエコシステムによって支えられたサービスの幅広さにより、Windows アプリケーションの構築、デプロイ、スケール、管理には AWS が最適な場所であると考えています。 Adobe、Pitney Bowes、デブリー大学といったお客様は、すべて中核となる実稼働 Windows Server ワークロードを AWS に移行済みです。これらのお客様のアプリケーションは、SharePoint サイトからカスタム .NET アプリケーションや SAP まで広範囲に実行しており、頻繁に SQL Server を使用しています。AWS の Microsoft SQL Server は EC2 Windows インスタンスで実行され、お客様のアプリケーション開発および移行をサポートできます。リレーショナルデータベースをオンプレミスで実行している場合のように、すべての設定を管理でき、32 ビットおよび 64 ビットバージョンのサポートがあります。本日、R4、M4、I3、X1 インスタンスで実行される EC2 上の Microsoft SQL Server Standard Edition のオンデマンドおよびリザーブドインスタンスの料金を、インスタンスタイプ、サイズ、リージョンに応じて最大 52% […]

Read More

EC2 Run Command を使用した、SSH アクセスなしでの大規模なインスタンスの管理

Ananth Vaidyanathan (EC2 Systems Manager のシニア製品マネージャー) および Rich Urmston (Pegasystems のクラウドアーキテクチャのシニアディレクター) によって書かれた次のゲスト投稿は、EC2 Run Command を使用して、SSH を用いることなく EC2 インスタンスの大量のコレクションを管理する方法を示しています。 — Jeff; 多くの場合、エンタープライズは管理対象環境および数千の Amazon EC2 インスタンスを持っています。Secure Shell (SSH) について悩むことなく、システムをセキュアに管理することが重要です。Amazon EC2 Systems Manager の一部である Run Command では、制御され管理可能な方法で、インスタンス (またはタグを使用してインスタンスのグループ) でリモートコマンドを実行できます。これは、Run Command サービスに毎日依存する Pega Cloud オペレーションにとって、生産性を向上するための優れた追加機能です。標準の IAM ロールとポリシーを通じた Run Command の制御、ドキュメントの定義による入力パラメーターの使用、コマンド出力を返すために使用される S3 バケットの制御が可能です。また、他の AWS アカウントや一般ユーザーとドキュメントを共有することもできます。全体として、Run コマンドは優れた一連のリモート管理機能を提供します。 SSH よりも優れる Run Command […]

Read More

Amazon Lightsail、東京リージョンにて提供開始

こんにちは、ソリューションアーキテクトの塚田です。 お待たせしました。現在開催中のAWS Summit Tokyo 2017 キーノートにてアマゾンウェブサービスジャパン株式会社社長の長崎からアナウンスがあったとおり、Amazon Lightsail が東京リージョンにやってきました! インスタンスの作成時に、リージョンとアベイラビリティゾーンで東京(ap-northeast-1)を選択することができます。 Tokyo, Zone A (ap-northeast-1a)を選んでインスタンスの作成をすすめると… 東京リージョンにLightsailのサーバが立ちました! また、東京リージョンでも料金は変わらず、月額$5〜のプランが利用可能になっています。 色々とはかどりますね。  

Read More

ランサムウェア「WannaCry」に関するAWSへの影響について

  2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。 このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。   WannaCryによるAWSサービスへの影響   EC2 Windows   Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。 AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。 AWSのWindows AMIのリリースノートはこちらです。   WorkSpaces   Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。   Directory Service   AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。   Elastic Beanstalk   […]

Read More

EC2インメモリ処理のアップデート: 4TBから16TBのメモリ搭載インスタンスと34TBのSAP HANAスケールアウト

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各AWS製品のロードマップがお客様の要望とフィードバックによってどのように決められているかやりとりします。 その良い例が、SAP社のビジネスソリューションのポートフォリオにとってAWSを魅力的な場所にするための私たちの取り組みです。長年にわたり、お客様はAWS上で大規模なSAPアプリケーションを本番環境で稼働しており、このワークロードに対応するように設計されたEC2インスタンスを提供することに努めてきました。SAPシステムは間違いなくミッションクリティカルであり、SAP社はいくつかのEC2インスタンスのタイプとサイズで彼らの製品を利用できるよう認定しています。私たちは、AWSをSAP製品にとって堅牢で信頼できる基盤にし、認定を取得するために、SAP社と密に連携しています。 ここで、この分野での最も重要なお知らせを簡単にまとめておきます: 2012年6月 – AWS上で利用可能なSAP認定ソリューションの範囲を拡大しました 2012年10月 – AWS上でSAP HANAインメモリデータベースを本番稼働できるようになりました 2014年3月 – 最大244GBのメモリを搭載したcr1.8xlargeインスタンスでSAP HANAが本番稼働し、テスト用途のクラスタはさらに大きく作成できるようになりました 2014年6月 – r3.8xlargeインスタンスのSAP認定と合わせて、SAP HANA導入ガイドとAWS CloudFormationテンプレートを公開しました 2015年10月 – SAP HANA、Microsoft SQL Server、Apache SparkやPrestoを実行するために設計された2TBメモリを搭載したx1.32xlargeインスタンスを発表しました 2016年8月 – X1インスタンスのクラスタを使用して、最大7ノードつまり14TBメモリの本番稼働SAP HANAクラスタを作成することができるようになりました 2016年10月 – 1TBメモリを搭載したx1.16xlargeインスタンスを発表しました 2017年1月 – r4.16xlargeインスタンスでSAP HANA認定を取得しました 現在、幅広い業界のお客様がSAPアプリケーションをAWS上で本番稼働させています(SAPとAmazon Web Servicesのページには、多くのお客様成功例が掲載されています)。 私の同僚のBas Kamphuisが最近、SAPとクラウドによるデジタルジャーニーのナビゲートという記事を書きました(閲覧には登録が必要)。彼は、デジタルトランスフォーメーションにおけるSAPの役割について説明し、それをサポートするクラウドインフラストラクチャの主要な特性を検証しながら、他のホスティングオプションと比較してクラウドのほうが多くの利点を提供していると指摘しています。彼がこの記事でこれらの利点をどのように紹介しているかは以下のとおりです: SAPアプリケーションの本稼働環境としてAWSがより良い場所になるよう、引き続き取り組んでいます。私たちが取り組んでいることのいくつかを以下に示します: より大きなSAP HANAクラスタ – スケールアウトのSAP HANAクラスタを最大17ノード(34TBメモリ)まで構成できるようになりました 4TBのインスタンス – 今度、4TBメモリ搭載のx1e.32xlargeインスタンスを提供します 8から16TBのインスタンス – 16TBまでのメモリを搭載したインスタンスを計画しています 詳細をみてみましょう! より大きなSAP HANAクラスタ SAP社と連携し、x1.32xlargeインスタンスを使用した最大17ノード(34TBメモリ)のスケールアウトクラスタでSAP認定を取得したことをお知らせします。これは、現在のクラウドプロバイダから提供される最大のスケールアウト構成であり、AWS上で非常に大きなSAPワークロードを展開することができます(詳細は、SAP HANA認定ハードウェアディレクトリのx1.32xlargeインスタンスを参照してください)。スケールアウトクラスタの構築および展開方法については、SAP HANA on AWSクイックスタートを参照してください。 メモリ重視のX1ファミリの拡張 お客様のご要望に対応し、確実な成長経路を提供するために、このインスタンスファミリおよび他のインスタンスファミリに引き続き投資します。 今年後半には、複数のAWSリージョンで、オンデマンドとリザーブドインスタンス両方の形式のx1e.32xlargeインスタンスを利用できるようにする予定です。このインスタンスは、(x1.32xlargeの2倍の)4TBのDDR4メモリ、128個のvCPU(4つの2.3 GHz […]

Read More

AWS X-Ray で AWS Lambda をサポート

本日、AWS X-Ray で AWS Lambda サポート の一般提供開始を発表しました。Jeff が GA で投稿したブログですでにご存知の方もいるかと思いますが (「Jeff の GA POST (Jeff’s GA POST)」)、X-Ray は分散アプリケーションの実行やパフォーマンス動作を分析する AWS サービスです。 複数の独立したコンポーネントを異なるサービスで実行するマイクロサービスベースのアプリケーションでは、従来の問題をデバッグする方法がうまく機能しません。アプリケーションでレイテンシーを分けることで、X-Ray はエラーや処理の低下、タイムアウトを迅速に診断することができます。それでは、シンプルな Lambda ベースのアプリケーションを構築し分析する方法をお見せしながら、独自のアプリケーションで X-Ray を使用する方法をご説明します。 今すぐ開始したい場合は、関数の設定ページで追跡を有効にすれば既存の Lambda 関数で簡単に X-Ray を使い始めることができます。 または AWS Command Line Interface (CLI) で関数の tracing-config を更新してください (必ず –function-name も忘れずに): $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ トレースモードをオンにすると、Lambda は関数を追跡しようとします (アップストリームサービスによって追跡されないよう明示的に指示されていない限り)。オフの状態では、アップストリームサービスによって追跡するよう明示的に指示されている場合のみ関数が追跡されます。トレーシングモードをオンにすると追跡の生成が始まり、アプリケーションとその間のコネクション (辺) におけるリソースのビジュアル表現が見られるようになります。 […]

Read More