Amazon Web Services ブログ

こんにちは。プロダクトマーケティングマネージャーの石橋です。 2016年は、Amazon Web Services（以下、AWS）が2006年に事業を開始してから10年、2011年に東京リージョンを開設して5年と、節目の年を迎えました。当時はクラウドのパイオニア、今ではある意味老舗になってきたAWSです。特に、ここ数年で多くの企業においてクラウドの活用が進んでいることをニュース等で目にするようになりました。同時に、AWSも多くのお客様にご利用いただけるようになりました。なぜ、AWSは成長し続けているのでしょうか？理由を考えてみたいと思います。   ■10年前のクラウド、今のクラウド クラウドと言えば、システム構築のためのITリソースであるサーバやストレージ機器を、自社や個人で購入、所有することなくインターネット経由で提供し、必要な時に使った分だけ支払う従量課金や、ものの数分でITリソースを準備できる俊敏性が利点のビジネスモデルとして注目されました。AWS設立当時は、いかに早くビジネスを立ち上げ、その結果から次の打ち手を考えることができるかという利点が活かせる、スタートアップ企業を中心にご利用いただいていました。ここ数年は、以前とどう変化したのでしょうか？導入するお客様の業種や事業内容、企業規模は多岐に渡り、お客様の求めるサービスやセキュリティレベル、堅牢性や可用性のニーズに合わせたサービスを提供できるようになりました。AWSクラウドのセキュリティコンプライアンスへの準拠（第三者認証や監査）、専用線によるAWSクラウドへの接続、無料かつ自動更新のSSL証明書（US East（Northern Virginia）リージョンのみで提供）※など、企業においてクラウドにおけるガバナンスが効くようになり、利用している企業だけでなく、さらにその先のお客様が安心してサービスを利用できるようになりました。また、お客様と共にサービスを拡充し続けることで、多種多様な企業においてご利用いただけるようになりました。   ■クラウドによるビジネスモデル変革 導入が進むクラウドですが、AWSが最初に起こしたビジネスモデルの変革は何でしょうか？それは「ITリソースの購買体験を大きく変えたこと」です。必要な時に使った分だけ、事前の契約なしに、誰でも購入できる体験です。従来のITリソースの購買（調達）体験をシステム導入のライフサイクルから考えてみましょう。システム開発のライフサイクルには、ビジネス要件の定義、インフラ設計、システム設計（サーバサイジング設計や容量計画）、ソフトウェア設計、ソフトウェア開発、運用管理設計、システムテスト、システム運用（メンテナンス）、End of Service(EOS)と一連の流れがあります。この中で、AWSのクラウドで費用・人的労力・時間を軽減したり短くする（＝どこか別のところに任せる、考える時間を少なくする）ことができる部分はどこでしょうか？すべての開発サイクルでクラウドにワークロードを移行できます。   ■クラウドがビジネスにもたらす利点 ワークロードを移行した結果、ビジネス上の利点は何でしょうか？今までオンプレミス環境を構築している場合、ITシステム構築のワークロードは自社内にありました。これらのITワークロードをクラウド側で処理できるとすれば、システムの導入初期費用だけでなく、中長期にわたり運用する為の人的工数、ハードウェア・ソフトウェアのライセンスやメンテナンス費用まで含めたTCO削減につながります。そして重要なのは、ITワークロードをオフセットしたことによる調達や作業「時間」を、今まで手が付けられなかったことや新たな事業に投資することで、さらなる事業展開の可能性を創出できるようになることです。仕事の仕方が変わるという事なのです。   ■AWSが成長し続ける3つの理由 AWSはテクノロジーの変化に合わせて、お客様のビジネス形態も変化していることをいち早く捉え、ビジネスのパートナーとして共に成長しています。AWSの成長はお客様の変革によってもたらされています。それでは、AWSが成長し続ける理由を見てみましょう。   (1) お客様が事業に集中できる 企業や組織内の事業基盤にある技術インフラをAWSにすることで、お客様を差別化するための事業に集中できる状況を作っています。そして長期間に渡って競争力を維持し続ける為の支援を、AWSおよびパートナーエコシステムを活用し一緒にビジネスを行っています。   (2) イノベーションを起こすためのインフラ提供 すべての企業は生き残るためにビジネスや顧客体験を変えていく必要があります。コストの低減は守りの一要素ですが、その先にはビジネスの俊敏性や変革が必要です。そのためのインフラも俊敏、柔軟で革新的であるものを提供し続けています。   (3) ITに必要なモノをあらかじめそろえておく 企業内で使うITリソースは多岐にわたります。必要なモノはできるだけAWSで準備し組み合わせて使うことで、ビジネスのニーズに合わせたアウトプットを、より早く、より簡単に提供できるようになります。2015年は722ものサービスリリースや機能改善を行いました。お客様に、その継続的な進化や革新による利点をすぐに享受していただけます。     クラウドサービスの検討をはじめた方は、どこから手を付けていいかわからない方もいらっしゃると思います。弊社のホームページでセミナー情報を探していただくと、「はじめてのアマゾン ウェブ サービス」や「初級トレーニング」といった無料でAWSを知る機会がありますので、是非活用してみてくださいね。すぐにでも始めてみたい方は、AWS にサインアップした日から 12カ月間お使いいただける無料利用枠があります。ほとんどの製品をお試しいただけます。ユーザ登録は簡単ですので試してみてください。   AWSアカウントの作成手順はこちら http://aws.amazon.com/jp/register-flow/   ※サービスを提供しているリージョンは3/25現在の情報に基づいています。    

Amazon ElastiCache は、クラウド内のインメモリデータベースのデプロイ、運用、スケールの実行を簡単にするサービスです。ご存知のとおり、ElastiCache では Memcached エンジンと Redis エンジンがサポートされています。 Redis 向けの強化 本日、Redis ベースの ElastiCache クラスターがより詳細に制御できるようになる、ElastiCache の更新をローンチしました。You can now scale up to a larger node type while 保存された情報を ElastiCache に保持したまま (ベストエフォートベース)、より大きなノードタイプにスケールアップできるようになりました。ElastiCache for Redis のエンジンバージョンのアップグレードはこれまでずっと可能でしたが、保存された情報を保ったままでこれを実行できるようになりました。これらの変更は、両方とも、即時適用またはクラスターのメンテナンス期間の適用が実行できます。 ElastiCache for Redis のスケールアップとエンジンアップグレードのために、見えないところでさまざまな戦略が活用されています。スケーリングは Redis レプリケーションをベースにしています。エンジンのアップグレードでは、マルチ AZ がオフになったときにまずフォアグラウンドのスナップショットが使用され (SAVE)、マルチ AZ がオンのときにレプリケーションに続いて DNS スイッチが実行されます。 大きなノードタイプにスケールアップするには、AWS マネジメントコンソールで [Cache Cluster] を選択し、[Modify] をクリックします。新しい [Node Type] を選択し、変更を即時適用するかどうかを決定してから、[Modify] をクリックします。 […]

Airbnb は、わずか数人のすばらしい着想が業界全体を大きく変えることがあることを示す、典型的なストーリーです。2008 年にスタートして以来、これまでに 8000 万人の客が Airbnb を利用して 190 以上の国にある 200 万軒以上の家に宿泊しました。最近では、全世界からの旅行者のため、キューバに 4000 軒の家をオープンしました。同社はまた、早くから AWS を活用してきました。 ゲストによる以下の投稿の中では、Airbnb エンジニアリングマネージャーである Kevin Rice 氏が、スタートアップにおいて AWS がどれほど重要な役割を担ったか、そしてどのようにその重要な位置にとどまっているかを解説しています。 – Jeff PS – スタートアップが AWS を利用してビジネスを展開する方法の詳細についてもご覧ください。 初期 当社の創設者たちは、Airbnb を成功させるために、スピーディーかつリーンであることが必要だと認識していました。これには、インフラストラクチャに投じる時間とリソースを最小化することが不可欠です。当社のチームは、ベーシックなホスティングについての業務にではなく、ビジネスを離陸させることに集中することが必要でした。 幸いなことに、ちょうどそのとき、アマゾン ウェブ サービスにはコンピューティングとストレージにおいて非常に成熟したサービスが構築されていたため、当社のスタッフは他の人からのサポートや最小使用要件に気を使うことなく、サーバーを立ち上げることができました。同社のクラウドコンピューティング機能のほぼすべてを AWS に移行することが決定されました。スタート当初の小さな企業では、利用できるリソースを可能な限り活用する必要があります。当社の従業員たちは、ビジネスを成功させるために替えのきかないところに注意を集中したいと考えていました。 Airbnb では、Amazon EC2 や Amazon S3 といった AWS の基本サービスの多くをすばやく導入しました。当初の MySQL データベースは Amazon Relational Database Service (Amazon RDS) に移行されました。RDS […]

このブログの常連読者の方は私がAmazon Relational Database Service (RDS)の大ファンであることをご存じだと思います。マネージド型のデータベースサービスとして、リレーショナルデータベースのセットアップ、実行、そしてスケーリングといった日常業務の面倒を見てくれます。 2012年にはじめてSQL Serverのサポートをローンチしました。それからSSLサポート、メジャーバージョンアップグレード、透過的なデータ暗号化、そしてMulti-AZといった多くの機能を追加してきました。これらの機能はRDS for SQL Serverの適用範囲を広げてより多くのユースケースへの扉を開きました。 多くの組織ではアカウントのクレデンシャルとそれに関連するアクセス権をActive Directoryに保管しています。ディレクトリによりこの情報に対する単一で一貫性のあるソースを提供し集中管理を可能にします。AWS Directory Serviceを使用してAWSクラウド上でMicrosoft Active DirectoryのEnterprise Editionを実行することができますので、次のステップにすすむときです！ Windows認証のサポートAWS Directory Service for Microsoft Active Directory (Enterprise Edition)に保存されたクレデンシャルを使用してAmazon RDS for SQL Serverに対するアプリケーションの認証ができるようになりました。同じディレクトリにすべてのクレデンシャルを保持することでそれぞれのコピーをさがして更新する必要がなくなるため時間と手間の節約になります。 SQL Serverを実行するデータベースインスタンスを新規に作成するときにこの機能を有効にしてActive Directoryを選択することができます。既存のデータベースに対して有効にすることもできます。こちらが新規にデータベースインスタンスを作成するときにディレクトリを選択するやり方です（新規にディレクトリを作成することもできます）： より詳細は、Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instanceを読んでください。 いますぐ利用可能この機能はUS East（北バージニア）、US West （オレゴン）、Europe（アイルランド）、Asia Pacific（シドニー）、Asia Pacific（東京）、そしてAsia Pacific（シンガポール）リージョンでいますぐ利用可能ですので今日からつかいはじめることができます。この機能に追加費用はありませんが、AWS Directory Service for […]

本日、AWSの暗号化チームは AWS Encryption SDKを発表します。この新しいSDKによって、開発者は、アプリケーションのセキュリティに影響を及ぼしうるエラーを最小化しながら容易に暗号化を実施できます。新しいSDKはAWSのお客様でなくてもご利用いただけますが、AWSのお客様にとってすぐに利用可能なサンプルが含まれています。   暗号化を行う際、開発者は次の2つの問題によく直面します: どのように正しく暗号鍵を生成し、利用するか 利用後、鍵をどのように保護するか 新しいAWS Encryption SDKによって提供されるライブラリは、ユーザーの開発環境で利用可能な暗号化プロバイダを利用し、低レベルの詳細な部分を透過的に実装することで1つ目の問題に対応します。また、どのように鍵を保護したいかを選択できる直感的なインターフェースを提供することで2つ目の問題への対応を手助けします。開発者は、暗号化の複雑性ではなく構築しようとしているアプリケーションコアにフォーカスすることが出来ます。この記事では、AWS Encryption SDKを利用してどのようにデータの暗号化プロセスを簡素化できるか、単一のリージョンあるいは鍵管理ソリューションに縛られない、アプリケーションの可用性を改善するのに役立つ方法でどのように鍵を保護できるかについてお伝えします。   エンベロープ暗号化と新しいSDK AWS Encryption SDKを利用する際に理解しておくべき重要なコンセプトは、エンベロープ暗号化(ハイブリッド暗号化としても知られています)です。アルゴリズムが違えば強度も異なり、単一のアルゴリズムで全てのユースケースにフィットするものは有りません。例えば、(RSAやAWS Key Mangement Service [KMS]などの)優れた鍵管理の特性を持つソリューションは、大容量のデータに対してはあまり有効ではありません。エンベロープ暗号化は、(AES-GCMのように)大容量データに適した単一用途のデータキーを使ってバルクデータを暗号化することでこの問題を解決します。エンベロープ暗号化ではその後、鍵管理に適したアルゴリズムや他のソリューションを使ってデータキーを暗号化します。 エンベロープ暗号化のもう一つの優位性は、複数の受信者で復号化できるようひとつのメッセージを暗号化できることです。全員で鍵を共有(これはたいていセキュアではありません)したり、全体のメッセージを複数回暗号化したり(これは現実的ではありません)するのではなく、データキーだけがそれぞれの受信者の鍵を使って暗号化されます。これによって重複した処理を顕著に削減でき、複数の鍵を利用した暗号化がより実用的になります。   エンベロープ暗号化の問題点は実装の複雑さです。全てのクライアントはデータフォーマットの生成および構文解析ができ、複数の鍵とアルゴリズムをハンドルでき、理想的には妥当な範囲で前方および後方互換性を保てる事が必須になります。   AWS Encryption SDKはどう役立つのか？ AWS Encryption SDKは、セキュアなアルゴリズムの組み合わせ(将来的に拡張可能)をサポートし、マスターキーのタイプやアルゴリズムの制限が無い、慎重にデザインされレビューされたデータフォーマットを採用しています。AWS Encryption SDK自身は、KMS、および AWS CloudHSMやその他の PKCS #11デバイスを含むJava Cryptography Architecture (JCA/JCE)を直接サポートするpoduction-readyなリファレンスJava実装です。他言語でのSDKの実装については現在開発中です。 AWS Encryption SDKの一つの利点は、低レベルの暗号処理はSDKで取り扱われるため、データの移動にフォーカスすることができることです。次に、パワフルでセキュアなマルチリージョンソリューションを構築する簡単なコードを示します。   Example 1:高可用性のためにアプリケーションの機密データを複数リージョンのKMSマスターキーで暗号化する 高可用性アプリケーションのベストプラクティスの一つは、複数のアベイラビリティゾーンだけではなく複数のリージョンでデプロイすることです。KMSはリージョンをまたがってカスタマーマスターキー(CMK)を共有できないため、データがKMSで暗号化されている場合にはこのようなデプロイメントは困難です。エンベロープ暗号化では、異なるリージョンの複数のKMS CMKを使ってデータキーを暗号化することでこの制限に対するワークアラウンドを取ることができます。各リージョンで稼働するアプリケーションは暗号文の復号化を行うために、高速で信頼性の高いアクセスのためにローカルのKMSエンドポイントを利用することができます。 このドキュメントの全ての例において、 IAM roles for EC2を設定したAmazon EC2インスタンスが稼働していることを想定しています。IAM […]

AWS Marketplace は先進の ISV (独立ソフトウェアベンダー) に大いに活用されています。 ユーザーは、ハードウェアの調達やソフトウェアのインストールを行うことなく、数分のうちに製品を見つけ、購入し、使用を開始することができます。このようなスムースな配信方法によって、ISV は新たな顧客を得ると同時に、販売サイクルを短くすることもできています。ユーザーは既存の AWS アカウントを通じ、標準の AWS 請求サイクルにしたがって製品に対する支払いを行います。 AWS Marketplace へのオンボーディングプロセスの一部として、各 ISV はソフトウェアの料金を自由に決定できます。ISV は、割引のある月間利用料金や年間利用料金の設定も選択できます。従来は時間以外に基づいてライセンスされていたソフトウェアについても、ISV は AWS Marketplace に、自分で選択したディメンションでのライセンシングオプションに対応する複数のエントリを作成できます。 このモデルはさまざまなタイプのアプリケーションで効果を上げています。しかし、通常はまだ向上の余地があります。 他の料金オプション ソフトウェアのパッケージングと料金設定については、いっそうの柔軟性を求める声が ISV から届いていました。AWS ではそれにお応えします。複数エントリを作成せずにユーザー数モデルへの拡張を希望される場合もあれば、別のディメンションでの課金を希望される場合もあります。セキュリティ製品ベンダーは、スキャン対象のホスト数に応じた課金を希望するかもしれません。分析向けの製品のベンダーであれば、処理するデータ量に応じた価格設定を望むかもしれません。 これらの選択肢を実現させるため、ISV が自社製品にとって有効なディメンション (スキャン対象ホスト数、処理データ量など) に基づいて使用量を追跡し、レポートすることが可能になりました。これらの使用量について、単位あたりの価格を設定することも可能です (1 ホストあたり 0.50 USD、1 GB あたり 0.25 USD など)。このような使用量に対する課金は、ユーザーの AWS 請求に表示されることになります。 この変更によって、AWS Marketplace の製品ラインナップがいっそう広がることになるでしょう。 新しい料金オプションの実施 自社の AWS Marketplace 製品にこの新しいモデルの料金を使用することを希望する ISV は、アプリケーションにいくらかコードを追加する必要があります。適切なディメンションにより使用量を測定し、使用量をレポートする新しい AWS API 関数を呼び出します。このデータ […]

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（1台のインスタンスから何千台のインスタンスまで）費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御、【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応。 私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが（可能な限り費用対効果を高めるよう変化）、フリート自体はその属性を保持します。 新しいスポットフリート メトリックス スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます：スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。 下記メトリックスは各スポットフリート毎に取得されます。（これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります） AvailableInstancePoolsCount BidsSubmittedForCapacity CPUUtilization DiskReadBytes DiskReadOps DiskWriteBytes DiskWriteOps EligibleInstancePoolCount FulfilledCapacity MaxPercentCapacityAllocation NetworkIn NetworkOut PendingCapacity StatusCheckFailed StatusCheckFailed_Instance StatusCheckFailed_System TargetCapacity TerminatingCapacity  メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、 AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。 BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。 EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか（1）スポット価格がオンデマンド価格より高い場合、または（2）入札価格がスポット価格よりも低い場合にはプールが不適用となります。 FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。 PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。 PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。 TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。 TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。 これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。 CPUUtilization DiskReadBytes […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 21 日 スポットフリート用の新しい CloudWatch メトリックスを発表しました。 AWS SDK for Java 用の再試行スロットリングを発表しました。 AWS マネジメントコンソールを介して Amazon Machine Learning を Amazon Redshift に接続することが簡単になったことを発表しました。 AWS Storage Gateway で最大 1 PB の仮想テープライブラリと、ゲートウェイあたり最大 512 TB の保管型ボリュームをサポートするようになったことを発表しました。 AWS Government, Education, & Nonprofits Blog が、AWS にすべてを移行した際に学んだ教訓についての記事を掲載しました。 AWS Mobile Development Blog が、CloudFormation を使用して AWS に Parse Server と MongoDB […]

週間 AWS – 2016 年 3 月 14 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 14 日 AWS SDK for C++ の開発者プレビューが使用可能になったことを発表しました。 AWS クラウド 10 周年を祝いました。 Sqoop、HCatalog、Java 8 などを含む Amazon EMR 4.4.0 をスタートしました。 AWS コンピューティングブログで、欧州 (フランクフルト) リージョンにおける AWS Lambda および Amazon API Gateway の使用開始を発表しました。 Amazon Simple Email Service ブログで、Amazon SES がドメインからのカスタムメールをサポートするようになったことを発表しました。 AWS Java ブログに、Amazon SQS […]

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。 Release: Amazon Redshift on 2016-03-17 Announcement: Amazon Redshift improvements and maintenance (Mar 17 – Mar 31) このリリースには以下の新機能が含まれています。 ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように 接続ログに、SSLのバージョンとSSLサイファーが記録されるように 1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。 デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は（今までと同様）常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。 参考）VACUUMコマンド　※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。 2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。 今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。 Loading Your Data in Sort Key Order　※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。  条件は以下の通りで、これらを全て満たしている必要があります。 表がコンパウンドソートキー（Interleaved Sort Keyではなく）を使っていて、かつソートキー列が1つのみ ソートキーの列がNOT NULL 表が100%ソート済か、もしくは空（から） 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造（時系列でデータを入れ続ける）の場合に役に立ちます。 3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。 この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上（リサイズに掛かる時間の短縮）、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。 この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。 なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。 下佐粉　昭（@simosako）