Amazon Lightsail
仮想サーバーや DB、ロードバランサを固定時間単価と月額上限で始められる。料金が読みやすく、小規模・入門に向く AWS の簡易クラウド。
- 仮想サーバーを固定時間単価と月額上限のプランで始められる。
- 公開 IP、通信枠、停止中の課金まで含めて費用を見積もる。
- 複雑な通信や細かな制御が必要になったら EC2 などへ移行する。
解決する課題
EC2 や VPC、RDS、ELB を個別に組み合わせると、入門者には設定項目が多く、料金も従量課金で読みにくいという悩みがあります。Lightsail はこれらを簡素化したパッケージとして提供します。
- VM・DB・ストレージ・ネットワークを あらかじめ組み合わせたプラン から選ぶだけ
- 料金が 固定時間単価・月額上限 で予測しやすい(転送量の枠込み)
- WordPress や LAMP、Node.js などの 構成済みイメージ(Blueprint) をすぐ起動できる
小規模なWebサイト、個人ブログ、検証環境、学習用途に向いた「迷わず始められる」入口です。
主要概念と用語
- インスタンス: 起動した1台の仮想サーバー。固定時間単価に月額上限があるプランで提供される
- Blueprint(ブループリント): OSのみ、またはWordPressなどアプリ入りの起動テンプレート
- バンドル / プラン: CPU・メモリ・ストレージ・転送量をセットにした定額メニュー
- マネージドデータベース: Lightsail内で簡易に使えるMySQLやPostgreSQLのDB
- ロードバランサ: 複数インスタンスへ振り分けるLB。証明書管理も簡易
- 静的 IPv4: インスタンスに固定で割り当てる公開アドレス。接続中は追加料金なし、未接続の状態が 1 時間を超えると 0.005 USD/時
- スナップショット: インスタンスやDBの時点バックアップ。復元や複製に使う
仕様・制限・クォータ
- リージョンを選んで配置する。提供リージョンはEC2より限定的
- 料金は 時間単価を積み上げ、プランごとの月額上限まで が基本
- プランには月間データ転送枠が含まれ、枠は送受信を数えるが超過料金は主に送信側へ発生する
- インスタンスと管理 DB は停止中も課金が続くため、不要ならスナップショット取得後に削除する
- Linux/Unix と Windows には公開 IPv4 付きと IPv6 のみのプランがある。IPv6 のみのインスタンスには静的 IPv4 を接続できない
- 1 アカウントあたりのインスタンス数や静的 IPv4 数に上限があり、引き上げ申請が可能
- 細かいネットワーク制御やインスタンスタイプの自由度はEC2に劣る(簡易さとのトレードオフ)
内部の仕組み
横にスクロール
Lightsail は、計算・保存・通信を独自のプランと管理画面にまとめた 簡易クラウド環境 です。利用者は個別の VPC 設計やサブネット、ルートテーブルを作らず、Lightsail のコンソールと API からリソースを操作します。
- インスタンスのストレージは永続ディスクとして提供され、停止してもデータは残る
- 既定で簡易ファイアウォール(ポート開放設定)が付き、必要なポートだけを許可する
- VPC ピアリングを有効にすると、同一リージョン・同一アカウントのデフォルト VPC とプライベート通信できる。デフォルト VPC が必要で、相手側の経路とセキュリティ設定も許可する
Lightsail のリソースは通常の EC2 リソースとして直接操作しません。自由度が必要になったら、対応するインスタンススナップショットを EC2 へエクスポートし、EC2 の AMI として移行できます。
設計パターン / ベストプラクティス
- 小さく始める: まずは最小プランで起動し、不足したら上位プランへ載せ替える
- スナップショット運用: 変更前にスナップショットを取り、復元ポイントを確保
- 静的 IPv4 の割り当て: 停止・起動で公開 IPv4 が変わらないよう、静的 IPv4 を使って DNS と紐付ける
- 将来の移行を見据える: 規模拡大が見込まれるなら、初めから移行先(EC2やRDS)を想定した構成に
運用・監視
- Lightsail コンソールに CPU使用率やデータ転送量のメトリクス が表示される
- しきい値を超えたときに通知する アラーム を簡易に設定できる
- スナップショットは手動取得のほか、自動スナップショット をスケジュールできる
- より高度な監視や横断的な可観測性が必要なら CloudWatch 連携や本格構成への移行を検討
コスト
最大の特徴は 固定時間単価と月額上限 で料金が読みやすい点です。月途中の利用は時間単価で積み上がり、上限到達後は同じ月のプラン料金が増えません。停止だけではインスタンスや管理 DB の課金は止まらないため、長く使わない資源は削除します。
定額とはいえ、含まれる転送量を超えると従量で追加課金されます。動画配信や大量ダウンロードなど転送が多い用途では、想定外のコストにならないか事前に見積もってください。
- 静的 IPv4 はインスタンスへの接続中は追加料金なし。未接続の状態が 1 時間を超えると 0.005 USD/時がかかる
- 公開 IPv4 が不要なら IPv6 のみのプランを選ぶと、対応するプランの料金を抑えられる
- マネージドDBやLBもそれぞれ定額プランで、台数分のコストがかかる
セキュリティ
- 接続は ブラウザベースのSSH/RDPクライアント が用意され、鍵なしでも接続できる
- 簡易ファイアウォールで 許可ポートを最小限 に絞る(不要なポートは閉じる)
- LBやディストリビューションには 無料のSSL/TLS証明書 を簡単に適用できる
- VPCピアリングや本格構成へ移行する場合は、IAMロールやセキュリティグループなど標準のセキュリティ機構を併用する
全ポートを開放したまま運用するのは危険です。WebならHTTP/HTTPSとSSHなど、必要なポートだけを開け、SSHは送信元IPを絞ってください。
Well-Architected の観点
- コスト最適化: 定額プランで予測可能。無料枠内に収まるよう転送量を意識し、不要リソースは削除
- 運用上の優秀性: 構成済みイメージとスナップショットで、立ち上げと復旧をシンプルに
- 信頼性: スナップショットによるバックアップ、必要に応じてLBで冗長化
- セキュリティ: 最小限のポート開放、TLS証明書の適用
試験で問われるポイント
- 「最小の手間・定額で小規模サイトを立てたい」→ Lightsail が第一候補
- 「細かいネットワーク制御や自由なスケールが必要」→ EC2 や VPC を選ぶ
- Lightsail のインスタンススナップショットを EC2 へエクスポートして移行できる
- 料金は固定時間単価・月額上限で、転送枠を超える送信分は従量課金
関連サービス・比較
最も自由度の高い仮想サーバーである EC2 とよく比較されます。
| 観点 | Lightsail | EC2 |
|---|---|---|
| 料金体系 | 固定時間単価・月額上限 | 従量課金+購入オプション |
| 設定の手間 | 少ない(構成済みプラン) | 多い(VPC等を自分で設計) |
| 自由度・拡張性 | 限定的 | 非常に高い |
| 向いている用途 | 小規模・入門・検証 | 本番・大規模・要件が多い構成 |
ハンズオン / CLI例
# 利用可能なBlueprint(起動テンプレート)を確認
aws lightsail get-blueprints --query "blueprints[].{ID:blueprintId,Name:name}"
# WordPress入りのインスタンスを最小プランで起動
aws lightsail create-instances \
--instance-names demo-wp \
--availability-zone ap-northeast-1a \
--blueprint-id wordpress \
--bundle-id nano_3_0
# インスタンスの状態を確認
aws lightsail get-instance --instance-name demo-wp \
--query "instance.{Name:name,State:state.name,IP:publicIpAddress}"
AWS Service
Amazon Lightsailを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
コンピューティング
比較で見る軸
クラウド: AWS / カテゴリ: コンピューティング / 難易度: basic
導入後に効く点
公開 IP、通信枠、停止中の課金まで含めて費用を見積もる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- コンピューティング
- 難易度
- basic
- 関連資格
- CLF-C02 / SAA-C03
- 設計柱
- cost / operational
判断チェックリスト
- 自社の用途が「コンピューティング / cost」に近いか確認する。
- 強みである「仮想サーバーを固定時間単価と月額上限のプランで始められる。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。