
つい先日も以下のように発言したのですが、
インスタンスタイプ、日本語名と英語名(タイプID?)とスペックがいまいち頭で一致してない問題勃発… #jawsug
— Kazutaka Goto ☁ 後藤和貴 (@kaz_goto) December 18, 2012
EC2を起動したり見積もりしたりするときに紹介ページやManagement Consoleなどを行き来しているとインスタンス名/日本語名/英語名+cloudpackでのプラン名間の対応が難しくてイライラすることが何度もありました。

つい先日も以下のように発言したのですが、
インスタンスタイプ、日本語名と英語名(タイプID?)とスペックがいまいち頭で一致してない問題勃発… #jawsug
— Kazutaka Goto ☁ 後藤和貴 (@kaz_goto) December 18, 2012
EC2を起動したり見積もりしたりするときに紹介ページやManagement Consoleなどを行き来しているとインスタンス名/日本語名/英語名+cloudpackでのプラン名間の対応が難しくてイライラすることが何度もありました。

先日AWS Command Line Interfaceなるものが発表されました。Python向けコマンドラインインターフェースとのことですが、別にたいした発表でも…と思ったのですが面白そうなので試してみました。
自分の場合はMacにPythonがセットアップ済みなので、あとの導入は簡単です。
$ sudo easy_install pip $ sudo pip install awscli
あとは.bash_profileに設定ファイルパスの環境変数追加。
AWS_CONFIG_FILE=/path/to/awscli.conf export AWS_CONFIG_FILE
加えて設定ファイル設置。
$ cat /path/to/awscli.conf [default] aws_access_key_id=<Access Key Id> aws_secret_access_key=<Secret Access Key> region=ap-northeast-1

17日目担当のゴトウです。当初は勢い余って「こんなCDPはいやだ」というタイトルで参戦しようとしたCDP Advent Calendarですが、みなさんマジメにやられているようなのでひよってしまい、まぁまぁ使える感じや〜つに変更することにしました。
さてAWS環境を有効に活用している多くのシステムでは、インスタンスの自動起動やオートスケールなど、予めサーバー台数や名前が決まってないことが多いです。そんなときでも現状起動中のインスタンス一覧を参照できないといけないケースが多々あります。
たとえばオートスケールする環境でも監視ツールによるモニタリングが必要な場合。または同様にオートスケールする環境でELBではないロードバランサーを利用して負荷分散しているケース。いずれのケースも設定ファイルに現在稼働しているインスタンスのホスト名ないしはIPアドレス一覧を更新する必要があります。
そのための元ネタとしてSimpleDBを使って起動中のインスタンスメタデータを保管する方法を実装したのでPHPのサンプルコードと共にご紹介します。いまいちいい名前が思いつかないのですが、名付けて Self Server Registrationパターン。(気に入ってないので名前は募集します!)

こんにちは。エバンジェリスト職をするものとして外で講演することは多いのになんだかとってもブログが苦手になってしまったゴトウです。
今回cloudpack Advent Calendar 2012に参加することになり、移行して動かなくなっていたMovableTypeをあわてて直してみたりして。ブログを書く感覚が思い出せず戸惑っていますが、良い機会なのでサービス名称「cloudpack」が生まれたときのことを振り返ってみようと思います。
cloudpackビジネスを始めたのは2010年3月。この記事で紹介してます。
アイレットと共同で Amazon EC2 の導入から運用までを引き受ける AWS+ というサービスを開始することになりました
記事中に「cloudpack」は一切ありません。あるのは「AWS+」という名称。
そうです。開始当初はAmazon Web Servicesの略した「AWS」に「+」をつけて、「AWS+」(エーダブリューエス プラス)という名前でスタートしました。ドメインも aws-plus.com を使っていましたね。
AWSを日本市場に広げていこう!という目標もあり、サービス開始当初は勝手にコ・マーケティングのつもりで「AWS」を使って、名称としての親和性をだすつもりで「AWS+」としていました。
当時のプレゼン資料はこんな↓感じw
名前のおかげかw、営業開始後から順調に仕事は伸びていき2010年の年末を迎えるまでには多くのお客様のインフラをお預かりするようになってました。ちょうどそのときにAWSのオフィシャルパートナー制度が開始されることを知りアプライをし、無事Solution Provider認定を受ける運びとなったのでした。
今まで完全にブログやウェブサイトのみのマーケティングスタイルで認知活動をしているだけで、特に自分たちのやっていることに何の後ろ盾もなく第三者から認められることなかったので、AWSによるSolution Provider認定を受けられるのは非常にうれしかったことを覚えてます。
一方で、2011年以降のAWS関連市場の伸びと自分達の成長ステージを考慮して以前から「AWS+」という名称についてどうするか内部ではずっと議論してました。Solution Providerになったのをきっかけに、「オフィシャルなパートナーとして自社とAWSブランドとの混同が起こらないようにすべきだ、ここで名称変更をしよう!」と決断したのでした。
そこからがつらかった…