Amazon Web Services ブログ

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

  AWSのVP and Distinguished EngineerであるJames Hamiltonが、彼のブログでこの10年のAWSの軌跡を振り返っています。ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。 ——————–   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 […]

Amazon GameLiftは、クラウドでセッションベースのマルチプレイヤーゲームサーバを簡単かつ費用対効果が高いデプロイ、運用、スケールが行えるフルマネージドサービスです。GameLiftは北米の2つのリージョンで一ヶ月前にローンチされ、本日、日本（ ​​gamelift.ap-northeast-1.amazonaws.com ）とヨーロッパ（ gamelift.eu-west-1.amazonaws.com ）のプレイヤーのために最適なゲームパフォーマンスを提供できるようになりました。   Amazon GameLiftの新しい高度なAuto Scaling機能を利用すると、動的にサーバーFleetのキャパシティを管理するためにGameLiftを設定できます。この機能を使用すると、プレイヤーが高速な接続を確保しがらコストを抑え、サーバのキャパシティをゲームの需要曲線に密接に従うことができます。FleetのためにAutoScaling機能を設定するには、単純にトリガーするタイミングとアクションの種類を定義するポリシーを設定します。例えば、Auto Scalingのルールを「15分以上のアイドル状態のインスタンスが20あれば、10までスケールダウンさせる」といったことができます。GameLift AWS Consoleは、スケーリングのポリシーを作成および適用するためのツールを提供し、またAWS CLIまたはGameLift SDKも使用することができます。Auto Scalingの状態はGameLift AWS Consoleのパフォーマンス・メトリックまたは、Fleetのイベントログで追跡することができます。GameLiftのAuto Scaling機能は、堅牢なAWS Auto Scaling serviceを使用しています。   GameLift Auto Scalingの詳細についてはGameDevのブログの記事をご覧ください。 こちらから始められます。 サービスコンソール ドキュメンテーション FAQ   翻訳はSA 森が担当しました。翻訳元：GameLift Expands Game Server Availability to Europe and Asia and Adds Auto-Scaling

Amazon Redshiftにテーブル単位でのリストア機能が追加されました。これまではスナップショットからのリストアではクラスタ全体をリストアするという方法でしたが、これが表単位で戻せるようになったことで、一部の表の操作ミス等の修復等の用途に使いやすくなりました。 以下はリリースノートの翻訳です。 == Amazon Redshiftのスナップショットから、クラスター全体をリストアするのではなく、表単位でリストアが可能になりました。この新機能を使うことでアクシデントで削除してしまった表を復活させたり、意図しない方法で更新や削除をしてしまったデータを元に戻すことが可能になります。スナップショットから表を復元するには、管理コンソールでクラスターの”Table Restore”のタブをクリックし、”Restore Table”ボタンを押してください。 注意点としては、テーブルのリストアは稼動しているクラスターから取得したスナップショットを同じクラスターに戻す場合にのみ利用できるという事です。また、そのスナップショットはバージョン1.0.1036もしくはそれ以降のバージョンで取得されたものである必要があります。詳しくはAmazon Redshift Cluster Management GuideのRestoreing a Table from a Snapshotをご覧ください。（訳注：本エントリ執筆時点では日本語版にはまだ記載がありませんでした。その場合は英語に切り替えてご覧ください） 原文：https://aws.amazon.com/jp/about-aws/whats-new/2016/03/amazon-redshift-now-supports-table-level-restore/ 翻訳：下佐粉　昭（@simosako）  

週刊 AWS – 2016 年 2 月 29 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 2 月 29 日 AWS Import/Export Snowball でエクスポートがサポートされるようになったことを発表しました。 欧州 (フランクフルト) リージョンでの Amazon CloudWatch Events の提供開始を発表しました。 南米 (サンパウロ) リージョンにおける VPC ClassicLink および ClassicLink DNS のサポートについて発表しました。 AWS Storage Gateway で EMC Networker 8.x と ゲートウェイ VTL の組み合わせがサポートされるようになったことを発表しました。 AWS Windows and .NET Developer Blog が、ASP.NET […]

AWS CodeCommit は、セキュアで高度にスケーラブルなプライベート Git リポジトリを容易にホストできるフルマネージドなソース管理サービスです。今回リポジトリ トリガーを追加することで CodeCommit はさらに有用なサービスになりました。これらのトリガーを利用することで、既にあるユニット テストやデプロイメント ツールをソースコード管理ワークフローに統合することができます。トリガーは効率的でスケーラブルなので、変更をポーリングするように構築されたモデルよりもより広範囲に適用可能です。継続的インテグレーションや継続的デリバリをベースとした開発方法論に向かって進むために、これらのトリガーが有用であることがお分かり頂けると思います。   通知に関するすべて CodeCommit のリポジトリごとに10個までのトリガーを作成することができます。トリガーはコードのプッシュ、ブランチ/タグの作成、ブランチ/タグの削除を含むリポジトリのアクションに対する応答として起動されます。トリガーはリポジトリの特定のブランチやすべてのブランチに対してセットできます。 トリガーによって Amazon Simple Notification Service (SNS) トピックの送信や AWS Lambda ファンクションの起動が可能です。また個々のトリガーはカスタム データで拡張することが可能で、そのデータによって特定のトリガーを同じイベントで実行される他のトリガーと区別することができます。リポジトリ イベントを email や SNS によって購買するためにトリガーを利用することができます。SNS から SQS へ書き込み、キューを通じて CI/CD のツールにジョブを上げたり、お使いのツールが提供する webhook に対して SNS を使ってアクティベートしたりできます。どのようなケースでも、CodeCommit リポジトリの変更によって指定したアクションがトリガーされます。また Lambda ファンクションを利用してビルド、シンタックスのチェック、コードの複雑度メトリックスの捕捉、開発者の生産性の測定（もちろん少ないほうがいいですね）などをトリガーできます。私の同僚もこの記事の最後にあるような、いくつかの珍しいアイデアを思いつきました！ トリガーは AWS マネジメント コンソール、AWS コマンドライン インターフェース（CLI）、または CodeCommit API を通じて作成、表示、管理することができます。ここではコンソールを使います。左側のナビゲージョン列に Triggers の項目が追加されています: Create Trigger をクリックして開始します。単一のイベント（または複数のイベント）を選択し、単一のブランチ（または複数のブランチ）を選択し、通知の発行や Lambda ファンクションの起動に必要な詳細を入力します: 対象となるイベントとブランチを選択しました: […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 2 月 22 日 Amazon RDS Update と MySQL 5.7 のサポートを発表しました。 AWS Mobile SDK for Android での AWS IoT のサポートを発表しました。 テルアビブでの AWS Pop-Up Loft について発表しました。 CloudCheckr が 5 つの一般的な AWS コスト問題について調査すべき項目と迅速に解決する方法を掲載しました。 AWS Data Pipeline でのオンデマンドパイプラン実行を発表しました。 AWS Mobile Development Blog が AWS SDK for .NET の Unity v3 サポートが正式リリースとなったことを発表しました。 N2WS が EBS […]

本日、AWS Config Rules Repositoryをリリースしました。AWS Config Rules Repository はコミュニティベースで、カスタマイズされたAWS Config Ruleを提供します。この新リポジトリを利用することで、AWSリソースのセキュリティに関するベストプラクティスに対し、評価とコンプライアンス評価の自動化が可能になります。 AWS Config Rules は、AWSリソースの定期的なセキュリティとコンプライアンスチェックを自動で行い、セキュリティ設定における手動作業の削減をサポートするサービスです。 AWS Config Rules Repository を使うことで、コンプライアンスチェックの自動化を加速させ、お客様はAWSコミュニティに集約された専門的な知識を簡単に利用できるようになります。それに加え、レポジトリは無料で公開されており、それぞれが独自に管理されています。それぞれのルールのコードが丸ごと共有されているため、そこから学び、コミュニティに貢献することもできます。全般的なセキュリティ専門家からの声とAWSユーザの観点からのセキュリティ専門家からの声を合わせることで、知見を高めることができればと思います。 以前のポストで述べたように、Center for Internet Securityと連携し、AWSアカウントを保護するための業界のベストプラクティスを確立しました。このリポジトリには、これらのベストプラクティスとの整合性を維持するのに役立つルールが幾つかあります。下記は現在、アクセス権を持っているカスタムルールのサンプルです： CloudTrailがすべての地域で有効になっているかの確認 すべてのアカウントで多要素認証（MFA）が有効になっているかの確認 ルートアカウントに対しキーが存在していないかの確認 AWS Identity and Access Management (IAM) にIAM Policyが存在しているかの確認 キーのローテーションが行われているかの確認 皆さんのAWSアカウントにこれらのルールを使用をする際には、GitHubの上のReadmeファイルを参照してください。是非このレポジトリを活用頂き、皆さんのカスタムルールをAWSコミュニテイで共有下さい！ Chad 翻訳は酒徳が担当しました。本文はこちら：http://blogs.aws.amazon.com/security/post/TxES3UX2Z5BQRU/Announcing-the-AWS-Config-Rules-Repository-A-New-Community-Based-Source-of-Custo 

AWS Import/Export Snowball が昨年の AWS re:Invent でローンチされました (詳細については、ブログポスト 「AWS Import/Export Snowball � Transfer 1 Petabyte Per Week Using Amazon-Owned Storage Appliances」を参照)。 ローンチ時には、このアプライアンスベースのモデルを使用して、大量のデータ (通常 10 TB 以上) を AWS に移行することができました。Snowball のこの機能はとてもうまく動作し、すでに多くのお客様が大いに活用しています。 Snowball を使用したエクスポート 現在、データエクスポート操作で同じモデルを利用できます。数 TB または数 PB のデータを AWS で収集、生成、または保存しており、これらの操作をネットワーク接続よりもはるかに高速に処理したい場合、AWS Import/Export Snowball を代わりに使用できるようになりました。 必要な操作は、単に AWS マネジメントコンソールにログインし、エクスポートリクエストを作成して、エクスポートするデータを指定するだけです。単一のリクエストで、1 つ以上の Amazon Simple Storage Service (S3) バケットを対象にすることができます。このサービスは必要なアプライアンスの数を判断し (アプライアンスごとに 50 TB […]

みなさん、こんにちは。Partner SA酒徳です。 本日、AWS Partner Meetingが品川で行われ多くのパートナー様が参加されました。Parnter Meetingは４半期に一度の頻度で開催されていますが、本日は2016年度初回ということで、去年１年間を通じ活躍をされたパートナー様を表彰するAPN Awardの授与式も合わせて行われました。 Partner Meetingの速報として、本日受賞されましたパートナー様とその受賞理由をご紹介させて頂きます。今年は10の賞に対し13社の受賞パートナー様が誕生いたしました。おめでとうございます！ ・APN Partner of the Year 2015 【受賞パートナー様】：アイレット株式会社 様 【受賞理由】数多くのAWS関連ソリューション、10以上の顧客事例のリリースや 積極的なメディア活動を通じ、メディア、エンターテイメント、スタートアップ企業のみならず、大手エンタープライズ企業のUnix Migrationなど更なるAWSビジネスの拡大への貢献が評価され受賞となりました。 【アワード内容】年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様。 ・APN Reference of the Year 2015 【受賞パートナー様】：株式会社野村総合研究所 様 【受賞理由】世界最大級のSAP基幹システムの稼働。2015年早期の事例公開により、その後における多くのSAP案件ならびに大型基幹システム移行において顧客の導入意思決定に大きく寄与したことが評価され受賞となりました。 【アワード内容】お客様公開事例において、AWSが企業のビジネスに大きく貢献する事を示し、市場に大き な影響を与えたAPNパートナー様 APN Cloud Package Business of the Year  2015 【受賞パートナー様】：ウイングアーク１ｓｔ株式会社 様 【受賞理由】SVF Cloudの運用Platformとして、信頼と可用性の向上を目的とし、AWSを全面採用。特に、Amazon Aurora・Kinesisなどの多くのサービスを積極採用頂きました。大規模ユーザ向けには大量の配送伝票を出力する案件提案が評価され受賞となりました。 【アワード内容】AWSの顧客に高い付加価値を提供した。または市場拡大に寄与したPackage on AWS または SaaSを提供したパートナー様。 APN Rookie of the […]