やーまんぶろぐ

気が向いた時にだけ書くブログ

EC2インスタンスの起動停止スケジューラー(CloudFormation)

AWS

起動時間、停止時間、タグを指定するだけで簡単に動きます。

下記リンクを参考にしました。
dev.classmethod.jp

CloudFormationを起動

https://console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#/stacks/new?stackName=EC2StateScheduler&templateURL=https:%2F%2Fs3.amazonaws.com%2Fcm-public-cfn-templates-fujimoto%2Fec2-state-scheduler.yml

設定入力

平日9:00(JST)起動、平日22:00(JST)停止の例を記載します。
設定はUTCなので注意が必要です。

以下、設定です。

StartSchedule 0 0 ? * MON-FRI *
StopSchedule 0 13 ? * MON-FRI *
Ec2TagKey XXXX
Ec2TagValue YYYY

設定変更

起動時間、停止時間を変更したい場合はCloudWatch Eventsのルールからスケジュールを変更することが可能です。

タグはLambdaの環境変数から変更することが可能です。

JAWS DAYS 2018 参加レポート

参加レポート AWS

去年に引き続き今年も参加。

AWSのコミュニティが集まるイベントで、今年は1800人を超えたそうです。

海外コミュニティからの参加も多く、AWSのChiefエバンジェリストであるJeff Barrとツーショットで写真撮影してきました。

jawsdays2018.jaws-ug.jp

2018/03/21 追記
スライドまとまってました。見たセッションの資料ものせておきます。
JAWS DAYS 2018 スライドまとめ - Qiita

エッジデバイスでディープラーニング！ AWSを活用したエッジデバイスマネジメントの紹介 河崎 敏弥

speakerdeck.com

推論部分をなるべくIoTデバイス側で行えるかがカギになりそうです。
まだプレビューですが、Greengrass Inferenceに期待。

コニカミノルタのIoTの取り組み 中村 明彦


[ランチタイムセッション] アールスリーインスティテュート


「AWS Technical Evangelists Special talk session -スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来-」 Jeff Barr / Randall Hunt / Julio Faerman / Channy Yun / 亀田 治伸

aws.amazon.com




これからも手を動かしてアウトプットしていきます。

サービスをスケールさせるために〜AWSとAWS利用者の技術 荒木 靖宏

www.slideshare.net

最近のMediaServiceから始まり内容盛りだくさんでした。スライド公開希望。

編集業務の生産性向上へ向けたserverlessなアプローチ(EditTech) 落合 隆文

speakerdeck.com

既存のサービスの置き換えというよりは、新しい社内向けサービスをserverlessで構築したお話でした。少人数でやっているみたいですごい。

aiboの心はAWSの中にある？(RoboTech) 森本 良平

speakerdeck.com



デバイス認証の話はいつも気になるところ。各部署から情報を集めて実現というのが驚いた。各部署にAPIを叩いてもらって実現しているように見えました。こちらもスライド公開希望。

[DeepDive] AWS Japan SA Lightnings! 浅野佑貴 / 藤原吉規 / 福井厚 / 江川大地 / 塚越啓介 / 桐山隼人 / 畑史彦 / 大村幸敬

www.slideshare.net

www.slideshare.net

www.slideshare.net

AWS SAによる連続LTでした。CloudFormationの話は参考になりそうでした。スライド希望。→スライド貼りました

雑談

いろいろな人と話ました。メモしておきます。

  • Well Archtectedレビューは強制するのはダメ。
  • Cloud9で共同作業をするときにCodeCommitへのコミット履歴はどうなるか。
    • IAMユーザ単位でのアカウント払い出しになるのでコミット履歴もわけられる。
  • GuardDutyは全リージョンに設定するべきか。
    • 全部するのが好ましい。お金かからないし、逆に使ってないリージョンに対してオンにするのもありかもしれない。CloudWatchイベントとかSNSをリージョンごとに設定しないといけないのが少し不便。

AWS 役割別 IAM管理ポリシー

AWS

IAMポリシーを役割別に管理しようとすると、どんどん複雑になっていきます。
例えば、管理者と開発者は分けたいとか、本番環境のアクセスは絞りたいとか、いろいろあると思います。

個人的には用意されているものを組み合わせて使うのが良いと思っています。

ということで、よくリンクがわからなくなる「職務機能の AWS 管理ポリシー」をメモしておきます。
docs.aws.amazon.com

  • 管理者: AdministratorAccess
  • 請求: Billing
  • データベース管理者: DatabaseAdministrator
  • データサイエンティスト: DataScientist
  • 開発者パワーユーザー: PowerUserAccess
  • ネットワーク管理者: NetworkAdministrator
  • システム管理者: SystemAdministrator
  • セキュリティ監査人: SecurityAudit
  • サポートユーザー: SupportUser
  • 閲覧専用ユーザー: ViewOnlyAccess

開発時はIAMをいじれる人はAdministratorAccess、IAMをいじれない人はPowerUserAccess or SystemAdministratorにしておいて、本番運用が始まるときに他のポリシーにして権限を絞るイメージでしょうか。

あとは必要に応じてBillingをつけましょう。

監査要員はViewOnlyAccessで充分でしょう。ただしS3に個人情報などが入ってる場合は、S3側でアクセスをちゃんと絞りましょう。(例えばVPCエンドポイントで絞る)

無停止でEBSのボリュームを変更する方法(Linux)

AWS

Linuxで無停止でEBSのボリュームを変更する方法をメモしておきます。

公式を参考にしました。
Linux の EBS ボリュームのサイズ、IOPS、またはタイプの変更 - Amazon Elastic Compute Cloud

コンソールからEBSのボリュームを変更する

インスタンスにログインして事前確認。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  80G  0 disk
└─xvda1 202:1    0  80G  0 part /

コンソールからEBSのボリュームを選択して、「ボリュームタイプ」、「サイズ」を変更します。
f:id:yamano3201:20180308190609p:plain

80Gから400Gに変更されました。

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  400G  0 disk
└─xvda1 202:1    0   80G  0 part /

ボリュームのファイルシステムを拡張する

まずは事前確認。80G全てを使いつくしています。

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/xvda1      82436764 82336544         0 100% /
devtmpfs         1920364       60   1920304   1% /dev
tmpfs            1928944        0   1928944   0% /dev/shm

パーティションを拡張します。

$ sudo growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=167768030,end=167772126 new: size=838856670,end=838860766

つづいて各ファイルシステムのサイズを新しいボリューム容量に変更します。

$ sudo resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 5, new_desc_blocks = 25
The filesystem on /dev/xvda1 is now 104857083 (4k) blocks long.

事後確認して終了。

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/xvda1     412716188 82343232 330272708  20% /
devtmpfs         1920364       60   1920304   1% /dev
tmpfs            1928944        0   1928944   0% /dev/shm

AWS 逆引き(rDNS)設定を登録・解除する

AWS

AWSでは逆引き(rDNS)設定の登録・解除は申請ベースで行う必要があります。

rDNS登録

https://image.slidesharecdn.com/rdnsec2emailrequest20141022-141219200331-conversion-gate01/95/aws-ec2-e-rdns-4-638.jpg?cb=1503970710

rDNS解除

https://image.slidesharecdn.com/rdnsec2emailrequest20141022-141219200331-conversion-gate01/95/aws-ec2-e-rdns-6-638.jpg?cb=1503970710


また、rDNS設定したElastic IPを削除するためには、事前に逆引き設定の解除をする必要があります。

解除申請時、「Reverse DNS Record for EIP」には記載しないことに注意。登録申請時に記載します。

AWS Organizations に属するアカウントを作成する

AWS

昔から一括請求でAWSアカウントを取りまとめているケースがあると思いますが、今はAWS Organizationsの機能の一部になっています。

通常、メンバーアカウントを追加する場合は、
クレジットカードなどを入力して作成したAWSアカウントを紐づけるという作業が必要になります。

以下の手順に従って、AWS Organizationsの機能を使うと簡単にメンバーアカウントを作成できました。
docs.aws.amazon.com

root ユーザーとしてアカウントに初めてアクセスする場合は、アカウントのパスワード復旧プロセスを行う必要があるので注意が必要です。
docs.aws.amazon.com

後で気づいたのですが、以下に綺麗にまとまってました。
qiita.com

SSL証明書のCT(Certificate Transparency)への対応について

2018/04/30 からChromeでのCT義務化がスタートします。

SSL証明書を利用してWebサービスを提供している管理者は、利用中のSSLサーバ証明書を確認して、サイトアクセス時の警告/エラーを回避する必要がありそうです。

詳細は下記サイトをご覧ください。
CT(Certificate Transparency)への対応について

CT(Certificate Transparency)とは

リンク先から引用。

CTは証明書発行の証跡を第三者の監査ログに記載する仕組みです。

主に、ウェブサイトの運営者やドメイン名の管理者が、その監査ログサーバを確認することで、自分のドメインに対して不正な証明書や、ポリシー外の認証局からの証明書が発行されていないかを検証することができます。

それにより利用者が不正に発行された証明書を信頼することを防止します。

監査ログサーバに証明書を提供する事で、ブラウザ等のクライアントは、そのログの中にその証明書データが登録されているかどうかを確認する事が出来ます。

全部は把握できてないので、一部だけメモ。

グローバルサインの場合

こちらもリンク先から引用。

アルファSSL 2016年08月29日以降に発行されるアルファSSLが対応予定です。
クイック認証SSL 2016年08月29日以降に発行されるクイック認証SSLが対応予定です。
企業認証SSL 2017年10月30日以降に発行される企業認証SSLが対応予定です。
EV SSL 2014年12月24日以降に発行された証明書は対応しております。

グローバルサインは今回の警告対象とはなっておらず、CTに非対応の証明書でも警告が出る事はない事を認証局に確認しております。

CTに非対応でもエラーメッセージが出るわけではないので直近で影響はなさそう。

AWS Certificate Manager (ACM)の場合

以下のリンクを参考。
AWS Certificate Manager (ACM) が Certificate Transparency (CT) をサポートするための準備 | Amazon Web Services ブログ
AWS Certificate Manager (ACM)のCertificate Transparency (CT)サポートが始まります ｜ Developers.IO

4/24からログ記録しますよ。無効にしたい人は3/27から無効にしてね。その場合はChromeでエラー表示されますよ。という解釈。

【訳注】Google の記事に詳細が記載されていますが、2018年4月24日までに ACM で発行された証明書には SCT 情報が付いていませんが、SCT 情報が付いて無くても Google Chrome でエラーメッセージが表示されるなどの影響は現時点では予定されていません。

CTログ無効化しない場合、SCT情報がなくてもエラーメッセージが出るわけではないので直近で影響はなさそう。

最後に

有効にするか無効にするかの判断材料については把握していません。
もう少しwatchしておく必要がありそう。