2025年のAWS: 知っているつもりでも今は間違っていること

 (lastweekinaws.com)
8 ポイント 投稿者 GN⁺ 2025-08-21 | 3件のコメント | WhatsAppで共有
  • AWSの中核サービスは急速に進化している
  • EC2、S3、Lambda などの主要機能は、過去とは異なり、ユーザーの期待を上回る性能と柔軟性を提供している
  • ネットワーキング、認証、コスト削減策 についても、多くの変化と最適化が行われている
  • 古い ブログ記事 や情報のために混乱が生じることがある
  • 最新のアップデートと変更されたポリシーを把握することが、AWS活用には不可欠である

AWS 2025: 過去の認識と変わった現在

  • AWSは20年近い歴史を持つクラウドプラットフォームであり、それだけサービスの「常識」も継続的に変化している
  • 既存ユーザーであっても変化の速さについていくのが難しいほど、多くの中核機能が改善されている
  • 依然として古い情報を提供するブログ記事も多いため、実際の構成がどう変わったのかを正しく把握しておくことが重要である

EC2

  • EC2インスタンスのセキュリティグループとIAMロール は、今では停止せずに変更できる
  • 稼働中のインスタンスで EBSボリュームのサイズ変更、アタッチ/デタッチ が可能である
  • 最近ではEC2インスタンスを 強制停止または終了 できるため、長いタイムアウトを待つ必要がない
  • 物理ホスト間の ライブマイグレーション 機能が導入され、インスタンス性能低下の警告はまれになった
  • インスタンスの信頼性は大幅に向上し、以前のようにインスタンスが予告なく消えることはほとんどない
  • Spotインスタンスの価格変動は 段階的 になり、投機市場のようにリアルタイム監視する必要が減った
  • 専有インスタンスが必要となるケースはごくまれになった（HIPAA BAAもほぼ10年前から不要）
  • AMI Block Public Access は新規アカウントでデフォルト有効となっている（2023年時点で、90日以上パブリックAMIを所有していないアカウントにも適用）

S3

  • S3はもはや Eventually Consistent ではなく、Read-After-Write Consistency を提供する
  • オブジェクトキーの先頭部分をランダム化する必要がなくなり、データ分散やホットスポット問題への懸念が減った
  • ACLs (Access Control List) はもはや推奨されず、新規バケットではデフォルトで無効になっている
  • 新規バケットでは Block Public Access がデフォルトで設定されている
  • 自動的に 保存データの暗号化 が適用される
  • GlacierはS3のストレージクラスになる前は別サービスだったが、現在は統合されている。請求明細などにその名残があるだけである
  • Glacierの復元コストと速度 は過去と比べてかなり予測しやすく安価になっており、以前の恐ろしい復元費用はもはや事実ではない
広告

ネットワーキング(Networking)

  • EC2-Classic は完全になくなった
  • パブリックIPv4アドレスは今では 無料ではなく、Elastic IPと同じ料金が課金される
  • VPC Peering の代わりに、Transit Gateway、VPC/リソース共有、Cloud WANなどのより良い選択肢が登場している
  • VPC Lattice と Tailscale によって複雑なネットワーキングの問題を簡単に解決できる
  • CloudFront の更新反映時間は45分からおよそ5分へと短縮された（それでもCloudFormationのデプロイ待ちでは長く感じることがある）
  • ELB Classic ではAZ間データ転送料金が課金されていたが、ALBではLCU料金のみが課金される。NLBでは依然としてAZ間料金が発生する点に注意
  • Network Load Balancer にセキュリティグループ対応が追加された
  • アベイラビリティゾーン(Availability Zone) IDはアカウントごとに異なっていたが、現在はResource Access ManagerでZone IDをそろえられる

Lambda

  • Lambdaは 5分制限 から 15分 に実行時間が延長され、コンテナイメージ(Docker)、EFS共有ストレージ、最大10GBの RAM、/tmp 10GB のサポートが追加された
  • VPC内Lambdaの呼び出し速度 は大幅に改善された
  • コールドスタート の問題は過去より大きく緩和されている

EFS

  • EFSのIO性能調整 は、今では容量とは別に制御できるため、意味のないデータで容量を埋める必要がない

EBS

  • 新規 EBSボリューム は、初期データがなければ 即座に最大性能 を利用できる
  • スナップショットから作成されたボリュームは、最初のデータ読み取り時に遅くなることがあるため、ディスク全体を一度読み込むことが推奨される（より高速な選択肢も提供されている）
  • io1ボリューム は複数のEC2インスタンスに同時接続できるが、実際には非常に特殊な状況でのみ推奨される
広告

DynamoDB

  • 項目内で 空フィールド を許容するようになった
  • 性能がはるかに安定し、以前のように ホットキー(Hot key)問題 を別ツールで監視する必要は減っている
  • Pricing の変化により、ほとんどのユーザーにとっては On Demand タイプの方が合理的である

コスト削減オプション(Cost Savings Vehicles)

  • Reserved Instances は徐々に廃止されつつあり、Savings Plans が今後の標準である。Savings Planの割引率はRIに比べて下がったが、柔軟性は高まった
  • EC2利用料金 は秒単位課金のため、インスタンスを非常に短時間だけ起動してもコスト効率が良い
  • Cost Anomaly Detector は予期しない利用パターンを非常に高い精度で検出し、しかも無料である
  • Compute Optimizer はEBSなどさまざまなリソースに対する推奨を提供し、信頼性も高い。Trusted Advisorの推奨は依然として一貫性に欠ける

認証(Authentication)

  • 権限付与には IAMロール の利用が推奨され、IAMユーザー はレガシーアプリにのみ適している
  • IAM Identity Center が AWS SSO に置き換わり、アカウントアクセスに使用されている。このため一部に混乱がある
  • ルートアカウントには 複数のMFAデバイス を登録できる
  • 組織のメンバーアカウントごとに別途ルート認証情報を構成する必要はない

その他(Miscellaneous)

  • us-east-1 の信頼性と耐久性は以前より大きく向上し、昔のように頻発していた障害は今ではニュースになるレベルの出来事である
  • AWSサービスの 廃止(Deprecation) は依然としてまれだが増加傾向にあるため、マイナーなサービスへの依存は慎重に考える必要がある
  • CloudWatchデータ の最後のポイントが不整合のため異常に低く表示される現象は、もはや発生しない
  • ルートアカウントから組織内メンバーアカウントのAWSアカウントを直接 終了(クローズ) できる

関連記事

3件のコメント

 
roxie 2025-08-23

わあ、本当にずいぶん変わりましたね
 
howudoin 2025-08-23

AWSはもはや単一のサービスを選んで使うことはできない。
何か一つやろうとすると、あれこれ全部を組み合わせて使わなければならない。
決して単純ではない。
ベンチャーで使うなら、クラウド費用だけでなくDevOpsの人件費も必要になる。
きちんと構築しようとすると、開発時間をすべて奪われるほど本末転倒に作業量が急増する。
しかも、マネージドサービスを使ったほうがよいケースが増えており、コードレベルですでにプラットフォーム依存になっている。
 
GN⁺ 2025-08-21
Hacker News の意見
  • S3 の「Block Public Access」が新しいバケットにデフォルトで適用されるようになったのを見て、当然正しい判断だと思う。これまで設定ミスの S3 バケットのせいで大規模なデータ漏えいが何度も起きてきた。ただ、ときどき私はファイルを公開配信するためにパブリック読み取り権限のある S3 バケットを作りたくなるのだが、そのたびに何かが変わっていて、昔のレシピが通用せず、最初から学び直す状況が繰り返される
    • 「Block Public Access」の設定は注意深く見るべきだと言いたい。これは人が大きなミスをしないようにする一種の安全装置だ。たとえ非常にずさんな bucket policy や ACL（古いが今でも使われている）を設定しても、Block Public Access が有効ならパブリックアクセスはできない。逆に Block Public Access を無効にして、非常によく設計されたバケットポリシーを使うなら問題ない。バケットポリシーが誰にアクセス権があるかを全面的に決める。もちろん長期的には、ポリシーが偶然変わったり、予期せず IAM ロールが追加されたり、信頼ポリシーが変更されたりする可能性があるので、その管理が重要だ
    • 私はこういう状況で LLM をよく使う。ドキュメントを読ませて、AWS 公式ドキュメントのあちこちに埋まっているデモコードを抜き出してくれと頼む。手に入れた後は、欲しいカスタム修正もその場で聞く
    • これ、前にもやらなかったかという既視感がある。10年前にもみんながバケットを開けっ放しにして、こういう対策をしていなかったかと思う
    • こういう変化のせいで、面接で「この技術に詳しいですか？」という質問がとても曖昧になる。技術が毎月変わるので、いつ時点の知識なのか聞きたくなる
    • 正式に学ぶなら 250 ドル払って認定試験まで受けさせてくれる
  • EC2 でインスタンスを停止せずにセキュリティグループや IAM ロールを付け替えられるのは、もう何年も前からできていた。スポットインスタンスは昔は入札市場だったが、今は入札自体がなくなり、むしろ急激な価格変動や特定ユーザーだけが使えるといったことがなくなって、ずっと良くなった。そして以前はオブジェクトキーの先頭をランダムにしてホットスポットを避ける必要があると言われていたが、今はその必要もなくなった。仲間を説得するのにかなり時間がかかったが、この人たちはどうせ S3 バックエンドのボトルネックとは無関係な超ミニサイズのファイルしか保存していなかった。Lambda は昔は 5 分制限でコンテナイメージもサポートしていなかったが、今は 15 分ランタイム、Docker イメージ、EFS 共有、最大 10GB RAM、/tmp ストレージ 10GB までサポートしている。私も一つ気づいたのだが、Python のグローバルスコープも /tmp のように生き残る
  • Glacier の復元は、もう苦痛なほど遅い必要はなくなった。Amazon らしい想像をすると、昔の Glacier はどこかの実際の Amazon の物流倉庫で動いていたのではないかという気がしていた。データをリクエストすると作業員が棚からリムーバブルメディアを探してサーバーに挿す、そんな感じだった。昔のタイムシェアリングコンピュータのテープバックアップ方式に近く、当時はテープを物理的に交換しなければならなかった
    • 実際にはテープロボットのような自動化設備を使っていた可能性が高いと思う。関連写真の例。人ではなくロボットがテープを探してドライブに入れ、オフセットまで巻いて読み取り、その後また巻き戻して返却する方式だ。待ち時間が発生するのは、テープを探す時間、巻き戻し、そしてドライブ待ちのためだ。おそらく効率のために、一度入れたテープ内のリクエストを全部処理してから取り出す形だったのだろう
    • 内部事情については公開できないが、Glacier の設計を正確に言い当てた人を見たことはない。私も昔 AWS にいたが、いずれにせよ Glacier も他の AWS サービスと同じデータセンターで運用されていたとは言える。エンジニアリングでもプロダクト管理でも重要なのは、顧客の期待値をうまく管理することだ。もしアップロード上限が 10 個だと言っておきながら 12 個アップロードできるようにすると、顧客はずっと 12 個を期待するようになる。期待値の管理が重要だ
    • ハードディスクは均一なので、倉庫は自動ロボットで回しているのだと思う。人を使うのは、さまざまなサイズや形状といった非標準なものを扱うためだ
    • いずれにせよ、こういう装置は何十年も前からロボット化されてきた
  • 私はもう AWS アカウントにログインできない。事前に MFA を設定していなかったからだ。デバイスを発行してもらおうとしても、まずログインが必要になる。前もって警告は受けていたが、ログインなしで MFA デバイスを申請できない仕組みはかなりもどかしい
    • サポートに問い合わせてみるのがよさそうだ
      AWS Support への問い合わせ
    • サポートが簡単に解決してくれそうな問題に見える
  • 私のような人は多いと思う。従来の AWS 流儀、つまり API Gateway、serverless Lambda、IAM ロールまでいじって合わせ込む複雑さはもうやめて、単に EC2 や LightSail VPS、S3 バケット、Route53 でドメインをつなぐだけにして、あとは気にせず済ませたくなる
    • ストレージ + VPS だけを使うなら、AWS より従来型の VPS のほうがずっと安い。私はむしろ、AWS を使う以上はきちんと、そして深く使うべきだという考えだ。委任できるものはすべて Amazon に任せて、効率とコスト削減を狙う。Step Functions、Lambda、DynamoDB も代替手段を上回ってきた。ただ、開発者がベンダー活用の最適化を思ったほど上手くやれていないのが残念だと感じる
    • 実際、クラウドを簡素化した業界は多いが、その理由はサービス提供地域の制限や、請求の予測しやすさにある
    • IAM 管理は時間を食いすぎる。以前はシステム管理に使っていた時間が、今では全部パーミッション管理に吸われている感じだ。IAM は難しすぎて、実際には純粋な損失になっている。VPS と、やりすぎたサーバーレス最小権限管理の中間あたりにスイートスポットがあるはずだ。Fargate がその候補で、もっと移行しながら試してみようと思っている
  • AWS には、他分野に追随しようとして AI 側で散漫にいろいろ出すよりも、これまで得意だった「基礎的だが重要なサービス」にもっと集中してほしい。AWS のリーダーシップは GenAI の方向性では道を見失った感じがするが、基盤インフラはうまく作る。AI のせいでパニック状態に見え、顧客の立場からするとあまりに散漫で不便だ
    • 今のリーダーシップの方向は、インフラを誰でも簡単にモデルを選んですぐ使えるようにすることだ。複雑なセットアップなしにすぐ使える環境を目指している
  • S3 バケットが VPC と同じリージョンにあっても、パブリックインターネット経由だと NAT Gateway の料金が請求されるのは本当におかしい。デフォルトは opt-out であるべきなのに、opt-in が初期設定なのは、おそらく AWS がこの構成で追加収益を得ているからだと思う。今の経路を望むユーザーはごく少数だろう
    • これはセキュリティがデフォルトだという点を考慮した設計だ。NAT Gateway、VPC Gateway Endpoint（S3）、その他のインターネット出口をすべて設定しない限り、ワークロードは S3 にアクセスできない。ネットワーキングは閉じているのが正しいし、もしユーザーが経路を十分理解せずに何かを作るなら、その責任は顧客側にある。AWS は Infrastructure as a Service（IaaS）の生の道具を提供しているだけだと考えるべきだ
    • S3 VPC Gateway Endpoint はまさにこのためにある。料金も無料だ
      AWS 公式ドキュメント
    • VPC、サブネット、PrivateLink エンドポイントなどを全部セットアップしてみると、本当にばかばかしく感じる。PrivateLink という名前を付けるのにも力を入れていて（技術的にも意味はあるが）、こういうものこそ最初から設定なしでデフォルト提供されるべきだと思う。しかもプライベートサブネットを使う場合、S3 などへのアクセスは PrivateLink が唯一の方法ではないのかと思えて、不自然に感じる
    • VPC エンドポイントはすべて無料でデフォルト適用されるべきだと思う。自社サービスの API を使うだけでも追加課金という構造はかなりきつい
    • これは価格差別化が目的だ。価格に敏感でない顧客はわざわざ気にしない。気にする側はコストを下げようと努力するし、そういう状況でもしばしば AWS を使わざるを得ないことが多い
  • 今回の記事のおかげで安心した。Amazon が何か大きく変えて移行を強要したらどうしようといつも心配していたが、2013 年から EC2 インスタンスをほとんど管理不要でうまく使えていた。予想外の変化がなくてよかった
  • 昔、Availability Zones がアカウントごとにランダムにマッピングされていたのは衝撃的だ
    • これは負荷分散のためだった。複数のアカウントで 1b のような特定 AZ を固定で使う場合でも、実際の物理的な分散が均等になるようにしていた。その後、AZ ごとの canonical 名が提供されるようになったが、実際にホットスポットを作っていたアカウントと、メタデータが必要なアカウントが異なっていたからだろうと思う
    • デフォルト設定でみんなが us-east-1a ばかり選んでしまい、特定 AZ に偏るのを防ぐのが目的だったのだと思う
    • 当初は負荷分散には良かったが、複数アカウント間でネットワーク（PrivateLink など）接続をするとき、どの AZ がどこと対応しているのかを毎回確認しなければならず混乱した。そこでアカウントごとの 1 対 1 マッピング手法を作り、内部参照テーブルまで構築したが、後になって AWS が zone ID をメタデータに追加し、簡単に確認できるようにしてくれた
    • この方針のせいで本当に苦労したことが多い
  • 訂正したい点がある。意味のない雑学もすべてひっくり返りうる
    Weird Al: Everything You Know is Wrong
    Firesign Theatre: Everything You Know is Wrong