こんにちは。Kaneyasuです。
今回は私が過去にWEBアプリエンジニアからAWSエンジニアに転身した際に直面した5つの壁について紹介します。
実体験に基づいているため、当てはまらない方はいるかもしれませんが、キャリアの幅を広げたい方の参考になれば幸いです。
本記事の対象者
WEBアプリのビジネスロジックの実装経験はあるが、クラウド・インフラの経験が浅い方を対象としています。
壁の1 ポート番号
WEBアプリケーション開発において、ポート番号を意識することはあまり多くありません。
ローカル開発においては、とりあえず8080番や3000番を使うことが多いのもあります。
下手すると、重複させなければ何番でもよい、という認識の方もいるかもしれません。
本当は、HTTPは80番、HTTPSは443番、SSHは22番、PostgreSQLは5432番など、身近なサービス・ソフトウェアには標準的なポート番号が存在します。
AWSにおいては、セキュリティグループやネットワークACLでポート番号を指定して通信の許可・拒否を設定します。
特にセキュリティグループは、インバウンド・アウトバウンドのルールを設定する際にポート番号を指定するため、最低でも、よく使うサービス・ソフトウェアの標準的なポート番号は覚えておかないと、AWSでシステムを構築してもなぜ通信ができないのか理解できず、壁にぶつかります。
壁の2 CIDR
CIDRは、IPアドレスの範囲を表現するための方法です。
例えば、CIDRで10.193.0.0/16と表現された場合、IPアドレスは最大で65536個指定できます。
そして、これを10.193.10.0/24と10.193.20.0/24のように、分割することもできます。
これを理解していないと仮想ネットワークであるVPCやサブネットの設計ができず、AWSでシステムを構築する際に壁にぶつかります。
/16や/24の部分はサブネットマスクと呼ばれるものですが、このサブネットマスクの意味を理解するのが難しいです。
そらで計算できる必要はないと思うのですが、/16・/24・/32などよく出てくるパターンと、サブネットは数が増えた方がIPアドレスの範囲は狭くなる、ということを覚えておくとだいぶ楽になります。
壁の3 セキュリティグループとネットワークACL
セキュリティグループとネットワークACLは、どちらもAWSにおけるネットワークのセキュリティを担う重要な機能です。
が、2種類あるというのがわかりづらいところです。
これらは以下の違いがあることを意識しつつ、基本的にWEBアプリエンジニアが触れるのはセキュリティグループであることを理解しておくとよいと思います。
- ネットワークACLの方が低レイヤー
- ネットワークACLはDenyが可能、セキュリティグループはAllowのみ
- ネットワークACLは送信元をCIDRで指定、セキュリティグループはCIDRに加えてセキュリティグループ自体も指定可能
- セキュリティグループはステートフル、ネットワークACLはステートレス
壁の4 ステートフルとステートレス
ステートフルとステートレスは、セキュリティグループとネットワークACLの違いを理解する上で重要な概念です。
セキュリティグループはステートフルです。
インバウンド（受信）のルールで許可した通信に対しては、アウトバウンド（送信）のルールを設定しなくても、応答の通信が許可されます。
一方、ネットワークACLはステートレスです。
インバウンド（受信）のルールで許可した通信に対しても、別途アウトバウンド（送信）のルールで応答の通信を許可する必要があります。
この違いを理解していないと、セキュリティグループとネットワークACLの設定を誤ってしまい、通信が通らない原因がわからなくなり、壁にぶつかります。
AWS認定でも頻繁に出題される重要な概念です。
壁の5 URLとパスルーティング
URLのパスルーティングはWEBアプリケーション開発において基本的な概念ですが・・・、
チーム開発のメンバーとして開発をしている場合、実際のパスルーティングの設定はリーダークラスのエンジニアが行うことが多いため、やったことがない方も少なくありません。
URLとパスルーティングに対する理解が浅い場合、URLにおけるプロトコル・
ドメイン・パス・パスパラメータ・クエリパラメータの違いがわからなかったり、AWSにおいてはAPI GatewayやALBの設定が理解できなかったりします。
URLの構造に着目して日々の開発を行うことで、壁を乗り越えられます。
一旦、以上です。
今後、AWSを勉強されようと思う方のヒントになれば幸いです。