Amazon Web Services ブログ

Amazon RDS for SQL Server – Windows認証のサポート

by AWS Japan Staff | on | in Amazon 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 Microsoft Active Directoryの通常料金がかかります。

— Jeff;（日本語訳はSA渡邉（@gentaw0）が担当しました。原文はAmazon RDS for SQL Server – Support for Windows Authentication）

 

 

データの暗号化をシンプルにし、アプリケーションの可用性を向上する新しいAWS Encryption SDKの利用法

by AWS Japan Staff | on | in AWS SDK, セキュリティ |
本日、AWSの暗号化チームは AWS Encryption SDKを発表します。この新しいSDKによって、開発者は、アプリケーションのセキュリティに影響を及ぼしうるエラーを最小化しながら容易に暗号化を実施できます。新しいSDKはAWSのお客様でなくてもご利用いただけますが、AWSのお客様にとってすぐに利用可能なサンプルが含まれています。
 
暗号化を行う際、開発者は次の2つの問題によく直面します:

  1. どのように正しく暗号鍵を生成し、利用するか
  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 Roleによってクレデンシャルの管理を避けることができ、最も近いエンドポイントへのリクエストができるビルトインロジックのアドバンテージがあります。また例では、AWS SDK for Java (AWS Encryption SDKとは異なります)の利用と、Bouncy Castleが利用可能であることを想定しています。

暗号化ロジックはとてもシンプルなハイレベルデザインを持っています。コマンドラインからパラメーターを読み込んだ後、マスターキーを取得してファイルを暗号化するのに利用するというものです(次のコードサンプルに示します)。不足しているメソッドに関してはこの記事の後続部分に記載します。

public static void main(final String[] args) throws Exception {
    // Get parameters from the command line
    final String inputFile = args[0];
    final String outputFile = args[1];

    // Get all the master keys we'll use
    final MasterKeyProvider<?> provider = getMasterKeyProvider();

    // Actually encrypt the data
    encryptFile(provider, inputFile, outputFile);
}

 

マスターキーを複数作成して一つのマスターキープロバイダーにまとめる

次のコードサンプルでは、3つの米国リージョン:us-east-1,us-west-1,us-west2のCMKを利用してデータをどう暗号化するかを示します。この例では、各リージョンのCMKをセットアップ済みでそれぞれのCMKに対してalias/exampleKeyという名前のエイリアスを作成しています。CMK作成の詳細については、AWS KMSドキュメントのCreating Keysをご参照下さい。

次にこの例では、全てのマスターキーを一つのマスターキープロバイダーにまとめるために MultipleProviderFactory を利用しています。最初のマスターキーは新しいデータキーを生成するのに利用され、他のマスターキーは新しいデータキーを暗号化するために利用されることに注目して下さい。

private static MasterKeyProvider<?> getMasterKeyProvider() {
    // Get credentials from Roles for EC2
    final AWSCredentialsProvider creds = 
        new InstanceProfileCredentialsProvider();

    // Get KmsMasterKeys for the regions we care about
    final String aliasName = "alias/exampleKey";
    final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

    return MultipleProviderFactory.buildMultiProvider(
        useast1, uswest1, uswest2);
}

開発を簡素化し、全ての暗号化データを企業の標準に適合させるためのMasterKeyProviderを構成するロジックは、一度セキュリティチームによって作成すれば、企業をまたがって再利用できます。

 

データを暗号化する

暗号化対象のデータは、どこからでも取得できますし、どのような形でも配布できます。次のコードサンプルでは、ディスクからファイルを読み取り、暗号化コピーを書き出しています。AWS Encryption SDKはこれを簡単に実現するため、Javaストリームとダイレクトに統合されています。

private static void encryptFile(final MasterKeyProvider<?> provider,
        final String inputFile, final String outputFile) throws IOException {
    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open the files for reading and writing
    try (
            final FileInputStream in = new FileInputStream(inputFile);
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the output stream in encryption logic
            // It is important that this is closed because it adds footers
            final CryptoOutputStream<?> encryptingStream =
                    crypto.createEncryptingStream(provider, out)) {
        // Copy the data over
        IOUtils.copy(in, encryptingStream);
    }
}

 

例えば、このファイルにはアプリケーションの機密データ(パスワード、証明書等)を含めることができ、それをEC2インスタンスのローンチの時に EC2 ユーザーデータとして送信することができます。

 

データを復号化する

次のコードサンプルは、EC2ユーザーデータのコンテンツを復号化し、指定したファイルに書き出します。AWS SDK for Javaは、デフォルトでローカルリージョンのKMSを利用します。ですので復号化はクロスリージョンコール無しに素早く処理されます。

public static void main(String[] args) throws Exception {
    // Get parameters from the command line
    final String outputFile = args[0];

    // Create a master key provider that points to the local
    // KMS stack and uses Roles for EC2 to get credentials.
    final KmsMasterKeyProvider provider = new KmsMasterKeyProvider(
        new InstanceProfileCredentialsProvider());

    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open a stream to read the user data
    // and a stream to write out the decrypted file
    final URL userDataUrl = new URL("http://169.254.169.254/latest/user-data");
    try (
            final InputStream in = userDataUrl.openStream();
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the input stream in decryption logic
            final CryptoInputStream<?> decryptingStream =
                    crypto.createDecryptingStream(provider, in)) {
        // Copy the data over
        IOUtils.copy(decryptingStream, out);
    }
}

おめでとうございます！これで複数のリージョンのマスターキーで暗号化されたデータを、常にローカルのKMSスタックを使って復号化するコードを得たことになります。これで、1つの暗号文を管理するだけで、高い可用性と低レイテンシーな復号化を実現することができます。

 

Example 2: エスクローとポータビリティのためにアプリケーションの機密データを異なるプロバイダーのマスターキーで暗号化する

複数のマスターキーでデータを暗号化したいもう一つの理由として、鍵管理を単一のプロバイダに頼る事を避けるためというものがあります。単一の鍵管理ソリューションと抱合せにならないことにより、アプリケーションの可用性を改善することができます。このアプローチは、コンプライアンス要件やデータ損失からの防御、災害対策の要件によって複数のプロバイダを必要とする場合に役立つかもしれません。

エスクローのためのデータ暗号化や、プライマリのプロバイダと独立した追加の復号化マスターキーを利用するために、この記事で先ほど紹介したものと同様のテクニックが使えます。この例では、RSAの公開鍵と、KMSとは独立したオフラインハードウェアセキュリティモジュール(HSM)のような鍵管理インフラストラクチャに保管されている秘密鍵を、追加のマスターキーとしてどのように利用するかを示します。(RSAキーペアの生成と管理はこの記事の対象外とします)

 

データを公開マスターキーで暗号化する

データを暗号化するためにいくつかのKmsMasterKeysを作成した先ほどのコードサンプルと同様に、次のコードサンプルはRSA公開鍵を利用するもう一つのMマスターキーを作成します。この例では、Java Cryptography Extensions (JCE)のjava.security.PublicKeyオブジェクトを利用するためにJceMasterKeyを利用します。この例では、新しいマスターキーを(他の全てのマスターキーと一緒に)MultipleProviderFactoryに渡します。この例では、rsa_public_key.derというファイルから公開鍵を読み込みます。

private static MasterKeyProvider<?> getMasterKeyProvider()
      throws IOException, GeneralSecurityException {
    // Get credentials from Roles for EC2
    final AWSCredentialsProvider creds =
        new InstanceProfileCredentialsProvider();

    // Get KmsMasterKeys for the regions we care about
    final String aliasName = "alias/exampleKey";
    final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

    // Load the RSA public key from a file and make a MasterKey from it.
    final byte[] rsaBytes = Files.readAllBytes(
        new File("rsa_public_key.der").toPath());
    final KeyFactory rsaFactory = KeyFactory.getInstance("RSA");
    final PublicKey rsaKey = rsaFactory.generatePublic(
        new X509EncodedKeySpec(rsaBytes));
    final JceMasterKey rsaMasterKey =
        JceMasterKey.getInstance(rsaKey, null,
            "escrow-provider", "escrow",
            "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

    return MultipleProviderFactory.buildMultiProvider(
        useast1, uswest1, uswest2, rsaMasterKey);
}

 

秘密鍵を利用した復号化

多くのHSMは、標準的なJava KeyStoreインターフェースをサポートしています。あるいは、少なくともJava KeyStore 実装を使うことができるPKCS ＃11ドライバーを提供しています。次の復号化コードサンプルでは、KeyStoreから取り出したRSA秘密鍵を利用しています。

public static void main(String[] args) throws Exception {
    // Get parameters from the command line
    final String inputFile = args[0];
    final String outputFile = args[1];

    // Get the KeyStore
    // In a production system, this would likely be backed by an HSM.
    // For this example, it will simply be a file on disk
    final char[] keystorePassword = "example".toCharArray();
    final KeyStore keyStore = KeyStore.getInstance("JKS");
    try (final FileInputStream fis = new FileInputStream("cryptosdk.jks")) {
        keyStore.load(fis, keystorePassword);
    }

    // Create a master key provider from the keystore.
    // Be aware that because KMS isn’t being used, it cannot directly
    // protect the integrity or authenticity of this data.
    final KeyStoreProvider provider = new KeyStoreProvider(keyStore,
            new PasswordProtection(keystorePassword),
            "escrow-provider", "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open a stream to read the encrypted file
    // and a stream to write out the decrypted file
    try (
            final FileInputStream in = new FileInputStream(inputFile);
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the output stream in encryption logic
            final CryptoInputStream<?> decryptingStream =
                    crypto.createDecryptingStream(provider, in)) {
        // Copy the data over
        IOUtils.copy(decryptingStream, out);
    }
}

 

結論

エンベロープ暗号化はパワフルですが従来は実装が難しいものでした。新しいAWS Encryption SDKはユーザーがデータキーを管理する助けとなり、複数のマスターキーでデータを暗号化するプロセスを簡素化します。結果、この新しいSDKを利用することでビジネスを前進させるコードにフォーカスすることができます。またこのSDKは、ユーザーの標準に適合、強制させる為に構成された暗号化ライブラリを利用しなければならない場合にも容易に拡張ができるフレームワークを提供します。

AWS Encryption SDKをリリースする事をとても嬉しく思っており、このSDKを利用して皆様が何をするかを伺うのを待ちきれません。新しいSDKやこの記事についてコメントのある方は、下記のコメントセクションにお願いします。実装や使い方に対する質問のある方は、KMS forumまでお願い致します。

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

CloudWatch Metrics for Spot Fleets

by AWS Japan Staff | on | in Amazon CloudWatch, EC2 Spot Instances |

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（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
  • DiskReadOps
  • DiskWriteBytes
  • FulfilledCapacity
  • NetworkIn
  • NetworkOut
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System

これらのメトリックスを利用することでアベイラビリティゾーン、インスタンスタイプをまたいだの負荷の許容可能な分布確認をすることができます。

フリート全体の使用率を把握するためにMax、Min、またはAvgを使用しメトリックを集計することができます。一方で、2種類以上のインスタンスからなるフリートでは、Avgを使用すること自体意味がないことにもご注意ください！

利用可能

この機能はすでにご利用頂けます。

— Jeff (翻訳は酒徳が担当しました。本文はこちら：https://aws.amazon.com/jp/blogs/aws/new-cloudwatch-metrics-for-spot-fleets/)

 

Redshiftアップデート：COPYやVACUUMの機能向上、クラスターリサイズの速度向上等

by AWS Japan Staff | on | in Amazon Redshift |

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。

このリリースには以下の新機能が含まれています。

  1. ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように
  2. COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように
  3. 接続ログに、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）

【アップデート】 AWS IoT が Elasticsearch Service と CloudWatch に連携できるようになりました

by AWS Japan Staff | on | in AWS IoT |

AWS IoT のルールでデバイスが生成したデータを直接、 Amazon Elasticsearch ドメインに渡すことができるようになりました。これによってデータを分析したり、データに対してフルテキストやパラメータによる検索を実行したり、 Kibana で可視化したりすることができます。この連携によって、デバイスの特定のエラーコードをフルテキスト検索したり、デバイスのパフォーマンスをリアルタイムに近い形で視覚化するような、ユースケースをサポートします。

加えて、AWS IoT のルールによって、デバイスが生成したデータを Amazon CloudWatch に発行することができるようになりました。これによって、デバイスのメトリックスをグラフ化して見たり、アラートをセットすることができます。

これらの新しいルールをどのように利用するかについての、より詳しい情報については、AWS IoT デベロッパー ドキュメントを参照してください。または、コンソールにサインインして、ルールを試すことができます。

 

日本語への翻訳は SA福井が担当しました。原文はこちらです： https://aws.amazon.com/jp/about-aws/whats-new/2016/03/aws-iot-integrates-with-elasticsearch-service-and-cloudwatch/

 

AWS Database Migration Service (DMS)が一般公開に！利用可能リージョンも拡大

by AWS Japan Staff | on | in AWS Database Migration Service |

WS000009みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか？それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか？

もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです！去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。

AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動（例：OracleからAurora）といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。

DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。１つのエンドポイント（※ソースもしくはターゲットのデータベースサーバ）はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません（AWS上で稼動するデータベースを別のVPC上に移すようなケース）。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか（インターネットVPNを使うことも可能です）、AWS Direct Connectで接続することが可能です。

データベースをマイグレーションする

数クリックでマイグレーションをセットアップすることが可能です！ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。

AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。（AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています）

 

コンソールにはマイグレーションプロセスのオーバービューが表示されています:

Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します:

このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです（訳注：オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります）:

レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。（正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました）

そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data（既存データの一括ロード）”,”migrate and then replicate（一括コピーをした後に、継続的に差分レプリケーション）”,”replicate going forward（差分レプリケーションのみ実行）”の３種類から選択が可能です。

Task Settingsをクリックすることで、追加のオプションを選択可能です（LOBというのはラージオブジェクトのことです):

マイグレーションタスクが準備完了になりました。タスクを選択してStart/Resumeボタンを押すことですぐに実行することが可能です:

実行中の状況を確認することが可能です。また表へのアクセスの統計情報(Table statistics)によって、何が起こっているのかを把握することが可能です（この図はテスト用の表を使った結果なので、あまりエキサイティングな図ではないですが）:

 ここまで来たら、あとはデータの正当性をチェックし、アプリケーションを新しいエンドポイントに向けるだけです。上記は一括ロードの例ですが、継続的なレプリケーション(ongoing replication)を選択することも可能です。

AWS Database Migration Serviceは多様なオプションを提供しており、上記はあくまで少し機能を紹介したに過ぎません。例えば、特定の表だけをマイグレーションしたり、複数の異なるレプリケーションタスクを作成し、それぞれ個別に実行することも可能です。DMSのドキュメントを読まれることを強く推奨します。マイグレーションを始めて行う人向けの良いガイドになっています。

多くのデータベースを移行する必要があり、作業を自動化したい場合は、AWS Command Line Interface (CLI) もしくはDatabase Migration Service APIを利用することができます。

費用と稼動リージョン

AWS Database Migration Serviceは US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) の各リージョンに存在します。そして本日より利用可能です！（私達は他のリージョンへの拡張を今後数ヶ月で検討しています）

— Jeff;

原文：https://aws.amazon.com/jp/blogs/aws/aws-database-migration-service/

翻訳：下佐粉　昭（@simosako）

 

Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました

by AWS Japan Staff | on | in Amazon RDS |

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。

フェイルオーバの優先順位は

指定した優先度
優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス
優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます

さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。

— 星野 (原文はこちら)

10 Lessons from 10 Years of Amazon Web Services ～ AWS10年に学ぶ10のレッスン

by AWS Japan Staff | on | in General |

 

Amazon.comのCTO  Werner Vogelsが、彼のブログでこの10年のAWSの軌跡を振り返っています。
ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。

——————–

AWSの革新は2006年3月14日のAmazon S3のローンチで、約10年前の出来事でした。10年前を振り返ると、低価格で予測可能なパフォーマンスにより、セキュアで、信頼性があり、拡張性が高い、構築・運用が実現できていることから、数百もの学びがあります。AWSは、世界規模でサービスを構築・運用できるパイオニアであり、これらの学びは我々のビジネスにとってとても重要です。以前も何度となくお伝えしている通り、経験だけはショートカットするする方法がない、ということです。毎月の数百万ものアクティブなお客様と共に、彼らの先にいる数億ものお客様と共に、お客様にサービスを提供しながら改善するためのまたとない環境と学ぶ機会を得ています。

みなさんと共有したいいくつかの学びをご紹介します。

1. 進化可能な仕組みを構築する

ビジネスが始まる初日から、開発していたソフトウェアは、もはやソフトウェアに非ず、ということを一年間走らせてみてわかりました。その期待値は、金額でいえば一桁、二桁も異なり、スケールの問題を解決する為のアーキテクチャの再考が必要になったものです。

 
とはいえ、世界中で24時間365日多くのシステムが我々のプラットホームで動作しているのですが、システムアップグレード時にメンテナンスによる中断を起こさないようにする形態をとることはできませんでした。我々は、サービス停止を起こさずに新たなコンポーネントを導入できるアーキテクチャを作る必要がありました。Marvin Theimer, Amazon Distinguished Engineerの彼が、Amazon S3を例えば言うならば、当初は単機エンジンだったセスナが、時間を経過するとボーイング737や747sにアップグレードされている、そして最後はエアバス380sのようだ、と冗談まがいに言っていました。成長の途中で、空中燃料補給をしながら、お客様に築かれないように飛行機を乗り換えているようだと。
 
2. 想定していないことを想定する

失敗はもたらされるもので、すべてが最後は失敗に成り立っている。ルーターからハードディスク、OSからメモリユニット、誤ったTCPパケット、一時的なエラーから、永続的な故障などがあります。これは、最高品質のハードウェアであろうが量産品であろうが、最終的な顛末は同じです。

拡張性において、さらに重要になってきます。例えば、S3が数兆回ものトランザクションを処理しているときでも、ほんのわずかな可能性でも、それは現実に起こります。このような故障のシナリオの多くは事前に予知できますが、設計や構築時点では知る由もありません。

我々は、故障が何なのかは知らずとも、自然発生で起こる故障も冗長化しカバーできる構築が必要でした。システムがもし火事にあったとしても動作し続ける構造が必要なのです。システム全体をダウンさせることなく、個々のモジュールを管理できることが重要です。我々は、システム全体のヘルスチェックを可能にするような、故障発生時の影響範囲を管理する基本的な仕組みを開発しました。

 

3. フレームワークでなくプリミティブ

ほどなくして、AWSのサービスを利用したいと考えている企業の多くは既に何らかのAWSサービスを取り組んでいると気づきました。お客様が制約を許容し、過去のIT関連のハードウェアとデータセンターの世界と決別すると、前例のない使用パターンで構築し始めるということが起こりました。そのように、お客様のニーズに合ったものを確実に届ける為に、素早く動かざるを得ない状況でした。

もっとも重要な事のひとつに、小さなサービスやツールをお客様に届けるという事で、ひとつのフレームワークを強制されるよりも、キッチンの道具のようにすべてそろっていて組み合わせるように、AWSクラウドで実現できる最適な方法を選んでいただけるような構成にしていました。この方法はお客様の成功につながりましたし、後にAWSのサービスの基本的な製品／サービスの考え方をして活用しています。

お客様がサービスを手に取り、使って構築するまで、どのような優先順位で対応すべきか予期することは難しい、ということに気付くのが重要です。最小の機能性でサービスをリリースし、お客様の要望に合わせてサービスのロードマップを作っています。

4. 自動化がカギ

サービスを構築するのと従来のソフトウェア開発でお客様に納品するのとは大きく異なります。拡張性の高いシステムを管理するには、お客様の期待する信頼性、パフォーマンス、スケーラビリティに合うようにする異なるマインドセットが必要です。できるだけ自動化を可能にし、マニュアル操作とエラーを事前に取り除く管理方法を実現するには自動化が重要なカギになります。実現するには、操作に重要となる機能を制御するAPIを構築する必要がありました。お客様にも同様に助けになることです。アプリケーションの構造を分解し、それぞれ管理用APIで、拡張可能でパフォーマンスとメンテナンス性に優れたルールを作ることができます。

5. APIは永続

アマゾンの小売りの経験から得たものでもありますが、AWSがAPI中心のビジネスになることはさらに重要です。お客様が我々のAPIを使ったシステムとアプリを構築し始めたのなら、お客様のビジネスに影響を与えるとして、APIを変更することは不可能になります。APIのデザインは非常に重要であり、正しく設計できるチャンスは一度きりだということを肝に銘じねばなりません。

6. リソースの使い方を知る

適切なサービス利用料を特定しサービスを見積もる際には、コストと運用の良いデータを手に入れることです。特に薄利多売のビジネスモデルにおいてです。AWSはコストを低減させるための努力を惜しまないため、お客様に届けるサービスも投資してもよいと思えるものであり、さらに値下げしても運用継続可能な範囲を見極め、利益を低価格という形でお客様に還元しています。

先の一例として、S3ではどの程度使用されるかパターンがわかりませんでした。ですから、ストレージとネットワークの帯域に対して主な課金を行うというように仮定しました。しばらく運用した後、リクエスト回数も同様に重要な指標だと気づきました。もしお客様がたくさんの小さなファイルを持っているとすると、ストレージと帯域は何百万件のリクエストであろうと計算しませんでした。我々は、AWSのビジネスが継続的なものになるよう、計算モデルを調整しなければなりませんでした。

7. ゼロからのセキュリティ対策

お客様をセキュリティの脅威から守ることは、運用の観点においても、提供するツールや仕組みにおいても、AWSとしては最優先すべき事項です。我々が永遠に投資をし続ける領域です。

素早く学ぶひとつのアプローチとして、最初にサービスを企画・設計する段階で、セキュリティ対策を組み込んでおくことが必須です。セキュリティの専門チームは、何かを構築してから検証するチームではありません。サービスが始まるその日からパートナーとして基本的なセキュリティが担保され強固であるか確認しています。セキュリティに関しては妥協しません。

8. 暗号化は最良の住人

暗号化はお客様にとってデータにアクセスする人に対する最大の制御方法であると言えます。10年前、暗号化のツールやサービスは使いにくく、我々のサービスにどう組み込むのがベストか検討しました。

暗号化はコンプライアンス順守の観点で、サーバーサイドの暗号化をS3で実装しました。もしあなたがデータセンターでディスクをのぞき見しようとしても、どのデータへもアクセスはできないでしょう。しかし、Amazon CloudHSMと後のAmazon Key Management Serviceを使えば、お客様は独自キーの管理とそれを使った暗号化ができるようになります。

今では、暗号化対応は新サービスには企画・設計段階で統合されています。例えば、Amazon Redshiftは、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。

暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。

9. ネットワークの重要性

AWSは多くの異なるワークロードに対応してきました。高トランザクション処理から動画変換、高度計算処理から大量のウェブアクセスまで規模を拡大しながら対応できます。これらのワークロードはネットワークにおいては独自の要件があります。

AWSはデータセンターの構成や運用に対して独自のスキルを有しており、お客様のワークロードがいかなるものであっても、それに対応した柔軟なネットワークインフラを持っています。我々は、お客様の達成したい目標に合わせて実現することに対して、ハードウェアまで独自に構築することもいといません。つまり、とても特殊な要件に対しても実現することを可能にし、AWSのネットワークを使用すればお客様が高いセキュリティの担保と差別化が可能になります。

どのようにAWS指定のネットワークハードウェアとソフトウェアでお客様のパフォーマンス改善しているかという成功事例でいうと、仮想マシンから仮想化されたネットワーク上での負荷を分散し解決する事でした。なぜならば、ネットワークアクセスは共有リソースであり、お客様が以前ネットワークアクセスで遅延を感じたこともあるからです。シングルルートの仮想I/Oに対応したNICの開発は独自のVMのハードウェア上にある仮想化NIC実装を可能にしました。これにより遅延に関しては2倍以上高速になり、ネットワーク上の実測では10倍もの改善になっています。

10. イノベーションに制限なし

AWSは、お客様に対して幅広で深いプラットホームを実現する為、様々な機能やサービスを提供しています。しかし、AWSはインハウスで構築するサービスはそれほど多くありません。パートナーエコシステムを活用し、様々な新たな方向にプラットホームを拡張しています。

例えば、StripeというパートナーはTwilioがAWS上でビジネスができるよう支払いサービスを提供しています。お客様の多くは提供するサービスの深さに対応する為のAWS上のサービスを構築しています。Philipsは健康に関するデジタルプラットホームを健康維持のためのデータ管理に使っています。OhpenはAWS上に少額バンキング向けのプラットホームを構築しています。Eagle Genomicsはゲノム解析のプラットホームを構築しています。他にもいろいろあります。肝心なことは、AWSプラットホーム上には、制限をかけるものは何もないので、やりたい事を実現すればいいのです。「制限がない」というのは、イノベーションに向けた開放で、思いがけない多くの発明の扉を開けるでしょう。

我々が今後学んでいくことが何か楽しみにしています。AWSのお客様が10年後に達成していることもです。覚えておいてください、今日がいつでも「初日」（Day 1）であることを・・・

——————–

 

（翻訳は石橋が担当しました。）

 

 

Ten Years in the AWS Cloud – How Time Flies! ～ AWSクラウドの10年

by AWS Japan Staff | on | in General |

 

10年前の今日、simple blog postでAmazon S3のローンチについて発表しました！それから10年経過したとは信じ難いです。そうでなければ、2000ものブログ記事を書いてはいないでしょう。

 

Future Shock
私が高校生の頃、1977年当時新しいと言われていたFuture Shockというタイトルの書籍を読んでレポートを書きました。その本の中で、未来学者のAlvin Tofflerが急速な変化は、人々を圧倒し、ストレスを加え、方向を失わせることについて論じていました。そのレポートをごみ箱に捨てるまでの間、変化はよいことであり、人も組織も受け入れ対処することによってさらによくなる、と議論したのを覚えています。

まだキャリアの浅い頃、多くの予見されている技術は、新しいものに移行するというよりも、過去のものをよりよくしている状況でした。その時、私は21歳で、過去よりも未来の技術の世界でやっていく、変化と進化を受け入れるだけではなく、積極的に探し求める、と決めました。その決断から35年が経ちました。2004年に最初のブログを書き始め、今では10年もの間AWSに関連するニュースをお届けすることができています。

A Decade of IT Change ～ 10年の軌跡、ITの変化10年
10年を振り返ってみると、ITの世界がどれだけ変化したのかを目の当たりにし、とても感銘を受けます。さらに印象深いことは、技術の面だけに留まらず、ビジネスモデルやその関連する事も変化しました。そのビジネス面の変化は、手に入れる、消費する、資源に対して支払う方法に新たな手段をもたらしました。エンタープライズやスタートアップの両方で起こっています。我々の使う表現や描写までも変化しているのです！10年前、まさか「クラウド」「マイクロサービス」「サーバレスアプリ」「IoT（モノのインターネット）」「コンテナサービス」「リーンスタートアップ」などという言葉を口にするとは思いませんでした。加えて「継続的インテグレーション」「継続的デリバリ」「DevOps」「ChatOps」を行っているとも思いませんでした。ChatOpsを試したことがないのであれば、VoiceOpsなるさらに新しい技術もあるのでお忘れなく。

むろん、変化をつかまえることは簡単な事ではありません。将来を見たとき、一瞬で終わるものなのか、それとも本物のトレンドなのかを見極めるようになることが必要で、昨日あったたわいもない技術が明日には本流になる技術に、すぐに軸足を変えられる柔軟さも持ち合わせていなければなりません。JavaScriptをその例として用います。（私のような）あなたが、もし、初期のころサーバサイドの開発者としてJaveScriptがあったら気にも留めなかったでしょうし、ブラウザのみで動作する言語は無視したでしょう、あなたは疑いもなくAjaxといった機能豊富で動的なアプリやNode.jsなどサーバ側で動く言語を動作させなかったでしょう。

今日、現状が意味するところは、同じプログラム言語、システムアーキテクチャ、業界のベストプラクティスが存在するということです。それは、現状のスキルを磨くことや新たなものを探すことに日々時間を使ったほうがいいということを意味しています。一日のうちに複数の開発が同時に起こる新しい世界が、グローバルチームと合意・協働し、ビジネス価値を提供し続けて、当たり前の状態になってきます。

A Decade of AWS　～ AWSの10年
AWSがローンチしたいくつかのサービスとブログ記事を見てみましょう。

最初でいまだ関連の深いサービス (2006) – Amazon S3 とてもシンプルなコンセプトですが、裏側の仕組みは複雑に動作しています。TechCrunchが革新的だと当時言っていました！

時間単位のサーバリソース (2006) – Amazon EC2 Cabo San Lucanのプールサイドに座ってブログを書いていました。ローンチは数か月間ひっ迫し、飛行機に乗る直前で世に出ました。そのシンプルなスタート（インスタンスタイプはひとつ、ひとつのリージョン対応、CLIのみでアクセス）から、今ではお客様の声を多数取り入れ現在に至ります。2006年の今日の出来事でした。

データベースを簡単に (2009) – Amazon Relational Database Service (RDS) インストールに時間を使う、チューニングするなどMySQLの管理工数は高く、個人的にも長期的なプロジェクト課題でした。RDSがいかにワークロードを軽くしたか、感謝したいです。

高度なネットワーク (2009) – Amazon Virtual Private Cloud 　VPCのデビューでした。これにより勇み足なエンタープライズITにおいてもAWSを使い始めました。ネットワークの論理的な分離が必要で、AWSが実現したことを喜んでいました。

インターネット時代のデータストレージ (2012) – Amazon DynamoDB ローンチ当時はNoSQLはまだまだ黎明期でした。今では、マーケットは見えつつあり、お客様が大規模データをDynamoDBで扱うことや要望を沢山聞くようになりました。

数分で構築できるデータウェアハウス (2012) – Amazon Redshift 多くの企業がデータウェアハウスの稼働に1四半期から年単位で時間を要しています。Amazon Redshiftは、すぐに始められる方法を提供しています。

クラウドでデスクトップ仮想化 (2013) – Amazon WorkSpaces あまり関係ないかすごくいいのどちらかで、見過ごされることが多いですが、デスクトップの仮想化は私にとってもお客様にとっても生産性向上の為に重要になってきています。

リアルタイム分析？どのくらいのデータ量？ (2013) – Amazon Kinesis データ取得、解析、結果の取得を大量のストリームデータから、簡単に取り出せます。

新たなプログラミングモデル～サーバレス (2014) – AWS Lambda このサービスも破壊的で革新的です。多くのエンタープライズで、Lambdaの使い方をマスターした、洗練された利用が開始されていることがとても印象深いです。スタートアップで利用する、アプリをサーバレスに置き換えるといったLambdaの使われ方を期待しています。

デバイスの未来 (2015) – AWS IoT 大量生産されている計算能力と広域のIP接続が可能にする、モノのインターネット。各種のデバイスがつながります。

Moving Forward ～ その先へ
10年前、クラウドコンピューティングのリスクが適用時の主な懸念点でした。それは、新しく、実証のない、答えのないものに対する懸念でした。その時代はいつしか過ぎ去りました。最近では、クラウドへ移行しないことのリスクが会話としてあるのを聞いたことがあります。どのような規模や形態の組織も、素早く、最新のインフラを利用し、同じものを使うことでプロを喜ばせることができるのではないでしょうか。今日の社員は、最新ではやりの技術を使って生産性を上げたいはずです。

次のクラウドの10年は、過去の10年と同じくらいエキサイティングであると確信しています。学び、開発し、あなたの成功を私たちに共有してください！

 

— Jeff;

 

お知らせです。この記事から学びの継続性についてわかっていただけたかと思います。同僚と話をし、qwikLABSをオンラインラボとして、3月31日（米国時間）まで無料で使っていただける機会をご提供することになりました。詳細は、qwikLABS.comを見てくださいね。日本語でご覧になりたい方はこちらをご覧ください。

 

 

（翻訳は石橋が担当しました。）

 

 

 

A Decade of Innovation ～ イノベーション10年の軌跡

by AWS Japan Staff | on | in General |

 

AWSのVP and Distinguished EngineerであるJames Hamiltonが、彼のブログでこの10年のAWSの軌跡を振り返っています。
ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。

——————–

AmazonS3PressReleaseSmall

 

2006年3月14日はコンピューティングの新時代の始まりでした。それは、Amazon Web ServicesがSimple Storage Service (S3)をリリースした日だからです。技術の点では、Simple Queuing Services (SQS) が先にリリースされましたが、クラウドコンピューティングにおいては、S3が光を点したといえるでしょう。その日をよく覚えています。そのとき私は、Microsoftの子会社となったアンチスパム、アンチマルウェア、アーカイブサービスをクラウドで提供するFrontbridge Technologiesのジェネラルマネージャでした。この経験で、クラウド管理型サービスの顧客価値がわかりました。お客様も設定のスピードが速くコストが低減できるクラウドが好きなことがわかり、多くの経験から既に気持ちが変化していました。クラウドホスティングが今後の本流だと感じたものです。

 いまだにS3の発表は私にとって開眼した出来事です。テクノロジ業界は毎日１００もの発表をしていますが、多くを目にすることはありません。多くの場合、興味がわくようなものではないのです。でも、S3の発表は革新的でした。特に驚いたのはサービスの価格でした。我々が当時支払っていたデータセンターの冗長ストレージの２桁近く安い価格だったのです。でも、さらなる破壊的な事もあり、サービスを利用するにはクレジットカードのみ登録すればよいという事でした。経理の承認の裁可もいらないし、相見積を取る必要もなく、ベンダーを選ぶ必要もなく、ベンダーとの交渉も必要なく、データセンターのスペースを探す必要もありませんでした。ただ、サインアップして使い始めることができたのです。

注目すべきことは、低価格と設定の容易さで、いわゆるトラディショナルなエンタープライズのITプレイヤーではなく、あのAmazonから発表があったという事なのです。高い中間マージンが必要で、交渉が難しく、ライセンス使用の監査も必要な企業ではなく、あのAmazonなのです。多くの企業においては、中間マージンが得られなければ、経営層を変えろという話になるでしょう。Amazonのビジネスは大きな変化をもたらしました。異なるサプライヤ、異なるビジネスモデル、設定にかかる短いステップ、そして徐々に安くなるのではなく、最初から価格が圧倒的に低いという、根本的に異なる価格体系です。

S3の発表は業界横断的に興味をそそり、どうやったらそれが可能になるのだろうかと疑問の声がありました。大量に仕入れと供給をするサプライヤであっても、バイト単位の販売に関しては実施しないでしょう。本当にその内容がいいと思いましたし、信頼できるストレージシステムとして、S3を使って作成したソースコードを保存していました。その時は、すこし格好悪いですが、とがっていて、大きなことを始めたいという気持ちでアプリを書いていました。

アプリを書いてから動かすまで何日かかかり、デバッグとテストを延長し、月末になって、私はVisaの請求を受け取りました。もちろん、S3が非常に低コストである事は知っていましたが、すべてのアプリ開発とテストにかかった費用は3.08ドルでした。請求が間違えているのかと思いました。開発が終わっても、テストデータはS3に保存してあったのですが、次の月に受け取った請求は0.07ドルでした。

とても革新的でしたし、当時社内でもブログを書きました。CTOやCEOといった会社のリーダーにもデモをしました。プレゼンにはS3での早期の開発例のひとつであるAl Vermeulenの写真が含まれていて、どうS3が動作するか、本当に他と異なるところを強調しました。私は2つのAWSのサービスに対する請求がありました。ポイントはAmazonがただ演技や少し試してみるといったことで一時的にサービスを提供しているわけではなく、インフラサービスの提供の真に新たな方法であると本当に考えられたものでした。当時は、ストレージが最初のリリースで、その後まもなくコンピューティングのサービスが始まりました。

私は心底AWSに興味を持ち、2007年までユーザグループのミーティングにも参加していました。Amazonでプレゼンも実施し、最終的には2008年後半にAmazonに入社しました。

AWSのエンジニアチームのメンバーとなりましたが、私の第一印象はとてもスピードが速いと、言い表せるのではないでしょうか。他の会社では、決定は素早くなされ新たなアイデアはソースコードになったとしても、最終的にお客様が利用できるようになるには大陸移動と同じくらい時間がかかる、いわゆるエンタープライズITのペースになります。前職では、半分冗談で「我々はお客様が必要かどうか10年に2度リリースすればよい」と考えていました。AWSでは、機能はすぐにリリースされ、追えないくらいになっています。

他に面白いストーリーとしては、エンジニアチームの議論をどうまとめるかです。議論はしばしば起こり、積極的なディベートになります。決定事項はさらなる情熱や信念が加わりますが、最終的にはデータに基づいた判断がなされます。AWSでは、戦略とお客様が何を必要としているのかの代わりに、我々が便利と思うものを見つけリリースし、広くお客様へのサービスとして普及するかどうか見極めてから投資をします。よいサービスが最高のサービスに素早く育つわけです。

以前の役割の中のいくつかで、このような建設的な議論が生活よりも多くを占め、ここ数年間の非生産性に終止符を打ちます。AWSならお客様の使用データからデータを発見し、素早くアクションにつなげられます。ディベートから成果物ではなく、その逆もあります。多くの労力をお客様が判断します。このような労力からソリューションが提供できるようになるのです。成果物のスピードはお客様が使うことでさらによくなることから、AWSはエンジニアにとってはエキサイティングな環境です。

イノベーションの証明となるのはお客様のコミットメントで、偽りなく、お客様のコミットメントの表れが全社の取り組みを変えます。Netflixは100%の移行を公で決めた最初の企業です。

  • 2010 Netflix
  • 2013 Kempinski Hotels
  • 2013 Suncorp Group
  • 2014 Infor
  • 2014 Nippon Express
  • 2014 Notre Dame University
  • 2014 National Democratic Institute
  • 2015 The Guardian Media Group

個人的な見解では、クラウドだけのインフラで行こうと決めた企業は、業界を変えるような大きな変化があります。

以下は、AWSのサービスリリース一覧です。

2006

  • 2006 Amazon S3
  • 2006 Amazon SQS
  • 2006 Amazon EC2

2007

  • 2007 AWS introduces commerce platform for AWS, rapidly accelerating adoption, Amazon FPS
  • 2007 Amazon S3 in EMEA
  • 2007 Amazon Simple DB

2008

  • 2008 pricing plan for Amazon SQS and new WSDL (1st price drop)
  • 2008 Elastic IP Addresses
  • 2008 Availability Zones for EC2
  • 2008 AWS adds Premium (enterprise) support
  • 2008 AWS Lowers Data Transfer Costs
  • 2008 Amazon Elastic Block Storage
  • 2008 EC2 SLA and GA, EC2 for Windows, EC2 for SQL Server
  • 2008 New Tiered Pricing for Amazon S3
  • 2008 Amazon CloudFront
  • 2008 EC2 in Europe (Ireland)

2009

  • 2009 AWS Management Console
  • 2009 New lower pricing tiers for Amazon CloudFront
  • 2009 Amazon FPS
  • 2009 Elastic MapReduce
  • May 2009 Elastic Load Balancing,
  • May 2009 Amazon Autoscaling
  • May 2009 Amazon CloudWatch
  • 2009 AWS Virtual Private Clou
  • 2009 New lower prices for Amazon EC2 Reserved Instances
  • 2009 New lower prices for Windows instances with authentication services
  • 2009 AWS enters the database market with Amazon Relational Database Service
  • 2009 Lower Amazon EC2 on demand pricing
  • 2009 EC2 Spot Instances
  • Dec 2009 AWS S3 Pricing reductions, Free Inbound Data Transfer until 6/30/2010
  • 2009 Amazon CloudFront Streaming
  • 2009 AWS US West Region

2010

  • 2010 Lower Pricing for Outbound Data Transfer
  • 2010 AWS launches first region in Asia Pacific (Singapore)
  • 2010 Amazon SNS
  • May 2010 Multi Availability Zones for RDS
  • May 2010 Amazon S3 Reduced Redundancy Storage
  • 2010 AWS Import/Export
  • 2010 Amazon CloudFront adds HTTPS Support, lowers prices, Opens NYC edge location
  • 2010 Cluster Compute Instances for EC2
  • 2010 AWS Identity and Access Management
  • 2010 Oracle certifies enterprise software on AWS
  • 2010 New lower prices for High Memory Double and Quadruple XL instances\
  • 2010 Read Replicas, Lower High Memory DB Memory Instance Prices for Amazon RDS
  • 2010 Amazon S3 lowers storage prices
  • 2010 Amazon Route 53
  • 2010 Mobile SDKs for AWS

2011

  • 2011 Amazon SES
  • 2011 AWS New Premium Support Plans, Lowers usage prices by 50% on existing plans
  • 2011 AWS Elastic Beanstalk
  • 2011 AWS CloudFormation
  • 2011 AWS Tokyo Region
  • May 2011 SAP certifies enterprise software on AWS
  • May 2011 Amazon CloudWatch custom metrics, lower prices for Amazon EC2 monitoring
  • 2011 AWS new Data Transfer Pricing
  • Aug 2011 Amazon ElastiCache
  • Aug 2011 AWS enables enterprises to connect their data centers directly to AWS via AWS Direct Connect
  • Aug 2011 AWS launches Region dedicated to US Government Agencies and Contractors (AWS GovCloud)
  • 2011 AWS Route53 lowers pricing for hosted zones
  • 2011 AWS US West Region (Oregon) 100% Carbon Free Power
  • 2011AWS enters South America with region in Sao Paulo, Brazil
  • 2011 Amazon Elastic MapReduce support for cc2.8xlarge and reduced pricing for cc1.4xlarge

2012

  • 2012 AWS Storage Gateway
  • 2012 Dynamo DB
  • 2012 Amazon SWF
  • 2012 Amazon S3 lowers prices for standard storage
  • March 2012 New lower pricing for Amazon EC2, RDS and ElastiCache
  • April 2012 Amazon CloudSearch
  • 2012AWS Marketplace for third-party selling of applications to businesses
  • 2012 AWS Support Expands Free Tier, Adds Features, Lowers Prices
  • 2012 AWS Sydney Region
  • July 2012 EC2 High I/O Instances
  • 2012 Amazon Glacier
  • 2012 EBS Provisioned IOPs Announced
  • 2012 Second Gen Standard Instances for Amazon EC2 and a price reduction for M1 Instances
  • 2012 More than 6K attend first AWS user conference, re:Invent
  • 2012 AWS announces Amazon RedShift
  • 2012 Amazon CloudSearch free trial program and price reduction
  • 2012 Amazon RDS and Amazon ElastiCache Lower Prices
  • 2012 Amazon S3 Lower prices for Standard Storage and RRS
  • 2012 AWS Data Pipeline

2013

  • 2013 Amazon Elastic Transcoder
  • 2013 High Memory Cluster Instances
  • 2013 EC2 Price Reduction, global expansion of M3 Standard Instances, reduced data transfer pricing
  • 2013 AWS OpsWorks
  • 2013 IBM protest reveals that AWS won $600M cloud contract with CIA
  • 2013 Amazon RDS reduces price of Multi-AZ Deployments
  • 2013 Amazon SQS and SNS lower prices and expand free tiers – 50% price drop for SQS
  • 2013 AWS CloudHSM
  • 2013 AWS introduces global developer training and certification program
  • 2013 Lower prices on Amazon EC2 Reserved Instances, Amazon DB
  • 2013 AWS lowers prices for Amazon S3 request pricing, Windows on-demand EC2 instances by up to 26%
  • May 2013 AWS first major cloud provider to gain FedRAMP certification
  • 2013 AWS lowers prices of on-demand and reserved RDS instances by up to 28%
  • July 2013 AWS price reductions on EC2 dedicated instances
  • 2013 AWS Gartner estimates that AWS customers are deploying 5x more infrastructure on AWS than the combined adoption of the next 14 providers
  • 2013 Amazon AppStream launched
  • 2013 Amazon WorkSpaces launched
  • 2013 EC2 GPU Instances
  • 2013 price reduction for M3 Instances
  • 2013 – Amazon introduces Amazon Kinesis
  • 2013 Amazon EC2 HI1 Instance price reduction and Spot availability
  • 2013 Amazon China Region

2014

  • 2014 New Amazon EC2 M3 Instance Sizes and Lower Prices for Amazon S3 and Amazon EBS
  • 2014 AWS Storage Gateway price reduction
  • 2014 Amazon Redshift new SSD-based node type
  • 2014 General availability for Amazon AppStream and Amazon WorkSpaces
  • 2014 AWS price reduction EC2, RDS, S3, ElastiCache, and Elastic MapReduce (price reduction #42)
  • 2014 AWS receives Department of Defense-Wide provisional authorization for all U.S. Regions
  • 2014 Availability of R3 instances
  • May 2014 Launch of AWS Management Portal for vCenter
  • May 2014 Introducing Amazon EBS encryption
  • 2014 AWS availability of a new SSD-backed volume type for Amazon EBS (price drop #43)
  • 2014 AWS Opened Pop-up Loft in San Francisco on temporary basis
  • 2014 Amazon Redshift free trial and price reductions in Asia Pacific (price drop #44)
  • 2014 new low-cost general purpose instance type for Amazon EC2
  • 2014 Introduction of Amazon Zocalo (now known as Amazon WorkDocs)
  • 2014 Route 53 price reduction (price drop #45)
  • 2014 Introduction of services for mobile developers: Amazon Cognito, Amazon Mobile Analytics, AWS Mobile SDK, and Amazon SNS Mobile Push
  • 2014 Launched Amazon CloudWatch logs
  • 2014 AWS GovCloud achieves Department of Defense CSM Level 3-5 Provisional Authorization
  • 2014 General availability of Zocalo (now known as Amazon WorkDocs)
  • 2014 AWS EU (Frankfurt) region
  • 2014 AWS Reopened Pop-up Loft in San Francisco on permanent basis
  • 2014 Introduction of native support for document models like JSON into DynamoDB
  • 2014 Introduction of AWS Directory Service
  • 2014 AWS achieves ISO- 9001 certification
  • 2014 Expansion of APN Partner benefits, introduction of new Managed Service and SaaS Partner Programs, and expansion of APN Partner training
  • 2014 CloudSearch price drop (price drop #46)
  • 2014 Introduction of Amazon Aurora, a MySQL-compatible database
  • 2014 Enterprise security & governance services: Key Management, AWS Config, & AWS Service Catalog
  • 2014 New application lifecycle management services introduced: AWS CodeDeploy & AWS CodePipeline
  • 2014 Amazon EC2 Container Service introduced
  • 2014 AWS Lambda announced
  • 2014 Amazon EC2 C4 and EBS pre-announced
  • 2014 AWS pledges long-term commitment to achieve 100 percent renewable-energy usage
  • 2014 Data transfer and CloudFront price drop (price drop #47)

2015

  • 2015 Amazon Wind Farm Fowler Ridge Announced
  • 2015 Amazon WorkMail launches in preview
  • 2015 Amazon Machine Learning, fully managed service announced
  • 2015 AWS Marketplace for Desktop Apps and Amazon WorkSpaces Application Manager
  • 2015 ISVs Go “All-In” with AWS announcement: MicroStrategy, Software AG, TIBCO, and Onshape
  • May 2015 AWS Educate to Accelerate Cloud Learning in the Classroom
  • 2015 Amazon Solar Farm US East Announced
  • 2015 M4 Instances for Amazon EC2
  • 2015 AWS Opens Second Global “City on a Cloud Innovation Challenge”
  • 2015 AWS 2016 India region pre-announced
  • 2015 AWS Opened Pop-up Loft in New York City
  • 2015 ISVs Go “All-In” with AWS announcement: Looker, Qlik, Sumo Logic, and Works Applications.
  • 2015 AWS Announces Amazon API Gateway
  • 2015 AWS Announces AWS Device Farm
  • 2015 Amazon Wind Farm US East Announced
  • 2015 Amazon Aurora General Availability
  • 2015 AWS Announced Pop-up Lofts opening in London and Berlin
  • 2015 AWS Announced Amazon QuickSight at re:Invent
  • 2015 AWS Announced AWS Snowball and Amazon Kinesis Firehose at re:Invent
  • 2015 AWS Announced AWS Database Migration Service and Amazon RDS for MariaDB at re:Invent
  • 2015 AWS and Accenture Announce the Accenture AWS Business Group
  • 2015 AWS Announced AWS IoT preview at re:Invent
  • 2015 AWS Pre-Announced the AWS UK region to be third in the European Union
  • 2015 Amazon Wind Farm US Central Announced
  • 2015 AWS Announced IoT General Availability
  • 2015 AWS Introduced t2.nano, the smallest and lowest cost Amazon Ec2 instance

2016

  • 2016 AWS launched Korea region as fifth in Asia Pacific (Seoul)
  • 2016 Amazon WorkMail General Availability
  • 2015 AWS pre-announced Canada-Montreal region
  • 2016 AWS Announced Amazon Lumberyard and Amazon GameLift Availability for Game Developers
  • 2016 AWS Announced the AWS Pop-up Loft in Tel Aviv

——————–

（翻訳は石橋が担当しました。）