こんにちは、技術3課の紅林です。 【そんなときどうする？】シリーズに便乗してみました。さて、今回は、S3をクロスアカウントで利用する方法やハマリポイントをご紹介します。 はじめに 開発環境と本番環境とでAWSアカウントを分けているとき等、クロスアカウントでS3を扱いたくなるケースがあります。その際に採用できそうないくつかの方法と、実際にやってみるとハマりがちなポイントについてご紹介します。 クロスアカウントでの利用方法 クロスアカウントでS3を扱う方法ですが、代表的な方法として以下３つの方法があると思います。今回はAWS CLIや各種SDK等からの利用を念頭に置きます。 IAMユーザの共有バケットポリシーの許可STSの利用 それぞれ簡単に概要を記載します。便宜的に、 S3バケットがあるアカウントを「アカウントA」S3バケットを扱うアカウントを「アカウントB」 とします。 1. IAMユーザ

全国のTerrafrom愛好家のみなさま、こんにちは。 技術4課岩本です。 まず、Terraformを使って、IPリストを登録する方法は以下になります。 CloudFront(Grobal)用の場合 resource "aws_waf_ipset" "ipset" { name = "tfIPSet" ip_set_descriptors { type = "IPV4" value = "192.0.7.0/24" } } 参考：aws_waf_ipset ALB用の場合 resource "aws_wafregional_ipset" "ipset" { name = "tfIPSet" ip_set_descriptor { type = "IPV4" value = "192.0.7.0/24" } } CloudFront(Grobal)の際はip_set_descriptors、

こんにちは。技術二課の永田（@nagaaki46）です。 皆さんの一番欲しい物って何ですか？ 五年前、私が一番欲しかった物といえばAragostaの車高調。 そして今年、一番欲しい物は衣類乾燥機に。 大人になるって、こういうことでしょうか。 そして、遂に我が家に導入されたガス式衣類乾燥機ィィィィィィィ！（リースやけどな） 人類の永遠の憧れ、仕事の「自動化」。 この衣類乾燥機と共に過ごせる私は最高に幸せ者です。 というわけで今回は、 サーバーワークスのAWS導入支援業務における 構築自動化の取り組みについてご紹介します。 サーバーワークスらしい構築の仕方って？ 私は2014年8月からサーバーワークスにジョインしました。 最先端のAWSに触れ、古い体質が無いサーバーワークスの仕事のやり方に 「ウヒョ〜」と刺激を受ける日々を過ごしてきました。 刺激って大事ですよね〜。 一方で、インテグレーター業

こんにちは。「Cygwinなんか捨ててMacに来いよ」とカウンター勧誘された竹永です。 フルスペックMac Proがホシイナァー（棒読み） せっかくCygwinにs3cmdをインストールしたので、今度はOctopressもガガッとインストールしてS3にブログを作ってみましょう。 前提条件 s3cmdがインストールされている Gitがインストールされている Ruby 1.9.3がインストールされている bundlerがインストールされている Web Hostingが有効になっているS3 Bucketがある S3 BucketのWeb Hostingを有効にする方法は、過去に素晴らしい記事が投稿されているので、ぜひ参考にしてください。 ちなみに、rbenvでRubyのインストールが出来ないなぁ…という時は、コマンドの頭に LANG=C をつけるとインストールできるかもしれません。 さっそくイン

4月から劇団サーバーワークスに加わりました。伊藤です。 社内ではくりゅーと呼ばれております。 AWS環境では、わずか数クリックでサーバーができたり、AutoScalingで自動的にサーバーが増えたり、 オンプレミスの監視運用のスピードでは全く追いつけません。 そこで、今回はAuto Scalingなどで監視対象のインスタンスが自動で増えたり減ったりしても、Zabbixで常に対象インスタンスを自動登録し、監視対象にする方法をご紹介します。 自動構成ツールなどには依存しないので、どんな方法で（マネージメントコンソール、SDK、CLI、API、Elastic Beanstalk等々）構築、運用していても適用できます。 監視対象インスタンスのAgent側設定 zabbix_agentd.confにおいて、以下の点を設定します。 Server=127.0.0.1 #Zabbix-serverのIPも

初めまして今年入社した長谷川です。 新入社員として最初の仕事である、Zabbixサーバの負荷を下げた話を書きたいと思います。 実はこのプロジェクトは、まだ新人研修を行っている入社１ヶ月目の時に、Rubyが得意？という理由でアサインされ、１週間で構築と実装しました。以上自慢です。 構築したシステムは、CloudWatch経由でしか監視ができないRDSやSQSなどのサービスのメトリクス（監視データ）を大量にZabbix取り込む場合の解決方法の一つだと思います。今後同じ問題に直面した方々の参考になれば幸いです。 従来のシステムの状況 従来のシステムは、Zabbixサーバがインストールされている1台のEC2インスタンスが、CloudWatchから値を取得しているだけのシンプルな構成でした。 ZabbixサーバーはCloudWatchから各サービスのメトリクスを取得するRubyスクリプトを実行し、そ

どうも、Zabbix 大好き 伊藤です。 社内ではくりゅうと呼ばれています。 2014/09/11にZabbix2.4.0がリリースされました！ ダウンロード http://www.zabbix.com/download.php リリースノート http://www.zabbix.com/jp/rn2.4.0.php 正確な情報は本家を見ていただくとして リリースノートから注目の変化ポイントををピックアップしてみたいと思います。 :: Multiple filters for low level discovery The filter section in low level discovery rule definition has been split out into a separate tab and, most importantly, allows to define se

CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを