eijiコメントはこの投稿ではオフになっています。Image)は、EC2インスタンスの起動に必要な情報を提供するイメージファイルで、OSやアプリケーションなどのルートボリュームのテンプレート起動を許可するAWSアカウントインスタンスにアタッチするボリュームのマッピングなどの情報が含まれている。AMIは、AWSや様々な組織が公開しており、これを利用することができる。等がパッケージに含まれているため便利で使い勝手が良い。自身が作成したインスタンスから生成したAMI(カスタムAMI)を登録/利用することもできる。AMIは同一リージョン内や別のリージョンにコピーを作成することや、他のAWSアカウントとイメージを共有することが可能である。別リージョンにバックアップシステムを構築する場合、AMIのコピーはシステム構築の有用な手段となる。AMIの共有は、公開範囲をパブリックに指定するか、「イメージパーミッションの変更」設定から、許可するAWSアカウントの追加を行う。他者が公開しているAMIを利用する際は、機密データが第3者に送信されていないかや、認証情報が事前に設定されていないかなどを十分に検証する必要がある。CLIのリージョン設定やプログラムのデフォルトリージョン設定をハードコーディングせずに、シェルスクリプト等で変更できるようにしておくと良い。CLIから以下のコマンドを入力する。既存のインスタンス、もしくはスナップショットからAMIを作成することが可能である。AMIの作成は、インスタンス上のすべての動作を停止し、作成プロセス中に一貫した状態が保たれるようにするために、インスタンスをシャットダウンしてから行う。自身で作成したAMIを共有する場合は、以下のように、共有キーやコマンド履歴の削除等の対策を行う。exitストレージストレージは以下の2種類が存在する。どちらのデバイスから起動させるか選択することも可能であるが、高速で永続的なEBS-basedの起動方法が奨励されている。StoreEC2と不可分の内蔵ディスクで、EC2をTERMINATEするとクリアされる。再起動ではクリアされない。インスタンス停止(STOP)することができない。Storeネットワークで接続されたディスクで、EC2とは独立しており、別途課金される。同じアベイラビリティゾーン内でレプリケーションされるため、高い可用性を有している。設定されているので、TERMINATEすると消去されてしまうことに注意が必要である。消去されたボリュームは、ゼロで上書きされて他のアカウントで使用される。機密データを有している場合は、暗号化の検討が必要である。スナップショットを取ることが可能である。スナップショットは、過去のスナップショットとの差分として記録される。スナップショットを取得する際には、EBSをアンマウントすることが望ましい。一方で、スナップショットが開始されれば、スナップショット取得処理中であってもEBSをアタッチして使用して問題ない。インスタンスとEBSボリュームはネットワーク経由で接続されているため、他の通信の影響を受ける。EBS最適化インスタンスを利用することで、インスタンスとEBSとの間のスループットが保証され、他の通信の影響を受けない。汎用SSD(gp2)のパフォーマンスは、ボリュームサイズに比例する。小さい容量のEBSの場合は、I/O性能も低い。したがって、高頻度のI/Oが発生する可能性があるアプリケーションが動作する場合などは、使用する容量が低くても、I/Oの性能を向上させるために、大きな容量を設定しておく必要がある。各ボリュームは、最初に540万I/Oクレジットを受け取り、標準性能を超えたI/O処理(バースト)は、このクレジットから消費されていく。標準性能を下回るI/Oであった場合はクレジットに加算されていく。加算できるクレジットは、初期値と同じ540万I/Oクレジットまで。クレジットが枯渇するとバースト性能を利用できなくなり、標準性能で頭打ちとなる。容量が3333GBに標準性能10000IOPSに達して、容量16TBまでこの性能を維持と定義されている。MB/秒、170GBを超えると160MB/秒である。インスタンス概要EC2は、1500MTUに加えてジャンボフレームをサポートする。ルートデバイスがEBSの場合は、インスタンスタイプを変更することが可能である。このときインスタンスIDは変更されない。パブリックアドレスは変更される。インスタンスタイプを変更する場合は、インスタンスを一度停止する必要がある。インスタンスのライフサイクルインスタンスは、以下のライフサイクルで動作する。インスタンスがStopのときは課金されない。EBSボリュームに対する課金は継続される。時期やタイミングによっては、EC2のリソースが枯渇し新たなインスタンスが起動できない場合もあるので、リソースを確保しておきたい場合は、インスタンスを作成し、使用するまで停止しておくとよい。インスタンスを再起動した場合は、同一ハードウェアで起動し、ボリュームやネットワーク設定等は前回起動の情報を保持する。インスタンスを一度停止し起動した場合は、別のハードウェアで起動し、これらの情報は引き継がれない。ハードウェア障害が発生した場合など、明示的に別のハードウェアでインスタンスを起動する必要がある場合には、再起動ではなく停止と開始を行う。インスタンスの公開鍵EC2に使用するSSHキーペアは、リージョンごとに別管理であるため、他のリージョンでEC2を使用する場合、通常は別途新たにキーペアを作成する必要がある。これでは管理する際に問題が生じるので、共通のキーペアで運用すると良い。手元の秘密鍵から公開鍵を生成し、AWSマネージメントコンソールから登録を行う。UTC(協定世界時間)時間帯に設定されている。他のタイムゾーンを設定する場合は、起動時に以下を実行する。/etc/localtimeインスタンスの復旧ハードウェア障害が発生した場合に、自動的に再起動を行うことが可能なCloudWatchアラームを作成することができる。復旧したインスタンスは、ボリュームやネットワーク設定等は前回起動の情報を保持する。自動復旧は、1インスタンスにつき1日3回までである。AWSがインスタンスの再起動や停止/開始、メンテナンスを事前に予告して実施する場合がある。再起動には、自身でスケジューリング可能なインスタンスリブートと、強制的に再起動されてしまうシステムリブートがある。ネットワークや電源のメンテナンスが実施される場合もある。インスタンスメタデータ実行中のインスタンスのメタデータは、以下のURLから取得することが可能である。AMIのIDや、ホスト名、リージョン、ネットワーク設定、セキュリティグループ名などを取得することができる。eijiコメントはこの投稿ではオフになっています。ファイル構成クラスファイルはヘッダファイルとソースファイルより構成される。init]などとしスーパークラスの初期化を行う。(1)アーカイブ2020年2月2020年1月2019年12月2019年11月2019年10月2019年9月2019年8月2019年4月2019年3月2019年2月2019年1月2018年12月2018年11月2018年4月2017年4月2016年12月2016年11月2016年10月2016年8月2016年5月2016年4月2016年3月2016年1月2015年12月2015年11月2015年10月2015年9月2015年5月2015年4月2015年2月2012年5月2012年4月2011年6月メタ情報ログイン投稿フィードコメントフィードWordPress.org。