先月、耳鳴りと難聴のため残念ながらAWS Summit 2017に行けなかったので、そのかわりに（というわけでもないですが）参加してきました。
※耳鳴りは良くなりましたが、右耳の聞こえづらさは治りません…あきらめました。
本家サイトのほうに登壇者ご自身のブログ記事とスライドが掲載されているので（私がこれを書いている時点で、一部のセッションについては記事が無かったりスライド自体もSlideShareやSpeaker Deckなどに上がっていなかったりしますが）、とりあえず参加したセッションなどの感想や気になったポイントだけ書きます。
会場に入ったとき
お馴染みの「クラメソおみくじ」を引いたのですが、カプセルを開けるのにてこずって、中身（ボトルホルダー）を取り出すときに肝心のおみくじが行方不明に…。
結局、運勢や開運○○が何だったのか、分からず。
【K-1】 History of AWS, Still Halfway through（佐々木大輔さん）
AWS以前の、初期のAmazonの画面を見て、「ああ、あの頃のWebサイトってこんな感じだったなあ」と懐かしくなりました（当時、「ブロードバンド」（もう死語か？）なんてものは日本にもアメリカにもほぼ存在しなかった…）。
また、現在、日本では大規模サイトを含めてAWS移行が盛んですが、首都圏と関西圏以外でも、私の地元の（世界的な）大企業が移行を始めたので、そろそろ地方でも本格的な移行が進むでしょうね。
因みに、私は会社のある層の人たちに「4年に1度だけ本気で働く男」という間違った認識を持たれているらしいです（これまで機器のリプレースを安全を見て寿命が来る前にきちんと実施するポリシーで進めてきたため）が、実際、レイヤ1（機器は製造しないので正確には1.5ぐらい？）からレイヤ7までの色々な「移行」に関わってきています（ITの引っ越し屋？）。
ところで、最近、サーバーワークスのロゴが変わったので、クラスメソッドも変えるかも…と勝手に推測していたのですが、今月から本当に変わってました。
ただ、めそ子さんは2代目にチェンジしましたが、サーバーワークスの高木さんはそのままですね。
【L-1】 ランチセッション
クラスメソッドはこれから「音声」に本腰を入れるらしい、です。
プレスリリースは読んでいましたが、実際に社長の言葉を直に聞くと、意図が良く伝わってきます。
「幼い子からお年寄りまで（幅広い世代に）親和性が高いのは音声」とのことですが、それであればぜひ、聴覚に障害がある人や声帯を失った人が困らないような「明瞭ではない声でも認識できる音声認識技術」も目指して取り組んでもらえるとありがたいです（技術自体はAWSなどが開発したものを使うスタンスだと思いますが）。
【A-1】 クラメソの請求を支える技術（サーバーレス編）〜40歳中年エンジニアの生存戦略〜（植木和樹さん）
同世代としては「40歳中年エンジニアの」というワードに反応せざるをえませんでした（正確には、こちらは四捨五入すると次のステージになってしまいますが）。
クラウドを活用すると「開発が『糊付け』部分だけになる」というのはわかりやすい例えですが、周囲の同世代以上の人たちにはなかなか理解してもらえません…。
「業務フローをパッケージに合わせる」って大事です。「開発上の制約」でパッケージの機能が使いづらい場合は別として、パッケージ化されて販売されるということは、ある程度「標準」を意識しているわけで。
特に「自社の強みの源泉」でないものであれば、従来の業務フローを維持することはかえって害悪になりかねず、いたずらに「業務に合わせてカスタマイズする」ことにこだわるよりも、パッケージに合わせたほうが幸せになれることのほうが多いと思います。
【A-2】 基礎からの OAuth 2.0 〜 認証と認可の概念、認可コードとアクセストークンの意味 〜（都元ダイスケ）
「皆さん、本当に聞きたかったのはOAuthではなくてOpen ID Connectの話ですよね？」というのが、なかなか核心をついていて面白かったです。
多分、4種類の中では、一番安直な実装を採用しているケースが多いのではないか？と思います。
実際、「認可」向けの機能を（結果的に）「認証」向けの処理に「代用」してしまうような「まずい実装」をしているサービスが世の中に存在しているような気がするようなしないような…。
【E-3】 AWS Security Best Practices Whitepaperをガッツリ読み解く会（森永大志さん）
「上級者向け」タグが付いていることにビビりながら参加申し込みしたので、恐る恐るの参加、です。
結果、内容は大体理解できましたが、まだ本格導入ではなくシステム移行を進めている最中なので、そもそも複数アカウントを使うかどうかを考えるケースがもう少し先の話だったり等、「経験から考える」ことができない議題がいくつかありました。
「サービスを提供する立場なら、顧客との間で責任共有モデルを作って契約に含めておいたほうが良いよ」という話は、契約の文言（大抵、サービス提供側が「無保証」という文言を入れているはず）を考えると「面倒なだけで無意味」と思いがちですが、実際に契約条項が全て有効なものと認められるとは限らないので（不公平な条項は無効扱いになることもある）、参考になる話です。
認証情報の扱い等、「テストだから」ということでつい雑な方法でやってしまいがちですが、「テストで使う」ときこそしっかり管理しないと漏洩⇒悪用リスクが大きそうだな、と反省すべき点にいくつか気づくことができたのが大きな収穫でした。
Qiitaの記事などにも安易にアクセスキー／シークレットキー形式でコードを書いて上げてしまっていたりするので、もう少し配慮が必要ですね…。
自社のサービスのユーザがS3等にウイルス付きのファイルをアップロードしてしまい、AWSから届いたメールを放置してアカウントがロックされてサービスが停止してしまう「事故」は起こりそうですね…。
ところで、ルート認証情報を使わないとできないことの1つに、「CroudFrontキーペアの作成（と更新）」（署名付きURL／Cookie生成用）がありますが、これ、AWSが「90日以内での更新」を推奨しているので、結果としてルート認証情報を頻繁に使わないといけなくて困ります。
おそらく、複数のキーペアを同時に使い分けることができるようになって、1組のキーペアの適用範囲を限定できれば、もっと更新頻度を下げてもいいのだと思いますが。
【B-4】 AWSネットワークのL4以下の話（大瀧隆太さん）
しっかり認識していなかったのですが、1AZで6DCというケースもあるんですね（といっても2014年の話なので、今ではもっと増えてるかも？）。
GCPネタもありましたが、きちんと追従・状況把握しておきたいところです。
Multipath TCPは面白そうです…最初はトラブルも多そうですが。
【F-1】 Festivals.IO
今回は懇親会まで参加してきました。
最近、老眼が進んで、薄暗い場所で受け取った名刺の字が読めずに困る、というトラブルが…。
そもそも、名刺を差し出されていることを認識するまで1～2秒掛かったので、画像認識の精度が著しく衰えている模様です（音声認識も）。
規模が違うため、自分の中ではJAWS DAYSほどのインパクトはありませんでしたが、それでも結構有益な話を聞くことができたと思います。
これだけの内容をたったの1,000円で聞くことができるのはすごいことです（私の場合は交通費がその20倍掛かりましたが）。
主催のクラスメソッドさんをはじめ、スポンサーや関係者・スタッフの皆さま、ありがとうございます。
