AWS」カテゴリーアーカイブ

AWS SAAへ挑戦するぞ

AWSの認定資格であるSolutions Architect Associateの試験を申し込んだ。

この認定資格は、たぶん5年位前。前職で取ろうと思って勉強したものの結局試験を受けずに放置。
昨年末、再び取ろうと思い、Udemyのコースを使って勉強を再開。一通りUdemyのコースを受講し終わったもののグダグダとしていた試験です。

ちょっと、いい加減にずるずるとしてしまっているので勉強が十分かどうかはさておき、試験の予約を取ってしまおうと。
勉強期間だけで考えると十分な期間ではあるものの、その間にAWSもどんどん変化していっており、以前は正解だった選択肢が現在においては不正解となるケースもいくつか見受けられます。

世の中にはAWSの全資格を取得するような強者がいるようですが、仕事でAWSだけやっていればいいというわけでもない場合には、その知識を更新し続ける必要があるわけで、なかなかそれは大変だなぁと、資格を一つも持っていないうちから心配しております。

SAA資格は、AWS認定資格の中でも全般的な知識を問われる資格なので、広範囲なサービスに対する知見を求められます。
実際にAWSを業務で使う際に、これらすべてが必要になるケースは稀な気がしているので、これらの知識アップデートは仮に資格を取得できたとしても、大きな課題となりそう。

さらに困ったことに、AWSだけではなくAzureやGCPも業務で使うシーンはあるんですよね。
欲を言えば全部知っているに越したことはないし、何かしら似通っているところはあるので応用も聞くとは思う。

いやはや、みなさん息してますか?って気分になってきますね。

とりあえず、まずはそんな捕らぬ狸の皮算用していないで、しっかりと目の前のSAAを取ってから考えなさいということなので、頑張りますよっと。

AWS Lambda で EC2 をスケジュール起動/停止

Lambda 、使ってますか?

まだLambdaがではじめたばかりの頃の AWS Summit で、その存在を知った時に、
結構面白そうなものが出てきたな〜と思ったものの、
当時の自分としてはそれほどAWSを使っていたわけでもないのでパッと用途が思いつかなかったんです。

S3に画像をアップロードしたのをトリガーに〜とか、Kinesisのデータを〜とか言われても、
そんなシーンが到底自分に来るなんて思えなかったし、実際のところまだ来ていない。

最近、少し期間が空いてまたAWSを触り始めた時に、EC2の起動/停止面倒だな〜、
そろそろEC2にもそういう機能が備わってないかな〜って調べていたら

http://dev.classmethod.jp/cloud/aws/lambda-scheduled-event-updown/

おおおおお。
素晴らしい。

何が素晴らしいって、ずっと心の中でくすぶっていたLambdaを触りたい欲求と、EC2のスケジュール対応が一度にできることですね。

Lambdaがスケジュール起動できるようになった話は聞いていたけど、
なんとなく又聞きで知ったような感じだったのもあって、とっさに思いつかなかったなぁ。

素直に嬉しい。
と、同時に、こういう形でLambdaが使えるようになると一気に出来ることが増やせそう。
うーん、やっぱりLambdaは楽しそうだぞ

AWS Summit 2015 TOKYO セッション資料公開

先日少しだけ参加させていただいた AWS Summit TOKYO 2015 のセッション資料が公開されました!

「AWS Summit Tokyo 2015」開催レポート動画・資料一覧http://aws.amazon.com/jp/summit2015-report/details/

当日は、見に行く事のできなかったセッションが多数あったので、ぜひチェックしたいところです。
一部のセッションは資料のみですが、結構多くのセッション動画も公開されています。
時間はかかりますが、目を通していきたいと思います。

Tech Deep Dive by Amazon

特に、AWSに関する事をAWS側で検証した「Tech Deep Dive by Amazon」は一通り目を通したいです。
まずはEBSのパフォーマンスに関してのセッションである「TA-06:Amazon EBS パフォーマンスベンチマーク 2015」を。
なーんとなく知っていた事もありましたが、それぞれの使い方を再確認するとともに、インスタンスストアの使い方とかちょっとはっとさせられる内容でした。
使い方次第では面白い使い方ができそうで、考えてみたい内容です。

 

KEY-03:DevCon Day1 クロージングキーノート2035 年、その時デベロッパーはどう生きるか

セッションの途中で退席してしまった大前さん親子のセッションも動画で拝見しました。

序盤はどういう流れになるのか怪しいな〜と思って別セッションへ移動してしまいましたが、
最後まで見るとなかなかどうして。考えさせられる内容でした。
価値を生み出すというキーワードはこれまでも多くの書籍で語られてきている内容ではありますが、
今一度思い起こす必要があります。

エンタープライズでの活用事例もいくつか見受けられるので、それも見ていきたいところですが。。。
ちょっと全部見るのは大変そうですね。。。

何かオススメがあれば教えてください。。。

AWS Summit Tokyo 2015 へ行ってみたよ(Day1のみ)

AWS Summit Tokyo が6/2-3の日程で品川プリンスにて開催されていました。

AWS Summit Tokyo 2015
AWS Summit Tokyo 2015 クラウドで、未来を「今」に。
http://www.awssummit.tokyo/

仕事の関係で、Day1の午後のみの参加となってしまいましたが感じたこと・考えたことのメモをば。

前提

AWS自体を私が触り始めたのはつい最近で、まだ1年程度。
しかも、触り始めたといってもずーっと何かをしているわけではなく、EC2とRDSを少し触りながら既存システムのAWS環境での動作確認等を行った程度のレベルなのでたかが知れます。

AWS Summit は初参戦で、申し込みが遅れてしまったのでほとんどのセッションが満席><
実際には事前のセッション申し込みはチェックされなかったので意味がなかったっぽいけれど・・・。

 [Dev-01]デベロッパー視点で見たAWS

AWSの各種サービスに関してのお話。
CodeZineで連載された、アプリ制作に関する話も交えながら、数あるサービスの中でどういったものを使っているのか?など。
ちなみに連載は見ていなかったけれど、こちらが初回。

【制作1日目】 池澤あやかさん、イベント会場がヒートアップ間違いなしのアプリを制作、まずはクライアント側処理です ~ Amazon S3 / Cognito / Kinesis / DynamoDB 登場
http://codezine.jp/article/detail/8642

S3の使い方や、Cognito。それにLambdaの話などが目につきました。
また、私の現在の業務からはちょっと考えづらいですが、AWSを前提としたアプリケーションを作る場合に、
ローカルでの開発(オフライン状態)が難しいという話は少し新鮮に感じました。

開発環境をそもそもクラウド等に構築するようなこともあると思う。
今後の開発のあり方というものは少し見守っていく必要がありそうだなぁ。

[Dev-02]デベロッパーが切り拓く、次の時代

タイトルからもわかるように、AWSと結局全然関係ないような内容だった。
パネリストはみんな大好きnaoyaさんと大場さん。

開発者はどういうスタンスで次の時代を乗り切っていくのかという話。
ともすると、どうしても技術オタクになってしまいがちな人が多いけれど、
技術が先にあるのではなく、課題が先にあって、その解決の手段として技術がある。

何かの技術に対して掘り下げていくことは悪いことではないんだけど、それをキャリアとして計画するのはどうなのか。
出来ないことを解決するためにいろいろな試行錯誤があるわけで、その前提条件として何らかの技術をおいてしまうと
出来ることや成長にブレーキがかかってしまう。

この話は、今一度自分自身を思い返したいところだと思いました。
そういう意味でも、最後にnaoyaさんが話をされていましたが、自分のポジションをちゃんと把握することが大事。
そのためには、現在の周りの状況が見えている必要がある。

我々エンジニアは、結局のところ死ぬまで勉強が続くのであるのだ。

[KEY-03]DevCon Day1 クロージングキーノート:2035年、その時デベロッパーはどう生きるか

大前さん親子の会話。
大局観的なとらえ方は面白いと思いつつも、少し気になるシアターセッションもあったので途中退席。
後でセッション資料や感想を確認したいところです。

それにしても、茶の間での会話レベルが高いな~。
わが家でもそういう話をするような時代が来るのかな?
まだまだ小さいわが子を見ていると、少し想像できませんね。

ちなみに、期待していたシアターセッションはあまり面白くありませんでしたので割愛。

[TE-05]ファイヤーサイドチャット~エンタープライズ企業はいかにクラウド化の流れを進めるべきか~

Amazonのえらーい人3人を交えたトーク。
ちなみにファイヤーサイドチャットというのは、暖炉のそばで話すようにフランクな会話ということらしい。
お題としてはエンタープライズ企業におけるクラウド化に関して。

実際のところ、AWSはすごいメジャーになってきていると思っているんだけど、日本の企業のどの程度がそう思っているのだろう。
AWSのようなスモールスタートが出来る環境であれば、大企業じゃなくても活用できるはずなんだろうけれど、
たぶん多くの企業ではそういうところまで目を向けていないんじゃないかな~。

印象に残った言葉としてはこれ

問題はテクノロジー側にあるのではなく、組織の文化だったりする。 口では色々なことをいうことは出来るんだけど、実際に動くことが出来るのか。

はたして、日本の企業はそういう考えを持つことが出来るのか。
個人的には、そういう考えを持てないと今後は生き残れないくらいまで過激なことは言わないけれど、
いいものはどんどんと活用していけばいいと思うんだよね。

ベンダーロックインという考え方は確かにあって、AWSがなくなったらどうするんだ?というのはリスクとしてはわかる。
その時には作り直せばいいんだ!って軽々しく口に出してはいけないことも、まぁわかる。
ただ、その時が来るまでに生き残れるのか?ということを考えるのであればやっぱりスピード感を持ってことにあたらないといけないと思う。

やはり、最後はいつも人の問題になるんだな。

実はこのセッションはこれ以外にもすごい色々なことを考えさせられるセッションでした。
AWSを使うことによるメリットを、どうエンタープライズに伝えていくのか。
実は業務でも少しかかわっている課題でもあるので、より深堀しながら考えて進めていきたいところです。

シアターセッション

展示会場に設置されたシアターセッションも時間のあいまではありますが、少し拝見させていただきました。

各回ともに10分程度の時間なので、それほど多くの情報は得られませんでしたが。
スカイアーチネットワークスさんがchef やserverspec。Zabbix等をまとめたツールに関しての話をしていた。

DevOpsサービス (スカイアーチネットワークス)
http://www.skyarch.net/devops/

chef や serverspec に関しては、知ってはいるものの、Windows主体で私が動いている&それらのツールがWindowsではイマイチ使いづらい印象が結構前にはあって、
本格的に見ていませんでしたが、もうそろそろ見直してみようかな~と。

まとめ

見てわかる通り、申し込みが遅れたこともあって「AWSを使いこんだぜ!」っていうセッションにいけませんでした。
どちらかというと、開発者や企業が今後どういう形で進めるべきか?というような、AWSべったりではないセッションが多かったです。

個人的には、それがとても良かったように感じます。
特に、ファイヤーサイドチャットで得たことは、今後大きな糧となってくれると思っています。

セッション資料等に関してはきっとAWS公式がまとめて公開してくれると勝手に思っているので、
AWSを使い倒したぜ!みたいなものに関しても見ていきたいと思っています。

今後が楽しみです!

 

AWS 環境の自動停止スクリプト

AWS を必要な時だけ立ち上げておきたいんだけど、人が操作するとどうしてもうっかり落とし忘れてしまう。
そこで、SDK を使うことである時間が来た際に自動で落とすような状態にしておきたい。

立ち上げるのは、必要に応じて自分で手動で行えばいいので、あくまで落とすことを優先させる。

AWS の SDK はいろいろな言語で出ているが、今回は Ruby を使ってみることにした。
あまりこれまで触れたことのない言語だったので。
理由はそれだけ。面白そうだったからに近い。

EC2 を落とすことは比較的簡単にできる。

予め、定義を作っておいて

[aws-config.yml]
access_key_id: <ACCESS_KEY_ID>
secret_access_key: <SECRET_ACCESS_KEY>
ec2_endpoint: ec2.ap-northeast-1.amazonaws.com

 

止めるための文を書く

[stopall-ec2.rb]
require 'aws-sdk'

AWS.config(YAML.load(File.read("./aws-config.yml")))

ec2 = AWS::EC2.new

ec2.instances.each do |ins|
  ins.stop if ins.status == :running
end

 

EC2 は比較的すんなりと行ったんだけど、RDS はよくわかっていない。

RDS の場合、そもそも停止という機能が存在していないため、本来の停止手順としては

  1.  一世代前の Snapshot の削除
  2. Snapshot の作成
  3. Instance の Delete

で、起動時には

  1. Snapshot からの RDS 作成
  2. セキュリティグループやパラメータグループ付け替え
  3. RDS インスタンスの再起動

という感じになると思う。
Snapshotをいつ削除するのかは好みなのかもしれないが、作成直前まで保持しておけば
バックアップとしても使えるし、もう少し手を加えて世代管理をしてもいいと思う。

EC2 と異なり、RDS は Snapshot からの起動となるので、手操作による名前付けミスは避けたい。
そういう意味では、起動まで自動化したくなるところではあるかな。

ただ、そもそも RDS の一覧が取れないように感じる。

[stopall-rds.rb]
require "aws-sdk"
rds = AWS::RDS.new(
  :access_key_id => <ACCESS_KEY_ID>,
  :secret_access_key => <SECRET_ACCESS_KEY>,
  :rds_endpoint => <RDS_ENDPOINT_URL>
)

rds.db_instances.each {|instance|
  p instance.endpoint_address
}

 

試しに Github 上で見かけたコードを元にこんなのを書いてみたけど、接続の時点で

C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:878:in `initialize': execution expired (Net::OpenTimeout)
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:878:in `open'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:878:in `block in connect'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:877:in `connect'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:862:in `do_start'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:857:in `start'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/http/connection_pool.rb:321:in `start_s
ession'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/http/connection_pool.rb:125:in `session
_for'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/http/net_http_handler.rb:55:in `handle'

from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:253:in `block in make_sync_re
quest'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:289:in `retry_server_errors'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:249:in `make_sync_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:511:in `block (2 levels) in c
lient_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:391:in `log_client_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:477:in `block in client_reque
st'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:373:in `return_or_raise'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:476:in `client_request'
from (eval):3:in `describe_db_instances'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/rds/db_instance_collection.rb:56:in `_each_i
tem'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/collection/with_limit_and_next_token.rb
:54:in `_each_batch'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/collection.rb:80:in `each_batch'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/collection.rb:47:in `each'
from stop-rds.rb:11:in `<main>'

のようにタイムアウトしてしまう。

と、ここで RDS 側の Firewall 関連の設定じゃないかと気づく。
RDS の構築を自分で行った環境ではなかったので気づくのが遅れた。

RDS を構築する際、 “Enable Public Access” って項目があって、通常は同じ VPC 内からのアクセスのみ許すようになっていた。
一時的にこれを変更して試してみたら、エラー内容が変化した

C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:918:in `connect': SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A (OpenSSL::SSL::SSLError)
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:918:in `block in connect'
from C:/Ruby200-x64/lib/ruby/2.0.0/timeout.rb:66:in `timeout'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:918:in `connect'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:862:in `do_start'
from C:/Ruby200-x64/lib/ruby/2.0.0/net/http.rb:857:in `start'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/http/connection_pool.rb:321:in `start_session'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/http/connection_pool.rb:125:in `session_for'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/http/net_http_handler.rb:55:in `handle'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:253:in `block in make_sync_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:289:in `retry_server_errors'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:249:in `make_sync_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:511:in `block (2 levels) in client_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:391:in `log_client_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:477:in `block in client_request'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:373:in `return_or_raise'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/client.rb:476:in `client_request'
from (eval):3:in `describe_db_instances'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/rds/db_instance_collection.rb:56:in `_each_item'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/collection/with_limit_and_next_token.rb:54:in `_each_batch'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/collection.rb:80:in `each_batch'
from C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/aws-sdk-v1-1.52.0/lib/aws/core/collection.rb:47:in `each'
from stop-rds.rb:17:in `<main>'

 

はて・・・。困ったな。

ちなみに、

rds.db_instances["<INSTANCE_ID>"]

という形では AWS:RDS:DBInstance オブジェクトへアクセスできる。ここから delete を呼び出すことは出来そうなので、ID を指定すればできそうだ。

逆に、 EC2 のように each で無条件にインスタンスを落とすことは出来ないのかもしれない。

AWS:RDS 以外に AWS:RDS:Client も RDS の操作する手段としてはあるので、こちらを使えばもしかしたらいけるのかな?
エラーとなっている、 db_instance_collection の each_item 実装を見てみると client.describe_db_instances を呼び出しているみたいなので、
AWS:RDS:Client の使い方を習熟することがエラー解決への近道なのかもしれない。

まぁ、実際の問題としては RDS がそんなに増えることはないだろうから、とりあえずこれでやってみようかな・・・。

なんか、もうちょっとうまいこと行くとうれしいんだが。。。

Softlayerを勉強してきた

以前のエントリで AWS をいじり始めたという話をしましたが、AWS だけでなく、Softlayer の研修も IBM で受けてきました。

会社では Microsoft の Windows Azure も利用している部署もあるのでより取り見取りですね。
私としては、これまでなんとなーく AWS が一番デファクト的な位置づけだと考えていたのですが、
単純にそれはその他を知らないだけという話でもあるかもしれないと考え、少し周りを調べ始めています。

AWS

AWS は言わずと知れたクラウドですね。

EC2 をはじめとして様々なサービスが提供されているので幅広い用途に使うことが出来ます。
個人的にはこのサービスの豊富さとその規模からくる価格メリット。そして成長・進化のスピードが AWS の強みに感じています。

まぁ、ろくに AWS を使っているわけではないので偉そうなことはあまりいうことは出来ませんが。

 

Softlayer

Softlayer は、もともとは独立したクラウドベンダーでしたが、IBM が現在は買収しています。
特徴的なのは、機器構成の自由度がかなりあるところです。

AWS で時々話があがるのは、インスタンスがどこに作られるかわからないので、同居しているインスタンスによってパフォーマンスに当たり外れがあるという話です。

Softlayer では、仮想ホストを共有する通常の形以外に、自分だけでホストを占有するタイプの仮想を選ぶことが出来ます。
(これをPrivateクラウドと呼ぶので混乱させているような気がしないでもない)
さらには、物理サーバーそのものを同じように Softlayer ポータルから借りることもできてしまいます

企業案件等でパフォーマンスがシビアに要求されるケースでは、ハイパーバイザーのオーバーヘッドを嫌がることもあると思います。
そういう意味では、Softlayer は自分たちで構成をゴリゴリと組みたいけどオンプレミスとして保持したくないというようなケースにおいては最適なのかもしれません。

もちろん、その場合のユーザー側の責任範囲は大きくなりますが。

一方で、サービス面に関しては AWS のほうが充実している印象を受けています。

クラウドで DB を利用しようとした場合、AWS であれば RDS を利用することが出来ます。
Softlayer ではバックアップを含めた運用管理は、よりオンプレミスに近い構築能力を要求されるとともに、Oracle 等を利用しようとした場合にはライセンスを用意する必要が出てしまいます。

クラウドの場合、やめようと思った時にやめられるのも利点ですが、こういったライセンスを時間貸しで利用できないのは、それが本来の形とはいえ辛いですね。
まぁ、MySQL や MongoDB 等のオープンソース系で行けばいいだけの話なのかもしれませんが。

AWS にしろ Softlayer にしろ、日々進化しているのである一時を切り出して優劣をつけていくのはなかなか難しい気もします。
ただ、それぞれの提供している特色というか特徴といったものがこの二つは分かれているので、すみわけは出来そう。

一方で、Microsoft の Azure は正直私が不勉強でよくわかっていないところが多いです。
どうなんだろうな

AWS 勉強中

最近、遅まきながら仕事でAWSを触り始めました。

実際に業務で使う範囲というのは、オンプレミスをそのまま AWS に移行するだけであればそれほど考えることはないように感じているのですが、
どうせならば豊富に用意されている AWS のサービスを把握したうえで使うべきところを使うという形にしたい。

これまでなんとなく話には聞いていたけれど、いざ実際に触ってみるとやはりわからないことが多いので、Web 媒体を使いながら勉強をしています。

以下、参考にしている個所をまとめてみました。

  • AWS クラウドサービス活用資料集(http://aws.amazon.com/jp/aws-jp-introduction/
    • AWS のトレーニング資料や活用事例が PDF や Slideshare で提供されています。一通りがそろっているので、あまり把握していないところに関しては見ておきたいところです
  • CLOUD DESIGNE PATTERN (http://aws.clouddesignpattern.org/index.php)
    • サービス構成をデザインパターンとしてまとめたものです。クラウドを利用するときにはどういう構成にすると、どういう問題を解決できるのかが解説されています。あまり運用周りの構成に関してはオンプレミス含めて強いほうではないので、いろいろと勉強になりました

それ以外にも、ブログや Qiita にもいろいろと記事は見つかるので勉強の仕方に関しては参考になります。
こうやって調べられるのは便利ですね。

勉強したら勉強したで、その成果を残したくなったり、指標が欲しくなります。
プログラムに関わるものであれば、それはプロダクトを開発することが本文といえば本文なのかもしれないけれど、
実際のところ AWS の豊富なサービス群を使い切るのは難しい。

というわけで、幅広く確認出来そうな内容としては資格が思いつくわけだ。
AWS は認定プログラムを用意していて、その内容としては

がある。ネットで見ている限り、ソリューションアーキテクトを受験する人が多いように感じた。
AWS 専用にアプリケーションを作成する場合は、デベロッパー資格を取ることを考えるのがいいのかもしれないけれど、
全体構成を考えたりするのにはソリューションアーキテクトがいいのかもしれない。

ちなみに、日本での受験料は15000円。
相変わらずこの手の資格試験はいいお値段がする。

いろいろと探していたら、法人向けではあるが AWS Partner Network というものがあるようで、そこにパートナー向けのトレーニングコンテンツがあるみたい。
というわけで、 register レベルであれば無料なようなのでさくっと登録してみた。

APN ポータルにログインして、 training をクリック。トレーニング用のポータルへ移動する。

APN で用意されている認定としては、

  • ビジネスプロフェッショナル
  • テクニカルプロフェッショナル

の二つ。

それぞれ、動画による e-learning 形式の教材と試験が用意されている。
スライドと音声による解説が主で、スライドは日本語の教材を選べば日本語で書かれているが、音声に関しては英語だった。
ただ、字幕を付けることが出来るのであまりこのあたりは気にしなくてもいい。
そして幅広く学ぶことが出来る。何よりも無料であることが大きい。

というわけで、APN にアクセスできる状態であるならばこちらの教材を利用して幅広く学び、
個別の詳細を活用事例集や各サービスに用意されているドキュメントを追いかける形の勉強方法がいいように感じた。

その先に、認定試験の受験と合格があるかもしれないが、これで満足してしまうかもしれない。
とりあえず、APN の認定試験を二つとも取得してから考えることにしようかな。