Reach Over The Sky, Tear The Sky

AWS認定 SysOpsアドミニストレーター アソシエイト に先日合格しました。 合格時のスコアは 794/1000 で、合格者の中では高くないほうだと思います。 分野的には「モニタリング」と「ネットワーク」が特に点数が低かったみたいで、その領域については別途改めてまとまった量の勉強を行っていった方がよさそうです。 学習内容について 学習方針は基本的にソリューションアーキテクトの時やデベロッパーの時と同じです。 学習方針 AWSが公式に提供している模擬試験を受ける 模擬試験の問題をすべてスクリーンショットを撮る スクリーンショットを見返して特にわかってなさそうなサービスや技術領域（監視系、サーバレス系、DB系　など）を特定する その分かっていないサービスや技術領域に関するドキュメントを読みまくる サードパーティーの有料教材は買わない これまでとSysOpsでの勉強方法や内容の違い Developer アソシエイトの場合は海外ブログ等を発掘してどのサービスを重点的に勉強すればよいかを洗い出していったのですが（これ勉強しとけよ！って書いてくれてる英語ブログとかあった）、SysOps アドミニストレーター アソシエイトの場合はとにかく先人のブログが少ないです。 それで今回は基本に忠実？に、スクリーンショットを見返してそこから自分が勉強すべき内容についてリストアップしました。 その結果以下のようになりました。 上から勉強した方がいい順です。 System Manager AWS Service Catalog Snowball Storage Gateway AutoScaling Group Egress-Only Internet Gateway SAMLフェデレーション VPN(Direct Connect?) NAT Gateway VPC Route53 CloudFormation S3 低頻度アクセス 受けたあとについでに学習したほうがいいと思ったのは、以下のようなサービスです。 AWS Config IAM Route53(優先度上げたほうが良かったかも） ちなみに今回は時間がなかった（取り掛かり始めるのが遅すぎた）ので、あんまり...

自分のためのメモの意味合いが強いです。 時系列で書いてみます。 それまでの自分 AWS歴は4年ほど EC2とかELBとかRDSとかのいまどきの「サーバーレス」っぽくない基本のプロダクトを業務でよく使っている 最近はWAFとかSAMとかいじってる ACMがDNS認証可能になってRoute53に勝手にレコード書いてタダでソッコーSSL証明書が入手できるのはほんといい時代だなーといつも思っている アプリのコードは書いていない 運用自動化のコードはマイペースに書いている 今の会社に転職する前に当時のAWS本を何冊か読み漁りあとは Developers.io や Qiita や公式ドキュメントで自分なりに学習してそれを業務で試す日々 Developers.io はメッチャお世話になっておりますクラスメソッドのみなさん本当にありがとうございます 40日前 受験を決意 公式の模擬テストを受けたんだけど ソリューションアーキテクト アソシエイトを合格したご褒美として無料 だった さらに 本番の試験費用もご褒美として半額になるクーポンが利用可能だった 模擬テストは全部画面キャプチャして見返せるようにした 模擬テストは受けた直後に結果がメールで届く 模擬テストの総合スコアは75%だったので頑張れば受かるぞという気持ちになった 39日前〜10日前 平日はふつーに仕事してた 仕事が結構大変で全然勉強できてなかった 休日は疲れを癒すのでわりと精いっぱいだったので全然勉強できなかった 7日目〜前日 GWに入ったので勉強のチャンスだった GW前までは仕事して気分転換にお酒飲んでゲームして寝るような日々が多かったのでなかなかスイッチを切り替えられなかった 毎日1時間ずつ増やしていった。1日目1時間、2日目2時間、3日目3時間みたいな…。 模擬テストのキャプチャを見返してSQSの知識が足りてなかったからSQSの公式ドキュメントを順番にたくさん読んだ 2日前からSQS以外のサービスについて「軽くは知ってるよ」レベルになるように学習対象をリストアップしてそれらについて各種ドキュメントを読んだ Code*系のサービスをもっと学習しておけばよかったなと思ったけど間に合わなかった Nintendo SwitchのFi...

自分のためのメモの意味合いが強いです。 時系列で書いてみます。 それまでの自分 AWS歴は3年半ほど EC2とかELBとかRDSとかのいまどきの「サーバーレス」っぽくない基本のプロダクトを業務でよく使っている ACMがDNS認証可能になってRoute53に勝手にレコード書いてタダでソッコーSSL証明書が入手できるのはほんといい時代だなーといつも思っている アプリのコードは書いていない 運用自動化のコードはマイペースに書いている 今の会社に転職する前に当時のAWS本を何冊か読み漁りあとは公式ドキュメントで自分なりに学習してそれを業務で試す日々 40日前 受験を決意 二千円払って公式の模擬テストを受ける 模擬テストは全部画面キャプチャして見返せるようにした 模擬テストは受けた直後に結果がメールで届く 模擬テストの総合スコアは84%だったので安心する 39日前〜10日前 平日はふつーに仕事してた 帰宅後スイッチ切り替えのため30分だけスマブラしたりしてた お酒飲みながらいつもより多めにAWS公式ドキュメントを読んだりした 週末に読みたい記事をTodoistにToDoとしてメモした TodoistはURLを貼ると記事名に変換されそれがタスクになるので便利 画面キャプチャの問題文を読み直しよくわかっていないプロダクトや単語をピックアップして自分の重点学習項目とした 多分1日30分 ワイヤレスイヤホンを買ったので皿洗いをしながらEFSのBlackbeltの動画を流して聞いたりした…2周したけどおかげで知識ゼロからだいぶ増えた 試験は平日にしか受けられなかったので会社に「AWSの試験受けてくるので休みます！」宣言をして許可と応援をもらった 10日目〜前日 週末の日中帯は部屋でずっとドキュメント読んでた Redshiftを業務で使ったことがなかったのでクラスメソッドさんのRedshiftの記事から新しい順に10本読んだりしてその記事に貼られている公式ドキュメントも読んだりした 1週間前から禁酒を開始して最後まで飲まなかった 英語オンリーっぽいけどAWSの公式ラーニングサイトで勉強動画見放題なのに気づいてすげーってなった 当日 テストセンターでの受験 米国（ホントかわかんない...

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に...

結論 結論から言うと API Gateway でした。 ACMで発行したSSL/TLS 証明書を シームレスに他のAWSプロダクトで利用することが可能なのですが、その時に内部動作としては規定のアカウントIDでCloudFrontディストリビューションが生成され、そのディストリビューションに対して証明書が適用されるようです。 直面した問題 AWSでのシステム運用にあたり、それなりの数のドメインを運用しているのですが、基本的にはACMにて発行した証明書を利用しています。 以前はメール認証しかできず、きちんと環境を整えてあげないと自動更新に失敗することもあり、DNS認証の同一ドメインの証明書を別に発行し、そちらに切り替える作業を行なっていました。 ACMで発行した証明書はAWSコンソール上から簡単にELBやCloudFrontといったAWSプロダクトに利用することが可能なのですが、証明書を削除する際には全てのインスタンス・ディストリビューションから利用を解除する必要があります。 「あとはどの子（インスタンス）が使っているのかな〜？」と確認したところ、 arn:aws:cloudfront::969236854626:distribution/ABCDEFGHIJKLMN のようなCloudFrontディストリビューションが利用していることがわかりました。 969236854626 の部分が自分のAWSアカウントIDになりますが、私が利用しているアカウントのIDは全然違います。 対策 「えっ…？」と思いましたが調べたらすぐに解決。 答えはこちらに書いてありました。 エッジ最適化のカスタムドメイン名を作成する方法 - Amazon API Gateway  https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-edge-optimized-custom-domain-name.html API Gatewayにカスタムドメインを割り当ててHTTPSを利用させたい場合に、AWSは特定のIDでCloudFrontディストリビューションを内部的に自動で作成し、そのディストリビューションに証明書を関連づけるのでした。...

オリジン間リソース共有 (CORS)という技術があります。 ドメインAのWebページを表示する際に、一部のコンテンツをドメインBから取得してそれを表示したいといった場合に利用する必要があります。 それは最近のWebでは割とありふれたことだと思います。 なので意識せずともかなりの頻度で利用されているのではないでしょうか。  先日業務でCORSを意識した問題に直面してしまったこともあって、一度きちんとした技術文書を読んだ方が良いと思い、Mozillaが提供している MDN web docsの丁寧なドキュメント を読んでみました。 CORSまとめ WebブラウザがドメインAのページを取得したいが、ドメインAのそのページはドメインBのコンテンツを含むといった場合に、ドメインAのサーバはドメインBのコンテンツを取得して自ページのコンテンツの一部としてWebブラウザに返さなければいけない その時に利用される技術がCORS CDNで画像やスタイルシートやフォントやスクリプトを配信している昨今ではかなりの頻度で利用されていると思われる 基本的にはHTTPヘッダに所定の内容をクライアントとサーバが用意することで成り立つ CORSができるかどうかを確認するために「プリフライトリクエスト」という事前HTTPアクセスが必要である 「プリフライトリクエスト」はOPTIONメソッドで行われる…GETやPOSTではない 「プリフライトリクエスト」が発生しない「単純リクエスト」というCORSリクエストもあるが該当条件が厳しい 特に世の中に多そうなcontent-typeが「text/html」のページは単純リクエスト対象外なので基本的にはほとんどのCORSでプリフライトリクエストが発生すると考えた方が良さそう プリフライトリクエスト時にクライアントから発送される「Access-Control-Request-Method」にはプリフライト後の本来のリクエストでどのメソッドが使われるかが書かれている 同様に「Access-Control-Request-Headers」には次に行われる本来のリクエストでどのようなヘッダが送信されるかについて書かれいる プリフライトリクエストを処理するためにサーバ側（CORSで一部コンテンツを提供するドメインBのサーバ）...

その時のスライドがこちらです。 Docker study for beginner in My Company 2017/10/19 from Masumi Yoshida 勉強会当日には、主に「Dockerを一ミリも使ったことがないエンジニア」に集まっていただき、Dockerってどんな感じのソフトウェア・システムなのか、自社ではどんな感じで開発に利用してるのかというような観点でお話しました。 デザイナーも来てくれたりしたので、具体的な操作方法は抜きにしてとにかく概要を理解してもらうことに重点を置いたスライドになりました。 本当はハンズオンのパートを作る時間を捻出できなかっただけですが…。 社内では割と好評だったので（そもそも勉強会をオラッっとやる人が少ない…）、次回はECSについて説明するようなスライドを作成できればと考えています。

日本語.jp みたいなドメインってたまに見かけますが実際に自分が運用することになるとは思わなかったので学んだことをまとめたいと思います。 このような形式のドメイン名は「 国際化ドメイン名 」と呼ばれるものらしいです。 従来のアルファベット、数字、ハイフン以外にマルチバイト文字を利用できるようにする仕組みのことで、日本語の他にもアラビア文字なども利用できるようです。 ただ、毎回国際化ドメインと呼ぶのもアレだし非エンジニアのスタッフに説明する時に相手に難しそうなイメージを持たれたくないので、 日本語が含まれたドメイン名のことを日本語ドメインと会社では呼んでいます。 中国語だったら中国語ドメインですね。 この日本語ドメインをDNSサーバが理解できるようにするためには、 Punycode（ピュニコード） と呼ばれる形式で、アルファベット数字ハイフンだけの、既存のドメイン名に使用できる文字だけの対応ドメインに変換してあげる必要があります。 言いたかったのはそれだけです。 たとえば、JPRSが運用している 日本語.jp はPunycodeだと xn--wgv71a119e.jp になります。 これはHTTPS接続についてほんのちょっとだけめんどくさいトラブルが発生します。 curlなどでHTTPアクセスのテストをすることはよくあると思いますが、開発している日本語ドメインのサービスがHTTPSを基本としていて、curlでもHTTPSで行う場合、通常はSSLに関するエラーが出力されます。 SSL証明書を取得するときはPunycode変換済みのドメイン名で取得することが前提となっており、変換済みのドメインは変換前のドメインとリテラル的に同等とみなされないからです。 SSL証明書エラーを回避するには curlの -k オプションを利用します。 今回私が運用することになった日本語のドメイン名は、AWSのACMで無料の証明書を取得しました。 そのドメインは お名前.com で購入したのですが、デフォルトの状態では取得不可能でした。 なぜか？それは、 こちらの仕様 によるもの 日本語ドメインは、A / AAAA / CNAMEレコードのみご利用いただくことが可能です。 設定方法はこちらをご参照ください。 これはMXレコードを設定できな...

とてもお久しぶりです。 恵比寿のITベンチャーでサービス運営やっています。 仲間募集中です。ご興味ある方はTwitterなどでご連絡ください。 今回はAWSを使って、わりと便利なソーリーサーバを構築しましたというお話です。 構成は下の図のようになっています。 通信フローとしては、まずエンドユーザがELBにアクセスします。 このELBは既存のWebサービスやWebサイトをバランシングしていたものです。 諸事情によりメンテナンスしたり、ドメインを畳むことになったという話を想定しています。 そのELBに接続されていたWebサーバやアプリケーションサーバの代わりにソーリーサーバを接続します。 するとエンドユーザはソーリーサーバにアクセスしてきますよね。 ソーリーサーバはリクエストを受けたら、各ドメインに対応させたいCloudFrontへリクエストをパスします。 CloudFrontはS3のコンテンツを返すのですが、このS3に静的なソーリーページを格納しておきます。 それにより、ドメインにアクセスしてきたエンドユーザにソーリーページを見せることができます。 ポイントはソーリーサーバとCloudFrontですがやってることは簡単です。 まず、ソーリーサーバはただのNginxです。 proxy_pass を使って、特定ドメインに来たリクエストを対応するCloudFrontのドメインへパスします。 その設定は、/etc/nginx/conf.d/virtual.conf に書きました。 server {          listen 80;         server_name example.com;         if ($http_x_forwarded_proto != https) {          ...

あー、なんか環境一式作ってくれるやつねー知ってるー使ったことないけどー…。 え？新しいアプリをElasticBeanstalkでローンチするの？それの運用やれ？ アプリはもうできている…？？ ということで速習にチャレンジ。 これを社内ドキュメントシステムにも残して、他のメンバーにも運用させる目論見…ｗ Environment Type（環境タイプ） Webサーバ　と ワーカーがある WebサーバタイプはHTTPポートを解放して外部からアクセスを受けるようなシステム全て。ユーザがブラウザでアクセスするタイプのソースコードを動かす場合は全部これ。 ワーカーはバックエンドのアプリのこと。SQSを使って他アプリというかシステムのワークフロー上の前後の機能とやりとりする。 DBの構築 RDSのインスタンスをElasticBeanstalkの構成の一部として起動することができる アプリを消すとDBも自動的に削除される。もちろん最終スナップショットは取れる 既存のRDSのスナップショットからRDSインスタンスを作成してそれをElasticBeanstalkアプリのDBにすることもできる ElasticBeanstalkの構成の一部としないDBを作成することもできる。その場合は、ElasticBeanstalkアプリを削除してもDBが残る。作り方は多分RDSインスタンスを普通に作り、ElasticBeanstalkからそこへ接続する。 その他のDBに関する仕様はRDSを参照 VPC内への構築 自分の既存のVPC内に構築することができる Elastic Beanstalk は、Linux プロキシ設定（HTTP_PROXY、HTTPS_PROXY および NO_PROXY）をサポートしていない。 直接インターネットからアクセスさせる（外部公開）するかNAT経由にする必要がある VPC全般に言えるがUDP123番ポートを利用してNTPで時刻同期している。なのでNTPが利用できるように解放しておく必要がある。 明示的にVPCを指定しないと自分のVPCを作ってそこに生まれる。 サービスロール、インスタンスプロファイル、ユーザーポリシー サービスロール は １個のサービスを正常に動かすために必要なポリシーをまとめたもの ...

先日、Apacheで配信していたWebサイトをS3＋CloudFrontの環境に移行しました。そのときにやったことを備忘録としてまとめました。 個人的にハマって悩んだところや大事だなと思ったところは太字にしています。 0. 前提条件 一通り構成を組んだ後でのテストでは、キャッシュがしぶとくてコンテンツ更新後の状況が再現できないことがあるので、Invalidationしまくったり、ブラウザキャッシュを削除しまくったりする必要がある。 適当なテストドメインを用意できると良い。 たとえば、 www.example.com について構築しようとしているのであれば、 www2.example.com などをテスト用として確保するとよい。 phpやrubyは動きません、 Javascriptは動きます、Basic認証はできません 、会員登録はできません（phpやrubyが必要なページは動かない）、などの制約事項があるので、 非Techの関係者にネゴっとく 必要がある。 1. S3の基本的な設定 なんでもいいのでバケットを作る。 バケット直で自分が持っているドメインを紐付けようと思うなら、ドメイン名と全く同じバケット名（www.example.comのサイトを作りたい場合は、バケット名をwww.example.comにする。ドットは入力できないとエンジニアの直感でなんとなく思いがちだけど、普通に入力できる…。）にする必要がある が、多分不要。（未検証、今回はドメインと同じバケット名にしました…。） 静的ウェブサイトホスティングを有効にする。 インデックスドキュメントはindex.html（他任意のファイル名でもOK）、エラードキュメントはerror.html（他任意ry）にする。 バケットに、html, access-logs, cf-logs のディレクトリを作成する。htmlがコンテンツ置き場、access-logがS3が直接ロギングするログ置き場、cf-logsがCloudFrontがロギングするログ置き場にする。 コンテンツを突っ込んでみて、静的ウェブサイトホスティング用のURLにアクセスして、コンテンツが表示されるかを確認する。 2. CloudFrontの基本的な設定 基本的にはググって出てくるサイトを参考にしてよい。 A...

概要 暗号スイートという、暗号化技術の利用セットみたいな概念があります。 HTTPS（SSL/TLS）通信では、複数の暗号スイートからクライアントとサーバが利用可能なものを自動で選択して利用します。 しかし、場合によっては、弱い暗号化方式を使われてしまい、セキュリティ強度が下がる場合があります。 また、攻撃者はそのような選択が可能な場合、攻撃プログラムに故意にそういう暗号スイートを選択させるようにしたりします。 今回は、セキュリティ強化のために、ELBが、弱い暗号化方式である3DESを利用しないようにします。 しっかり理解したい方は、解説されている方がいらっしゃいますので、そういうブログや、セキュリティ系の書籍等をご覧ください。 理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷 http://tkengo.github.io/blog/2015/12/01/https-details/ 手順 ロードバランサーの画面を開きます 対象のロードバランサータグを選択し、リスナータグを開きます。 HTTPSの行の「暗号」をクリックし、カスタムセキュリティポリシーを選択します。 「SSL暗号」というリストの中から、「 DES-CBC3-SHA」を外します。 「保存」をクリックすると反映されます。 DESを利用した暗号化方式がリストアップされないことを確認します。 以下の記事を参考にさせていただきました。 【小ネタ】cipherscan で対象サイトの SSL cipher suite を確認する https://blog.cloudpack.jp/2014/07/29/cipherscan-ssl-cipher-suite/ ELBの暗号設定画面では、暗号化プロトコルも選択できます。 たとえばTLS1.2以外は使わせたくないぜ！という場合には、 同様にカスタムセキュリティポリシーの画面を開き、 「 SSL プロトコル」から Protocol-TLSv1.2以外のものを外せばいいです。 これで、またひとつシステムがセキュアになりました。

自分向けのプログラミングTipsメモです。大した内容ではありません。 Gistにサンプルコードを書いてみたので、まずそれを貼りたいと思います。 コードは、AWSを操作するための Python版 AWS SDK（Boto3）を利用したプログラムの一部です。 仕事で書いているBoto3プログラムで、こういう場面がありました。 取得した配列のある要素の値がTrueかFalseかで後続で実行する関数の引数を変えたい。 関数の引数にはTrueかFalseを用いる 当たり前といえば当たり前ですが、条件判定しているTureかFalseを、そのまま関数の引数として与えれば、条件判定する必要がないんですよね。 こういう小さな省力化（短いコードで書く努力）を積み重ねることで、一個のサービスが出来上がった時に体感できるような差が生まれるのかなぁなどと思いました。 普段はサーバ管理みたいな仕事が多いので、こういう風にプログラミングに対して自分で「おっ、こうした方がいいじゃん？」みたいな思考ができたこと自体がなんだかとても嬉しくなりました。 こういう気持ちはたとえ小さくてもきちんと表現したり記録しておくことが精神衛生上、そして今後の技術力向上のモチベーション管理上も良いのかなぁと思って、ブログに書いておこうと思った次第です。 こういうTipsがまとまった本とか、あるのかな、普通にありそうだな。 プログラミングをもっと業務でできるようになりたいです。 スマートPythonプログラミング: Pythonのより良い書き方を学ぶ

今の会社に2015年5月に入社してから1年経ちました。 あっという間だった気もするし、すごく長かった気もします。 自分がどのくらいの仕事をして、何が新しくできるようになったのかを整理したいと思い、箇条書き形式でまとめてみました。 今の会社ではAWSを使っていて、AWSを使ったインフラ全般の構築運用を行うエンジニアとして働いています。 入社前はAWSもEC2をちょっと触ったことがあるぐらいで、インフラの知識もそんなに自信がない状態でした。（今もないですが…w） AWSエンジニアとしてはまだまだジュニアだと思いますが、1年前には何もできなかったことを考えると、少しはできることが増えてきたなぁと思います。 会社の体制も大分変わり、1年前はエンジニアがCTOとインターンのみでしたが、私の他複数名のエンジニアが採用され、エンジニアチームができ、外部委託している部分を大幅に巻き取って、自分たちのプロダクトを自分たちで責任を持って育てる土壌ができたのかなと思います。 できるようになったこと 日々の設定変更作業 Ansibleの初歩的な利用法を学び、初歩的にAnsibleを導入して設定業務が効率化された。 サーバ新規構築時のエンジニアのアカウント作成、公開鍵配布、sudo可能化、個人ファイル配布がAnsibleで自動実行できるようになった。 Python AWS SDK (Boto3) を利用して、AWSの管理効率化スクリプトを幾つか作成できた。 毎日すべてのEC2のAMIを自動バックアップ 指定した世代より古いAMIとEBS Snapshotを自動削除 各ELBに紐付いているEC2インスタンスの表示名、Public IP、ヘスルステータスを表示 ELBに紐付いているサーバを切り離したり、紐付いていいないサーバを接続させる 指定したEC2のAMIを取得し、そのAMIから任意の台数のEC2インスタンスを作成 監視 Zabbixを導入し、一元的な監視が可能になった。 Zabbixが検知したトリガーをSlackに流し、タイムリーに社内に報告される体制ができた。 一部のエラーに対してはZabbixで検知した障害をトリガーに復旧スクリプトを実行して自動復旧をすることができた。 Zabbixのグラフやスクリーン機能を利用することに...

得られた正規表現 '^i-([a-zA-Z0-9A0-zZ9]{8}|[a-zA-Z0-9A0-zZ9]{17})$' 背景 今の勤務先ではAWS系インフラエンジニアとしてAWSの管理全般を行っています。 昨今のクラウド全盛期においては運用業務の各種自動化が大事ということで、Python + AWS SDK（Boto3）で、AWS管理自動化プログラミングを少しずつ進めています。 AWSの操作はEC2に関するものが多く、EC2のインスタンスIDを引数に与えるものが多くなっているので、インスタンスIDが正しく入力に与えられているかをバリデーションできたらいいなと思い、ちょっと探してみた結果、以下のような正規表現を得ることができました。もっといい案がありましたら教えてください。 数ヶ月前に、インスタンスID及びAMI IDの文字数拡張がアナウンスされています。なので、「i-(英数字８桁)」の場合と、「i-(英数字17桁)」の場合に対応する必要がありました。今回はそれに対応できるようになりました。 得られた正規表現をPythonで使いたい Pythonで使う時には、 標準で用意されている re というモジュールをインポート して、 search() を使うことで、与えられた文字列が正規表現にマッチしているかどうかを確認することができます。 「i-」の後ろが8桁の英数字か、17文字の英数字の時のみ、オブジェクトが返ってくるので、そのオブジェクトの存在を確認すれば、インスタンスIDが実在するかはどうであれ、少なくとも形式に沿った値であるということがわかります。 >>> >>> re.search('^i-([a-zA-Z0-9A0-zZ9]{8}|[a-zA-Z0-9A0-zZ9]{17})$', 'i-0') >>> re.search('^i-([a...

AWSのサポートからこんなメールが届きました。 Dear Amazon RDS Customer, A system update is now available for any Amazon RDS PostgreSQL database instances you created before 13 October 2015. We recommend installing this update to take advantage of several performance improvements and security fixes. You may choose to install this update immediately, or during your next scheduled maintenance window. After approximately six weeks, your RDS instance will be automatically upgraded during your maintenance window. To learn more about scheduling or installing an upgrade, please refer to the RDS documentation: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.OSUpgrades.html. Installing this update will have an availability impact for a few minutes on your RDS instance (60-120 seconds for Multi-AZ instances). To reduce downtime, you may consider converting your Single-AZ instances to Multi-AZ. If you have any questions or concerns, please contact your TAM or AWS Support. Sincerely, The ...

最近は業務でAWSをよく使っており、AmazonLinuxを操作することが増えてきました。 Zabbixは業務で使う可能性が出てきたので、模索しながらインストール手順をまとめました。必要最低限レベルですが、なんとか自分で構築したZabbixにログインして管理画面を拝むことができました。 使ったAMIは amzn-ami-hvm-2015.03.0.x86_64-gp2 (ami-cbf90ecb) です。 AmazonLinuxを使う時は、RHELもしくはCentOSの6だと思って色々適用してみるとよさそうですね、ベースとしてCentOSを使っているということですし。 参考にさせていただいたページ Buena Vista de la Tecnología: Zabbix2.2のインストール with PostgreSQL http://daiti0804.blogspot.com/2014/02/zabbix22-with-postgresql.html Amazon LinuxにZabbix2.0.9をインストールしてみた ｜ Developers.IO http://dev.classmethod.jp/cloud/aws/zabbix2_0_9-on-amazon-linux/ 4 Installation from sources  https://www.zabbix.com/documentation/2.4/manual/installation/install Zabbix以外の必要プログラムのインストール システム系プログラムのアップデート sudo yum update -y Apacheのインストール sudo yum install -y httpd24 PostgreSQLのインストール sudo yum install -y postgresql93 postgresql93-server postgresql93-devel postgresql-93-libs Zabbixのインストール sudo rpm -ivh  http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-release...