ついにGOがAWSにきた！！ 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉 ついにGolangがAws lambdaに対応しました！！！！ 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉 今まで、様々なライブラリを使ってなんとか無理くり、やっていましたが、これでできるようになりました！ それに伴い、serverlessも対応しましたので、早速バイト先のserverlessのボットのプロジェクトをしれっと全部Goにしたので、 その時のことを書いていきます。 serverlessがどうなったのか serverlessフレームワークは今は、使われているところが徐々に増えてきていますが、serverlessはこれまで、Goは対応しておらず、バイナリをaws cliであげるとか、pythonのCのラ

AWS SDK for Goがついにプレビュー版になりましたね！ まだまだ仕様が変わる気がしないでもありませんが現バージョン(v0.6.2)でのS3のアップロードサンプルをやってみます。 CloudFormationでS3bucketをつくる S3バケットをつくりましょう。作り方は何でもいいです。今回はCloudFormationを使ってみます。 こんな感じのJSONを用意してStackを実行してS3バケットをつくってください。 バケット名は既にある名前だとつくれないので注意してください。 { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { }, "Resources": { "DemoBucket" : { "Type" : "AWS::S3::Bucket", "Properties" : { "AccessContr

EC2でパブリックIPアドレスを固定したい時にはEIP (Elastic IP) を使いますが、 それなりにAWSを使っているひとからも、「どういう時に料金が発生するのか分かりにくい」という話を聞くことがあります。 ちょっとまとめてみました。 その前に : そもそもEIPとは ひとことで言えば「EC2インスタンスで使える、パブリックIPアドレス（グローバルIPアドレス）の固定IPアドレス」です。 これを説明しだすと長くなるので、参考URLをご紹介するに留めさせてください。 Elastic IP アドレス - Amazon Elastic Compute Cloud サブネットとインターネット通信 ｜ Developers.IO 問題は、これが完全に無料で使えるわけではないということです。 公式には、下記のように記載されています（記事執筆時点での東京リージョンの場合）： $0.00 : 実行

セキュリティグループは、1 つ以上のインスタンスのトラフィックを制御する仮想ファイアウォールとして機能します。インスタンスを起動するときに、1 つ以上のセキュリティグループとインスタンスを関連付けます。各セキュリティグループに対してルールを追加し、関連付けられたインスタンスに対するトラフィックを許可します。セキュリティグループルールはいつでも変更できます。新しいルールは、セキュリティグループに関連付けられているインスタンスすべてに自動的に適用されます。インスタンスに到達できるトラフィックを許可するかどうかの判断では、インスタンスに関連付けられているすべてのセキュリティグループのすべてのルールが評価されます。 by AWS 要するにファイアウォール。 あるある事例 同じ様なポリシーが乱立 AWS担当者が一人の場合にはあまり起こらないが、複数人で設定を行うと同じ様な設定が複数個作られる。特にた

まずはapacheが入ってるか確認 rpm -qa *http* 入ってなかったらインストール yum install httpd* これでインストールできるなんて！yum便利すぎる 起動　　/etc/init.d/httpd start 停止　　/etc/init.d/httpd stop 再起動　/etc/init.d/httpd restart 早速、起動してみたのですが 『そんなページないよ』って言われてしまいました あれれれ confファイルとかの設定してもダメだったので ポートを疑ってみました ここでチェック↓ http://www.cman.jp/network/support/port.html 案の定こんなメッセージが・・・ ホスト：（ホスト名）　ポート：80　にアクセスできませんでした。 EC2をみてみたら、２２番しか解放されていませんでした。うぬー。 なので、EC2の

はじめに AWSチームのすずきです。 クラウドサービスのAWS、有効なクレジットカードと電話番号があれば、10分ほどでその利用が開始できます。 AWS アカウント作成の流れ この様に簡単に取得できるAWSのアカウントですが、その管理が不適切な場合、意図せぬ事故の原因となることがあります。 今回、AWSを安全に安心して利用するため、AWSアカウントを開設後に実施すべき設定についてまとめてみました。 AWS環境が、弊社クラスメソッドメンバーズを初めとする請求代行サービスを利用されている場合、一部当てはまらない項目もありますのでご注意ください。 目次 ルートアカウントの保護 MFA（多要素認証）の導入 アクセスキーとシークレットキーの確認 IAM（Identity and Access Management）設定 IAMグループ作成 IAMユーザ作成 IAMユーザの認証設定 IAMのパスワードポ

よく訓練されたアップル信者、都元です。アカウント認証というのはIDとパスワードによってなされるのが一般的です。パスワードは複数の文字種を使い、数字を含め、長いモノを設定する等、各種プラクティスはあちこちで議論されていますが、そもそものアカウントの数が多くなると、厳正なパスワード管理にもどこかにほころびが出てくる可能性 *1が出て来ます。 MFAによるセキュリティ向上 そういった状況で、パスワードだけに依らないセキュリティ向上の手段として、AWSではMFA（Multi-Factor Authentication - 二要素認証）に対応しています。 具体的にどういうことかというと、ログイン時には通常のIDとパスワード *2に加えて、そのログインのタイミングで手持ちのデバイス（ハードウェア）に表示されている数字 *3を入力しなければ、認証に成功しない、という認証方式です。デバイス上の数字は一定時

かなり痛い目を見たので、自戒の意味も込めてメモ。 事象 今年4月に,社内向けにある用途のアプリケーションサーバとして、microインスタンス上にRails + Nginx + MySQLの環境を作成。 6月でそのアプリの用途が終わったが、お上からの要望で7月いっぱいは24hで稼働させておくことに。 7/31にサーバをTerminate. 見積もりでは、利用料金は数ドルで済むと考えていました。実際、6月まではその通りでした。 ですが、7月分の利用料金を確認してみると、なんと80ドルも課金されていました。 上記80ドルすべてがEBSのI/Oに対しての料金でした。 インスタンスの稼働時間自体は無料範囲内です。 7月はほとんど使っていないのに、なぜ？と考えてみました。 原因 調査をしようにもサーバ自体はTerminateしているので、手の打ちようがありません。ここから先は全て私の推測です。 もうお

AWSを使いはじめる時に入力したメールアドレスとパスワードでログインするアカウントをAWSアカウントと呼びます。 このAWSアカウントは、何でもできる権限を持ったアカウントになります。 しかし、普段の運用においては何でもできる権限は不要のはずです。 また、AWSの運用を複数人で行う場合、共有アカウントの利用は好ましくありません。 AWSでは権限を限定したユーザをIAMで作ることができます。 普段はIAMで作成した権限が限定されているアカウントで運用しましょう。 パスワードポリシーを設定する IAMユーザにはパスワードをかける際のポリシーを定義することができます。 強固なパスワードを設定してもらうためにまずこれを設定しましょう。 メイン画面から[IAM]を選択する 左メニューから[Password Policy]を選択する パスワードのポリシーを設定する チェックが多いほど厳しいポリシーにな

最低限セキュアな構成とは 「最低限セキュアな構成」を次のように定義する。 Webサーバーやデータベースサーバーが直接、インターネットに公開されていない。 公開・非公開に関わらず、特定のポートのみインバウンドを受け付けている。 非公開のサブネットは特定のサブネットからのみインバウンドを受け付けている。 踏み台サーバーは必要な時のみ存在している。 この定義を満たす構成は次のようになる。 構築手順 ざっくりと以下の手順を踏む。 VPCの構築 パブリックSubnetの構築 Subnetの構築 Internet Gatewayの構築 Route tableの構築 プライベートSubnetの構築 Subnetの構築 パブリックSubnetにNATインスタンスを構築 Elastic IPのアロケートとNATインスタンスへの結び付け Route tableの構築 Auto Scaling Groupのため

このエントリは、随筆風にだらだら書きたいと思います。 （なんとなくそういう気分だからです） このブログの過去エントリを翻ってみると、 はじめてAWSに関するエントリを書いたのが2012年11月。 実際に使い始めたのはもっと前からなので、 AWSを扱い始めてから、もう5年以上過ぎていることになります。 AWSの進化は速く、 この5年の間にいろいろなサービスがリリースされました。 ですが、同時に、基本的な考え方は変わってないなとも思っています。 このエントリでは、 私がAWSでシステム構成を考えるときに気をつけていることを、 （その中でも特にずっと変わっていないこと） 改めてまとめてみたいと思います。 消えて困るものはとにかくS3昔から、JAWS-UG (AWS User Group - Japan)で登壇者は、 自分の好きなAWSのサービスを言う習慣がありますが。 私は好きなサービスの一つは