AWSで知らないと損する8選｜NAT Gateway料金・Lambda

RJC Techチーム

AWSって、覚えることが多いうえに、仕様そのものが更新されていくんですよね。数年前に覚えた常識が、いまはもう違っている。そんなことも普通に起きます。

今回は、実務で「ほぉー」となったものを8つ集めました。古い常識のままだと損するものから、請求書に効くものまで。1つでも知らなかったら儲けものです。異論・追加も大歓迎です。

① 「1a」は、アカウントごとに違う場所です

これ、初めて知ったときは静かに驚きました。

ap-northeast-1a のようなアベイラビリティゾーン名、実はアカウントごとに割り当てが違うんです。あなたの1aと、別のアカウントの1aは、物理的に別のデータセンターかもしれない。

なぜそうなっているかというと、みんなが「aから使う」と偏ってしまうからなんですよね。分散させるための仕組みなんです。だから「うちは1aに寄せているので、御社も1aで」という会話は噛み合いません。

複数アカウントで物理的な場所を揃えたいときは、AZ IDという別の識別子を使います。こちらはアカウントをまたいでも同じ場所を指します。

② マルチAZは、リードレプリカではありません

RDSでいちばん誤解されているところかもしれません。

マルチAZ配置（DBインスタンス構成）のスタンバイは、待機しているだけなんです。読み取りを分担してはくれません。役割は可用性で、性能ではないんですよね。障害が起きたときに自動で切り替わる保険です。

読み取りの負荷を分散したいなら、リードレプリカを別に用意する必要があります。ここ、料金を倍払っているのに性能が上がらない、という悲しい勘違いを生みやすいところなんです。

ちなみに、あとから登場したマルチAZ DBクラスター構成では、スタンバイからも読み取れるようになっています。同じ「マルチAZ」でも中身が違うので、どちらの話をしているか確かめると安心です。

③ S3は、もう結果整合性ではありません

「S3は書き込んだ直後に読むと、古いデータが返ることがある」。そう習った方も多いと思います。私もそう覚えていました。

2020年12月に変わったんです。いまは書き込み直後の読み取りでも、強い整合性が保証されます。追加のコストも、性能への影響もありません。

昔の設計だと、この仕様のために「少し待ってから読む」「別の場所にフラグを置く」といった回避策を入れていたんですよね。いま新しく作るなら、そこは素直に書いて大丈夫です。古い記事を読むときは、日付を見るのが大事だなと思わされた出来事でした。

④ S3のキー名を、ランダムにする必要はありません

これも古い常識シリーズです。

かつては「オブジェクトのキーの先頭をランダムにしないと性能が出ない」と言われていました。日付から始まるキー名は避けろ、と。いまは自動でスケールするようになっているので、その工夫は不要なんです。

プレフィックスごとに、毎秒3,500回の書き込みと5,500回の読み取りに対応できます。しかもプレフィックスはいくらでも作れるので、必要なら並列に増やせばいい。

つまり、キー名は読みやすさで決めていいということなんですよね。日付やIDで整理された素直な構造の方が、後から探すときに助かります。

⑤ NAT Gateway経由の通信は、思ったより料金がかさみます

請求書を見て驚くやつです。

プライベートサブネットからS3にアクセスするとき、NAT Gatewayを経由していませんか。NAT Gatewayには、起動している時間あたりの料金と、通したデータ量に応じたデータ処理料金がかかります。さらに構成によっては、これとは別にデータ転送料金も発生するんです。

でも、S3とDynamoDBにはゲートウェイ型のVPCエンドポイントという仕組みがあって、これが無料なんですよね。ルートテーブルに設定するだけで、NAT Gatewayを経由せず直接つながります。

大量のデータをS3に置いている環境だと、これだけで請求額がはっきり変わります。なお、他のサービス向けのインターフェース型エンドポイントは有料なので、そこは別物として考えてください。

⑥ Lambdaはメモリを増やすと、安くなることがあります

直感に反するやつです。

Lambdaの料金は、メモリ量と実行時間の掛け算で決まります。だからメモリを増やすと高くなりそうですよね。ところが、Lambdaはメモリを増やすとCPUの割り当ても増えるんです。処理が速く終わるようになるので、実行時間が縮む。結果として、合計金額が下がることがあるんですよね。

128MBで3秒かかっていた処理が、512MBで0.5秒で終わる。こうなると、単価が上がっても総額は安くなります。

CPUを使う処理ほど効きます。メモリ設定は「足りるかどうか」ではなく、「どこがいちばん安いか」で決めるものなんです。

⑦ スナップショットを消しても、容量が減らないことがあります

EBSのスナップショットは増分方式なんです。1回目は全部、2回目以降は前回からの差分だけを保存します。だから2回目以降は安い。

ここまではよく知られているんですが、削除したときの動きが面白いところで。あるスナップショットを削除しても、そのブロックを他のスナップショットが参照している場合、実体は消えないんです。

つまり「古いスナップショットを消したのに、容量が思ったほど減らない」という現象が起きます。不要な世代を消すときは、この参照関係を意識しておくと、期待とのズレが減ります。

⑧ コスト配分タグは、有効化して初めて集計されます

最後は、地味だけど効くやつです。

リソースにタグを付けて、プロジェクトごとに費用を把握したい。よくある要件ですよね。でもタグを付けただけでは、費用の内訳としては見られないんです。請求の設定画面で、そのタグをコスト配分タグとして有効化する必要があります。

そしてここが「ほぉー」なんですが。以前は、有効化した時点より後の費用しか集計されませんでした。あとから気づいても、過去分は取り返せなかったんですよね。いまは条件を満たせば、最大12か月前まで遡って適用できるようになっています。

「先月までの内訳を出して」と言われてから気づいても、まだ手が残っているということなんです。とはいえ、遡りの作業が発生することに変わりはないので、タグの運用ルールを決めたら有効化までを1セットにしておくのがおすすめです。

番外編：請求書でよく見かける、2つのこと

ひとつめは、EC2を停止してもEBSの料金はかかり続けること。止まるのはインスタンスの料金だけなんですよね。

そしてふたつめが、これも古い常識が更新されたところなんです。パブリックIPv4アドレスは、2024年2月から使っているかどうかにかかわらず課金されるようになりました。1時間あたり0.005ドルです。

それまでは「Elastic IPは、どこにも割り当てていないときだけ課金」でした。起動中のEC2に付いていれば無料だったんですよね。いまは、ちゃんと使っていても時間あたりで課金されます。1つあたりは小さな額ですが、台数が増えると地味に効いてきます。そもそもパブリックIPが必要なリソースなのか、見直す価値があります。

「使っていれば無料」で止まっている知識、私も危なかったです。AWSの更新の速さを、あらためて感じたところでした。