Amazon Web Services ブログ

本日より、3つの人気のあるPostgreSQLのExtensionが、RDS PostgreSQLにてサポートされるようになりました。

ip4r - ip4r extension は、単一のIPv4アドレスから任意の範囲のIPv4やIPv6のアドレス帯に及ぶIPアドレスデータ型をサポートします。

pg_buffercache - pg_buffercache extensionは、共有バッファキャッシュで何が起きているかをリアルタイムに確認する方法を提供します。

pgstattuple - The pgstattuple extension モジュールは、リレーションの物理的な長さ、バキュームが必要かどうか決定するのに役立つ"不要"なタプルの割合などのタプルレベルの統計情報を入手するための各種関数を提供します。

新しいExtensionに加えて、追加機能を提供するためのRDS PostgreSQLに、3つの新しいパラメータが追加されています。

rds.force_admin_logging_level -これにより、RDSのインターナルユーザー(rds_admin)によるDBインスタンス内での操作を記録し、PostgreSQLのエラーログに出力できます。

rds.force_autovacuum_logging_level - これは autovacuum workerによるDBインスタンス内の全データベースでの操作を記録し、PostgreSQLのエラーログに出力できます。

rds.rds_superuser_reserved_connections - これにより、PostgreSQLのスーパーユーザーに設定できるように、rds_superuserによる接続を予約できます。

これらの3つのExtension、rds.rds_superuser_reserved_connections parameterパラメーターは、PostgreSQL9.4.5以上のRDSで利用可能です。もし、あなたのデータベースがPostgreSQL9.4の古いバージョンがインストールされていれば、"Modify"ボタンをクリックし、9.4.5を利用可能なバージョンリストから選択してください。もし、PostgreSQL9.3がインストールされていた場合は、RDS documentationの手順に従い、9.4.5にメジャーアップグレードする必要があります。rds.force_admin_logging_level と rds.force_autovacuum_logging_level のパラメーターは、PostgreSQL9.4.5とPostgreSQL9.3.10で利用可能です。

新しいパラメーターについての、詳細はRDS ドキュメント(本ブログ公開時点では英語のみです)で確認してください。

AWS User Guideにて、すべてのPostgreSQLのExtensionを確認できます。もし、あなたが利用したいExtensionがリストになければ、AWS Forumや営業、TAM、rds-postgres-extensions-request@amazon.com にリクエストをいただければと思います。

- 江川(原文はコチラ)

クイックスタートは、AWS クラウドでの主要なワークロード向けに自動化されているリファレンスデプロイです。クイックスタートでは、セキュリティと可用性のためのAWSベストプラクティスに基づき、AWSのコンピュート、ネットワーク、ストレージ、AWS上の特定のワークロードを展開するために必要な他のサービスを設定し、実行します。

このクイックスタートでは、AWSクラウド上のChef Serverの展開を自動化します。Chef Serverは、Chefの自動化プラットフォームにおける高いスケーラブルな基盤です。AWSクラウド上で動作する動的なインフラストラクチャーを作成し、管理するためにChef Serverを使用するか、オンプレミスのデータセンターにあるサーバーを管理することができます。

クイックスタートでは、インフラストラクチャの自動化を簡単に実現するために、AWS Marketplaceにある公式なChef ServerのAMIを使用しています。Chef Analytics、Chef Management Console、そして、Chef Reportingが、Chef Serverには含まれており、Chef Premium FeaturesとAWSの利用料金が合わせ、時間ごとに請求され、5-250ノードの管理をすることができます。また、オプションで、Chef Workstationと管理ノードを含めるように選択することも可能です。

クイックスタートには、ソフトウェア展開のためのステップバイステップの手順を記載したデプロイガイドが含まれています。また、Chef Workstationの設定方法や、Cookbook、ChefのコマンドラインツールによるEC2インスタンスでの起動時設定など、Chefの使用を開始する手順を説明しています。

AWS上のシェフのサーバーを開始するには、下記を参照してください。

Chef Server on the AWS Cloud : クイックスタートリファレンスデプロイ - HTML | PDF
他のAWSクイックスタートリファレンスデプロイの参照と実行

翻訳：瀧澤与一（原文： https://aws.amazon.com/jp/about-aws/whats-new/2015/12/chef-server-on-the-aws-cloud-quick-start-reference-deployment/）

AWS Directory Serviceで、Microsoft Active Directory (AD)をマネージドサービスとして動作できるようになりました。AWS Directory Service for Microsoft Active Directory (Enterprise Edition)、またはMicrosoft ADはWindows Server 2012 R2をベースとしています。ディレクトリタイプを選択して起動すると、自分のVirtual Private Cloud (VPC)に接続されたドメインコントローラーの高可用性ペアが作成されます。ドメインコントローラーは選択に応じてリージョン内の異なるアベイラビリティゾーンで動作します。ホストの監視とリカバリ、データのレプリケーション、スナップショット、そしてソフトウェアアップデートが自動的に構成されて管理されます。

Microsodt ADはMicrosoft SharePoint、カスタムの.NETおよびSQL Serverをベースにしたアプリケーションなどディレクトリ対応のワークロードをAWSクラウド上で動作させることを可能にします。さらにAWSクラウド上のMicrosoft ADと、既存のオンプレミスのMicrosoft Active Directoryとの信頼関係を構成して、シングルサインオン(SSO)をつかってユーザーとグループにお互いのドメインにあるリソースへのアクセスを提供することができます。

AWS Directory ServiceはAWSクラウド上のディレクトリのセットアップと実行、またはAWSリソースを既存のオンプレミスのMicrosoft Active Directoryに接続することを簡単にします。ディレクトリを作成すると、それを使用してユーザーとグループの管理、アプリケーションとサービスに対するシングルサインオンの提供、グループポリシーの作成と適用、Amazon EC2 LinuxとWindowsインスタンスのドメイン参加、さらにクラウドベースのLinuxおよびMicrosoft Windowsワークロードのデプロイと管理をシンプルにすることができます。

詳細を知るためにはAWS Directory Service documentationのページを参照してください。はじめる準備ができているのであれば、750時間のDirectory Service利用を提供する無料使用枠のなかでサービスをためすことができるため、一ヶ月のあいだ単一のディレクトリを継続的に稼働させるには十分でしょう。

（翻訳は渡邉（@gentaw0）が担当しました。原文はAnnouncing Managed Microsoft Active Directory in the AWS Cloud）

1. 本日より既に起動しているAmazon RDS DBインスタンスのポート番号を変更可能になりました。今まではRDS DBインスタンスを起動する際にポート番号を指定出来、起動後に変更することが出来ませんでした。今回の機能追加によりファイアーウォールやアプリケーションの変更に追従することが可能になり、任意のタイミングでデータベースのポート番号を変更出来ます。この機能は、全てのAWSコマーシャルリージョンの全てのRDSエンジンで利用可能です。(原文はこちら)

2. Amazon Relational Database Service (RDS) では現在MySQL5.5 と MySQL5.6をサポートしています。本日より、MySQL5.5データベースエンジンでスタンダード (M4) / メモリ最適化 (R3) / バースト型 (T2) インスタンスファミリーをご利用頂けるようになりました。Amazon RDSで利用出来るインスタンスについて更に詳細な情報はインスタンスクラスページをご覧下さい。(原文はこちら)

-- 星野

私たちはAmazon Auroraを昨年発表し数ヶ月前にリリースしました(詳細は【AWS発表】Amazon Aurora - Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください)。お客様のAmazon Auroraへのご興味やAmazon Auroraを採用したシステムが増えてきています。そして、Amazon AuroraはAWSサービスの中で最も速く発展しているサービスとなりました！そして、最近のリリースとしてAsia Pacific(東京)リージョンで日本やその周辺のお客様にご利用頂けるようになりました(既に US East (Northern Virginia),US West (Oregon), and Europe (Ireland)リージョンではご利用頂けていました)。

リソースの暗号化

暗号化はデータを保護する方法として重要な事の1つです。本日、Amazon Auroraに保存するデータの暗号化を容易に行う方法をリリースしました(リソースの暗号化(encryption at rest)として知られている方法です)。RDSで提供している他の暗号化オプションと同様に、データベースインスタンス作成時に、AWS Key Management Service (KMS)より暗号化キー(AWS-managedかcustomer-managed)を選ぶだけです。

rds_encrypt_aurora_db

暗号化(AES-256)は、データベースに保存されるデータ、ログ、バックアップ、スナップショット、リードレプリカに適用されます。すでに起動しているデータベースインスタンスに対して、このオプションを無効化したり有効化することが出来ないため、データベースインスタンス作成時に暗号化オプションを有効にする必要があります。詳細はこちらをご覧ください。

ご自身のKeyを指定した場合は、1年毎のKeyローテーションを設定する事が可能です。

kms_key_rotate_turn_turn_turn API操作のログを取得するためにAWS CloudTrailもご利用頂けます。有効にする事で、監査のためにKMSへの全てのAPIコール(EncryptやDecrypt操作を含む)をトラッキングする事が可能です。設定方法などの詳細はドキュメントをご覧ください。

P.S. Amazon Auroraはデータ転送時の暗号化にAES-256を使用しています。

-- Jeff (翻訳は星野が担当しました。原文はこちら)

Amazon CloudWatch LogsをAmazon S3へバッチエクスポートする機能が利用可能になりました。

CloudWatch Logsで、ほぼリアルタイムに近い形でご自身のシステムやアプリケーションログを集めて、監視し、保管することができます。本日の発表により、指定したS3バケットへ保存したログデータをバッチでエクスポートすることが出来るようになりました。バッチにより一旦S3へログデータが転送されると、こちらのデータをさまざまな処理や分析、あるいは他のシステムへロードすることが可能となります。バッチエクスポートはAmazon CloudWatch Logsサービスの価格として含まれます。S3に保存したログデータへは標準のS3ストレージ料金が適用されます。

利用開始するには、Amazon CloudWatch Logsコンソールへアクセスして、エクスポートするためのロググループを選択し、アクションメニューにある"データをS3にエクスポート"を選択してください。またはAmazon CloudWatchバッチエクスポート開発ガイドをご覧ください。Amazon CloudWatch Logsを利用開始する方法については、CloudWatch Logsの使用開始をご覧ください。価格についての詳細は、Amazon CloudWatch価格およびAmazon S3価格ページをご覧ください。

翻訳は舟崎が担当しました。原文はこちらです。

AWS Service Catalogでは、組織内で承認済みのITサービスカタログの作成や管理を行うことができます。これらのITサービスには、仮想マシンのイメージや、サーバ、データベース、完全なマルチティアのアプリケーションアーキテクチャを全て含めることができます。

AWS Service Catalogは、ITサービスの展開することを集中管理でき、一貫性のあるガバナンスの実現と、ITサービス部門が要求するコンプライアンスを満たすことができます。

AWS Service Catalogは、米国東部（バージニア）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（東京）の地域で現在利用可能です。詳細については、当社のウェブページを参照してください。

翻訳：瀧澤与一（原文： https://aws.amazon.com/about-aws/whats-new/2015/12/aws-service-catalog-now-available-in-the-asia-pacific-tokyo-region/）

エンタープライズのお客様と会話すると、オンプレミスの仮想化環境に対する過去の投資をどのように活用すれば良いかというご質問を頂きます。多くの場合、この質問の意図は開発やデプロイ、認証といった各プロセスを推し進めるために、既に構築済みのゴールデンイメージを利用したいというものです。

このご質問へのご回答として、AWSではVM Import/ExportとAWS Management Portal for vCenterという2つのツールをご用意しています。これらのツールは構築済みの仮想マシンイメージをAWSにインポートし、短時間で利用をスタートすることを可能にします。

本日より、これらのツールは新たなオペレーティングシステムに対応いたしました。これに加えて、AWS Management Portal for vCenterでは複数の仮想ボリュームを備えた仮想マシンのインポートが可能になりました。

新たなオペレーティングシステムのサポート

今回のアップデートにより、新たに以下のオペレーティングシステムのインポートに対応いたしました。（対応OSの詳細や前提条件についてはこちらをご参照ください）

SUSE/SLES 11-12
Oracle Enterprise Linux 6-7
Fedora 19-21
Windows 10（ライセンスについてはこちらをご参照ください）

AWS Management Portal for vCenterのアップデート

AWS Management Portal for vCenterを利用すると、VM Import/ExportでサポートするすべてのOSイメージのインポートが可能です。今回のアップデートにより、複数の仮想ボリュームを備えた仮想マシンのインポートにも対応いたしました。インポートプロセスはAmazon Machine IMage(AMI)とEC2インスタンスを作成します。

インポートプロセスはポータル画面で以下のように確認することができます：

この新機能をご利用頂くためには、ポータルの自動アップグレード機能を有効にするか、最新バージョンを手動でダウンロードする必要があります。

これらの機能は本日よりご利用いただけます！

（翻訳は小林が担当しました。原文はNew VM Import Options for EC2です。）

停止および再起動したバックエンドインスタンスの Elastic Load Balancing への自動再登録が可能になったことをお知らせします。
この機能を利用し、不要となった EBS-backed インスタンスを停止することで、Amazon EC2 のコストを削減することが可能となります。
ロードバランサに登録されている停止したインスタンスを再起動すると、自動再登録機能により自動的にロードバランサのサービスに復帰します。
これによりEC2インスタンスを停止および再起動した際、ロードバランサにバックエンドのEC2インスタンスを手動で再登録する必要がなくなります。

ロードバランサへのEC2インスタンスの登録についての詳細は、こちらをご覧ください。
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-deregister-register-instances.html

翻訳：辻正史（原文： Elastic Load Balancing: Support for Automatic Re-registration of EC2 Back-end Instances When Stopped and Restarted）

AWS Directory Serviceは既存の企業IDを使用したAWSサービスへのアクセスやディレクトリの可用性に依存したMicrosoft WindowsやLinuxアプリケーションのクラウドベースでのデプロイを可能にします。昨年、2つのタイプのディレクトリ（AD ConnectorとSimple AD）をローンチしました。詳細はこちらの記事、New AWS Directory Serviceを参照してください。

先週のおわりに3つ目のオプション、Windows Serverマネージド型Microsoft Active Directoryのサポートをローンチしました。このオプションを選択すると、50,000ユーザー（およそ200,000のユーザー、グループ、コンピュータをふくむディレクトリオブジェクト）までをサポートするように設計されたMicrosoft Active Directoryを利用することができます。ディレクトリはVirtual Private Cloudの中にある2つの分離されたAvailability Zoneで動作します。

プロビジョニングは簡単で迅速（25～30分）、かつ素直です。マネージドサービスなので、一般的な管理タスクについては心配する必要はありません。これにはホストの監視と自動的な交換、データのレプリケーション、スナップショットによるバックアップ、そして自動的なソフトウェアアップデートがふくまれます。AWSではよくあることですが、管理に費やす時間を削減してアプリケーションやビジネスにより多くの時間を使えるようになります。

ユースケース
このローンチによって、ディレクトリを意識したワークロードの稼働がより簡単になります。これにはMicrosoft SharePointや.NETおよびSQL Serverを使用したカスタムアプリケーションなどがあります。

システム管理者はユーザーとグループメンバーシップの管理、LinuxとWindowsコンピュータのドメイン参加、Kerberosシングルサインオン（SSO）、グループポリシーの適用、そしてドメイン間の信頼関係の作成が可能です。さらに既存の企業クレデンシャルを使用してAWS Management ConsoleにログインしてAWSリソースを管理することができます。

ディレクトリのプロビジョニング
AWS Directory Service Consoleからマネージド型Active Directoryをプロビジョンすることができます。コンソールをひらいて、Get Started Nowをクリックし、Create Microsoft ADを選択します：

名前（わたしはdir.jeff-barr.comをつかいました）を入力して、管理者パスワードをセットアップし、VPCを選択してふたつのサブネットをえらびます：

そしてNext Stepをクリックして設定をレビューしAWS Directory Serviceの無料利用枠の条件について理解したことを確認したら、Create Microsoft ADをクリックします：

ディレクトリのリストをひらいて、電子メールをチェックしたり、犬の散歩をしたりしてステータスがActiveになるまでまちます（ときどき更新アイコンをクリックしながら）：

そして通常のやり方でディレクトリに接続して、グループとユーザーの作成、そして上記の恩恵が受けられるようになります。

コンソールからスナップショットを作成（そしてのちほどリストア）ができます；ナビゲーションバーのSnapshotsを選択してCreate Snapshotをクリックするだけです。

価格と利用可能なリージョン
マネージド型のMicrosoft Active Directory Serviceは現在US East（北バージニア）、US West（オレゴン）、Europe（アイルランド）、Asia Pacific （シドニー）、そしてAsia Pacific（東京）リージョンで利用できます。1ヶ月（750時間の利用）を無料で使用することができます。その後、US East（北バージニア）リージョンでは$0.40/時の支払いが発生します；ほかのリージョンの価格についてはAWS Directory Service Pricingのページを参照してください。

— Jeff;（翻訳はSA渡邉（@gentaw0）が担当しました。原文はAWS Directory Service Update – Support for Managed Microsoft Active Directory）

これまで、多くのAWSのお客様やパートナー様からAWSサービスの価格情報にプログラマティックにアクセスできる方法が無いかというお問い合わせを頂いてきました。この情報は様々な方法で利用することができます。AWSの採用を検討中のお客様は、オンプレミスのワークロードをクラウドへ移行するフィージビリティとコスト効果を評価し、”損得を考える”ことを欲しています。AWSをご利用中のお客様やパートナー様は、予算の計上や費用予測、分析のためのツールが、AWSのWebサイトからの抽出に頼らずに価格を分析できるようにしたいと考えています。AWSのマネージドサービスパートナーは、(Consolidated Billingでグループ化されている)数万のリンクされたAWSアカウントを作成、管理しており、お客様に対して提示する請求書に各リソースの費用を反映しなければいけません。

新しいAWS Price List API
このようなお客様のニーズに対応し、コスト管理や予算の計上などによりフォーカスしたツールの開発を促進するため、AWS Price List APIを発表します。このAPIによって、JSONとCSVのフォーマットで価格情報にアクセスできるようになり、必要に応じてこの情報をダウンロードして処理することが出来ます。更に、価格情報が変更される度に Amazon Simple Notification Service (SNS)を通じて通知を受けることも可能です。

価格情報はURLでアクセス可能です。URLの構造は次のようになっています:

https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/{offer_code}/current/index.{format}

formatにはjsonまたはcsvのいずれかを指定します。

サポートする全てのサービスのoffer codeとURLについては、Offer Index(https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json)にアクセスすることで確認することが出来ます。このデータは次のように始まります (currentVersionUrlの値は全てhttps://pricing.us-east-1.amazonaws.comに関連付けられています):

{"formatVersion":"v1.0","disclaimer":"This pricing list is for informational purposes only. All prices are subject to the additional terms included in the pricing pages on http://aws.amazon.com. All Free Tier prices are also subject to the terms included at https://aws.amazon.com/free/","publicationDate":"2015-11-19T02:10:02Z","offers":{"AmazonS3":{"offerCode":"AmazonS3","currentVersionUrl":"/offers/V1.0/aws/AmazonS3/current/index.json"},"AmazonRedshift":{"offerCode":"AmazonRedshift","currentVersionUrl":"/offers/V1.0/aws/AmazonRedshift/current/index.json"},"AmazonEC2":{"offerCode":"AmazonEC2","currentVersionUrl":"/offers/V1.0/aws/AmazonEC2/current/index.json"},"AmazonCloudWatch":{"offerCode":"AmazonCloudWatch","currentVersionUrl":"/offers/V1.0/aws/AmazonCloudWatch/current/index.json"}}}

それぞれのAPIレスポンスは製品情報(product information)をと価格情報(pricing information)の2つのセクションを含んでいます。

{"formatVersion":"v1.0","disclaimer":"This pricing list is for informational purposes only. All prices are subject to the additional terms included in the pricing pages on http://aws.amazon.com. All Free Tier prices are also subject to the terms included at https://aws.amazon.com/free/","offerCode":"AmazonRDS","version":"20151001000000","publicationDate":"2015-11-15T04:02:20Z","products":{"FNR4GZ675EW5UXJW":{"sku":"FNR4GZ675EW5UXJW","productFamily":"Database Instance","attributes":{"servicecode":"AmazonRDS","location":"US West (Oregon)","locationType":"AWS Region","instanceType":"db.t2.small","currentGeneration":"Yes","instanceClass":"Burstable performance instances","vcpu":"1","memory":"2","piopsOptimized":"No","networkPerformance":"Low","engineCode":"10","databaseEngine":"SQL Server","databaseEdition":"Express","deploymentOption":"Single-AZ","usagetype":"USW2-InstanceUsage:db.t2.small","operation":"CreateDBInstance:0010"}},

全ての製品に対して、製品属性(product attributes)を付与しています。価格の確認が必要なプロダクトのSKUを探すために製品属性を利用することが出来ます。価格をより早く見つけるため、価格情報はSKUで索引付けされています。

こちらが先ほどの製品情報に関連する価格情報になります:

"FNR4GZ675EW5UXJW":{"FNR4GZ675EW5UXJW.JRTCKXETXF":{"offerTermCode":"JRTCKXETXF","sku":"FNR4GZ675EW5UXJW","effectiveDate":"2015-10-01T00:00:00Z","priceDimensions":{"FNR4GZ675EW5UXJW.JRTCKXETXF.6YS6EN2CT7":{"rateCode":"FNR4GZ675EW5UXJW.JRTCKXETXF.6YS6EN2CT7","rateType":"Fixed","description":"$0.044 per RDS T2 Small Instance hour (or partial hour) running SQL Server EX - LI","beginRange":"0","endRange":"Inf","unit":"Hrs","pricePerUnit":{"USD":"0.0440000000"},"appliesTo":[]}},"termAttributes":{}}},

今すぐ利用可能です
価格情報は既に利用可能ですので今日から使い始めることが可能です。この機能は北京リージョン(China)を除く全てのパブリックリージョンで利用可能です。無償利用枠、スポットインスタンス、AWS Marketplaceに関する情報は提供されません。

詳細については、Using the Price List APIをご確認ください。

— Jeff(翻訳はSAは布目が担当しました。原文はこちら)

皆様に嬉しいお知らせがあります。AWSがISO27017の証明書を取得しました。この新しいクライテリアはISO27002に対し、特にクラウドサービスプロバイダーに適用できる追加のコントロールを加えたものです。AWSはこの証明書を取得した最初のクラウドプロバイダーとなりました。証明書はコンプライアンスのサイトよりダウンロードすることができます。また、私達は「AWS ISO 27017 よくある質問」のサイトも用意しましたので、この認証に含まれるリージョンやサービスについて更に学ぶことができます。

この認定は私達がこの国際的に認知されているクラウドセキュリテイの実務規範に適合しているという更なる透明性や独立した保証を提示しており、お客様にとって大変良い知らせであると言えます。しかしながら、私達がまた別のベストプラクティスにも適合していることを認証しているということは驚きに値することではありません。私達はかねてより情報セキュリティがAWSにおいて最も重要なことであることを示してきました。私達はお客様のデータを保護することに莫大な投資を行ってきています - この投資は私達のサービスを利用する際に私達のお客様であるあなたへの投資となります。ヘルスケアやライフサイエンス、連邦政府や州政府、金融サービスそして保安に関わるような業界を含む、幅広い規制産業の世界中のお客様が最もクリティカルで規制がとられているワークロードに対してAWSの利用を促進し続けています。私達の認証と証明は重要でありますが、お客様が独自の高度なセキュリティとコンプライアンス機能を構築するために、これらの保証の上でより重要になることは、お客様が何をできるかということにあります。

AWSのサービスを用いることで、お客様はAmazon InspectorやAWS WAF（Web Application Firewall）、AWS Config Rulesといった革新的な新しいクラウドセキュリティの機能を利用することができます。これらのツールはAWSの環境の中で信頼でき、どこでも利用できるコントロールを確立することで、より包括的で透明性のある方法でのコンプライアンスを可能にし、セキュリティを管理する能力を高めてくれるものです。

AWSでは、私達は常に認証を取得し、ワールドクラスのセキュリテイプログラムを所持していることを示しています。しかし、より重要なことは私達はお客様にもワールドクラスのセキュリティプログラムを持って頂きたいと思っているということです。私達が提供する革新的で業界をリードするセキュリティの能力について更に知りたい方は、上記のリンクやre:InventにおけるSteve Schmidtのキーノートをご覧下さい。

私達のお客様がどのようにAWS上でセンシティブなワークロードを動かしているか更に知りたい方は、ケーススタディをご覧ください。

Healthcare and Life Sciences	Financial Institutions	Government / Public Sector	Large Enterprise
DNA Nexus MedStar Health Pacific Life Healthcare.gov	Federal Home Bank of Chicago FINRA NASDAQ OMX	US Center for Disease Control (CDC) US Department of State US Food and Drug Administration (FDA)	Nike Expedia Delaware North

— Jeff; （日本語訳は高田智己が担当しました。）

原文：https://aws.amazon.com/blogs/aws/aws-certification-update-iso-27017/

Auto Scaling を使用すると、事前に定義された条件に基づいて複数のEC2インスタンスを起動・停止することができます。インスタンスをスケールアウトさせることによって、必要な処理能力が増加した場合でも、要求されるレベルのパフォーマンスを維持することができます。スケールインさせることで、負荷が低い期間にかかるコストを抑えることができます。

本日より、Auto Scalingグループがスケールインを実行する際に、削除するインスタンスを制御できる機能を追加しました。これまでは、特別なアクションを行わなければ、Auto Scalingグループのどのインスタンスでも削除されました。本日から利用可能になった新しい機能により、特定のインスタンスが削除されないよう保護することができます。

いくつかの理由でこのような制御を行いたい場合があるでしょう。1つ目は、インスタンスが長時間の処理を実行しているような場合です（SQSキューからPullされたメッセージの処理かもしれません）。インスタンスが削除されないようにすることで、無駄な処理を避けることができます。2つ目は、インスタンスがAuto Scalingグループの中で特別な処理を行っているような場合です。Hadoopクラスタのマスタノードであったり、インスタンスのグループの実行状態を示す”カナリア”の役割をする場合などです。

スケールイン時のインスタンスの削除保護

Auto Scalingのコンソールでインスタンスを選択し、操作メニューからインスタンスの保護を選択することで、簡単にインスタンスを削除から保護することができます。

そして、内容を確認します。

コンソールで、Auto Scalingグループ中のインスタンスごとに削除保護のステータスを確認できます。

インスタンスの保護ステータス変更は、SetInstanceProtection 関数を呼び出すことでも行えます。長時間実行されているプロセスやキュードリブンなワーカープロセスをスケールイン時の削除から保護するために、次のようにアプリケーションをセットアップします（コードは擬似的なものです）。

PHP

while (true)
{
  SetInstanceProtection(False);
  Work = GetNextWorkUnit();
  SetInstanceProtection(True);
  ProcessWorkUnit(Work);
  SetInstanceProtection(False);
}

Auto Scalingグループの中で、最低1つのインスタンスは保護しないままにしておくケースが多いでしょう。全てのインスタンスが保護される設定の場合、スケールインアクションは実行されません。さらに詳細を知りたい場合は、Auto Scaling Lifecycle を参照してください。

この新機能は既に利用可能で、本日から使用いただけます！

— Jeff;

PS - AWS SDKs は12月8日にアップデートされます。このアップデート後から SetInstanceProtection 関数をお使いいただけます。

翻訳：国政丈力（原文：https://aws.amazon.com/jp/blogs/aws/new-instance-protection-for-auto-scaling/）

Redshiftの新機能が３つアナウンスされたのでご案内します。なおこれら新機能はこれから１－２週間かけて世界中のリージョンに展開されていく予定です。ご自身のRedshiftクラスターに適用されるまでもう少しお待ちください。

（原文）

https://aws.amazon.com/about-aws/whats-new/2015/12/amazon-redshift-announces-tag-based-permissions-default-access-privileges-bzip2-compression-format/

タグベース、リソースレベルのパーミッション設定が可能になり、また新しくDBオブジェクトを作成する際にデフォルトのアクセス権限が設定できる事になったことにより、Amazon Redshiftのアクセスコントロールがより容易になりました。またAmazon RedshiftのCOPYコマンドがBZIP圧縮フォーマットをサポートしました。これら新機能の詳細は以下の通りです:

タグベース、リソースレベルのパーミッション：リソース、つまりクラスターやスナップショットに付けたタグを基準にAWS IAMユーザに対して、作成や変更といったリソースへの操作を制限することが出来るようになります。例えば特定のユーザには"development"とタグ付されたRedshiftクラスターのみ変更可能にすることが可能です。より詳細な情報は”IAM Policy Elements for Amazon Redshift”を参照してください。
新規作成のオブジェクトに対するデフォルト権限付与:ALTER DEFAULT PRIVILEGESコマンドを利用することで、新しく作成されるDBオブジェクトに対してデフォルトで設定されるアクセス権限のセットを定義することが可能になります。このデフォルト権限をユーザやユーザグループに対してアプライすることが可能です。デフォルト権限は、そのDB全体で作られるオブジェクトに対しグローバルに設定することも、特定のスキーマ以下のオブジェクトに限定することも可能です。より詳細には"ALTER DEFAULT PRIVILEGES"を参照してください。
BZIP2データフォーマットのサポート:COPYコマンドが、これまでのGZIPとLZOP(LZOファイル)に加えて、BZIP2フォーマットで圧縮されたデータをサポートし、Amazon Redshiftへのデータロード時に利用できるようになりおました。詳細は"Data Format Parameters"を参照してください。

(※補足：現時点ではリンク先のRedshiftマニュアルは、日本語版は最新情報を反映していませんでした。反映されるまでは、英語に切り替えて御覧ください）

翻訳：下佐粉　昭（@simosako）

私が最初のドメイン名を登録したのは約20年も昔のことです！その頃は、ドメイン名とサーバのマッピングはシンプルで分かりやすいものでした。ロードバランシングや地理的冗長化、Webサイトのモニタリング、クラウドコンピューティングなどは、その頃はありませんでした。マッピングは、常にドメイン名と1つの固定IPアドレスに対するものでした。

もちろん今では状況は大きく違っています。ドメイン名とIPアドレスのマッピングは、必ずしも1対1とは限りません。洗練されたWebサイトでは、リクエストを送信者にできるだけ近いサーバーにルーティングすることができます。送信者のロケーションの情報を、別の形で利用する場合もあるでしょう。

Route 53 トラフィックフロー

このような特徴を持つクラウドベースのアプリケーションをより簡単に構築・実行できるように、先週、Amazon Route 53 に新しいトラフィックフロー機能を追加しました。この機能を使って、ユーザーからクラウドやオンプレミスのエンドポイントへのトラフィックを、位置情報、レイテンシー、可用性の情報を組み合わせてルーティングするシステムを構築することができます。

トラフィックルーティングのポリシーは、ゼロから作成することもできますし、ライブラリからテンプレートを選択してカスタマイズして使うこともできます。1つのDNS名に対して複数のポリシーを作成して、どのポリシーを有効にするかをいつでも設定することもできます。さらに嬉しいことに、これらの作業をRoute 53のコンソール内でグラフィカルに行うことができます。

トラフィクポリシーの作成

私の持っているドメイン名の1つ doordesk.com に対して、トラフィックポリシーを作成します。まずは、名前と説明を入力します。

コンソールで、グラフィカルなトラフィックポリシーエディタが表示されます。

Start Point は、単純なDNSエントリです。

DNSエントリは、複数の異なるタイプのルールとエンドポイントに接続できます。

新規のエンドポイントを選択すると、詳細の入力が促されます。

Valueを選択してIPアドレスを入力すると、Start Point を IPアドレスにマッピングすることができます。

ここまでで、Aレコードを固定IPアドレスにマッピングするポリシーを1つ作成しました。

本番サーバと準本番サーバがあるかもしれないので、95%のトラフィックは1台目のサーバに、残りの5％は2台目に送信するようにしてみましょう。下ような重み付けルールを作成することで、これを実現できます。

下の図のように、Route 53 ヘルスチェックに、ルールの各要素を関連付けすることもできます。そうすると、ヘルスチェックによりエンドポイントが正常であると判断された場合のみ、トラフィックがエンドポイントにルートされるようになります。

フェイルオーバーのルールを作成することもできます。例えば、サーバーが正常な場合はサーバーに、正常でない場合はS3でホストされているフォールバック用の静的Webサイトにトラフィックをルートします。以下のように設定します。

次のオプションは位置情報に基づくルールです。DNSクエリの送信元の位置情報により、トラフィックのルーティングを決定するルールを作成することができます。以下がそのサンプルです。

最後のルールのタイプはレイテンシーです。このルールは、最もレイテンシーが小さいAWSリージョンを、DNSクエリの送信元の位置情報に基づいて判断します。EC2インスタンスをUS East(North Virginia)とAP(東京)のリージョンに持っている場合、トラフィックを適切にルーティングすることで快適なユーザエクスペリエンスを提供することができます。これを実現するには以下のように設定します。

複数のルールを組み合わせて、さらに複雑なトラフィックフローを作成することもできます。以下は、位置情報、レイテンシー、重み付け、フェイルオーバーを、この順に組み合わせたポリシーの一部です。

ここまで実験してきましたが、一番最初に示したポリシーを採用することにします。つまりシンプルなIPアドレスとエンドポイントのマッピングのルールのものです。そして Save as new version をクリックします。

ポリシーレコードの作成

次に、実際にトラフィックポリシーを実行するポリシーレコードを作成します。コンソールで実行すると簡単です。ドメイン名とDNS名を選択するだけです。

この操作が完了すると（通常は1,2分以内に完了します）、新しいポリシーが適用されたDNSレコードが有効になります。DNSの設定を変更した際は常に起こることですが、DNSのTTL(Time to Live)が切れて、DNS名前解決の結果をキャッシュしているDNSサーバーやクライアントアプリケーションに新しいレコードが伝搬されるまで、多少時間がかかります。

複数バージョンのトラフィクポリシーを作成・保存して、（ポリシーレコードを作成して）お好みのバージョンのポリシーを有効にすることができます。

今すぐご利用いただけます

この新しい機能は既に利用可能で、今日からお使いいただけます。さらに詳細を知りたい場合は、Route 53 Developer Guide の Using Traffic Flow to Route DNS Traffic を参照してください。料金は、ポリシーあたり月額$50.00です。（詳細はRoute 53 Pricingを参照ください）

— Jeff;

翻訳：国政丈力（原文：https://aws.amazon.com/blogs/aws/new-route-53-traffic-flow/）

AWS OpsWorksで、Amazon EC2およびオンプレミス用のLinuxインスタンスを構成および管理するためにChef 12を利用することができるようになりました。こちらは、AWS OpsWorksではWindows用にChef 12が既にサポートされており、その追加となります。OpsWorksは、Chefを使ってコードデプロイメント、ソフトウェア構成、パッケージインストール、データベースセットアプ、およびサーバスケーリングのような運用タスクを自動化するのに役立ちます。

AWS上でLinuxやWindowsサーバを構成、管理するためのChef 12の機能を一式を利用可能です。PHP、Node.js、MySQL等のアプリケーションサーバを立ち上げるためにChefコミュニティによって作成、管理されているクックブックを利用可能です。そのため、それらのChef 12のクックブックをOpsWorksで利用する前に適応させる必要がありません。OpsWorks組み込みレイヤーはChef 12ではサポートされていません。こちらにより、より幅広くクックブックを選定することができ、特定のニーズを満たすためにOpsWorksをカスタマイズするのに役立ちます。さらにスタックやレイヤー、インスタンスについて情報を見つけるためのネイティブのChef Search機能を利用することができます。今までは、OpsWorksで環境リソースを検索するには、ネイティブのChef環境の検索とは異なる構文が必要でした。

OpsWorksでのChef 12対応についての詳細は私たちのブログやドキュメントをご覧ください。OpsWorksでクックブックを利用開始するには、こちらをご覧ください。またChefについて学ぶにはChefのウェブサイトをご覧ください。

AWS OpsWorksについての詳細：
・製品ページ
・ドキュメント

翻訳は舟崎が担当しました。原文はこちらです。

いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。

月曜日 11月30日	AWS Certificationのアップデート – ISO 27017を発表いたしました。（日本語版記事） AWS Big Data BlogにてAWSトレーニングのビッグデータコースを大幅アップデートしますがポストされました。
火曜日 12月1日	CloudFrontとRoute 53の新たなエッジロケーション（米国シカゴ）を発表いたしました。 Amazon RDS for PostgreSQLが新たに3つのエクステンションと3つの新たなパラメータをサポートいたしました。 AWS Compute BlogにてAmazon Web ServicesでJAWSフレームワークを始めようがポストされました。 AWS Windows and .NET Developer BlogにてAWS Tools for Windows PowerShellが新たにフェでレーテッドユーザをサポートがポストされました。 AWS Partner Network BlogにてCloudEndureを利用してEC2インスタンスをEC2-Classic環境からAmazon VPCに移行する方法がポストされました。 AWS Security BlogにてWindows Powershellによりフェデレーションを利用したAPIアクセスを行う方法がポストされました。以下のツールとSDKをアップデートいたしました。 AWS Mobile SDK AWS CLI AWS SDK for JavaScript
水曜日 12月2日	EC2 Container Serviceがシンガポールリージョンで利用可能になりました。 Chef Server on AWSのクイックスタートリファレンスを公開いたしました。 AWS Windows and .NET Developer BlogにてCode Analyzers Added to AWS SDK for .NETにCode Analyzerが追加されましたがポストされました。 AWS Mobile Development BlogにてAWS Device Farm CLIとCalabashを始めよう（パート2）がポストされました。 AWS Partner Network BlogにてAtlassian BitbucketがAWS CodeDeployをサポートがポストされました。 AWS Startup Collectionにて12月のAWS Pop-up Loftsでホットな話題がポストされました。
木曜日 12月3日	CloudFormationが新たにAWS Config、CodePipeline、EC2 Simple Systems Manager、KMSをサポートいたしました。 Amazon Machine Learningがランダムなデータ分割と交差検証(Cross-validation)をサポートいたしました。 AWS Application Management BlogにてAWS OpsWorksがLinux向けにChef 12をサポートがポストされました。（日本語版記事） AWS Big Data BlogにてAmazon Redshiftクラスターの暗号化を行う際にメタデータを移行するがポストされました。 AWS Enterprise Blogにてスタッフにクラウドを学習してもらう際に考慮すべき11のポイントがポストされました。 AWS Partner Network BlogにてBitiumによるAWSにおけるActive Directoryのシングルサインオンがポストされました。以下のツールとSDKをアップデートいたしました。 AWS CLI AWS SDK for Java AWS SDK for Ruby AWS SDK for JavaScript
金曜日 12月4日	トルコのインスタンブールに新しくAWSのオフィスを開設いたしました。 AWS PHP Developer BlogにてAWS ConfigのデプロイメントをAWS SDK for PHPで自動化する方法がポストされました。

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

11月30日(月)
- Cloudynにてあなたが知るべき7名のクラウド・インフルエンサーがポストされました。
- Cloud EnlightenedにてAWS LambdaでRubyのコードを動かすがポストされました。
- Logz.ioにてログ管理のためにAWS Elasticsearch Serviceを活用するがポストされました。
- AloomaにてAmazon Redshiftでカスタム分析ソリューションを構築するがポストされました。
12月1日(火)

CloudEndureにて2016年に開催される108のクラウドイベントまとめがポストされました。
Cloud AcademyにてAWSのセキュリティ:踏み台ホスト、NATインスタンス、VPCピアリングがポストされました。
Cloudreachにてサーバレスなアーキテクチャ – インフラストラクチャなしのスケーラビリティがポストされました。
DevOps ServiceにてAWS Servicesは予約できます！とAWS VPCの基本がポストされました。

12月2日(水)

CloudHealth Academyにてクラウドサービスプロバイダを選定する時に注意すべき7つのポイントがポストされました。
Cloud AcademyにてAWS Directory ServiceのSimple AD – クラウド上のActive Directoryがポストされました。
ParkMyCloudにてAWS Cost Explorerはコストの見える化を支援するが、コストコントロールは別に行う必要があるがポストされました。

12月3日(木)

CloudCheckrにてコストとセキュリティに関するCloudCheckrのアラートがポストされました。
Apcelent Blogにて10個のコマンドでAnsibleによるEC2インスタンスの管理を始める方法がポストされました。

12月4日(金)

Bitnami BlogにてPHP 7がリリースされました:インストーラ、仮想マシン、イメージ、コンテナがポストされました。

12月5日(土)

Cloud EnlightenedにてCloudFormationのパラメータのグルーピングとラベル付けがポストされました。

P.S.　
このブログの最新情報はTwitterでお知らせしています。お気軽に@awscloud_jpをフォローください。
----
ソリューションアーキテクト小林正人

データ保護において、暗号化は重要なポイントです。これまで我々は、お客様がクラウドに格納するデータを暗号化する作業を簡単にするために、数々の機能を発表してきました。そのうちの多くはAWS Key Management Service(KMS)を利用するようになっています。下記はその一例です。

各機能に関してはAWS Key Management Serviceが提供する機能の詳細ページをご参照ください。これまで多くのお客様から、データの暗号化が簡単になったとのお声を頂いています。これらの機能は面倒な作業をAWSに任せて、お客様は必要に応じて機能をオンにすれば良くなったということを意味します。

暗号化されたEBSブートボリューム

本日、ブートボリュームであるEBSの暗号化機能をリリースいたしました。この機能は、最近追加された暗号化されたEBSスナップショットのコピー機能をベースとしています。

お客様は暗号化されたEBSボリュームをブートボリュームとして利用するAmazon Machine Image(AMI)を作成し、このAMIからEC2インスタンスを起動できるようになります。ストレージに書き込まれたデータは暗号化が施されます。また、EBSボリュームとEC2インスタンス間のデータ転送経路においても同様です。データは必要に応じてEC2インスタンス内部で復号化され、復号化されたデータはメモリだけに保持されます。

この機能はお客様のセキュリティやコンプライアンス、監査といった業務に役に立つでしょう。EBSに書き込まれたすべてのデータが、格納先がブートボリュームであってもデータボリュームであっても、暗号化されていることを簡単に確認することができるようになるからです。さらに、この機能はKMSを利用していますので、すべてのユーザの暗号化キー利用状況を追跡し、必要に応じて監査することが可能です。

EBS-backed AMIは少なくともひとつのEBSスナップショットを参照します。最初のひとつはブートボリュームですが、場合によってはこれに加えてデータボリューム用に別のスナップショットを参照しているかもしれません。AMIからインスタンスを起動すると、AMIが参照するEBSスナップショットからEBSボリュームが作成されます。データボリュームの暗号化は既にサポートされていますので、今回のリリースによって全ボリュームが暗号化されたAMIを作成できるようになったことになります。ちなみにもし必要ならば、それぞれのボリュームに対して個別のカスタマーマスターキーを利用することも可能です。

暗号化されたブートボリュームを作成する

暗号化されたブートボリュームは、既存のAMI(LinuxでもWindowsでもOKです)から作成します。元となるAMIは利用者自身が所有しているものか、パブリックかつ特別な利用料が不要であり直接利用可能なものである必要があります。もしそれ以外のAMIから起動したインスタンスのブートボリュームを暗号化したい場合、一度インスタンスを普通に起動し、それをご自身でAMI化してください。(たとえばAWSが提供しているWindowsのAMIでは、この操作が必要になります)。ブートボリュームが暗号化されたAMIはプライベートなものとなり、別のAWSアカウントに共有することはできませんので注意が必要です。

AMIと暗号化されたスナップショットの準備ができたら、ec2-copy-imageコマンドを利用して新たなAMIを作成することができます。

$ ec2-copy-image -r source_region -s source_ami_id \[-n ami_name][-d ami_description][-c token] \[--encrypted][--kmsKeyID keyid]

パラメータとして--encryptedを指定したものの、--kmsKeyIDによるキーの指定を行わなかった場合、そのAWSアカウントにおけるデフォルトのEBSカスタマキーが利用されます。こちらがAmazon Linux AMIのコピーを作成する場合のサンプルです。

$ ec2-copy-image -r us-east-1 -s ami-60b6c60a  \
  --encrypted --kmsKeyId arn:aws:kms:us-east-1:012345678910:key/abcd1234-a123-456-a12b-a123b4cd56ef

もちろん暗号化されたブートボリュームをもつAMIは、コンソールからでも作成できます。

暗号化されたブートボリュームを利用する

AMIが作成できたら、あとはいつも通りにインスタンスを起動して利用するだけです。アプリケーションコードや運用手順などの変更は必要ありません。

すぐにご利用いただけます

この新機能は中国（北京）を除くすべてのリージョンで本日からご利用頂けます。本機能の利用に伴う追加料金はございません。

— Jeff;（翻訳は小林が担当しました。原文はNew – Encrypted EBS Boot Volumesです。）

7週間前にEC2 Run Commandをローンチしたとき（詳細はわたしの記事、New EC2 Run Command – Remote Instance Management at Scaleを参照してください）、わたしは同様の機能をLinuxが稼働するインスタンスに約束しました。この機能が利用可能になり今日からつかいはじめられることをお知らせできてうれしく思います。

Run Command for Linux
Windowsのカウンターパートのように、どれだけの台数が稼働しているかにかかわらずEC2インスタンスを簡単でセキュアなやり方で管理できるようにこの機能は設計されています。パッチのインストール、コンフィグファイルの変更などがおこなえます。まとめると、この機能は以下のような管理の必要性に対応するようにできています：

インスタンスに対する構成の変更を一貫性をもちながらアドホックに実装する必要
複数インスタンスにまたがる信頼性と一貫性のある結果の必要
だれが変更を実行できてなにができるのかのコントロール
どのアクションがとられたかの明確な監査パス
自由なSSHアクセスの必要なしに上記のすべてが実行できるようにしたいという要求

この新機能はコマンドの実行をセキュアで、信頼性と利便性があり、さらにスケーラブルにすることができます。自分自身のコマンドを作成して、AWS Identity and Access Management (IAM)をつかって実行権限のきめこまかいコントロールをおこなうことができます。すべてのコマンドはAWS CloudTrailで集中的にログされて容易に監査ができます。

Run Commandの利点
Run Commandの機能は以下のような利点を提供するように設計されています（これらはLinuxとWindowsの両方にあてはまります）：

コントロール／セキュリティ　-　IAMポリシーとロールをつかってコマンドとインスタンスへのアクセスを統制することができます。それによってインスタンスに直接アクセスするユーザーの数を削減することができます。

信頼性　-　構成変更のためのテンプレートを作成することでシステムの信頼性を向上させることができます。それによってコントロールを強化しながら予測可能性を向上させ時間の経過による構成の不整合を削減することができます。

可視性 -　Run CommandはコマンドをトラッキングをサポートしてさらにCloudTrailと統合されているため構成変更の可視性を高めることができます。

使いやすさ　-　コンソール、CLIまたはAPIを使用して事前に定義されたコマンドセットを選択して実行、そして進行状況をトラックできます。

カスタマイズ性　-　自分の組織のニーズにあわせてRun Commandをしつらえてカスタムコマンドを作成することができます。

Run Command on Linuxの使用
Run Commandはそれぞれのインスタンスで実行されるエージェント（amazon-ssm-agent）を使用します。以下のLinuxディストリビューションで利用可能です：

Amazon Linux AMI (64 bit) – 2015.09, 2015.03, 2014.09, および 2014.03.
Ubuntu Server (64 bit) – 14.04 LTS, 12.04 LTS
Red Hat Enterprise Linux (64 bit) – 7.x

こちらはRun Commandでできることの一部です：

シェルコマンドまたはスクリプトの実行
ユーザーやグループの追加
ユーザーやグループの権限の設定
すべての実行中サービスの表示
サービスの開始と停止
システムリソースの表示
ログファイルの表示
アプリケーションのインストールやアンインストール
スケジュール（cron）タスクのアップデート

あたらしいLinuxインスタンスを起動してこのようにUserDataに数行を追加することでエージェントをブートスラップすることができます（詳細は、EC2ドキュメントのConfigure the SSM Agentを参照してください）：

こちらがコマンドドキュメントの選択方法です（LinuxとWindows用で別々のコマンドドキュメントが利用可能です）：

そしてこちらが対象となるインスタンスを選択して実行するコマンドまたはコマンド群を入力する方法です：

こちらがコマンドのアウトプットです：

こちらがすでに実行したコマンドからのアウトプットの確認方法です：

Run a Command Today
この機能US East（北バージニア）、US West（オレゴン）、そしてヨーロッパ（アイルランド）リージョンではいますぐ利用可能で今日からつかいはじめることができます。コマンドに費用はかかりませんが、使用するその他のAWSリソースに応じて課金されます。

より詳細は、Run Commandページを参照してください。

— Jeff;（翻訳はSA渡邉（@gentaw0）が担当しました。原文はEC2 Run Command Update – Now Available for Linux Instances）

以前にt2.nanoをアナウンスしました。より大きなサイズ(t2.micro, t2.small, t2.medium, t2.large)と同じように、処理能力のベースラインを提供し、未使用サイクルを貯めて必要な時にバーストできます。

以前のポスト(新しいT2.Largeインスタンス)に書いたように、このモデルは私達のお客様にとって非常に人気があります。実際に私達がこの数日間に調査して分かったことですが、96%以上のT2インスタンスが常にCPUクレジットが余っている状態でした。つまり、みなさんは必要以上に多い処理能力に対して支払っていたことになります。1年もしくは3年のリザーブドインスタンスを支払った場合は、この価格(後述しますが)の差は更に大きくなります。

t2.nanoはトラフィックの少ないウェブサイト、マイクロサービス、開発・テスト環境に使われることを想定していますし、費用効果を計測する車両にも使えると期待しています。さらに、トレーニングや教育用途もあります。

仕様

t2.nanoインスタンスは 512MiBメモリと 1 vCPUを備えており、32/64bitのOSとアプリケーションが動作可能です。EBS暗号化と、最大2つのElastic Network Interfaceをサポートします。

t2.nanoは、24時間の平均CPU利用率が5%以下の場合、高周波数のIntel CPUコアの最大性能を利用できます。CPUクレジットが残っている間、必要な時にCPUコアの最大性能を利用でます。新しく起動したt2.nanoは30CPUクレジットを保持しており、1時間毎に3クレジットを受け取り最大72CPUクレジットまで蓄積できます。つまり、各インスタンスは一気に連続して最大72分間、最大コア性能でバーストできます。

t2.nanoインスタンスでLinuxまたはWindowsを起動できます。しかし、私達のデータではWindowsインスタンスはLinuxインスタンスよりも多くのCPUとメモリを消費しますので、どのインスタンスサイズが皆様のアプリケーションに最適かどうかを決めるために、テストと評価をしたいと思うでしょう。Windows GUIが不要なら Server Core AMIも評価対象になるかもしれません。

EC2価格とサンプル設定

t2.nanoインスタンスの価格は各リージョンのt2.microの半額となります。以下が価格例となります(詳細はEC2料金ページを参照ください):

リージョン	価格/ 時間(オンデマンド)	価格/ 月(オンデマンド)	1年リザーブドインスタンス/月	3年リザーブドインスタンス/月
米国東部(バージニア北部)	$0.0065	$4.75	$3.125	$2.10
米国西部 (オレゴン)	$0.0065	$4.75	$3.125	$2.10
欧州(アイルランド)	$0.0070	$5.11	$3.42	$2.31
アジアパシフィック(東京)	$0.0100	$7.30	$5.25	$3.44
南米(サンパウロ)	$0.0135	$9.85	$5.67	$4.17

トラフィックの少ないウェブサイト(月間最大25,000ビジット程度)をt2.nanoで稼働させた時の全システムの月間コストを見てみましょう。この例の負荷を捌くには十分な設定です。

インスタンスに加えて、ストレージとして8GB EBS SSDボリュームと、Amazon Route 53でドメインを管理する設定とします。下りネットワークトラフィックとして2GBを含めます。つまり、このコストはAWSでウェブサイトを動かす全コストとなります。以下、米国西部(オレゴン)での月間コストです：

AWS Service	設定	オンデマンド	1年リザーブドインスタンス	3年リザーブドインスタンス
EC2	t2.nano	$4.75	$3.17	$2.11
EBS Volume	8 GB SSD	$0.80	$0.80	$0.80
データ転送(アウト)	2 GB	$0.09	$0.09	$0.09
Route 53	1 ドメイン + 25000クエリ	$0.51	$0.51	$0.51
合計		$6.15	$4.57	$3.51

想定よりも成功して10倍多くのvisit数になったとしても、追加のデータ転送費用は1ドル以下(正確には0.81ドル)です。小さなウェブサイトを稼働させて、様々なコストに気をつけておきたいなら、請求アラームを作成することをお忘れなく。

簡単にスケールさせることで、より多くのトラフィックを捌いたり、より複雑なサイトやアプリケーションを稼働させたりすることができ、システムを始めるのに強力です。やがて、S3、Elastic Load Blancing, Auto Scaling, Amazon Relational Database Service(RDS)、AWS CloudFormationといったその他のAWSサービスを利用するように拡張できます。またT2インスタンスの他のサイズや、全てのEC2インスタンスタイプに変更することもできます。

私達のパートナーであるBitnamiは、数クリックでAWS上で使える、幅広いパッケージとアプリケーションを提供しています。とても人気のあるWordPress AMIはt2.nanoでの利用に最適化されています。このAMI以外にも多くのアプリケーションをAWS Marketplaceで探すことができます。

今すぐ使えます

t2.nanoインスタンスは本日より米国東部(バージニア北部)、米国西部(オレゴン)、米国西部(北カリフォルニア)、欧州(アイルランド)、アジアパシフィック(シンガポール)、アジアパシフィック(東京)、南米(ブラジル)、AWS GovCloud(US)リージョンで利用可能です。欧米(フランクフルト)とアジアパシフィック(シドニー)もすぐに利用可能になります。t2.nanoはAWS Elastic BeanstalkやAWS CloudFormationでも利用できます。

— Jeff; (翻訳は松尾が担当しました。原文はEC2 Update – T2.Nano Instances Now Available | AWS Official Blogです)

RDS for PostgreSQLで、3つの(ip4r, pg_buffercache, pgstattuple)と3つのパラメーターがサポートされました

Chef ServerをAWS上で展開：クイックスタートリファレンスデプロイ

【AWS発表】AWSクラウド上のマネージド型Microsoft Active Directory

既存のAmazon RDS DBエンジンのポート番号を変更可能に・Amazon RDS MySQL5.5でM4・R3・T2インスタンスサポート

【AWS発表】Amazon Auroraでリソースの暗号化をサポート

Amazon CloudWatch LogsをS3へバッチエクスポート可能に！

AWS Service Catalogが東京リージョンで使えるようになりました

【AWS発表】VM Import/Exportが新たなOSをサポート

Elastic Load Balancing：停止および再起動したEC2バックエンドインスタンスの自動再登録をサポート

AWS Directory Serviceアップデート – マネージド型Microsoft Active Directoryのサポート

【AWS発表】新しいAWS Price List API

AWS Certificationのアップデート – ISO 27017

Auto Scalingでのインスタンス保護

Amazon Redshiftに新機能追加予定：タグ付けによるリソース利用制限、デフォルト権限設定、COPYでのBZIP2ファイル対応

【AWS発表】Amazon Route53 トラフィックフロー

AWS OpsWorksがLinux用にChef 12をサポート

週刊AWS - 2015年11月30日

【AWS発表】ブートボリュームのEBS暗号化をサポート

EC2 Run Commandアップデート – Linuxインスタンスで利用可能に

EC2アップデートー T2.Nanoインスタンスが利用可能に