AWS 上で稼働する WordPress に 特化したホスティングサービスです。 Amimoto は、AWS（Amazon Web Services）上で稼働する WordPress に特化したソリューションです。経験豊富な WordPress の専門チームと AWS プロフェッショナルによる構築とメンテナンスが行われ、サーバサポート、定期的なセキュリティ監査、自動スケーリングなどの機能を持ち、どんなトラブルが発生しても迅速に復旧する体制を整えています。
AWSで下記の４つの概念の関係を明確に教えていただけないでしょうか？ - Instance - Volume - Snapshot - AMI 個々の概念は下記のように理解しています。 - Instance(いわゆるサーバ、ホスト) - Volume (ブロック型ストレージ。HDDのようなもの) - Snapshot (S3上のオブジェクト) - AMI (仮想マシンのひながた) しかし４つの関係がわからなくなることがよくあります。 例えばVolumeとSnapshotはそれ単体で存在できるのでわかりやすいのですが、AMIってそれだけでは存在しなくて、Snapshot(またはVolume?)と表裏一体だったりしますよね。 ということはAMIとは必ずAMI on Snapshot またAMI on Volumeということになるのでしょうか。 また、EBS root Instanceは、「ルー
ども、大瀧です。 Linuxのメモリ管理で欠かせないのがswapですよね。EC2のディスク管理には独特な仕様があるのでその辺りを踏まえつつ、EC2(Linux)でどのようにswap領域を用意するのが良いのかまとめてみたいと思います。 理屈をこねながらの解説になるので、先に本エントリーの結論を。 公式AMIにはswap領域が含まれない m1.small、c1.mediumには900MBのスワップ領域がおまけでついてくる(Amazon Linux AMIであれば、Cloud-initによって自動マウントされる) swap領域には、インスタンスストア(別名Ephemeral Disk)を使うべし では、それぞれ見ていきます。 公式Linux AMIの初期構成にはswapパーティションが無い Amazonから提供される公式のLinux AMIのブートディスクには、swapパーティションが含まれてい
ども、大瀧です。みなさん、EC2をバリバリ使ってますか?使いたいときにすぐ使える仮想マシンとして、開発・検証から本番まで幅広く活用されていると思います。 日頃EC2を業務で運用する中で、EC2インスタンスをコピーすると意図しない環境設定に変わってしまうというトラブルが度々あり、cloud-initというツールに拠ることがわかってきました。 「EC2インスタンスのコピーなんて、一旦インスタンスを作成したあとはあまりやらないのでは?」と思われがちですが、EC2独特の制限などもあり、実際の運用では思ったよりも頻繁にインスタンスのコピーが必要になります。インスタンスのバックアップ&リストアなどはイメージしやすいと思いますが、それ以外にも意外なケースとして以下があります *1。インスタンスのコピーは、AMI(Amazon Machine Image:インスタンスのバックアップ)を取得し、新規インスタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
