AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

カテゴリー: AWS

AWS SAA合格までのサクセスストーリー


iOSエンジニアとしてひーこら言いながらも、現場にも慣れて心に余裕が生まれてきた9月上旬。
7月に新卒研修を終えてPOSチームに配属されてから、HandsPOSの業務をしっちゃかめっちゃかしつつもなんとかこなしていた。
いきなり業務に携わり、大きな不安を抱えながらもそれなりに頑張ってきた。

しかし、配属から2ヶ月経ったその時、それは突然にやってきたのだ。

OJT。

業務をこなしつつ、それに追加して少しずつ課題を解いていく。
基礎的な技術力や知識量の向上が主な目的だ。

そしてトレーナーは言った。
「渡邉さん、来月中にAWSのSAAとってね。」

SAAとは、AWS初心者がまず取得を目指す資格である。

「大したことない課題じゃん」そう思われる方もいるだろう。
確かに、この資格は難しすぎるわけではなく、ほどほどの難易度だ(と個人的には思っている)。

しかし、わたしは目の前が暗くなっていくのを感じた。
これから始まる勉強は、恐ろしく辛く苦しいものになると、わかったからである。

ここで、私渡邉の略歴を書いておく。
普通科の高校を卒業後、情報系の専門学校でiOSとAndroidでのモバイルアプリ開発を専門に2年間学んだ。
2017年4月にハンズラボに入社。現在社内最年少の21歳である。

専門学校で習ったとはいえ、クライアント側以外の知識は皆無である。
具体的に言うなら、HTTPってなんかの規格でしょ?ポートってなんか穴空いてるんでしょ?くらいのものだ。

正直に言おう。わたしはサーバーサイドやインフラを食わず嫌いしていた。
学生時代も学ぶ機会はあったが、なんとなく避けてきていた。
ついに逃げられなくなった。だから絶望したのである。

しかし、ここで逃げては問題を先延ばしにするだけだとわかっていた。進展はない。
絶望すると同時に、絶対に成し遂げてみせる、そう思っていたのもまた事実なのである。

こうして、私とSAAの戦いは幕を開けた。

chapter1. vs 参考書1周目

AWS SAAの参考書といえば、これが有名だろう。

例にもれず、私もこれをまずは購入した。
持ち運びしやすいサイズ、適度に薄く書き込みしやすい紙、軽さ、全てにおいて最高の参考書だ。

意を決して開いてみる。
リージョンとAZの概念はすんなり理解できた。IAMというものがあるのか。ふーん。
IDフェデレーション。フェデレーションってなんだ。
ほう、そんな認証方法があるのか。ふーん。

1周目なんて、わからない言葉を都度調べて書き込んで、
書かれている日本語を私が理解できる言語に噛み砕くだけだ。作業ゲー以外のなにものでもない。
眠くなる。寝たい。やめたい。しかし、やらなければならない。
今辛いのは、今まで奴らから逃げてきたツケだ。

自分に鞭を打ちつつ、まずは1周、読破した。

chapter2. vs 模擬試験

ところで、私のOJTトレーナーはAWS Solutions Architect Professionalを取得している。
10日でAWSのアソシエイト資格3つ制覇した話」の人見だ。

今読んでも10日間で全部取ったのは尊敬する。尊敬しすぎてちょっと引く。

それはさておき、その人見が「模擬は早めに受けろ」と繰り返し言ってきた。
なぜかと聞くと、「その方がいいから」というなんとも微妙な答え。
しかしプロを取得した人見がいうのだから間違いはないだろう、と、参考書を1周終えてすぐに模擬試験を受けた。

この問題は本で読んだからわかる。これは書いてあった気がするが自信がない。なんだこれは。初めて見る言葉だ。
結果は、50%。不合格ラインだった。当たり前だ。

しかし、早めに受けたこの模擬試験には2つの大きな利点があった。
一つは、実際の試験の形式がわかったこと。もう一つはどこまで理解を深めれば合格できそうかのイメージがつかめたことだ。
早めに目標ラインが定まったのは、その後の勉強の効率を高めることにつながった。

chapter3. vs 参考書2周目

模擬試験を終え、参考書に戻った。
参考書に書いてあるどの部分を頭に叩き込めばいいのかがわかった今、
インフラやサーバーを食わず嫌いしていた私はいなくなっていた。

インフラやサーバーに興味がでたわけではない。
好きになったわけでもない。
AWS SAAという壁を打ち破りたい。ただの意地だった。

この部分は本番で出題されそうだ。
これに関してはすっかり抜けているな。しっかり抑えよう。
参考書の文だとわかりにくいから、自分がわかりやすい文章に変えてしまおう。

参考書の余白への書き込みはどんどん増えていった。
汚れていく参考書。消えていく余白。蛍光ペンのインクがなくなる。
買いに行く時間が惜しい。ボールペンで勉強を続行する。
結局、最後まで蛍光ペンを買い足すことはなかった。

参考書には各章の最後に確認問題があるのだが、
その解答を覚えてしまうほどやりこんだ時、一抹の不安がよぎった。
試験3日前のことである。

chapter4. vs WEB問題集で学習しよう

試験3日前。参考書はほぼ暗記してしまっていた。参考書の問題集の正答率は100%だった。
これなら合格できそうだ、と一息ついたときに、一つの記憶が蘇った。

模擬試験に、参考書ではみたことがなかった言葉が使われていたのを思い出したのである。

つまり、参考書で出題範囲を全てカバーしているわけではないということだ。
当たり前の話なのだが、AWS SAAを倒すと息巻いている私にとって、
この「カバーしきれない範囲」は恐怖対象へと変わったのだ。

手元にある問題は暗記してしまっている。勉強にはならない。
どこかに初めて見る問題はないのか。本に載っていないような問題はないのか。

そこでたどりついたのがこのサイトだった。

フリープランに登録して、まずは解いてみる。
ボロボロだ。今までなんども解いたから問題と答えを暗記していただけであって、
根本の理解をしているわけではない。

まずい。

試験前は3連休だったのだが、ある意味本気の勉強はここからはじまった、とも言えるのかもしれない。

chapter5. vs 参考書3周目

2周目の参考書は、確認問題を重視していた。
一発で正解すれば理解している、という指標としてわかりやすいからだ。
確かに、それはわかりやすい。しかし、なんども繰り返し解くのには向かない。

そこで私は、今一度各章の解説部分を読み直すという行動に出た。
想像以上に時間がかかる。しかし、根本を理解するにはもうこれしかないのである。

読み終えたあと、確認問題(今更だが選択形式だ)の正答と誤答それぞれの理由をつぶやきながら確認問題を解いた。
ここまでやっても詰まる問題はある。
正答がわかっても、理由が説明できないのなら、そこからの応用はない。

解説に詰まったら、戻る。これを繰り返す。作業ゲー以外のなにものでもない。
しかし、辞めたいとは思わなかった。意地が勝った瞬間である。意地の塊と化していた。
元来、わたしは両親がお手上げするほど意地っ張りなのだ。

chapter6. vs BlackBelt

AWS試験の教材として、BlackBeltを参考にしている人は多いのではないだろうか。
実際に使われている様子や、細かい仕様などの解説が動画で見られるのは大変ありがたい。

しかし、私はBlackBeltはほぼ視聴しなかった。
具体的には、最後の最後まで不安だったAuto Scailingのオンデマンドセミナーのみを視聴した。

理由はとてもシンプルだ。時間的制約。

勉強期間は1ヶ月。その間SAAの勉強のみをしていたわけではなく、
仕事や家事、やることは盛りだくさんだ。参考書を開く時間すらない日も少なくなかった。

BlackBeltはわかりやすいが、どうしても時間が取られる。
対時間コストというのだろうか。時間的コスパが低い。
そう判断し、参考書や模擬の復習を優先した。

chapter7. 試験本番

会場は池袋。目の前のカフェに10:00に入店。試験は13:00からだ。
時間が近づくにつれ、緊張感が高まっていく。

高校受験の時、緊張しなかったことを思い出した。
あの時は「これ以上やれることはない、これで落ちたら仕方がない」と思っていたからだろう。
後悔というのは、やり残したことへの執着だ。
やり残したことがなければ後悔もない。

しかし、緊張していた。
当日のわたしは、自分の勉強方法を悔いていた。
なぜ参考書にこだわり続けたのか。なぜ、もっと他の問題をこなさなかったのか。
今考えても仕方がない。しかし、過去の自分を悔いていた。

やれるだけのことをやろうと心を決めて、試験会場に入った。
その頃には、穏やかな心境になっていた。

勉強方法への後悔はあるが、受験とは違って再度受け直すこともできる。
受かったら万々歳。落ちても勉強方法への反省点という収穫がある。
なにも怖いことはないと、それまでの1ヶ月をぶつけてきた。

合格

結果は、合格だった。
カメラで監視されていることも忘れて、渾身のガッツポーズをした。

頰がゆるみ、凝り固まっていた肩がフッと軽くなる。
飛んでいきそうな足を抑えて会場を後にする。
いつもは人の多さにげんなりする池袋の街が輝いて見える。

会社に戻る電車の中で、結果通知のメールをなんども読み返す。
思いついて、頰をつねってみる。痛い。夢じゃない。
ここまで嬉しかったことはいつ以来だろう。

資格は、成功したときの形がわかりやすい。合否があるからだ。
白か黒か、0か1か、はっきりと結果がでてしまう。諸刃の剣にもなるのだ。

だからこそ面白い。そう思えた。
努力が実るのは気持ちがいい。
実るかわからない努力がつらいなら、何が何でも実らせてやるという意地と根性を持てばいいのかもしれない。

勉強方法に後悔がある状態での合格は、ラッキーだったと思っている。
次の試験勉強は、後悔がない状態まで持っていくのが課題だ。

(サクセスストーリー風にお届けしました。いつもはもっと適当に生きています。)


Cognitoユーザープールから発行されたアクセストークンの署名チェック


こんにちは。百木田です。

アプリケーションの認証にCognito User poolsを使用する場合、API Gatewayを使用していればCognito User pools Authorizer機能を使って、Cognito認証済みユーザーからのリクエスト以外は拒否するといった制御できるのですが、自前サーバーでアクセストークンを使ったアクセスコントロールをしたい場合、トークンの有効性や改ざんされていないかなどの検証機能を用意する必要が出てくるかと思います。

今回は、署名チェックするための公開鍵作成(Node.js)から署名チェック(Go)までの手順をまとめましたので共有させていただきます。

環境

流れ

  • アクセストークンから公開鍵を作成
  • 作成した公開鍵を使って署名チェック

やっていきます。

トークンから公開鍵を作成(node.js)

JSON Web Token (JWT) Setをダウンロードする

(公式)ID トークンとアクセストークンの署名を確認する

<リージョン名>、<CognitoユーザープールID>を環境に合わせて入れます。
ここでダウンロードした情報をもとに公開鍵を作っていきます。

モジュールをインストール

公開鍵作成に必要なモジュールをインストールします。

公開鍵作成スクリプトを作成

スクリプトはこちらの記事を参考にさせていただきました。
Node.jsでAWS Cognito User Pools のアクセストークンを検証する

3行目のaccessTokenは公開鍵を作成したいユーザープールから発行されたものにします。

実行して出力された公開鍵をファイルに保存します。

作成された公開鍵はこんな感じになっているかと思います。

これがユーザープールの公開鍵として利用できます。

公開鍵を使ってトークンを検証する

今度は作成した公開鍵をもとに、サーバーに送られてきたアクセストークンが正当なものかをチェックします。

コードはこちらの記事を参考にさせていただきました。
【Go言語】GoでJWT(JSON Web Token)を使うサンプル

tokenStringに検証するトークンを入れます。

実行する。

有効なトークンであれば上記のような出力になるかと思います。

トークンの無効性を確認してみる

こちらのサイトでトークンのエンコード・デコードができるので、試しに内容を書き換えた(改ざんした)トークンを検証してみます。

RSA公開鍵暗号アルゴリズムを選択します。

左側にアクセストークンをいれると、右側にデコードされたトークンの中身が表示されます。

右側のトークンの内容を書き換えると左側にエンコードされたものが表示されます。
それを先ほどの署名チェック(validationCheck.go)のtokenStringに入れて再度実行するとInvalid tokenと出力されるかと思います。

有効期限が切れたトークンでも同様に無効の結果となります。

まとめ

ちょっとつらかったですができました。これをいい感じでアプリに埋め込むといいのではないでしょうか。


東急ハンズでAmazon Chimeを導入した時に調べたこと


こんにちは。百木田です。

今年の2月にリリースされたAmazon Chimeをこの度、東急ハンズの会議に使ってみることになりました。

以下がChimeを採用したいくつかの理由です。

  • シンプルな操作
  • 最大100人がビデオミーティングに参加可能
  • 主催側から参加者をミュート可能

Chimeを本格的に利用することになり、いろいろ調べたのですがまだまだナレッジが少なく試行錯誤したので、わかったことを残しておこうと思います。

Chimeアカウントとユーザー

Chimeにはアカウントユーザーという単位が出てきます。イメージ的にはアカウントは会社やチームなどのグループで、ユーザーは個人に紐づくものです。

ChimeユーザーはAmazon.co.jpのアカウントと紐付いていて、AWSアカウントを持っていなくても使用できますが、AWSコンソールからChimeアカウントとChimeユーザーを紐付けることでユーザー管理をすることができるようになるなど便利に利用できます。

以下がChimeアカウントの種類です。

少し補足するとこんな感じ。

Amazonアカウント

・ AWSアカウントで管理されていない単独のアカウント(ユーザー)。

チームアカウント

・ AWSのChimeで作成したアカウントにユーザーを招待できる。

エンタープライズアカウント

・ 自社のドメインをAWSアカウントのChimeへ登録する必要あり。
・ そのドメインのメールアドレスでChimeにログインすると自動的にアカウントにユーザーが追加される。

ちょっとややこしいです。整理するために図にしてみました。

グループミーティングをホストするにはPro Editionを付与したChimeユーザーが必要です。主催者によってミーティングがホストされると、Chimeユーザーを作成していない人でもミーティングIDを教えてもらうことでミーティングに参加することができます。

ポートと通信帯域の要件

通常のビデオミーティングをする場合は以下のそれぞれのIPアドレス:ポートに対するアウトバウンド通信を許可してあげる必要があります。

IP Address

  • 52.54.62.192/26
  • 52.54.63.0/25
  • 52.54.63.128/26
  • 52.55.63.128/25

Ports

  • TCP/443
  • UDP/16384:17383
  • UDP/3478

ポートの要件はこちらに記載されています。
hosts-ports-and-protocols-needed-for-amazon-chime

各機能を利用する上で必要な通信帯域はこちらに記載されています。
what-are-the-bandwidth-requirements-for-amazon-chi

料金体系

各ユーザーエディションごとの料金は公式サイトに記載されているとおりです。

ユーザーはAWSコンソール上からエディションをGrantさせたりRevokeさせたりできるのですが、課金されるのはProエディションをGrantさせてた期間の日割り計算になります。
なので1ユーザーを1ヶ月のうち合計20日間ProエディションをGrantさせていた場合、

という計算になります。
なお、課金は1ユーザーごとになるため、2ユーザー以上利用した場合はユーザー数分の課金が発生します。

AD連携

AWSのAD Connectorを利用することでChimeのAD連携をすることができます。しかしながらAD連携するにはAD Connectorがバージニアリージョンにある必要があります。

まとめ

以上となります。Chimeの使用感や問題点、会議する上で工夫したこと、考慮した方がいいことなどあるのですが、そちらは別の機会に書ければと思っています。
Chime自体、登場したばっかりでまだまだ改善の余地がありますがフィードバックをしつつ、アップデートに期待したいと思います。
ありがとうございました。


IAMポリシーで自分の所有リソース以外の操作を制限する


こんにちは。百木田です。

先日、こんなことがありましたね。
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。

人間が関わっている以上、人的ミスはどうしても避けられないので工夫してミスを減らしましょうという教訓ですね。

今回のブログでは新しい技術は使ってないですが、そんなニュースもあったので人的なミス防止に関連する共有です

AWSを導入している企業であればAWSの機能や技術を検証するために、
サービス提供しているアカウントから分離された検証用アカウントを利用している場合も多いかと思います。
本番環境ではユーザーに適切な権限を付与し、事故を防止していることと思いますが、検証環境では事故の影響が小さかったり、検証するために必要な権限が多い or 不明確であったりということもあり、それぞれのIAMユーザにAdministrator権限に近い権限を付与しているといったこともあるかと思います。

自分が操作しているリソースのすぐとなりに他の人が検証で使用しているリソースがある場合、そういった権限を持っていれば少しコンソール操作をしくじっただけでリソースが消え、両者、冷や汗状態です。

基本的に私はしくじる側の人間だと思っているので、そんな環境でコンソール操作するのはめちゃくちゃイヤなわけで、寝ぼけながら操作しても自分以外の管理するリソースを操作すること無いようにしたかったわけです。
(入社した月にそんなことやらかした時にはもうあれですね。)

今回はEC2インスタンスの[開始/停止/再起動/削除]操作を制限するポリシーを設定します。

設定方法

  1. 操作制限を書いたIAMポリシーを作成
  2. 自分の使用しているIAMユーザーに対して作成したIAMポリシーを付与
  3. 自分が管理しているEC2インスタンスにタグ付け
      Ownerというタグネームに対して自分のIAMユーザー名を設定
      

作成したIAMポリシーは以下です。

「操作するEC2インスタンスのOwnerタグと、現在使用しているIAMユーザー名が異なる場合はActionの操作を拒否」という内容です。
また、どのユーザーでも同じポリシーが使用できるようにユーザー名の部分は変数を指定しています。

試してみる

Ownerタグに自分のIAMユーザー名が設定されているインスタンスは操作できます。

そうでないリソースは操作時にエラーが出るようになりました。

CLIで試しても同様にエラーとなります。

まとめ

権限を少し工夫するだけで安心して作業できるようになりました。
現在お使いのIAMユーザーにIAM操作権限が付与されていれば今からでも手軽に設定できると思いますので実施してみてください。


Serverless Frameworkでバイナリデータを処理するアーキテクチャを構築したかった


こんにちは。AWSチーム百木田です。

サーバーレス、してますか?

この度、「クライアントから画像を受け取ったらLambdaでその画像の処理をする」ということがしたく、受け取る部分を昨年11月に発表されてできるようになったAPI Gatewayでのバイナリデータサポートを利用してやってみました。
そして何かツールを使って楽にデプロイしたいと思い、今回はServerless Frameworkを利用してやってみることにしました。

環境

  • OS(VM): CentOS Linux release 7.2.1511 (Core)
  • Node Version: 7.5.0
  • Serverless Version: 1.8.0

準備

Serverlessの定義ファイル作成

Serverlessのセットアップについては省略させていただきます。’serverless’コマンドが実行できる前提です。

‘serverless.yml’を作成します。

定義している内容は以下です。

  • LambdaからS3にデータを置くためのIAMロールを定義
  • POSTで受けてLambda処理を行うAPI Gatewayを定義
  • 画像を保存するS3 Bucketを定義

注)S3バケット名の部分は変更してください。

タイトルで「してみた」にできなかったのには理由があり、残念なことに肝心のバイナリデータサポートの設定は現時点でServerlessでは対応していませんでした。そのためプラグインを使用するか他の方法で設定する必要があります。今回は泥臭くデプロイ後にマネジメントコンソールで設定することにします。

Lambda実行コードを作成

Lambdaでの処理は受け取った画像データをS3にアップロードするという簡単なものにしました。

ここではデータを’/tmp’に一度保存していますがもちろん受け取ってそのままS3にあげちゃってもOKです。

デプロイ

バイナリデータサポートを設定

‘serverless deploy’するとS3バケットやAPI Gateway、Lambdaといったリソースが作成されているかと思います。その後、API Gatewayのマネジメントコンソールからバイナリサポートのバイナリメディアタイプに’image/jpg’などPOSTで受ける’Content-Type’に合わせた値を設定します。

バイナリサポート設定後のAPIをデプロイするために再度’serverless deploy’をします。再度デプロイしても手動で設定したバイナリサポートの設定は消えません。

これで設定は完了です。

実際に試してみる

お手軽に試すにはローカル端末から以下のコマンドを実行します。

‘Upload Sccessful’が表示され、S3の指定バケットにファイルが保存されています。

まとめ

今回はServerless Frameworkを利用しましたが他にもSAMApexLamveryなどツールが出ているので今後試していきたいと思います。Serverless Frameworkも順次アップデートされているので今後楽しみです。

ありがとうございました。