Amazon Web Services ブログ

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。 フェイルオーバの優先順位は 指定した優先度 優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス 優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。 — 星野 (原文はこちら)

週間 AWS – 2016 年 3 月 7 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 7 日 AWS CodeCommit 向けの通知をスタートしました。 新規の AWS アカウントがデフォルトで長い EC2 リソース ID に設定されるようになったことを発表しました。 AWS セキュリティブログに、AWS IAM および AWS CloudFormation を使用して VPC へのアクセス制限を自動化する方法を掲載しました。 Botmetric に、AWS セキュリティの脅威に対する取り組みの現状: アクセスコントロールが掲載されました。 CloudCheckr で、AWS の多様なサービスを有効に活用するための 5 つのヒントが共有されました。 CloudEndure に、2016 年に必読のクラウドコンピューティング書籍トップ 5 が掲載されました。 Cloud Academy から、AWS CloudWatch によるログ管理の一元化シリーズのパート […]

  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は、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。 暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。 […]

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