はじめに

サーバーを1台借りて、そこに MySQL をインストールする。動きます。ちゃんと動きます。

けれど、そのあとに続く問いに答えられるでしょうか。

そのサーバーが壊れたら、データはどうなりますか
バックアップは誰が、いつ、どうやって取りますか
OS のセキュリティパッチは、誰が当てますか
データベースのマイナーバージョンアップは、いつやりますか

これらは 必ず考えなければならない のに、ユーザーからは見えない 作業です。新しい価値を生まないのに、時間だけは確実に奪っていきます。

AWS はこれを 「差別化につながらない重労働（undifferentiated heavy lifting）」 と呼んでいます。マネージドサービスとは、この重労働を肩代わりしてもらい、本来の価値づくりに集中するための仕組み でした。

この記事では、責任範囲の考え方 → マネージドDB → オブジェクトストレージ → DNS → VPC の内外という視点 までを1本にまとめました。

このシリーズでは「ネットワークの仕組み」「可用性設計の基本」も解説しています。あわせて読むと全体像がつかめます。

この記事で分かること

マネージドサービスで「どこまで任せられ、何ができなくなるか」が分かる
アプリが接続先を IP ではなくエンドポイント名で持つべき理由が説明できる
スナップショットから復元したときに、なぜ接続先を変える必要があるのかが分かる
オブジェクトストレージの公開設定でつまずくポイントが分かる
DNS のフェイルオーバーが即時に切り替わらない理由が理解できる
「このサービスは VPC の中か外か」で切り分けができるようになる

第1章：どこまで任せられるのか

「サーバーを借りて自分で入れる」のと「マネージドサービスを使う」のは、責任範囲がどこで切れるか の違いです。

作業	物理サーバー	仮想サーバーに自分で導入	マネージドDB
ハードウェア・電源	自分	AWS	AWS
OS のインストール	自分	AWS	AWS
ミドルウェアの導入	自分	自分	AWS
パッチ適用	自分	自分	AWS
バックアップの仕組み	自分	自分	AWS
アプリからの利用	自分	自分	自分

仮想サーバーを使うだけでも、下の2つは任せられています。マネージドサービスは、その境界をさらに上へ押し上げます。

ただし、任せるということは 自由が減る ということでもあります。たとえばマネージドDB には SSH でログインできません。「設定ファイルを直接書き換える」という手段は使えなくなります。代わりに、コンソールから設定値を変更する仕組み（パラメータグループ）が用意されています。「できないこと」とセットで理解する のが大事です。

第2章：マネージドDB ― 落ちない DB をボタンで作る

自前で DB を冗長化しようとすると、レプリケーションを組み、監視を入れ、障害時に切り替える仕組みを作り……と、それだけで数週間の仕事になります。マネージドDB では、これが チェックボックス一つ でした。

冗長構成と自動フェイルオーバー

ここで最も重要な仕掛けは、アプリが接続するのは IP アドレスではなく「エンドポイント名」だ という点です。

障害が起きてスタンバイ側に切り替わっても、エンドポイント名は変わりません。つまり アプリケーションのコードを書き換える必要がない。これがマネージドDB の価値の中核でした。

アプリエンジニアとして覚えておくべきことは、ほぼこれだけです。接続先はエンドポイント名で持つ。IP アドレスを設定ファイルに書かない。 これさえ守っていれば、裏でどんな切り替えが起きても、アプリは知らないまま動き続けます。

バックアップとリストア

指定した時間帯に自動でバックアップ（スナップショット）が取得されます。任意のタイミングで手動取得もできます。

そして復旧するときの挙動が、少し直感に反します。

スナップショットからの復元は、元の DB を上書きするのではなく、隣に新しい DB インスタンスを作ります。当然、エンドポイント名も新しいものが払い出される ので、アプリの接続先を切り替える作業が発生します。「復元したのにデータが戻らない」と焦る前に、自分がどちらを見ているか確認してください。

また、削除の挙動にも癖があります。自動で取られたスナップショットは DB を削除すると消えますが、手動で取ったものは残り続けます（そして課金されます）。片付けのときに見落としがちなポイントでした。

停止にも制限がある

コスト削減のために「使わない間は止めておこう」と考えるのは自然ですが、マネージドDB は 連続して停止できるのは最大7日間 です。それを超えると、必要なメンテナンスを受けるために 自動的に起動します。

停止しているつもりで放置し、気づいたら課金が積み上がっていた、というのはよくある事故です。料金アラートを設定しておくと安心です。

第3章：オブジェクトストレージ ― ファイルの置き場所

前章までで「ステートレス設計のために、ファイルはサーバーの外に出す」という話をしました。その置き場所として使われるのが オブジェクトストレージ（AWS では S3）です。

特徴は明快です。

安い：ブロックストレージ（EBS）の数分の1程度の単価
壊れにくい：アップロードされたデータは、自動的に 最低3つの AZ に保存 される
サーバーが要らない：容量の見積もりも、ディスクの増設も不要

「フォルダ」は本当のフォルダではない

コンソール上ではフォルダのように見えますが、オブジェクトストレージは本来 フラットなキーバリュー構造 です。images/photo.png というのは「images フォルダの中の photo.png」ではなく、images/photo.png という名前のキー なのです。

これを知っていると、パス関連のトラブルで迷いません。imgs/ と images/ を取り違えていれば、それは「フォルダ名の間違い」ではなく まったく別のキー です。ファイルは存在しません。

公開設定は「2段構え」

外部に公開するとき、初学者が必ずつまずくのがここでした。設定が2箇所あり、両方が揃わないと公開されません。

デフォルトでは「パブリックアクセスをすべてブロック」が有効になっています。これは 強力な安全装置 で、有効なままだと、どんなに寛容なポリシーを書いても ポリシーごと無効化されます。「ポリシーは正しいのに AccessDenied が返る」という状況の多くは、このブロック設定が残っているケースでした。

逆に言えば、うっかり全世界に公開してしまう事故を防いでいるのがこの設定 です。解除するときは「本当に世界中に見せていいファイルか」を必ず確認してください。設定ミスによる情報漏洩は、クラウドで最も多いインシデントのひとつです。

静的サイトなら、サーバーは要らない

HTML と CSS だけのページ（ランディングページ、メンテナンス告知など）であれば、オブジェクトストレージだけで公開できます。サーバーを立てるより安く、可用性も高く、運用の手間もありません。「とりあえず仮想サーバー」と考える前に、この選択肢を思い出してください。

第4章：DNS ― ドメイン名を IP に変える仕組み

意外と説明されないまま使われているのが DNS です。DNS はドメイン名を投げると IP アドレスを返してくれるシステム です。それだけです。

この ①② を 名前解決 と呼びます。設定は「レコード」という単位で管理します。

レコード	役割
A	ドメイン名と IP アドレスを対応させる
CNAME	ドメイン名の別名を定義する
NS / SOA	ネームサーバーや管理情報。ドメイン取得時に自動作成される

AWS 独自の「エイリアス」

ロードバランサーの接続先は IP アドレスではなく DNS 名（長い文字列）です。本来 A レコードには IP アドレスしか書けないので困るのですが、AWS の DNS サービスには エイリアス という拡張があり、A レコードでロードバランサーなどを直接指定できます。実務ではほぼこれを使います。

DNS で障害対応もできる（ただし遅い）

DNS には、プライマリが応答しなくなったらセカンダリに切り替える（フェイルオーバー）機能があります。「Web サーバーが全滅したら、静的ホスティングのお詫びページを見せる」といった構成が作れます。

ただし、ここには重要な注意点がありました。

DNS の切り替わりは、即座には反映されません。 応答はブラウザや ISP のリゾルバに一定時間キャッシュされるからです（この保持時間を TTL と呼びます）。実際に切り替わるまで数分〜10分以上かかることも珍しくありません。「エラーが出た瞬間に切り替えたい」という要件には向かない、と理解しておいてください。

裏を返せば、「エラー画面を出し続けるくらいなら、数分後にでもお詫びページを出したい」 という要件には、シンプルで有効な手段です。用途を見極めて使うのがコツでした。

第5章：VPC の中か、外か

最後にもう一つ、地図として持っておくと便利な視点があります。そのサービスは VPC の中で動くのか、外で動くのか という問いです。

仮想サーバー、マネージドDB、ロードバランサーは、作成時に VPC やサブネットを指定します。VPC の中の住人 です。だからセキュリティグループやルートテーブルの影響を受けます。

一方、オブジェクトストレージや DNS は、作成時に VPC を聞かれません。VPC の外にいます。だからネットワーク設定をいくらいじっても挙動は変わりません。

この区別ができると、トラブルの切り分けが速くなります。「オブジェクトストレージにアクセスできない」ときにセキュリティグループを疑っても意味がありません（VPC 外なので）。逆に「DB に繋がらない」ときは、まずセキュリティグループとサブネットを疑うべきです。新しいサービスを触るときは、まず「これは VPC の中か外か」を確認する。 それだけで見るべき場所が半分に絞れます。

まとめ：マネージドサービスチェックリスト

マネージドサービス＝差別化につながらない重労働 を任せ、価値づくりに集中する仕組み
任せるぶん 自由は減る（例：マネージドDB には SSH できない）
アプリは エンドポイント名で接続する。IP を書かなければ、裏の切り替えに影響されない
スナップショットからの復元は 隣に新しいインスタンスを作る（エンドポイントも別になる）
手動スナップショットは消さない限り残る（＝課金される）
マネージドDB の停止は 最大7日。以降は自動起動するので放置課金に注意
オブジェクトストレージは安く、最低3つの AZ に自動保存 される
「フォルダ」は見た目だけ。実体は フラットなキー
公開は ブロック解除＋ポリシー許可 の2段構え。ポリシーだけでは公開されない
静的なページなら サーバーを立てずに ホスティングできる
DNS の A レコードは、AWS では エイリアス でロードバランサーを直接指せる
DNS のフェイルオーバーは TTL の分だけ遅れる。即時切替の用途には不向き
新しいサービスは、まず 「VPC の中か外か」 を確認する