AWSCLI describe-instances でよく使うコマンドまとめ【随時更新】

EC2インスタンスの一覧を見るAWS CLIのdescribe-instancesコマンドでよくつかっているコマンドを紹介します。

リージョン内のすべてのインスタンスの情報を取得

aws ec2 describe-instances

特定のインスタンスIDの情報を取得

aws ec2 describe-instances --instance-ids i-xxxxxxxx

複数指定の場合はスペース区切りでインスタンスIDを列挙する。

aws ec2 describe-instances --instance-ids i-xxxxxxxx i-yyyyyyyy i-zzzzzzzz

起動中のインスタンスのみ取得

aws ec2 describe-instances --filter "Name=instance-state-name,Values=running"

停止中の場合はValues=stoppingで取得可能。
他にもpending,shutting-down,terminated,stoppingが指定可能です。

特定のインスタンスタイプのみ取得

aws ec2 describe-instances --filter "Name=instance-type,Values=t2.micro"

特定のVPC内のインスタンスのみ取得

 aws ec2 describe-instances --filter "Name=vpc-id,Values=vpc-xxxxxxxx"

タグが一致するものを取得

以下の例だとNameタグがwawawaのインスタンスの情報を取得します。

aws ec2 describe-instances --filter "Name=tag:Name,Values=wawawa

リージョン内のインスタンスIDの一覧を取得

aws ec2 describe-instances  --query 'Reservations[].Instances[].InstanceId'

インスタンスIDとインスタンスタイプを取得

aws ec2 describe-instances --query 'Reservations[].Instances[].{instanceid:InstanceId,instancetype:InstanceType}'

インスタンスIDとNameタグを取得

aws ec2 describe-instances --query 'Reservations[].Instances[].{instanceid:InstanceId,Tags:Tags[?Key==`Name`].Value|[0]}'

インスタンスIDとそれにアタッチされているEBSを取得

aws ec2 describe-instances --query 'Reservations[].Instances[].{instanceid:InstanceId,ebs:BlockDeviceMappings[].Ebs.VolumeId}'

インスタンスIDとそれにアタッチされているセキュリティグループを取得

aws ec2 describe-instances --query 'Reservations[].Instances[].{instanceid:InstanceId,security_groups:SecurityGroups[].GroupName[]}'

インスタンスIDとプライベートIPアドレスを取得

aws ec2 describe-instances --query 'Reservations[].Instances[].{ipaddress:NetworkInterfaces[].PrivateIpAddress[]',instanceid:InstanceId}

昇順でソートしてインスタンスIDを取得

aws ec2 describe-instances --query 'sort(Reservations[].Instances[].InstanceId)'

降順でソートしてインスタンスIDを取得

aws ec2 describe-instances --query 'reverse(sort(Reservations[].Instances[].InstanceId))'

インスタンスIDで昇順でソートして、インスタンスIDとプライベートIPを取得

aws ec2 describe-instances --query 'sort_by(Reservations[].Instances[].{ipaddress:NetworkInterfaces[].PrivateIpAddress[],instanceid:InstanceId,name:Tags[?Key==`Name`].Value|[0]},&instanceid)'

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

S3で一定期間が経過したファイルをGlacierに格納する

S3上にアクセスログを定期的に書き込むようなシステムがあったとして、古いアクセスログも残しておこなければならないんだけどそんなに頻繁に利用するわけではないから安価に保存したいといった場合があります。

これらを実現するために S3バケットにライフサイクルルールを設定し、古いログを削除するよう設定します。

ライフサイクルルールの設定手順

ライフサイクルルールの設定はバケット単位で設定します。

バケットの「管理」の「ライフサイクル」から「ライフサイクルルールの追加」を選択します。

ライフサイクルルールの「ルール名」に任意のルールを設定します。
フィルターの追加も任意で構いません。
これを設定するとtest/ディレクトリ以下のオブジェクトにのみライフサイクルを設定するといった設定ができます。

移行の設定で「現行バージョン」にチェックを入れ、オブジェクト作成から「AmazonGlacierへの移行の期限」を選択します。
オブジェクト作成からの日数にGlacierへ移行するまでの日数を入力します。
今回は確認のために1日としています。

設定の失効はとくに何も設定せずそのまま「次へ」でかまいません。

設定の内容が正しいことを確認して「保存」します。

S3の設定は以上で完了です。

実行結果

これが
こうなります。

ストレージクラスがGlacierとなっているのがわかります。
Glacierに新たにボールドが作成されるわけでなく、S3から各オブジェクトを確認することになります。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Ubuntu16.04で拡張ネットワーキングをONにする【AWS】

EC2で拡張ネットワーキングを有効化する設定方法をご紹介します。

そもそも拡張ネットワーキングとは？

拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。

Linux の拡張ネットワーキング - Amazon Elastic Compute Cloud

ということです。
つまり有効にするだけで通信が早くなるというすぐれものです。

設定方法

Ubuntuでネットワーキングを有効にする方法を記載します。

環境

• Ubuntu Server 16.04 LTS (HVM), SSD Volume Type - ami-15872773

ネットワークインターフェイスドライバーを確認する

ethtoolコマンドでネットワークインターフェースで利用されているドライバーを確認します。

driverの箇所がixgbevfとなっていたらOKです。「拡張ネットワーキングの設定を行う」まで読み飛ばしてもらって構いません。
以下の場合はvifとなっているのでネットワークインターフェースの設定を実施する必要があります。

$ ethtool -i ens3
driver: vif
version:
firmware-version:
expansion-rom-version:
bus-info: vif-0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

ixgbevfモジュールをインストールする

まずixdbevfのモジュールのソースをwgetでダウンロードします。

wget "sourceforge.net/projects/e1000/files/ixgbevf stable/2.16.4/ixgbevf-2.16.4.tar.gz"

ダウンロードしてきたファイルを解凍します。

tar -zxvf ixgbevf-2.16.4.tar.gz

パッケージを/usr/srcの移動させます。
dkmsがこのパッケージをビルドできるようにするためです。

sudo mv ixgbevf-2.16.4 /usr/src/.

dkms.confを作成して以下のように値を設定します。
そのままコピーで大丈夫です。

sudo vim /usr/src/ixgbevf-2.16.4/dkms.conf

PACKAGE_NAME="ixgbevf"
PACKAGE_VERSION="2.16.4"
CLEAN="cd src/; make clean"
MAKE="cd src/; make BUILD_KERNEL=${kernelver}"
BUILT_MODULE_LOCATION[0]="src/"
BUILT_MODULE_NAME[0]="ixgbevf"
DEST_MODULE_LOCATION[0]="/updates"
DEST_MODULE_NAME[0]="ixgbevf"
AUTOINSTALL="yes"

dkmsを利用してモジュールを追加します。

sudo dkms add -m ixgbevf -v 2.16.4

モジュールをビルドします。

sudo dkms build -m ixgbevf -v 2.16.4

モジュールをインストールします。

sudo dkms install -m ixgbevf -v 2.16.4

拡張ネットワーキングの設定を行う

インスタンスに拡張ネットワーキングの設定を行うには、AWSCLIで以下のコマンドを実行します。

$ aws ec2 modify-instance-attribute --instance-id i-xxxxxxxxxxxxxxxxx --sriov-net-support simple

以下のAWSCLIを実行し、SriovNetSupportのValueがsimpleとなっていればOKです。

$ aws ec2 describe-instance-attribute --instance-id i-xxxxxxxxxxxxxxxxx --attribute sriovNetSupport
{
    "SriovNetSupport": {
        "Value": "simple"
    },
    "InstanceId": "i-xxxxxxxxxxxxxxxxx"
}

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

S3で一定期間が経過したファイルをライフサイクルで削除したい

S3上にアクセスログを定期的に書き込むようなシステムがあったとして、古いアクセスログを自動的に消す仕組みを作ってみたいと思います。

これらを実現するために S3バケットにライフサイクルルールを設定し、古いログを削除するよう設定します。

ライフサイクルルールの設定手順

ライフサイクルルールの設定はバケット単位で設定します。

バケットの「管理」の「ライフサイクル」から「ライフサイクルルールの追加」を選択します。

ライフサイクルルールの「ルール名」に任意のルールを設定します。
フィルターの追加も任意で構いません。
これを設定するとtest/ディレクトリ以下のオブジェクトにのみライフサイクルを設定するといった設定ができます。

以降の設定は今回はそのまま「次へ」を選択します。
Glacierなどに以降するライフサイクルを設定する場合にはここで設定を行います。

ライフサイクルルールで削除の設定を行います。
「オブジェクトの現行バージョンを執行する」の箇所が重要です。
たとえば30日より前のログが不要である場合には30を設定します。
今回はテストのために1日経過したオブジェクトを削除するように設定しています。

設定を確認して、「保存」を選択します。

実行結果

これが

一日後…

「s3_index.html」が削除されていることがわかります。

まとめ

ライフサイクル機能をつかうことで手動で過去ログを削除するといったわずわらしさから開放されます。

消し忘れや誤った削除も発生しませんので是非活用してみてください。

Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS)

S3で有効期限付きの署名付きURLを作成する

S3で署名付きURLを利用してユーザごとに別々のURLを発行できるようにしてみたいと思います。

手順

対象のディレクトリに対するアクセス権を無効にする

まずは署名付きURLを利用するコンテンツを配置するディレクトリに誰もアクセス出来ないようにアクセス権を設定します。

基本的にはなにもしなくてOKです。
バケットポリシーに何も指定しなければ暗黙的拒否扱いになり、オブジェクトへのアクセスは拒否されます。

署名付きURLをつくる

署名付きURLを作成していきます。
例として「/wawawa/s3_index.html」というコンテンツに署名URLを作成していきます。

署名付きURLはAWSCLIを使うことで作成できます。
以下のようなコマンドを実行します。

aws s3 presign s3://kabegiwa-secret/wawawa/s3_index.html --expires-in 3600

実行すると以下のようなURLが応答されます。
URLはコマンドを実行するたびに新しいものが生成されます。

https://kabegiwa-secret.s3.amazonaws.com/wawawa/s3_index.html?AWSAccessKeyId=AKIAJ4M6D6DG7LQHQ53A&Expires=1511184525&Signature=mFMiY7%2BMoJm%2FOsWB1D6Wp0jWqj8%3D

ちなみにコマンドのオプションの--expires-in 3600はこの署名付きURLは3600秒有効だという意味です。
URLの生成から3600秒=1時間経過するとこのURLは無効となり、アクセスできなくなります。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

S3へのアクセスログを記録する

S3にはアクセスログを記録する機能があります。
その機能を有効にすると、別のS3バケットにログを記録することができます。

手順

ログ格納用のバケットを作成する

まずはログを格納するためのバケットを作成します。
バケットの名前はなんでもよいです。
今回は「kabegiwalog」という名前のバケットを作成しました。

バケットのログ記録を有効にする

アクセスログを記録したいバケットで「ログ記録」機能を有効にします。

アクセスログを記録したいバケットに移動し「プロパティ」タブを選択、「サーバーアクセスのログ記憶」を選択して、さきほど作成したバケットをターゲットバケットに指定します。
ターゲットプレフィックスは特に指定がなければそのままで構いません。

アクセスログを確認してみる

上記の設定をして1時間くらいするとログが書き出されるようになりますのでしばらく待ちます。

1時間後…
アクセスログが無事格納されました！

ログの中身については以下の公式ドキュメントが役に立ちます。

docs.aws.amazon.com

まとめ

S3でアクセスログを記録することができました。
ただ、このログの記録はベストエフォートであり、確実に記録される保証はありません。(実際はほとんど欠落することはないようですが)

即座に保存されるわけではなく、保存されるのにしばらく時間がかかるのもデメリットです。

ですが、かんたんでログの記録そのものには料金はかかりませんので、検討してみるのもいいかもしれません。

Amazon Web Services パターン別構築・運用ガイド 一番大切な知識と技術が身につく

S3と独自ドメインでウェブサーバを構築する

S3にはストレージとして利用する以外にもうひとつの使い方があります。
それは静的コンテンツを公開するWebサーバとしての使い方です。

S3には静的ウェブホスティング機能というものがあり、この機能を有効にするとS3に保存したファイルをWebサイトとして公開することができます。

手順

独自ドメイン名でS3バケットを作成する

独自ドメイン名でS3バケットを作成します。
たとえば当ブログのドメイン名でもある「www.kabegiwablog.com」で運用するのであれば「www.kabegiwablog.com」というバケットを作成します。

静的ウェブホスティングを有効にする

作成したバケットのプロパティを開き「Static website hosting」を選択します。
設定項目が開くので「このバケットを使用してウェブサイトをホストする」を選択し、「保存」します。
「インデックスドキュメント」と「エラードキュメント」はそれぞれ「index.html」と「error.html」で構いません。

バケットポリシーを設定する

現時点ではアクセス許可をだれにもしていない状態ですのでバケットポリシーでオブジェクトへのアクセス許可を与えます。

バケットの「アクセス権限」から「バケットポリシー」を選択してバケットポリシーエディターに以下のように入力します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.example.com/*"
        }
    ]
}

"Resource": "arn:aws:s3:::www.example.com/*"の箇所は自分のバケットのARNに読み替えてください。

実際に設定されたかどうか確認してみます。
S3に任意の内容の「index.html」ファイルをアップロードし、S3のエンドポイントのURLを指定してブラウザでアクセスしてみると、以下のようにファイルの中身が見れるはずです。

S3のエンドポイントのURLは静的ウェブホスティングを有効にした際と同じく、バケットのプロパティを開き「Static website hosting」を選択したところに記載があります。

Route53で独自ドメインを設定する

S3へのアクセスはできるようになりました。
つづいて独自ドメインでアクセスできるように設定します。

具体的にはAレコードのAlias機能を利用します。

Route53で「Create Record Set」を選択して、それぞれ以下のように設定します。

• Name - www.
• Type - A - IPv4 address
• Alias Target - バケットの一覧が出てくるので今回作成したバケットを選択

　

以上で設定は完了です。
さて、独自ドメインでアクセスしてみると、S3上のオブジェクトにアクセスできるようになっているはずです。

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

Amazon Linux で snmpwalk を利用する

Amazon Linuxでsnmpwalkを利用しようとしたときにCommand not foundって言われたので簡易メモ。

インストール

sudo yum -y install net-snmp-utils

確認

snmpwalk -v 2c -c public localhost

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

Windows Server 2016 にSNMPサービスをインストールする(英語版)

zabbix 3.0でWindows Server 2016 SNMPサービスを入れる方法をご紹介します。

環境

以下のAWS環境標準のWindows Server 2016のAMIを利用。

Microsoft Windows Server 2016 Base - ami-4325fa25
Microsoft Windows 2016 Datacenter edition. [English]

手順

Windows Serverの準備

SNMPサービスをインストールする

左下のWindowsマークのスタートメニューをクリックし、「Server Manager」を選択します。

「Dashboard」から「Add role and featrures」を選択します。

「Next」を選択します。

そのまま「Next」を選択します。

ここもそのまま「Next」を選択します。

ここでも「Next」を選択します。

中盤までスクロールして「SNMP Service」にチェックをいれます。

するとウインドウが開くので、「Add Features」を選択します。

「Next」を選択します。

「Install」を選択します。

「Close」で閉じます。
以上でSNMPサービスのインストールは完了です。

SNMPサービスの設定

「Server Manager」の右上の「Tools」をクリックし、「Services」を選択します。

一覧の中から「SNMP Service」を探して、右クリックで「Properties」を選択します。

「Secrurity」タブを選択し、「Accept community names」の「Add」ボタンを押下します。

「Community rights」を「READ ONLY」にし、「Community Name」になにか任意の名前を入力します。
入力したら「Add」を選択します。

「Accept SNMP packets from any host」をのラジオボタンをONにします。
そして「OK」を押せばSNMPの設定は完了です！

まとめ

以上でWindows Server 2016(英語版)へのSMPサービスのインストールすることができました。

SNMPをつかってZabbixなどの監視装置と連携することも可能です。
それらについてはまた別記事でご紹介しようと思います。

ひと目でわかる Windows Server 2016

Windows Server 2016 で拡張ネットワーキングをONにする【AWS】

AWS上のWindows Server 2016で拡張ネットワーキングをONにして見たいと思います。

そもそも拡張ネットワーキングとは？

拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。

Linux の拡張ネットワーキング - Amazon Elastic Compute Cloud

ということです。
つまり有効にするだけで通信が早くなるというすぐれものです。

拡張ネットワーキングを有効にする手順

環境

• Windows Server 2016 Base
• m4.large

Intelネットワークドライバをインストールする

以下のURLからIntelネットワークアダプタドライバーをダウンロードします。

downloadcenter.intel.com

「ProWinx64.exe」というファイルがダウンロードされたかと思います。
それを「ProWinx64.zip」に拡張子を変更します。

「ProWinx64.zip」を展開します。

コマンドプロンプトを開き、「ProWinx64.zip」を展開したフォルダに移動して以下のコマンドを実行してINFファイルを追加/インストールします。

pnputil -i -a PROXGB\Winx64\NDIS65\vxn65x64.inf 

Windows Server をシャットダウンします。

拡張ネットワーキングを有効にする

ローカルのPCなどの別の環境でいかのコマンドを実行して拡張ネットワーキングを有効にします。
Trueと応答されればOKです。

AWSCLIの場合

aws ec2 modify-instance-attribute --instance-id  i-xxxxxxxxxxxxxxxx --sriov-net-support simple

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxx -SriovNetSupport "simple"

拡張ネットワーキングが有効か確認する

デバイスマネージャーを開き、「ネットワークアダプター」の下に「Intel(R) 82599 Virtual Function」があることを確認します。

インスタンスに拡張ネットワーキングの属性が設定されている確認します。
"Value": "simple"となっていればOKです。

AWSCLIの場合

 aws ec2 describe-instance-attribute --instance-id i-xxxxxxxxxxxxxxxx --attribute sriovNetSupport --query 'SriovNetSupport'

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxxx -SriovNetSupport "simple"

上記2つがOKであれば拡張ネットワーキングは有効化されています。

まとめ

有効にするだけで通信がはやくなるのでどんどん設定していきましょう！

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWSのキー管理を比較してみた【KMS/CloudHSM】

AWSで利用できるキー管理のそれぞれの利点についてまとめてみました。

KMS

キーの保存場所/制御方法

• AWSにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 定義ポリシーをAWSが実行してキーの仕様を制御する
• AWSが責任をもって実行する

料金

• キー単位と使用量単位で料金がかかる

CloudHSM

キーの保存場所/制御方法

• AWS内で実行されるHSMにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 自作のコードまたはSafenet APIでキーを管理することができる
• 自分たちで責任を持って管理する

料金

• 1時間あたりの課金
• CloudHSM Classicを利用する場合は前払い料金が発生する

3rdparty製ツール(AWS MarketPlace)

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• 1時間あたりの課金または1年単位での支払い

自作ツールでの管理

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• ツール(ベンダー)による(場合によっては安くすむかも)

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

VGWのパス決定の優先順位まとめ

VGWの外のトラフィックのパスに複数のオプションがある場合は、以下のようにパスが特定されます。

パス決定の優先順位

1→2→3→4の順にパスが特定されます。

1. 範囲の狭いIPアドレスプレフィックス
   172.24.0.0/16より172.24.1.0/24より172.24.1.1が優先される
2. 静的ルートを使用したVPN接続
3. Direct Connectのパス
4. AS_PATHを利用した動的(BGP)ルートを使用したVPN接続

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWS Well-Architected Framework 5つの柱まとめ

AWS Well-Architected Framework 5つの柱について自分なりにまとめてみました。

セキュリティ

• すべてのレイヤーをセキュリティで保護する。
• リソースの変更やインスタンス内部へのログインなどログを記録する。
• セキュリティの確保を自動化させる。

信頼性

• 障害からの復旧、回復が迅速にできるようにする。
• 障害からの復旧を自動化する。
• 可用性を向上するため適切にスケーリングを設定する。
• 長年の勘とかに頼らない。

パフォーマンス効率

• 最新の技術を導入してその恩恵をうける。
• 分単位でデプロイを行う。
• サーバレスアーキテクチャを利用する。
• 適切な技術を導入する。

コストの最適化

• 不必要なコストを排除する。
• データセンターへの投資をやめる。
• 支出を分析する。
• マネージドサービスを利用して使用量を抑える。

運用上の優秀性

• コードで運用作業を実施する。
• 変更処理を自動化する。
• 想定外の障害などに対応するためのテストを行う。
• 手順は常に最新に保つ。

参考資料

https://aws.amazon.com/jp/architecture/well-architected/ http://media.amazonwebservices.com/jp/wp/Well-Architected_Whitepaper_v2_JP.pdf

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSの設計におけるベストプラクティス

AWSでの設定におけるベストプラクティスみたいなものを自分なりにまとめてみました。

スケーラビリティを確保する

• インフラをシームレスにスケールできることがAWSの利点。
• AWSのすべてのレイヤーでスケーラビリティを活用するべき。
• 理想的なシステムはスケールアウトするだけでなく、不要なインスタンスが稼働し続けないようにシステムをスケールダウンするようなシステム。

インフラ環境を自動化する

• リソースのプロビジョニング、終了、設定は可能な限り自動化する。
• 例えば異常のあるリソースの検出と代替リソースの起動を自動化する。
• リソースの変更時に通知を受信するようにする。

リソースを使い捨てにする

• 各インスタンスの設定を同一にし、リソースのデプロイを自動化する。
• 使用していないリソースは削除する。
• 固定IPアドレスはできるだけ利用せず、新しいIPアドレスに自動的に切り替える。
• 古いインスタンスと新しいインスタンスをかんたんに置き換えられるようにしておく。

疎結合化する

• 独立したサービスでアーキテクチャを設計する。
• システムのレイヤー間にAWSのマネージドサービスを活用して疎結合化させる。
• ELBとSQSを利用するとかんたんに疎結合に近づくことができる。

AWSのサービスを最大限利用して設計する

• すべてをEC2インスタンスのサーバの内部で実施するのではなく、AWSサービスを利用することを検討する。
• マネージドサービスを利用してサーバレス化させる。

データの特性にあったデータベースを選択する

• 要件にあったデータベースを適切に選んで利用する。
• Read/Writeやストレージのサイズ、レイテンシーなどを考慮する。
• データベースにあわせて業務を決めるのではなく、業務をもとにデータベースを洗濯する。

SPOFをなくす

• 一箇所の障害によってシステム全体が停止するのを避けるため、冗長性を保たせる。
• 物理ハードが故障した場合でもサービスを維持し続けられるように設計する。

コスト効率をあげる

• コストを最適化する。
• リソースのサイズやタイプが適切かどうか確認する。
• 使用されていないリソースを終了する。
• マネージドサービスを積極的に利用し、利用料を下げる。

キャッシュを利用して通信料を抑える

• CloudFrontなどのキャッシュサービスを利用する。
• キャッシュを利用することで通信コストやレイテンシーなどを軽減することができる。

セキュリティを確保する

• ユーザには権限は利用する最小の権限しか与えない。
• データのやり取りは暗号化する。
• アクセスログを記録する。

参考資料

AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

EC2Schedulerをつかってみる

今回はEC2SchedulerというAWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールを利用してみたいと思います。

EC2Schedulerとは?

AWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールです。
EC2に起動停止の時間などを記載したタグをつけることで、インスタンスを毎日自動的に起動/停止してくれます。

EC2Schedulerをつかってみる

実際にEC2Schedulerを使ってみたいと思います。

CloudFormationテンプレートのダウンロード

以下からec2-scheduler.templateをダウンロードします。

docs.aws.amazon.com

CloudFormationスタックをつくる

マネジメントコンソールのCloudFormationから「スタックの作成」を選択します。

「テンプレートの選択」でさきほどダウンロードしてきたec2-scheduler-.templateを選択します。
選択したら「次へ」すすみます。

「スタックの名前」に任意の名前をつけます。
「パラメータ」はデフォルトのままいったん「次へ」でかまいません。

オプションも一旦そのまま「次へ」でかまいません。

CAPABILITYの「AWS CloudFormationによってIAMリソースが作成される場合があることを承認します」にチェックをいれ、「作成」を選択します。

スタックが作成されるのでしばらく待ちます。
「状況」が「CREATE_COMPLETE」となったら完了です。

インスタンスにEC2Schedulerのタグをつける

EC2Schedulerでスケジュール起動停止したいインスタンスを選択し、タグを設定します。
設定するタグの例は以下の表に示します。
時間はUTCでしか記載できないので注意が必要です。

EC2Schedulerのタグの例

タグ値の例	説明
0800;1800;utc;all	インスタンスは08:00に開始し、18:00にすべての曜日に停止します。
1000;1700;utc;weekdays	インスタンスは1000から開始し、月曜日から金曜日の17:00に停止します。
1030;1700;utc;mon,tue,fri	インスタンスは1030に開始し、月曜日、火曜日、金曜日にのみ17:00に停止します。
0815;1745;utc;wed,thu	インスタンスは0815に開始し、水曜日と木曜日のみ1745に停止します。
none;1800;utc;weekdays	インスタンスは、月曜日から金曜日の18:00に停止します。インスタンスは手動で起動する必要があります。
0800;none;utc;weekdays	インスタンスは月曜日から金曜日の08:00に開始します。インスタンスを手動で停止する必要があります。
none;none;utc;weekdays	インスタンスは手動で開始および停止する必要があります（自動アクションは実行されません）。
0800	インスタンスは08:00に開始され、Amazon DynamoDBテーブルに格納されているデフォルトのアクティブ日にデフォルトの停止で停止します。
0800;1800	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
0800;1800;utc	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
default	インスタンスは、デフォルトのスケジュールで開始および停止します。
True	インスタンスは、デフォルトのスケジュールで開始および停止します。
EMPTY	インスタンスに対して実行されるアクションはありません。
Random String	インスタンスに対して実行されるアクションはありません。

以下公式ドキュメントから抜粋
Automated Deployment - EC2 Scheduler on AWS

EC2Schedulerが実行されたか確認する

マネジメントコンソールの「CloudWatch」から「メトリクス」、「EC2Scheduler」と選択します。

「Region」を選択します。

するとEC2Schedulerを設定したインスタンスのリソースIDを設定したが表示されるので、EC2Schedulerの実行状態を確認したいインスタンスのリソースIDを選択します。

グラフが0か1になっているのがわかるかと思います。
0が停止で1が起動です。
今回は1405;1420;utc;weekdaysと設定してみましたので設定通り14:05起動(1)、14:20に停止(0)されていることがわかります。

まとめ

EC2Schedulerをつかってインスタンスの自動起動停止を実施してみました。
夜間はインスタンスを停止するなど、コスト削減の基本ですのでこういったものを利用してみるのもいいかもしれません。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~