楽しく勉強したい垣見です。
昔SAAの勉強に使った教科書から、覚えにくいAWSの概念に対する語呂合わせや落書きをたくさん発掘しました。
強制的に頭に入ると（私の中で）評判なので、いくつかご紹介します。
- はじめに
- Well-Architected フレームワーク6本の柱 →「運信持セパコ」
- ElastiCache の Memcached と Redis →「猫戦士と不死の精霊使い」
- Kinesis の Data Streams と Firehose →「川と消防ホース」
- Security Group と Network ACL →「秘書と、自分を自分を入国審査人だと思い込んでいる会社の受付」
- Gateway EndpointとInterface Endpoint →「門と携帯電話」
- おまけ：Transit Gateway →「トラ柄のハブ（蛇）」
- 後書きとさらなるおまけのAthena
はじめに
皆さん、AWSの資格勉強はしていますか？そして、教科書に落書きをしていますか？私は両方しています。（先日SAPro受かりました！わーい！）
1年ほど前、AWS認定ソリューションアーキテクト – アソシエイト（SAA）を受験しました。
最近そのときに使っていた教科書を見返していたら、試験に備えて自分で作った語呂合わせ（ダジャレ）やそれにちなんだ落書きがたくさん出てきました。
右：機密を教えてくれるMacieちゃん
現在も思い出すのに使っていたりする優秀語呂合わせなので、せっかくなので再編してブログにまとめてみることにしました。対象資格はCloud Practitioner・Solutions Architect – Associateあたりですが、今見ても面白かったので誰でも見てください。
全く知らない単語はそもそも覚えるのが大変なので、まずこのブログでざっとイメージをつかんでから、教科書や問題で周辺知識を抑えていく…というような使い方の想定です！
AWSのサービスを覚えるのに苦労している方に、少しでも役立てばと思います。
※あくまで最初の一歩として、他の情報を頭に入れやすくするフレームワークとしてのブログです。業務で使うときはちゃんと触ったり、理屈を理解したりしましょう。ぜひサーバーワークスのエンジニアブログをご活用ください！
Well-Architected フレームワーク6本の柱 →「運信持セパコ」
一番のお気に入りから紹介しますね。
AWS Well-Architectedフレームワークには、システム設計のベストプラクティスとして6本の柱があります。
これは業務の中でもたくさん出てくるのに覚えにくい！！
なので、私は「運信持セパコ」という架空のお嬢様として覚えています。
- 運: 運用の優秀性 (Operational Excellence)
- 信: 信頼性 (Reliability)
- 持: 持続可能性 (Sustainability)
- セ: セキュリティ (Security)
- パ: パフォーマンス効率 (Performance Efficiency)
- コ: コスト最適化 (Cost Optimization)
運信持セパコ様は優雅で高貴でWell-Architectedなので、従うことであなたのアーキテクチャも強固なものになるでしょう。
運信持家はノブレスオブリージュ（高貴たるものの義務）としてWell Architected Toolなど便利な道具をたくさん提供してくれます。
運信持ってかっこいい苗字ですね。どんな家なんでしょう……なんだか運送業で成功していそうですね。Amazonだし。
このシリーズはこんな感じで緩く進んでいきます。
「この記事だけで全て勉強する」というよりは、例えば今後WAフレームワークに関する概念が出た時に、「お、セパコ様がまた何か役に立つ診断ツールをくれたぞ」「セパコ様のベスプラ関連ね〜」と知識を紐付けやすくするためのブログなので、妄想想像力を豊かにしてお読みください。
ElastiCache の Memcached と Redis →「猫戦士と不死の精霊使い」
タイトルがおとぎ話みたいで素敵ですね。
ElastiCacheはメモリキャッシュサービスですが、MemcachedとRedisという2つのエンジンがあります。
その違いを「軽装備の猫の戦士（MeowCat）」と「不死の精霊使い（Ladies）」として覚えましょう。ちょっと無理があるような気はしますが気合です。
- Memcached: シンプルで軽量、分散キャッシュに最適で、キャッシュ機能のみを提供する→「軽装の猫の戦士（MeowCat）」
- Redis: 高機能で永続性があり、複雑なデータ構造も豊富、マスター＆複数のレプリカ型 →「不死の精霊使い（Ladies）」
このキャラクター設定で、それぞれのエンジンの特徴を覚えやすくします。
シンプルでスピーディーなキャッシュが欲しいならMemcached、リッチな永続機能が必要ならRedisです。
多分猫の名前は「ドラちゃん」かもしれないですね。頭文字D。
Kinesis の Data Streams と Firehose →「川と消防ホース」
Kinesisには、リアルタイムデータ処理を行うData Streamsと、データをS3などに配信するFirehoseがあります。
この違いを「川（Data Streams）」と「消防ホース（Firehose）」として覚えましょう。これは英語そのまんまですね。
- Data Streams: 「川」→ リアルタイム処理が得意、細かい制御が可能
- Firehose: 「消防士のホース」→ 簡単にデータを大量に流し込む、一方向の大量データ転送に最適
Kinesis Data Streamsはリアルタイムのデータを「川」のように流し続けます。一方、Firehoseは大量のデータを「消防士のホース」のように一気に送り出します。
消防ホースはすごい勢いで水（データ）を届けることに特化しており、川の水は飲んだり洗ったり畑にまいたりいろんな加工ができます。川の水を田んぼに引いてくる（シャードで分割）することもできます。
Security Group と Network ACL →「秘書と、自分を自分を入国審査人だと思い込んでいる会社の受付」
Security GroupとNetwork ACLはAWSのセキュリティ機能として重要で、二つの違いを覚えるのはAWS勉強をする皆が頷く項目だと思っています（主観です）。
この違いを「秘書（Security Group）」と「自分を自分を入国審査人だと思い込んでいる会社の受付（Network ACL）」として覚えましょう。
.......すみません、言いたいことは分かります。
最初ACLは「ステートレス」という特性から「入国審査官」だったのですが、秘書（Security Group）との関係性の説明のしやすさを考えた結果こんなに複雑な例えになってしまいました。
ややこしい人は「入国審査官」に読み替えていただいても大丈夫です。仕事の位置関係や通信を見る順序は「秘書に対する会社受付」で、仕事内容としては「入国審査官」というイメージです。
(会社ビルをVPCとして部屋をサブネットとした方が説明は良さそうなのですが、あまりにややこしくなりそうなのでやめました。逆にややこしいのが大丈夫な人は「入国審査官だと思い込んだ用心棒」だと正確かもしれないです。)
- Security Group: 「秘書」→ インスタンスごとに指定、細かいアクセス制御、ステートフル
- Network ACL: 「自分を自分を入国審査人だと思い込んでいる会社の受付」→ サブネットごとに指定、ネットワーク全体のアクセス制御、ステートレス
Security Groupは「秘書」が個々のインスタンス（社長、部長という個人）に直接アクセスを許可するかどうかを決めるようなものです。
一人の社長に何人も秘書が付いたり、1人の秘書が何人かの役員を補佐したりすることもあり得ます。
一方、Network ACLは「会社の受付」がサブネットという会社の入り口のアクセスをコントロールします。もちろん、入国審査のつもりなので「行きは通ったら帰りはOK！」とはなりません。
秘書はいっぱいいるので、全員が相手を審査してどこかにアポ（許可）があったら通してくれます。(全てのルールをチェックして通信可否を判断)
入国審査官は一人で通る相手をチェックするので、ルール番号の小さい順にチェックし、通信内容に合致するルールがあったら通信可否を判断するという仕事の仕方をしています。（ルールの順位付け）
また、秘書にはない仕事内容として、拒否リストにある良くない人がいたら追い返す（拒否リスト）ということもしてくれます。
一般的にはSecurity Groupを使い、追加のセキュリティとしてACLを使うことが多いです。これは「この受付は癖が強いから」みたいに覚えられますね。（もちろん実際はとても便利な機能で、単なる使い分けの問題です）
実際に試したい人はこちら： blog.serverworks.co.jp
Gateway EndpointとInterface Endpoint →「門と携帯電話」
VPCの中で使われるエンドポイントには、Gateway EndpointとInterface Endpointがあります。
どちらもインターネットに出ることなくサービスにアクセスできるサービス（グローバルIPをもつAWSのサービスに対して、VPC内部から直接アクセスするための出口）です。
これは「移転門（Gateway）」と「携帯電話（Interface）」です。
- Gateway Endpoint: S3・DynamoDBへの通信を最適化する、地続きの土地でしか使えない「移転門」（無料）
- Interface Endpoint: デバイス（ENI）を互いに持つことで、離れたところ（他リージョン、アカウント、オンプレミス）でも使える「携帯電話」（有料）
門と携帯電話というイメージで、エンドポイントの使い方を区別しやすくします。
「移転門は公共（そうなのか？）→パブリックIPで接続」、「携帯電話は個人的なもの→プライベートIP」みたいに覚えてください。
VPCエンドポイントポリシーは両者にあります。
「携帯電話のアドレス帳/着拒設定」とすれば覚えやすいのですが…ゲートウェイ型にもあるんです。便利機能があることで文句を言うのもおかしな話ですね。
ポリシー例：VPCエンドポイントポリシーの運用について本気出して考えてみた
Gateway型とではなくVPCピアリングなどとの比較の考え方ですが、電話の方は相手とのCIDR重複を許容します。相手の現地が見えない、あくまで声だけの繋がりって感じですね。
ちょっとこのあたりは意訳感が強い例えですので、詳しく知りたい方はBlackbeltがおすすめです。p77あたりから見ると「なーんだ」となるかと思います。イラストは思い出すきっかけにでも使ってください。
https://pages.awscloud.com/rs/112-TZM-766/images/20201021_AWS-BlackBelt-VPC.pdf
おまけ：Transit Gateway →「トラ柄のハブ（蛇）」
お気に入りの例えですが覚えられる情報が少ない、「弱い」やつです。
Transit Gatewayは複数のVPCやオンプレミスネットワークを接続するハブの役割を果たします。「トラ柄のハブ（蛇）」として覚えましょう。
……やっぱりブログに載せるには少し弱いですね。
ですが、私はTransit GWってなんだっけ？となったら、トラ→虎→「トラ柄のハブ（蛇）」→「ハブの役割をする奴だ～」と思い出してお世話になっていました。
- Transit Gateway: ネットワークのハブとして機能する
Transit Gatewayは、各ネットワークをつなぐ「交通の交差点」のようなものです。これを使えば、異なるネットワーク間のトラフィックがスムーズに流れるようになります。
後書きとさらなるおまけのAthena
いかがでしたでしょうか？ちょっとでも勉強の手助けになったり、または何となく楽しい気分になっていただけたりしたら幸いです。
まだいくつかストックがあるので評判が良ければまた書くかもしれません（これからも勉強の過程で増えるのではないかと思います）
皆さんも素敵な覚え方があったら是非教えてください！
AWSの世界を楽しんで学んでいきましょう！
これはひどい
