【初心者向け】2025年版 AWS EC2で始めるRailsデプロイ完全ガイド
はじめに
AWSのEC2を使ってRailsアプリケーションを公開する方法を、初心者の皆さんにわかりやすくまとめます。
プログラミングが初めての方でも「手順の全体像」「セキュリティ面の考慮」「本番運用のポイント」などを一度に理解できるよう、できる限り簡単に解説します。
本記事では、インフラ環境のセットアップからデプロイ後の動作確認・維持管理まで扱います。
AWSやRailsという言葉が出てくると、敷居が高そうに感じるかもしれませんが、ステップを分解しながら進めれば意外とシンプルです。
専用サーバーの設定や、オンプレミス環境を自分で構築するよりも、クラウドサービスの利用はハードルが低いと考えることもできます。
これからEC2を使ってRailsアプリを運用してみようという方は、ぜひ一緒に学んでみましょう。
この記事を読むとわかること
- AWS EC2でRailsをデプロイする全体的な流れ
- インスタンスの作成手順とセキュリティグループの基本的な扱い
- Railsアプリに必要なパッケージのインストール方法
- デプロイ戦略や運用中のトラブルシュートのポイント
- アプリをスムーズに公開するための構成例
EC2を使ったRailsデプロイの特徴
EC2はAWSの代表的なクラウドサーバーであり、世界中の企業・個人がさまざまな規模のアプリケーションを運用しています。
Railsはシンプルな記述でアプリ開発ができるフレームワークとして人気があります。
この2つを組み合わせると、クラウドの柔軟性を活かしたRailsアプリの公開が実現できます。
クラウド上での柔軟な拡張
クラウド環境では、必要に応じてサーバーのスペックを拡張できます。
アクセスが増えて処理が重くなったと感じたら、EC2のインスタンスタイプを上位のものに切り替えるだけでOKです。
オンプレミス(自社運用)に比べて、機器を調達したり設定したりする時間やコストを抑えやすい点が魅力です。
環境が「作りやすい」というメリット
AWSでは、EC2だけでなくVPC(仮想ネットワーク)やRDS(マネージドデータベース)など、アプリに必要な機能が網羅されています。
開発や運用で必要になる機能を、コンソール画面からある程度簡単に追加できるため、環境構築もスムーズです。
クラウドの管理画面に慣れれば、実務的な作業負荷をぐっと減らせるでしょう。
本番環境を想定したデプロイの全体像
Railsアプリの開発がひととおり進んだら、EC2を使って本番環境を整えます。
このとき、以下の流れを把握しておくとスムーズです。
- AWSアカウントの作成とEC2の起動
- 必要なパッケージ (Rubyなど) のインストールとRails環境の準備
- SSH経由でアプリコードをアップロード
- データベースとの接続設定
- アプリケーションサーバーやWebサーバーの設定
- セキュリティグループ (ファイアウォール設定) の調整
- ブラウザを使った動作確認
このように、ステップごとに作業を分けるとゴールが見えやすくなります。
AWSアカウント作成とEC2インスタンスの立ち上げ
AWSを使うためには、まずAWSアカウントを作成します。
クレジットカード登録や、電話認証などの手続きが必要なので、指示に従って進めましょう。
EC2インスタンス作成時のポイント
EC2インスタンスを新規作成するときは、以下の点を意識してください。
インスタンスタイプ
どの程度の性能のサーバーを使うかを選ぶところです。
開発やテストなら最低限のプランでも十分ですが、後から変更できるので悩み過ぎずに選んで問題ありません。
キーペア (SSH鍵) の設定
インスタンスへリモート接続するときに必要です。
適宜ダウンロードした秘密鍵は安全に保管しましょう。
セキュリティグループ
外部からのアクセスをどのポートで受けるか、IPアドレスの制限をかけるかなどのルールを設定します。
Railsアプリ用であれば、一旦はHTTP(80)とHTTPS(443)のポートを開けるケースが多いです。
ログインとRails環境のセットアップ
EC2インスタンスを起動し、ターミナルからSSHでログインできたら、Railsアプリを動かすための環境作りを始めます。
オペレーティングシステムの種類や環境によって一部コマンドが異なる場合がありますが、ここでは一般的な流れを示します。
パッケージマネージャーを利用する
EC2に標準搭載されているパッケージマネージャーを使って、必要なツールをインストールします。
git、Rubyやその他の依存パッケージをインストールしましょう。
例としては、次のようなコマンドが挙げられます。
sudo yum update -y sudo yum install -y git sudo yum install -y gcc make openssl-devel
※パッケージマネージャーの種類はオペレーティングシステムにより異なります。
RubyとRailsをインストール
Rubyをソースからインストールする方法もありますが、初心者の皆さんはパッケージマネージャーやバージョン管理ツール(rbenvなど)を使った方法がおすすめです。
たとえば、次のようにします。
# rbenvを利用する例 git clone https://github.com/rbenv/rbenv.git ~/.rbenv echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile source ~/.bash_profile rbenv init exec $SHELL -l # ruby-buildプラグインを追加 git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build # 好きな安定版をインストールして使用 rbenv install 3.0.0 rbenv global 3.0.0 # Railsをインストール gem install rails rbenv rehash
ここで書いているRubyのバージョン番号は一例です。
安定したバージョンを選んでインストールすればOKです。
そして、rails --version
のようにバージョン確認すれば、Railsが使える状態になります。
データベース準備と接続設定
本番環境でアプリを運用する際には、データベースをどう運用するかが重要です。
今回はデータベースをEC2上に直接インストールする方法を例として考えてみましょう。
データベースのインストール例
Railsアプリでは、よく利用されるデータベースとしてMySQLやPostgreSQLなどがあります。
MySQLを利用する場合、パッケージマネージャーを使って以下のようにセットアップできます。
sudo yum install -y mysql-server sudo systemctl enable mysqld sudo systemctl start mysqld
初期パスワードの設定や、外部からアクセス可能にする際は設定ファイルを編集する必要があります。
あまり慣れていない場合は、ひとまずデフォルトのままインスタンス内での接続のみを試してみるとよいでしょう。
Railsアプリへの接続設定
RailsアプリをEC2にデプロイするとき、config/database.yml
に本番環境の接続情報を記載します。
たとえば、MySQLを使う設定例は以下のようになります。
production: adapter: mysql2 encoding: utf8 pool: 5 database: myapp_production username: dbuser password: <%= ENV["DB_PASSWORD"] %> host: localhost
本番運用ではパスワードは環境変数に設定して、コード上に直接書かないように気をつけましょう。
Railsアプリコードのアップロード手順
EC2上のRails環境が整ったら、実際のアプリコードをインスタンスに配置します。
やり方はいくつかありますが、大まかには以下のいずれかを選ぶことが多いです。
Git経由でクローンする方法
GitHubなどのリポジトリにアプリのソースコードがある場合、インスタンスにSSHで接続した上でクローンするだけです。
以下のようにすると、とてもシンプルです。
cd ~ git clone https://github.com/username/myapp.git cd myapp bundle install
このあと、Railsのシークレットキーや環境変数などを設定する必要があります。
本番で動かすためにはRAILS_ENV=production
で起動するので、以下のコマンドなどを利用します。
RAILS_ENV=production bundle exec rails assets:precompile
SCPやSFTPを使う方法
リポジトリを使わない場合は、ローカル環境からSCPやSFTPなどでサーバーへ転送することもできます。
ただし、ファイル数が多いと手間がかかるので、Gitが使えるならそちらの方が楽です。
アプリケーションサーバーとWebサーバーの設定
RailsアプリをEC2上で起動するには、アプリケーションサーバー(PumaやUnicornなど)とWebサーバー(NginxやApacheなど)が必要です。
Rails標準の開発用サーバー(WEBrickなど)は本番環境には向きません。
アプリケーションサーバーの起動
Pumaを使う例を考えてみましょう。
Gemfileにpuma
が含まれていれば、以下のように起動できます。
RAILS_ENV=production bundle exec puma -C config/puma.rb
config/puma.rb
ファイルには、どのポートで起動するか、スレッド数やワーカー数などを設定します。
EC2上で直接アクセスするときはlocalhost:3000
のようなURLで確認できます。
Nginxの設定例
本番稼働のためにNginxを導入して、80番ポートや443番ポートでリクエストを受け取るのがよくある構成です。
Nginxをインストールしたら、設定ファイルにPumaのポートをプロキシとして指定します。
以下はイメージ例です。
server { listen 80; server_name yourdomain.com; location / { proxy_pass http://127.0.0.1:3000; } }
Nginxを起動すると、EC2のパブリックIPまたはElastic IPにブラウザでアクセスしたとき、Railsアプリにリクエストが流れる仕組みになります。
セキュリティグループとファイアウォールの確認
セキュリティグループはEC2の外部に対してアクセス制限をかけるルールのことです。
80番ポートや443番ポートを開放しないと、ブラウザからアプリにアクセスできません。
HTTPとHTTPSの開放
Railsアプリをデプロイする場合、最低限HTTP(80)のポートを開けます。
利用者に公開する段階でHTTPS(443)での通信をするなら、そのポートも開けてください。
SSHのアクセスを限定する
運用中はSSHのポート(22)も外部からは重要ですが、許可するIPを限定しないとセキュリティリスクが高まります。
固定のグローバルIPを持っていれば、そのIPだけを許可する設定がおすすめです。
ドメイン設定とHTTPS対応
アプリが動いたら、ドメイン名を割り当ててアクセスできるようにしたいですよね。
EC2にはパブリックIPが割り当てられますが、インスタンスの再起動などで変わることがあります。
Elastic IPの利用
Elastic IPを取得すれば固定IPとして使えます。
ただし、IPアドレスでアクセスするのは利用者がわかりにくいため、独自ドメインをEC2のIPに向けるのが一般的です。
HTTPSの設定
インターネット上で安全に通信するために、HTTPS化は重要です。
証明書の取得方法はいくつかありますが、Let's Encryptなどを利用すれば無料で導入できます。
Nginx設定のserverブロックにSSL関連の設定を追加し、HTTPSで接続できるようにします。
本番運用のための注意点
無事にRailsアプリが動いても、本番運用ではいろいろな課題が出てきます。
ログの管理
RailsやNginx、システムログなどがどのように出力されているかを把握し、必要に応じて監視ツールを導入するか検討しましょう。
問題が起きたときに素早く原因を突き止められるよう、ログの保管先と閲覧方法を整理しておきます。
アプリの自動再起動
もしPumaやNginxが何らかの理由で落ちた場合、自動的にサービスが再開する仕組みを用意しておくと安心です。
Systemdのユニットファイルを作成して、サービスとして起動する設定にしておくと、OSが再起動しても自動的にアプリケーションが立ち上がります。
バックアップ
データベースをEC2内に構築している場合は、定期的なバックアップ戦略が必須です。
AWSのサービスを使ってスナップショットを取る、または手動でmysqldumpなどを活用するなどの方法があります。
定期的にバックアップが実施されているか確認し、復旧テストも可能なら実施しておきたいところです。
トラブルシュートのポイント
実際に運用を始めると、いくつかのトラブルに遭遇しやすいです。
初心者の皆さんがハマりがちなポイントと対処法をまとめてみます。
ポートが開いていない
「EC2のパブリックIPにアクセスしても反応がない」というときは、セキュリティグループでポートを許可していないケースがあります。
HTTPやHTTPSの設定を確認しましょう。
アプリがエラーで落ちる
RailsのバージョンやGemとの依存関係でエラーが出る場合があります。
bundle install
時のメッセージや、rails s
(ローカル起動時)のログを確認し、Gemをアップデートするなど対応してください。
データベース接続がうまくいかない
本番環境のDB設定がconfig/database.yml
と合っているかをチェックします。
EC2内でmysql -u user -p
のように直接ログインできるか試してみるのも手です。
スケーリングと負荷分散について
アプリが成長して利用者が増えると、1台のEC2インスタンスでは処理が追いつかなくなる場合があります。
そのときはロードバランサーやオートスケーリングを活用すると便利です。
ロードバランサーで処理を分散
AWSの Elastic Load Balancing (ELB) を使えば、複数のEC2インスタンスにリクエストを振り分けられます。
これによって負荷を分散し、サービスの可用性を高めることができます。
オートスケーリングで自動的に台数調整
利用者数が急に増えたときに、自動的にEC2インスタンスを増やすのがオートスケーリングです。
逆にアクセスが落ち着いたら台数を減らして、コストを抑えることもできます。
運用上のセキュリティ対策
クラウド上でアプリを公開するときは、セキュリティを常に意識する必要があります。
OSやソフトウェアのアップデート
EC2インスタンスのOSやライブラリ、RailsのGemなどは定期的にアップデートしましょう。
脆弱性が発見された場合は迅速に対策を施さないと、攻撃のリスクが高まります。
不要なポートの閉鎖
使っていないポートを開いていると、その分だけセキュリティリスクが増えます。
セキュリティグループの設定を見直し、本番運用に必須のポートだけを開くようにしましょう。
アプリ内の認証と権限管理
Railsアプリでもユーザー認証機能や管理画面へのアクセス制限は重要です。
余計な機能を開発途中で無効化したまま公開しないように、コードベースも確認しましょう。
AWSアカウントのルートユーザーをそのまま使い続けると、万が一流出した場合の被害が大きくなります。
利用権限を分割し、必要最小限のIAMユーザーを作る運用をおすすめします。
コスト管理のコツ
クラウドサービスは従量課金制であるため、思わぬコストをかけてしまうケースもあります。
数日間、EC2を起動したまま放置したり、大きいインスタンスタイプを選んだりすると費用が増えるので注意しましょう。
リソースをこまめに確認
EC2インスタンスが不要になったら停止、または削除するとよいでしょう。
また、Elastic IPを使っている場合、インスタンスに紐づいていないと追加費用が発生します。
課金アラートを設定
AWSには請求アラート機能があり、一定の金額を超えそうなときに通知を受け取ることができます。
これを利用すると、使い過ぎを事前に察知しやすくなります。
現場での活用イメージ
実際の業務では、以下のようなシチュエーションでEC2+Railsの構成が使われます。
シンプルな業務アプリ
既存システムと連携する簡単な社内向けアプリをRailsで作り、AWS上で公開する例です。
EC2一台から始めて、必要に応じて機能拡張できます。
スタートアップのMVPプロダクト
早めにサービスを市場に出したいとき、Railsでプロトタイプを開発し、EC2上にすばやくリリースするケース。
プロダクトが成長したらロードバランサーやオートスケーリングを追加し、徐々にスケールアウトします。
趣味や学習目的のWebサービス
個人プロジェクトでも、クラウド上に公開すると実際の運用に近い体験が得られます。
駅すぱあと的な検索サービスや、雑学を投稿するブログサービスなど、多彩な分野で試されています。
デプロイを自動化する方法(簡単な概要)
手動デプロイを繰り返すのは面倒という場合、デプロイツールを導入する選択肢もあります。
以下のようなツールを使うと、EC2インスタンスへのデプロイがスクリプトで自動化できます。
Capistrano
Rails界隈では古くから有名なデプロイツールで、リポジトリからコードを持ってきて、リリースフォルダを切り替えるなどの作業を自動化できます。
サーバーが1台でも複数台でも対応可能です。
CI/CDツールとの連携
GitHub ActionsやCircleCIなどでテストを自動実行した後、合格ならデプロイを走らせるといった仕組みもよくあります。
運用フェーズに入ったら、こうした自動化は検討する価値があります。
実務でよくある疑問とポイント
初心者の皆さんが、いざ本番運用を始めると「これはどうするの?」となりがちなポイントをまとめます。
ドメインをどこで取得すればいいか
AWSのRoute 53で取得してもいいですし、他のレジストラで取得したドメインをRoute 53に移管する方法もあります。
取得先によって運用に大差はないですが、Route 53を使うとAWS内で設定を完結できるメリットがあります。
EC2とRDSの使い分け
データベースをEC2上に入れても問題ありませんが、RDS(Amazon Relational Database Service)を使うとバックアップやスケーリングがやりやすくなります。
ただし、RDSの利用料がかかるため、小規模ならEC2にDBを入れる選択肢もありです。
障害時の対応
インスタンスが落ちたときに備えて、別のインスタンスを用意しておくか、AMI(Amazon Machine Image)を作っておくと復旧が早いです。
アプリやデータベースのバックアップを定期的に取ることも忘れずに。
あらかじめスナップショットやAMIを作成しておくと、トラブル時に素早く復旧できます。
スナップショットはディスクの状態を定期的に保存する仕組みで、AMIはEC2インスタンスのテンプレートのように使えます。
まとめ
AWS EC2でRailsをデプロイする一連の流れを見てきました。
初めてクラウドを使う場合、最初はセットアップやネットワーク周りの設定に戸惑うかもしれません。
しかし、慣れてしまえば自由度が高く、自分の好きな構成でサーバーを運用できるメリットが大きいです。
RailsアプリをEC2に公開すると、Webサービスが本格的に世界へ向けてオープンになります。
セキュリティやコスト管理など、最初は気をつけるべきポイントがたくさんありますが、一歩ずつ対応していけば大丈夫です。
ぜひ本記事を参考に、皆さんのRailsアプリをAWSのクラウド上で稼働させてみてください。
開発から本番まで一気通貫で経験すると、アプリケーション開発の視野が広がります。
そして、その先にはスケーリングや冗長化など、より高度な技術に踏み込む選択肢が見えてくるはずです。