EC2において、大きいインスタンスを借りると維持費が高くなります。
従って、やむを得ずメモリが少ない状態で稼働させざるを得なくなるかもしれません。その場合、多くの場合はスワップファイルを作成して対応することになるかもしれません。
スワップファイルの欠点
スワップファイルは確かに手ごろな解決方法です。しかし、スワップに関しては大量のディスクI/Oが発生することになります。これにより、次の問題が発生します。
I/Oが集中することにより、GP2ボリュームではI/Oクレジットが枯渇する、IO1ボリュームではプロビジョニングしたIOPSを無駄に消費される問題が発生します。マグネティックであれば、過剰なI/Oにより高額請求を引き起こす恐れもあります。
スワップは別のEBSへ
この方法は、あくまで最小限の費用でパフォーマンス低下を軽減する方法でしかありません。
EBSを別途作成し、スワップをそちらへ移動することでI/Oの集中を防止できます。
また、この方法でI/Oの発生状況を個別に監視することもできます。多くの場合、1GiBのGP2ボリュームで十分かと思います。
この方法でのスワップパーティションの作成方法については、次のページを参考にしてください。
https://begi.net/read/base/09.html
なお、EC2では基本的にファイルシステムはUUIDで指定することになっています。デバイスファイルで指定すると、再起動時に順番が変更され、EC2インスタンスが起動しなくなる恐れがあります。lsblk -fコマンドによりUUIDを調べ、代わりにそのUUIDを/etc/fstabにUUID=の形式で指定してください。
I/Oが集中するファイルシステムも
I/Oが集中する恐れのあるファイルシステムに関しても、別のEBSを用意することをお勧めします。具体的には、データベース等が該当します。
大量の読み書きが発生する部分だけにIO1を採用し、遅延を避ける設計も可能です。逆に、ほとんどI/Oが発生しない場合はマグネティックやSC2、ST1ボリュームを採用することもできます。
すべてGP2やIO1で運用することもできますが、コストを考えると組み合わせて運用するほうが良いかと思います。
マグネティックをシステムボリュームに使用することは推奨していません。多量のI/O操作の発生により課金が高額となる、起動時間が長くなるといったことが想定されるためです。