ハクソク

世界を動かす技術を、日本語で。

2025年のAWS: あなたが知っていると思っていることは今や間違っている

278日前原文(lastweekinaws.com)

概要

  • AWSの進化 と変化の速さについて解説
  • EC2やS3など基盤サービス の主要なアップデートまとめ
  • コスト削減や 認証方式の最新動向 も紹介
  • 古い情報との違い や注意点を強調
  • 最新の 運用ベストプラクティス を簡潔に整理

AWS基盤サービスの進化と最新事情

  • AWSは約20年の歴史 を持つクラウドサービス
    • 長い歴史ゆえに 古い情報が混在 しやすい現状
    • 基盤サービスの進化を見落としやすい点に注意

EC2の主な変更点

  • セキュリティグループやIAMロール の変更がインスタンス停止不要に
  • EBSボリュームのリサイズ・アタッチ・デタッチ が稼働中に可能
  • 強制停止・強制終了機能の追加で クリーンシャットダウン待ち不要
  • ライブマイグレーション 対応でインスタンスの信頼性向上
  • スポットインスタンスの価格変動 が緩やかになり、利用しやすさ向上
  • Dedicated Instanceの必要性減少 （HIPAA BAA要件撤廃済み）
  • AMI Block Public Access が新規アカウントでデフォルト有効化

S3の主な変更点

  • 即時整合性（Read-after-write consistency） に対応
  • オブジェクトキーの ランダム化不要
  • ACL非推奨・デフォルト無効化、新バケットはBlock Public Accessが標準
  • バケット暗号化 がデフォルト
  • GlacierがS3ストレージクラスに統合、復元料金も簡素化・低額化
  • Glacier復元速度の大幅向上

ネットワーク関連の進化

  • EC2-classicの廃止
  • パブリックIPv4アドレスが有料化 （Elastic IPと同額）
  • VPC Peeringの代替 としてTransit GatewayやVPC共有、Cloud WAN等が登場
  • VPC LatticeやTailscale でネットワーク構成の柔軟化
  • CloudFrontのデプロイ時間短縮 （約5分に改善）
  • ELB ClassicのクロスAZ転送課金廃止 （ALB/CLBは無料、NLBは課金注意）
  • NLBでセキュリティグループ対応
  • Availability ZoneのID共有 がResource Access Managerで可能

Lambdaの進化

  • 最大実行時間が15分 に延長
  • コンテナイメージやEFS対応
  • RAM最大10GB、/tmp最大10GB まで拡張
  • VPC内の起動速度改善（コールドスタート問題の緩和）

EFS・EBSの主な変更

  • EFSのIO性能調整が容量と独立 して設定可能
  • 新規EBSボリュームは即時フル性能
  • スナップショットからの復元は初回アクセス時のみ遅延
  • io1タイプならマルチアタッチ可能 （ただし推奨はされない）

DynamoDBの改善点

  • 空フィールドが許容 されるように
  • パフォーマンスの安定化 とホットキー可視化ツールの一般化
  • オンデマンド利用が標準、特殊用途以外で推奨

コスト最適化と運用の最新トレンド

コスト削減手段の変化

  • Reserved Instanceは段階的に廃止、今後はSavings Plansが主流
  • Savings Plansの割引率低下 と柔軟性向上のトレードオフ
  • EC2の秒単位課金 で短時間利用のコスト最適化
  • Cost Anomaly Detectorの無償化 と精度向上
  • Compute Optimizerの推奨信頼性向上 （Trusted Advisorは注意）

認証・認可の最新動向

  • IAMロール中心の権限設計 が推奨
  • IAMユーザーはレガシー用途限定
  • IAM Identity Center （AWS SSOの後継）が人の認証基盤
  • MFAデバイスの複数登録 が可能
  • 組織メンバーアカウントでroot認証情報不要

その他の最新事情と運用上の注意

  • us-east-1リージョンの安定性向上
  • サービス廃止（deprecation）の増加傾向、ニッチサービス利用時は移行計画を検討
  • CloudWatchの最終データポイント問題解消
  • 組織内アカウントの一括削除がrootアカウントから可能

まとめ

  • AWSの進化は速く、古い情報に注意
  • 基盤サービスの運用・コスト・認証方式 は常に最新情報を確認
  • 新機能・デフォルト設定の変更 を活用した効率的な運用体制構築が重要

Hackerたちの意見

まだバカバカしいと思うのは、VPCと同じリージョンにS3バケットがあるのに、NATゲートウェイを使ってデータをパブリックインターネットに送って、また同じデータセンターに戻すのに課金されることだよね。VPCエンドポイントを使わない限り、デフォルトでその動作をオプトアウトにしない理由が全くない。AWSがこの分野に対する人々の無知から利益を得ているだけだと思う。今のオプトインの動作を望む人は…ゼロではないにしても、ほんとに少数派だよ。

└

VPCやサブネット、PrivateLinkエンドポイントの設定の楽しさを経験したら、全体が本当に馬鹿げてると思えるよ。プライベートVPCエンドポイントに「PrivateLink」って名前をつけるために努力したみたいだけど、これって初めからデフォルトであるべきで、特に目立たない機能だと思う。実際、プライベートサブネットがある場合、S3などを使う唯一の方法はPrivate Linkだと思うんだけど、間違ってたら教えて。ほんとに驚きだよ。

└

それは価格セグメンテーションだね。価格に敏感でない人は、これを修正するために時間をかけないだろうし、そういう人はAWSを使うべきじゃないかもしれないけど、何らかの理由で使わざるを得ないことが多いから、彼らは請求書を減らすために努力するんだ。

└

VPCエンドポイントは一般的に無料で、デフォルトで有効にすべきだと思う。自分のVPCからAWSのAPIエンドポイントにアクセスするのに追加料金がかかるのは、ちょっとひどいよね。

└

問題は、VPCエンドポイントが無料じゃないことだよね。もちろん、同じリージョンのAWSサービスに対しては無料であるべきだと思う。[編集: インターフェースエンドポイントについて話してるけど、S3やDynamoDBはゲートウェイエンドポイントを使えるから、同じリージョンでは無料だよ]

└

これは、S3 VPCゲートウェイエンドポイントの意図された使用ケースで、無料で使えます。 https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpo... （免責事項：私はAWSで働いていますが、意見は私自身のものです。）

└

これはデフォルトで安全な設計です。NATゲートウェイもS3用のVPCゲートウェイエンドポイントもない（他のインターネット出口手段もない）場合、ワークロードはS3にアクセスできません。ネットワークはデフォルトで閉じておくべきで、実際にそうなっています。ユーザーが理解していないもの（NATゲートウェイみたいな）を設定するのは自己責任です。マネージドNATゲートウェイだけがインターネット出口の選択肢ではなく、ユーザーはAWSの基本機能の上に構築するネットワークに責任を持つ必要があります（そう、これがIaaSであってPaaSではないことを忘れないでください）。

└

収益を上げている会社はバカじゃないよ。

└

VPC内にALBがあって、リクエストをVPC内の何かにルーティングして、それがバケットのAWS PutObject APIを呼び出す場合、まだその状況になるのかな？

S3: 「新しいバケットでは、パブリックアクセスがデフォルトで無効になっています。」一方で、これは明らかに正しい決定だよね。誤って設定されたS3バケットによる大規模なデータ漏洩の数は膨大だから。でも…年に一度くらい、パブリックリードアクセスのあるS3バケットを作りたいと思うことがあるんだ。そういう時、毎回何かが変わっていて、以前のやり方が通用しなくなってるから、また一からやり直さなきゃいけないんだよね！

└

バケットを公開するためにいろいろ手間がかかるのは全然気にしないし、むしろそれが面倒だと思うのは、私にとってはバグじゃなくて機能みたいなもんだね。

└

そのバケットの前にCloudFrontを置くだけです。そうすれば、バケットをまったく公開する必要がなくて、DNSのカノニカルホスト名にポイントできます。

└

こういうの、面接で本当にイライラする。人が「○○技術に詳しいですか？」って聞いてくるけど、うん、何月の話？

└

「パブリックアクセスをブロック」設定について覚えておくべきことは、これは大きなミスを避けるための冗長性が組み込まれているということです。たとえひどい許可のバケットポリシーやACL（古いけどまだ存在する）が設定されていても、パブリックアクセスをブロックがオンになっていれば、オブジェクトへのパブリックアクセスは許可されません。オフにしても、しっかりしたバケットポリシーがあれば大丈夫です！バケットポリシーが誰がアクセスできるかを決めます。もちろん、時間が経つにつれて誰かがそのバケットポリシーを誤って変更したり、アクセス権のあるIAMロールを追加したり、既存のIAMロールの信頼ポリシーを変更したりしないように気をつける必要があります。

└

これがまさに僕がLLMを使う理由なんだ。AWSのドキュメントに埋もれてる基本的なデモコードを読み取ってくれるからね。それを手に入れたら、必要なカスタムの調整もお願いできるし。

ちょっと話がそれるけど：君が知っていることは全部間違っている。ウィアード・アル。 https://www.youtube.com/watch?v=W8tRDv9fZ_c ファイアサイン・シアター。 https://www.youtube.com/watch?v=dAcHfymgh4Y

AWSのやり方（API Gateway、サーバーレスラムダ、IAMロールをいじって動くまで）から、EC2やLightSailのVPSインスタンス、S3バケットをもらってRoute53でドメイン設定して、あとはお任せって感じに進化した人が多いと思います。

└

主にフットプリントの柔軟性（すべてのAWSサービスがすべてのリージョンにあるわけではない）と請求の一貫性のために、クラウドを大幅に退化させた業界がたくさんあります。

└

正直、IAMの管理だけで時間が取られちゃって、システム管理に使ってた時間を権限管理に費やしてるって説明してるんだ。IAMはすごく複雑だから、結果的に損してる気がする。生のVPSと、詳細すぎる最小権限のサーバーレス設定の間にちょうどいいバランスがあると思うんだけど、そこに戻りたいな。Fargateは候補としては管理できないわけじゃないけど、まだ「これだ！」とは思ってないから、もっとワークロードを移してみて確かめてみるつもり。

└

ストレージバケットとVPSとして使う場合、AWSが他のコンピューティング競合よりも価値があるのはどのタイミングなんだろう。そうなると完全に高くつくよね。もっと伝統的で堅実なVPSプロバイダーを選んだ方がいいんじゃない？俺は逆の哲学を持ってるけど、AWSにお金を払うなら、正しく、最大限に使いたいんだ。例えば、NのことをAmazonにオフロードできるなら、それが適切なら望ましいよね。Step Functions、Lambda、DynamoDBなどは、時間が経つにつれてその代替品を置き換えてきて、全体的に効率的でコスト効果も高いと思う。ただ、開発者がベンダーの使い方を最適化することをあまり考慮していないと思うんだ。

ここにはいい情報があるね。AWSは、今やってる「AI」の追いつき合戦みたいな余計なことじゃなくて、地味だけど重要なことに集中してほしいな。AWSのリーダーシップは大きなチャンスを逃しちゃったけど、まあそれは仕方ない。結局、AWSにはGenAIに強いリーダーシップや才能がないけど、昔はそこそこ優秀なエンジニアがいたはず。基本に戻って、そこに集中してほしいな。今のリーダーシップはGenAIにパニックになってて、何かがうまくいくように無作為に色々投げてる感じがして、ほんとに顧客にはイライラするよ。

EC2では、インスタンスをシャットダウンせずにセキュリティグループやIAMロールを変更できるようになったよね。これって何年も前からそうじゃなかった？ >スポットインスタンスは昔はもっと入札戦争みたいな感じだったよね。そう、今は全然入札がないから、すごくいいよ。可用性が下がるときに超高い入札をして確保しようとした人だけが取れるってことがなくなったから。 >オブジェクトキーの最初の部分をランダム化して、分散させてホットスポットを避ける必要はないよ。これには本当に苦労したし、頑固な同僚たちを説得するのに時間がかかった。面白いのは、彼らがデータを何百万もの10-100kbのファイルとして保存してたから、S3のバックエンドのスケーリングがパフォーマンスのボトルネックになってなかったってこと。 >元々、Lambdaは5分のタイムアウトがあって、コンテナイメージをサポートしてなかった。今は最大15分まで実行できて、Dockerイメージを使ったり、EFSで共有ストレージを使ったり、最大10GBのRAMを与えたりできるようになった（それに合わせてCPUもスケールするし、見えないけど）。/tmpには最大10GBのストレージも与えられるようになった。これはすごいことだよ。pyarrowのパッケージサイズを管理するのが大変だったから、PythonのLambda関数で使いたいときはほんとに面倒だった。一つ付け加えたいのは、Pythonのグローバルスコープが実際には持続されているってこと。/tmpディレクトリだけじゃないんだ。

AWSアカウントにログインできなくなった、MFAを設定してなかったから。MFAを設定したいけど…デバイスのリクエストにはログインが必要。そう、事前に警告されてたのは知ってるけど、ログインなしでMFAデバイスをリクエストできないのは…最悪だよ。

└

これ、サポートに連絡すれば簡単に解決できそうじゃない？

グレイシャーの復元ももう遅くないよね。私には理論があって（証拠はないけど、Amazonの運営方法を知ってるから）、元々のグレイシャーサービスはどこかのAmazonのフルフィルメントセンターから運営されてたんじゃないかと思ってる。データのリクエストをすると、ピッカーが棚に行って、リムーバブルメディアを取ってきて、それをラックのドライブに差し込むって感じ。これ、昔のタイムシェアリングマシンのテープバックアップのやり方に似てるよね。テープをリクエストすると、マシンルームのオペレーターが棚から取り出して、テープドライブにマウントしなきゃいけなかった。

└

うん、でも彼らは何十年もロボットみたいだったよ。

└

最も可能性が高い説明は、ここで見られるテープロボットを使っているってことだね：https://www.reddit.com/r/DataHoarder/comments/12um0ga/the_ro... これは基本的に君が説明した通りだけど、ピッカーがロボットなんだ。データリクエストはキューに入って、リクエストが来るとロボットが要求されたデータを調べて、テープとオフセットを見つけて、テープを取り出してドライブに挿入し、オフセットまで早送りして、ファイルを一時ストレージに読み込んで、テープを巻き戻して、取り出して戻す。オフラインストレージのレイテンシはカセットの取り出し/交換やテープの早送り/巻き戻し、さらに空いているドライブを待つことにあるんだ。実際には、システムはキューから次のリクエストを取得して、そのテープを調べて、そこからのリクエストを処理するから、同じテープを20回も入れ替えることはないと思うよ。

└

ハードドライブが均一だから、絶対にルビーのロボットを使ってるだろうね。倉庫に人間がいるのは、異質性（サイズが違ったり、質感が違ったり、柔らかさが違ったりするから）だけだと思う。

└

これについては話せないけど、Glacierが最初にどう設計されたかの正確な推測を見たことがないんだ。Glacierは他のAWSサービスと同じデータセンターで動いてたって言っても大丈夫だと思う。もうかなり前のことだし、僕が離れた後にいくつかの機能が追加されたから、変化があったのは明らかだけど、ちょっと慎重に言うね（でも、もう誰も気にしてないだろうけどさ）：エンジニアリングやプロダクトマネジメントの全ての分野で最も重要なことの一つは、顧客の期待を管理することだよ。もし「顧客は10枚の画像しかアップロードできません」って言っておいて、12枚アップロードさせたら、彼らは常に12枚アップロードできると思うようになる。期待を管理することは、将来的にやりたい変更のための余地を作るのに本当に価値があることもあるよ。10枚から20枚にサポートを増やすのは、逆よりずっと簡単だからね。

アベイラビリティゾーンはアカウントごとにランダムだったよね（俺のus-east-1aが君のus-east-1cみたいな）。なんでだよ？

└

これには本当にイライラしたわ。

└

これはus-east-1aの負荷を分散させるためだったんだ。最初は問題なかったけど、アカウント間でネットワークを接続する方法（例えば、PrivateLinkエンドポイントサービス）が出てきて、どのAZがどれかを把握しないといけなくなった。だから、各アカウントで同じAZにマッピングできるようにする必要があったんだ。俺はこれを数十のAWSアカウントでマッピングするための方法論を作り、社内インフラ用のルックアップテーブルも作った… そしたらAWSがAZメタデータにゾーンIDを追加して、直接調べられるようになったんだよね。

└

おそらく、誰もが基本設定でus-east-1aを選んでも、同じAZに全員が集まらないようにするためだろうね。

└

負荷を分散させるためだったんだよ。もし誰かが複数のアカウントでリソースを管理していて、常に例えば1bにデフォルト設定していたら、AWSはどのAZがどのデータセンターセグメントに対応しているかをランダムにして、ホットスポットを避けるようにしてたんだ。標準的なAZ名が提供されたのは、必要なユーザーがホットスポットを引き起こすユーザーとはあまり重ならないって気づいたからだと思う。

「オブジェクトキーの最初の部分をランダム化する必要はなく、分散させてホットスポットを避けることができます。」僕の理解では、これは完全に正確ではないと思う。でも、AWSはこれをあまり詳しく文書化してないのは確かだね。数ヶ月前にAWSのエンジニアと（非公式に）話した感じでは、だいたいこんな感じで動いてる（エンジニアがあまり共有したくなかった詳細は省いてるけど）：S3のリクエストは「パーティション」と呼ばれるものに基づいてスケールする。パーティションは、バケット内のオブジェクトの最小共通プレフィックスと、そのプレフィックスを持つオブジェクトが受けるリクエスト数に基づいて自動的に形成される。そして、バケットは最初は1つのパーティションから始まる。例えば、「2025-08-20/foo.txt」と「2025-08-19/foo.txt」というオブジェクトがあるバケットがあったとしたら、最小共通プレフィックスは「2」だ（もしかしたらルートが生成パーティションとして考慮されるかもしれないけど、実際にはわからない）。（念のために言うと、S3のオブジェクトキーの「/」には特別な意味はないよ。ただの別の文字だから。サブディレクトリはない）。だから、そのプレフィックスに基づいてパーティションが形成される。最初は1つのパーティションから始まる。もし「2025-08-20/foo.txt」が突然たくさんのリクエストを受けたら、S3はそのリクエストを約30〜60分間スロットルすることになる。それが新しいパーティションが形成されるまでの時間だ。この場合、「2025-08-20/foo.txt」の最小共通プレフィックスは「2025-08-2」になる。だから、そのプレフィックスのために2番目のパーティションが形成される。（再度言うけど、ここでの詳細は完全に正確ではないかもしれないけど、これが僕に伝えられた例だ）。パーティションが形成されたら、もう大丈夫。でも、ここでの重要な問題は、そのウォームアップ時間を待たなきゃいけないことだ。もし小さなオブジェクトを大量に生成したり読み込んだりするワークロードがあると、そのワークロードはパーティションが形成されるまで、かなりの時間スロットルされるかもしれない。もしそのワークロードが数分の遅延に敏感なら、それは基本的にダウン状態だよ。これを回避する方法は、AWSサポートにチケットを提出して、ワークロードが実際に稼働する前にパーティションを事前に生成してもらうことだよ。あるいは、負荷をシミュレートしてパーティションを生成することもできる。でも、もちろんどちらも理想的ではない。理想的には、数十億の小さなオブジェクトを保存しようとせず、無限のスケーラビリティと遅延なしを期待しない方がいいよ。例えば、S3の前に何らかのキャッシングレイヤーを使うといいかもね。

└

これも僕の理解だし、特に最近のデータに対して読み書きが多いワークロードには問題があるよ。日付や自動インクリメントIDでパーティショニングすると、同じ問題にぶつかる。例えば、プレフィックスが/id=12345だとする。S3は内部で、/id=と/id=1という名前のパーティションを生成する。今、IDが/id=20000にロールオーバーしたら、/id=2xxxxの読み書き活動は元のパーティションに戻る。ロールオーバーの際に、読み取りの競合が発生することになる。高スループットのワークロードで読み取りが不均等に分布している場合は、パスのルートに何らかのランダム性や均等に分散されたパーティションキーを使うのがベストだよ。