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

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

概要

  • 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のカノニカルホスト名にポイントできます。

Hacker Newsで議論の続きを見る