AWS のコストをサクッと削減 ~ EBS 編 ~ - Qiita
AWS のコストをサクッと削減する方法を何回かに渡って書いて行きます。 まずは、EBS編です。 最初に結論 EBSボリュームは gp3 を使おう。gp2よりの上位互換、コストも削減できることがほとんど。 でも、gp3 誕生前から gp2 を使っていたり、EC2 インスタンス作成時のデフォルト設定が gp2 なせいで、あまり gp3 使われていないよね チェックスクリプトを使って、gp3 へ変更した場合のコスト削減効果をサクッとだそう 一気に変換できるなら、変換スクリプトを使って、一気に変換しちゃおう。サービス影響まったくないよ。一気にできない場合でも、1つずつ手作業で変換していこう。 コスト削減効果は、塵も積もれば山となる！ やっていること ボリュームタイプ gp2 と gp3 について知る gp2 の EBS を全部 gp3 に変換した場合のコスト削減幅を知る gp2 を一気に gp3
【Linux】AWSサーバのSSHが落ちた: 備忘録
最近勉強のためにAWSにサーバを立てて色々といじっていたのですが、ちょっとSSHの設定をミスったままsshdを再起動してしまい、sshdが起動せず接続不可能な状況に陥ってしまいました。 AWSはクラウドサーバなのでSSHが使えないと何もできません。設定の修正すらできないので詰み状態です。 とはいえ対処法がないわけではありません。単体で詰みならもう一つ用意してそっちで作業すればよいわけで、 新規インスタンスを作成->問題のサーバのEBSボリュームをAttach->新インスタンスで設定を修正->EBSボリュームを戻す という手順で復旧は可能です。他のPCにディスクを繋げていじる感覚ですね。 実際やってみましたが、注意点がいくつかあります。 Attach時に指定したマウント先と実際のOS上でのマウント先が異なる場合があります (CentOS7では/dev/sdf -> /dev/xvdf) mo
ログインできないec2インスタンスを調査する ｜ DevelopersIO
はじめに サーバを運用しているといろいろなことが起こります。 今回はなんらかのトラブルによりインスタンスが正常に起動しない、 ログインできなくなった場合の対応方法をご紹介します。 障害インスタンンスはAmazon LinuxでrootボリュームはEBSということで話を進めていきます。 障害インスタンスを停止する 正常に起動しない、ログインができないインスタンスをstopします。 サーバにログインできないのでマネジメントコンソールやAPIでstopします。 障害インスタンスのルートボリュームをデタッチする ルートボリュームのEBS IDを確認してVolumesへ移動します。 ・DescriptionのRoot Device 「/dev/xvda」をクリック また後でアタッチし直すのでRoot Device名はメモしておきます。 ・EBS ID をクリック ・Volumesに移動します。 ・A
【遂に来た！】EBS でボリュームサイズを変更できるようになりました（ボリュームタイプ変更も）
こんにちは、藤本です。 待ちに待ったアップデートです。EBS のボリュームサイズ、ボリュームタイプを変更できるようになりました。 Amazon EBS Update – New Elastic Volumes Change Everything 概要 今まで運用中に EBS のボリュームが足りなくなった場合、 一度スナップショットを作成して、 新規ボリューム作成して（この時にボリュームサイズ増加）、 ディスクを差し替える必要がありました。 これにより、インスタンスを停止する必要が発生したり、出来るだけダウンタイムを短くしたくてノーリブートでスナップショットを取ると整合性が担保されない、スナップショット取得から切り替えまでのデータの欠損が発生するなど、多くの問題がありました。 それが今回のアップデートにより、インスタンスの停止する必要がなく、データの欠損が発生することなく、ボリュームサイズを
AWSの失敗談 - しらなくてミスした話 - Qiita
お疲れ様です。 株式会社アカツキでサーバエンジニアとして働いている申です。 はじめに AWSを使用する上で失敗（ミス）した話と、それの原因及び対処方法などを共有し、みなさんは私と同じ過ちを起こさないようにすることが目的です。 Single-AZよりMulti-AZのほうが重い 概要 Single-AZとMulti-AZの両方性能テストする機会があり、Single-AZに比べてMulti-AZの方が性能が悪くていろいろ調べました。（特にコミット遅い） 原因 別AZ間でマスター・スレーブを配置するMulti-AZ構成では、AZ間で通信のレイテンシーが発生するためです。 Multi-AZのRDSにおいて、AZ間のデータレプリケーションは、非同期ではなく、 同期レプリケーション です。 よって、マスターDBに書き込み及びコミットが発生した場合、スレーブDBに書き込むための通信が発生し、それが完了す
AWSでEBSボリュームのサイズを変更する（拡張と縮小）：領域サイズ変更のノウハウ
サーバを運用していると、 ・だんだんデータが増えてきて、ボリュームの残りが減ってきた ・思ったよりもデータが小さくて、無駄に空きが余っている という事があります。 一から構築するシステムなどは、どのくらいデータが増えていくのか緻密に計算するのは困難ですから えいやっ！とある程度決め打ちで領域を切っていく事はよくあります。 そんなときは、領域のサイズを変更しましょう。 AWSでEBSのサイズを変更する EBSボリュームは、一度作成してしまうとサイズの変更はできません。 では、どうやってサイズを変更するかというと、EBSボリュームのコピーボリュームを作成します。 このコピーボリュームを作成するときに、好きなサイズを指定することができるのです。 ※今回紹介する手順は、ルートボリューム(/)以外を対象としています。 ルートボリュームのサイズ変更手順とは異なりますので、ご注意ください。 ======
Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する - Amazon EBS
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Elastic Volumes オペレーションを使用して Amazon EBS ボリュームを変更する Amazon EBS Elastic Volumes では、EBS ボリュームのボリュームサイズの増加、ボリュームタイプの変更、パフォーマンスの調整を行うことができます。インスタンスで Elastic Volumes をサポートしている場合は、ボリュームのデタッチやインスタンスの再起動を行うことなく、これらの操作を行うことができます。したがって、変更の適用中でも、アプリケーションを引き続き使用できます。 ボリュームの設定を変更するための料金は発生しません。ボリューム変更を開始すると、新しいボリューム設定料金が発生します。詳細については、Amazon EBS 料金表ペ
EBSスナップショットからのレストア | DevelopersIO
渡辺です。 今年の11月の北海道は暖かく、スキー場に雪が降ってもレストア（雪解け）してしまいます（T_T 運用設計時、バックアップは検討しているにも関わらず、レストア手順の検討を行っていないケースは稀によくあります。 最悪、バックアップ（EBSのスナップショット取得）さえしておけば何とかなるといえばなんとかなるのですが、レストアが必要な場合に焦らないよう、レストア手順はしっかりと押さえておくべきでしょう。 今回は、EBSのスナップショットからのレストア方法について３パターン紹介します。 新規インスタンスを作成してのレストア ひとつ目の方法は、EBSスナップショットからAMIを作成し、そのAMIからEC2インスタンスを新規に作成する方法です。 AMIを作成する手間はありますが、元インスタンスを残したままにレストアできるため、レストア失敗時のリスクが最小に抑えられること、元インスタンスからのデ
AMIとEBS、スナップショットの関係がよくわかっていなかった話 - endokのブログ
AWSの話。 AWS使っている方であれば当たり前に理解している話かと思います。 AMIとEBS インスタンス起動時にAMIが読み込まれ、 EBSは追加データを保存する場所なのかなと思っていたのだけど、 どこからどこまでがEBSに保存されるんだ？などどいまいち腑に落ちていなかった。 で、ちゃんと調べてみたところ、 Amazon マシンイメージ（AMI）は、ソフトウェア構成（オペレーティングシステム、アプリケーションサーバー、アプリケーションなど）を記録したテンプレートです。AMI から、クラウドで仮想サーバーとして実行される AMI のコピーであるインスタンスを起動します。 (http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html) AMI には次が含まれています。 インスタンス
EC2のスナップショットを自動的にAWS Lambdaで作成する - Qiita
AWS Lambda? サーバレスでプログラムを実行できるようなもの 1 か月 1,000,000 リクエストは無料 今回のような１日１回動かす程度なら無料でずっと使えます 詳しくは → https://aws.amazon.com/jp/lambda/faqs/ やりたいこと Lambdaのスケジュールイベントを使って自動的にEBSのスナップショットを作成する 今回使用する言語はPython スナップショットの対象は、EC2インスタンスのタグに「Backup-Generation」が付いているものとする Backup-Generationの値には、0以上の数字を指定する スナップショットの保存件数は、Backup-Generationの値とする 0のときはスナップショットを作成しない スナップショットの保存件数を超えた場合は、作成日付の古いものから削除する 作成したスナップショットのDe
【新サービス】共有ストレージ(EFS)が発表！EFSの良い点、気になる点 #AWSSummit | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 4月9日(現地時間)に開催れてれいるAWS Summit 2015 San Franciscoで共有ファイルストレージサービスが発表されましたので、ご紹介します。 2015/07/21 Widows用クライアントの記述に誤りがありましたので、内容を修正します。 共有ファイルストレージ AWSでは今までストレージザービスは以下の3種類が提供されていました。 S3：オブジェクトストレージ（OSでマウント不可） EBS：ブロックストレージ（OSでマウント可能） Glacier：アーカイブストレージ（OSでマウント不可） OSでマウント可能な物はEBSのみですが、複数のサーバで共有することができませんでした。そのため高可用性クラスタのシステムを構築するときには、独自にGlusterFSやCephでストレージを構築したり、DRBDでデータレプリケ
EC2上のLinuxのパーティションを拡張する - サーバーワークスエンジニアブログ
いつもいつまでもお世話になっております。サーバーワークス 高橋です。 4月に新卒で入社し、もう半年が経ちました。だらだらしているとあっという間に時間が過ぎていきます。 さて今回はLinuxのパーティションを拡張する方法をご紹介します。 インスタンスの起動からディスクの確認まで まずEBS-Backedインスタンスを立ちあげてみましょう。今回はRootボリュームが80GBの、EBS-Backedインスタンスを立ちあげます。 インスタンスの起動後に lsblk,df コマンドでディスクの状態を見てみましょう。 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 80G 0 disk └─xvda1 202:1 0 6G 0 part / $ df -h Filesystem Size Used Avail Use% Moun
growpartでRHEL EC2のルートパーティションを自動拡張する - サーバーワークスエンジニアブログ
こんにちは、サーバーワークス 技術1課の三井です。 EC2インスタンスの運用中に、ルートボリュームのEBSを拡張しなければならない場面、意外とあるんじゃないでしょうか。EBSの拡張方法についてGoogle先生に訪ねてみたところ、概ね以下のような手順が一般的なようでした。 対象EC2インスタンスにアタッチされているEBSボリュームのスナップショットを作成 1で作成したスナップショットを元に、大きいサイズのEBSボリュームを作成 対象EC2インスタンスから、既存EBSボリュームをデタッチ 2で作成したEBSボリュームを対象EC2インスタンスのルートボリュームとしてにアタッチ 上記の手順自体は問題ないですね。欲を言うとAWS側でEBSをよしなに拡張してくれる機能があったりするとますます我々のゆとり化に拍車が掛かるわけで最高なのですが、なかなかそうも行かないのでしょう。 さて、EBSの拡張には続き
[小ネタ] EC2インスタンスのEBSルートボリュームに自動でNameタグを付与する | DevelopersIO
ども、大瀧です。今回は小ネタを。 EBSはEC2インスタンスで使用するディスクボリュームのサービスで、インスタンス間で付け外ししたりインスタンスの削除時にボリュームを残すようにしたりといった、柔軟なボリューム管理が可能です。ただ、一旦インスタンスから外れてしまうと、どのボリュームを何に使っていたのかわからなくなってしまう恐れがあります。そうならないようボリュームにはNameタグとしてボリューム名を設定することができますが、EC2インスタンスのルートボリュームには既定でタグが付かないため、ついついボリューム名の設定を忘れてしまいがちです。 そこで今回は、インスタンス作成時に自動でルートボリュームにボリューム名を付与する方法をご紹介します。 仕組み インスタンス起動時に、ユーザーデータとして後述の処理を実行するよう設定します。 EC2インスタンス自身のインスタンス名とインスタンスIDを調査 ル
AWSストレージ関連サービスの正しい理解と使い方講座
AWSストレージ関連サービスの 正しい理解と使い方講座 アマゾンデータサービスジャパン ソリューションアーキテクト 小林 正人 本セッションの目的 AWSが提供する様々なストレージ関連サービスの特徴 についておさらいする サービス毎の機能概要やユースケースを正しく理解する ユースケースに応じて最適なストレージサービスを選択 できるようにする 自己紹介 AWSのストレージ関連サービス S3 安価かつ高い耐久性を持つオンライン ストレージサービス Glacier 超安価かつ高い耐久性を持つコールドス トレージサービス StorageGateway オンプレミス環境と連携したバックアッ プ&ストレージサービス EBS 仮想サーバ(Amazon EC2)にマウントで きるディスクサービス Zocalo マルチデバイス対応でフルマネージド型 の文書保存・共有サービス 各サービスの機能と 正しい使い方
知らないあなたは損してる！M1を使ってる人は実はC3じゃなくてM3もおトクだったりする！ - yoshidashingo
cloudpackエバンジェリストの吉田です。 M3もmediumから揃ったことですし、今回はメモリ（RAM）の搭載量を軸に、Tokyo/Linux/オンデマンドの価格を並べてみたいと思います。例によってインスタンスストレージはメリデメ考えるうえでの基準にしてません。さて、何が見えるかな。 RAM：1.7GB タイプ.サイズvCPUCPU種別総ECURAMインスタンスストレージネットワークEBS最適化利用オンデマンド/Linux/Tokyo価格 m1.small 1 Intel Xeon ファミリー 1 1.7 1 x 160 低 -- $0.088 c1.medium 2 Intel Xeon ファミリー 5 1.7 1 x 350 中 -- $0.185 m1.smallを価格で置き換えるインスタンスはない c1.medium -> c3.large $0.007/h(↑) RAM：
AWS EC2インスタンスをPV形式からHVM形式に変換する（≒t1からt2に移行する） - Qiita
参考URL EC2のt1.microをt2.microへ移行する 手作業でPV -> HVMへの変換を行う方法 AWSで仮想化方式 PV(paravirtual) の既存 CentOS AMIを HVMにする 1の作業手順をベースに、少し改変を加えたもの シンボリックリンク追加のところが一番のミソ PV->HVM変換ツール pv2hvm.rbを試してみた ・Rubyスクリプトに変換作業を代行してもらう方法 ・2015-05現在では、sudo gem install aws-sdk --no-ri --no-rdocのところは、aws-sdkのv1を明示してインストールする必要があることに注意（参考：AWS SDK for Ruby V2） ・色々と問題が起きた（ルートデバイス名とブロックデバイス名を合わせないと動かない等）ため採用しなかった EC2編～PVインスタンスからHVMインスタンス
AWSにおける共有コンテンツ参照方式を検討する（"S3をマウントしたい"から始まった議論の一部始終） - Qiita
1.背景 S3の可用性や耐障害性って魅力的！ ただし、NFSマウントできないので、扱う側がS3のAPIで会話しないといけない。 現行では、複数台あるWebサーバがそれぞれファイルサーバへNFSマウントして共有コンテンツを参照していたんですが、S3だとこの構成がとれない。。。 なんとかならないか？そんな理由で始まった検討経緯を共有します。 2.方式案 思いついたのは、大きく以下の4方式。早速各方式について検討開始しました。 ①：S3コマンドで会話するよう、アプリケーション修正（AWS推奨） ②：何らかの形でS3のバケットをNFSマウントする（S3fsとか） ③：インスタンス側にデータを同期する（S3 syncとか） ④：EC2でファイルサーバを構築する（最終手段） 3.検討の流れ やはり最初は教科書通りにやろうとはしましたが、アプリケーション側の修正が大きいので非現実的でした。 ということで
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.suz-lab.com/2011/08/suz-lab-centos-6ebs.html
