はじめに
サーバーを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 の中か外か」 を確認する