#1.はじめに
以下の記事によるとサーバーエンジニアに多い転職理由としてオンプレではなく、AWSなどのクラウドスキルを身に着けたいが挙げられていました。
https://engineer-no-susume.com/serverengineer-tensyoku/
ちょうど1年前の自分と一致してたのでAWSを業務利用した経験のないサーバーエンジニア(インフラエンジニア)でこれからAWSエンジニアになりたい、もしくはなろうか迷っている人の背中を押すための記事です。
#2.私の経歴
現職：AWSのクラウドインテグレーターのインフラエンジニア（2018/2～）
※AWSのクラウドインテグレーターってなんだ？って方はクラスメソッドさんとかを思い浮かべてもらえればと思います
前職：自社Webサービス会社のインフラエンジニア兼社内SE(約3年)
ここではESXi上に自前で仮想サーバーを立てて管理してました
※VCenter、ESXiが動いてる物理サーバーだけ事業者が管理してくれてました
前々職：ホスティング会社のサーバーエンジニア(約1年)
ここはデーターセンターの物理サーバーを管理してました
資格：
・LPIC Level 2
・CCNA(失効)
年齢：30代前半
#3.結論
問題なくなれます！！
私が今所属している会社でもAWS未経験の方がたくさん入社してきています。
むしろほとんどAWS未経験の方たちです。
そして転職市場において年齢というのはかなりの武器なので私より若い方ならAWSエンジニアになるだけならハードルはそんなに高くありません。
なのでここからはなってからの苦労を減らすための準備について書いていきます。
#4.準備編
##4-1.自分でアカウントを取得してAWS環境を作ろう
WordPressがおそらく一番簡単ですが、RailsやDjangoなどが動く環境を自分で作ってみましょう！
このときのポイントは多少の出費はケチらず、なるべく実践に近い形で環境を構築することです。
EC2単体であれば無料枠の範囲内で構築可能ですが、実際の案件でそんな構成はほぼないので以下のような構成でやってみることをお勧めします。
WordPress環境を例に説明します。
構成図だけだと不親切なので各コンポーネントについて少し説明を加えます。
・Route53：独自ドメインを取得して、そのゾーンをRoute53で管理
※ドメインの取得はAWSでなくても問題なし
・S3：静的ファイル類の配信
※S3からWordPressの静的ファイル類を配信するためのプラグインがあるのでそれを使用してください
・CloudFront：静的ファイル類をキャッシュする
・ALB：Webインスタンスへの振り分けに使用する
※CLBでも問題ないが、新規の案件の場合はALBがほんとんど
・RDS：RDS(MySQL)のMulti-AZ
・サブネット
Public：インターネットへの接続可、インターネットからの接続可
DMZ：インターネットからの接続不可、インターネットへの接続はNAT Gateway経由で可、踏み台から接続可
Private：インターネットからの接続不可、DMZのインスタンスからのみ接続可
・EC2(踏み台)：E2(Web)へのSSHするための踏み台
・EC2(web)：ApacheでもNginxでもWordpressが動けば良い
あえて詳しく書いていないのは自分で調べて欲しいからなので、質問とかあればコメント下さい。
##4-2. AWS認定ソリューションアーキテクト-アソシエイトの取得を目指して勉強しよう
AWSに関する資格は色々ありますが、インフラエンジニアのとっかかりとして一番いいのはソリューションアーキテクトのアソシエイトで間違いないと思います。
勉強法にかんしてははqiitaに以下のような記事がありますのでそちらを参考にして頂ければ問題ないと思います。
３週間でAWS認定ソリューションアーキテクト-アソシエイト-とったので、勉強法などまとめてみる
ただし、2018年のどっかで試験内容が変わっているのでなるべく最近の記事を参考にすることをお勧めします。
ちなみに合格までは必要ありません。
なぜなら受験料が高いからです。
おそらくAWSエンジニアを求めている会社は受験費用の補助や資格手当を準備しています。
入社後にそれらを利用して取得するのがよいかと思います。
もしかしたら受験費用の補助や資格手当がない会社もあるかもしれませんが、おそらくそういう会社はエンジニアを大事にしない会社である可能性が高いのでやめておきましょう。
##4-3. 英語のドキュメントに慣れよう
これ実はめちゃくちゃ大事です！！
というのもAWSのドキュメントの日本語が非常に読みづらいからです。
また読みづらいだけでなく、英語にするとある情報が日本語にすると見当たらないケースがそこそこあります。
なのでAWSのドキュメントを英語で読めるようにすることは非常に価値があります。
これはどんな種類のエンジニアにもあてはまることなのでやっておいて損はないと思います。
といってもいきなりはきついので私なりの方法を紹介します。
##4-4. 英語のドキュメントの慣れ方
・まず日本語である程度情報をインプットする
ある程度英語が読める方でも未知の情報を英語でそのまま仕入れるのは厳しいのでまず概要を日本語で仕入れます。
それはAWSのドキュメントでもqiitaの記事でもクラスメソッドさんのブログでもなんでも構いません。
※個人的にはクラスメソッドさんのブログをお勧めします
・そのあと英語のドキュメントに当たる
この時のポイントは知らない単語が出てきてもいちいち調べないことです。
英語というだけで日本語を読むときに比べて読む速度が落ちるのに、いちいち調べていたら全然進まなくなってしまうからです。
特に副詞などの日本語でいうところの修飾語は飛ばしてもそこまで問題ありません。
また重要な単語であれば読み進めていくうちに複数回現れますので、推測出来る場合があります。
それでも推測できない場合だけ調べましょう。
・比較的読みやすい英語ドキュメントを見つけて読む練習をする
英語のリーディングスキルを上げるために一般的に多読というものがいいと言われます。
だからといってエンジニアが脳科学などのドキュメントを読む必要はありませんし、読める必要もありません。
先ほども述べましたがそもそも日本語で知らないことをそんなに英語が得意ではない人間が読むのは厳しいです。
なのでエンジニアに関係のある技術ドキュメントでの多読をお勧めします。
色々な英語ドキュメントを読む経験をしていくとおそらく自分にとって読みやすいドキュメントと読みにくいドキュメントが存在することに気づくと思います。
その差は何でしょうか？
私なりの結論は以下の2点です。
①すでに日本語として知っていること
②そのドキュメントがネイティブではない人間を意識しているかどうか
①に関してはまず日本語で自分の知っている範囲を広げる努力が必要です。
②に関してどう見極めるかはちょっと難しいところで、書いてる人がネイティブじゃないとそうなるのかなと勝手に想像していますが。。。
なので私なりに英語ドキュメント慣れに向いてるものを紹介します。
Terraformに限らずHashiCorpさんのドキュメントは読みやすいと思います。
##最後に
途中から英語のリーディングに関する分量が多くなってしまいましたが、AWSエンジニアになる上でAWS以外のインフラエンジニアとしての経験は全く無駄ではありませんし、むしろ必要です。
私の観測範囲ではAWS以外のインフラエンジニアの経験のないAWSエンジニアよりもAWS以外の経験のあるインフラエンジニアのほうがあとあと伸びます。
たとえばRDS(MySQL)でパフォーマンス劣化が起こった場合、オンプレでのMySQLの経験はそのまま生かせます。
この記事がちょうど1年前の自分のようにAWS未経験でAWSエンジニアになることに不安を持っている方の背中を押すのに役立てば何よりです。