新規事業の立ち上げにAWSを選択する こういう状況はままあるでしょう。最安というわけではないけれど、将来どんな開発が必要になるか全く想像できない新規事業立ち上げフェーズにおいて、多種多様なPaaSを提供してくれるAWSはとても魅力的。 さて、いざ、EC2インスタンスを立ち上げてアプリケーションをデプロイするわけだが、みなさん、ちゃんとネットワーク設計していますか？まさかデフォルトVPCでサービス運営なんてしてないですよね？ というわけでネットワーク設計をして、VPCを設定していくわけだが、何を作ればよいか決まっている事業フェーズならともかく、新規事業立ち上げフェーズでは「将来どんな機能が必要になるかわからない」という前提でネットワーク設計をしておかなければいけない。そこで、「例えばこんな設計はどうでしょう」という提案をしてみる。 IPレンジ設計 まずはVPCとサブネットを使ってIPレンジを

CircleCIからEC2上に構築しているサーバにデプロイする方法です 前提 ローカルなどからcapistranoでデプロイできる状態 準備 セキュリティグループ SSHをセキュリティグループで制限している場合、CircleCI上からのアクセスを許可しなくてはなりません VPC VPCでは他セキュリティグループからの許可ができません CircleCIはEC2 US East region上に構築されているのでそのIPを全部許可すればよいのですが現実的ではありません（よね？） AWS CLIを使ってビルドの開始時にコンテナのIPをSSH許可して、終了時にSSH許可を取り消す事で対応します SSH許可 aws ec2 authorize-security-group-ingress --group-id $MYSECURITYGROUP --protocol tcp --port 22 --c

・・・と、題名は書いてみたものの、２日間悩みました。一番の問題は、私自身、ネットワークがかなり弱く、言葉でやりたいことを表現すると。 WEBとかDBとかにグローバルIPをもたせたくない グローバルIPはいらないんだけど、プライベートIPしかもっていないサーバからもインターネットには接続させたい EC2 再起動毎に、IP ADDRESSが変わるのが許せないので、固定IPにしたい です。いまさらながら、VPCでれば、それが実現できると聞きまして、やって見た、作業証跡になります。他のサイトの例を参考にして試行錯誤はしていたのですが、皆様のレベルが高すぎて、あたりまえの部分があえて省略している多く、そのあたりまえの部分もわからない僕には、一からつくるときのパターンが知りたくて、あえて手順をおこしました。なので、若干というかかなり自分用のメモに近いと思います。セキュリティの観点から・・とか・・実装的

日に２回もブログを書くなんて人生初かもしれないonagataniです。こちらにちわ。という事で今回もRoute53の小ネタを。 皆さんRoute53利用されてますか！利用していない方は今すぐに利用しましょうとても便利です。 とはいえ、Route53に全部移設するのは無理だよー、wwwやwwwなしドメインは管理部署が違うので・・・という事もあるかと思います。 そんなときに便利なのが「サブドメインのDNSをRoute53に委任する」です。DNSの基本的な機能なのですが知らない人もいるかと思いますので紹介させて頂きます。 DNSの委任についてはこちらの記事が参考になるかと思います AWSのマニュアル読めば理解できる方はこちらをどうぞ。 つまり「example.jp」というドメインがあるとして、www.example.jpやexample.jpについてはDNSは今のままで sub.example.

森永です。 前回の記事でWordPressにアクセスできるところまでいきました。 引き続き構築を行っていきます。今回の手順は順序を変えるとうまくいかないことがありますのでご注意下さい。 おさらい こんな構成を作っていきます。 今回構築のメインとなるのは、CloudFrontの部分です。 CloudFrontにはURLによって振り分け先を変えるリバースプロキシの機能がありますので、メディアファイルを参照する場合のみS3に向くように設定をしていきます。 WordPressの基本設定 プラグインのセットアップ Beanstalkで作成されたサーバは、AutoScalingで起動されているEC2インスタンスのため、基本的にローカルにファイルを保存してはいけません。そのため、本来サーバのローカルに格納される画像などのメディアファイルは、プラグインを使用してS3に格納するようにします。 管理画面から、

個人情報を扱っているサイトなどを運営していると、httpリクエストを強制的にhttpsにリダイレクトしたいケースが出てきたりします。 Webサーバがロードバランサー配下にあり、ロードバランサーでSSLを扱っている場合には、ロードバランサーとWebサーバ間の通信は実はhttpで、Webサーバの443ポート空けてるけど意味ないじゃん。みたいなことがあったりします（ないか…）。 実際に、SSLをELB（Amazon Web ServiceのElastic Load Balancer）に導入しているサイトで、強制的にhttpsにリダイレクトさせたいという要件が出てきました。今回はwebサーバ（nginx）の設定でリダイレクトさせるようにしましたのでその一例を示したいと思います。 いろいろなやり方があると思いますが、今回はnginx.confの設定で対応しました。 server { listen 8

Check! はじめての Fluentd 〜 IAMロールで Amazon EC2 と S3 間をセキュアにAWSFluentdEC2IAM こんにちは、[cloudpack][] の @dz_ こと[大平かづみ][]です。 Prologue - はじめに 今回は、Fluentd から Amazon S3 へのログを送ってみます。 S3 への出力は、デフォルトで out_s3 プラグインが用意されています。セキュアな通信にするには、Credentials ( aws_key_id と aws_sec_key ) を設定すればよいのですが、設定ファイルに Creadentials を記載するのは、セキュリティやメンテナンスの点で不便です。 そこで、AWSが提供する AWS IAM の機能を利用して、Amazon EC2 インスタンスと Amazon S3 の通信を制限し、上記を実現してみたい