Amazon Web Services Advent Calendar7日目の記事です。 寒さ厳しくなる中、みなさまいかがお過ごしでしょうか。 みんなのウェディングのインフラエンジニア横山です。 11/27~12/1にかけてAWSのカンファレンスであるAWS re:Invent 2017が開催されました。 多数の新サービスがアナウンスされ、早速利用している方も多いのではないでしょうか。 個人的には自然言語処理サービスである「Amazon Comprehend」に注目しています。 日本語対応が待ち遠しいところです。 さて、今回はそんな「Amazon Comprehend」ではなく、同じくre:Inventで発表された「Amazon Guard Durty」を利用してみたのでレポートします。 Amazon Guard Durtyとは 「Amazon Guard Durty」とは、AWS上のVP
AWS SAM Local（ベータ版） – サーバーレスアプリケーションをローカルに構築してテストする | Amazon Web Services
Amazon Web Services ブログ AWS SAM Local（ベータ版） – サーバーレスアプリケーションをローカルに構築してテストする 今回、新ツール、SAM Local のベータ版がリリースされました。これにより、簡単にサーバーレスアプリケーションをローカルに構築してテストできるようになります。この記事では、SAM Local を使用し、クイックアプリケーションの構築、デバッグ、デプロイを実行します。これにより、エンドポイントに curl コマンドを使用してタブやスペースで投票できるようになります。AWS は サーバーレスアプリケーションモデル（SAM）を昨年導入しました。これにより、デベロッパーはサーバーレスアプリケーションをより簡単にデプロイできるようになっています。SAM の基本にまだなじみがない場合は、私の同僚である Orr が SAM の使用方法について書いた素
はじめまして、みんなのウェディング 横山です。 ご覧いただいてる通り、みんなのウェディングではエンジニアリングブログを運営しています。今回、エンジニアリングブログのCI環境をCodePipeline＆CodeBuildへ移行したので概要をお伝えします。 エンジニアリングブログは何を使って構築されているのか。 middleman という静的サイト構築用のフレームワークを利用しています。 middlemanでは記事の追加・修正後、HTMLファイルを再生成するためにビルド作業を行う必要があります。 みんなのウェディングのエンジニアリングブログでは、記事の追加・修正はマスターブランチへ変更をマージすることで行っています。こうすることで、マスターへのマージをトリガーにビルド作業および生成されたHTMLファイルのデプロイを自動で行うことができます。 ビルド&デプロイ自動化の仕組み これまでは、Circ
MySQLのインデックスの代わりにElasticsearchを使おうと思い立っていろいろやってみた結果、Elastic社のホスティングけっこうオススメなんじゃないかってなった話です。これです: www.elastic.co 経緯としては、AWSにのっけたサービス、とりあえずMySQLとRedisだけでやってきた仕組みが、そろそろノーキャッシュ新規クエリ単発で1秒以上かかる場合が出てきたというのがあります。 アプリケーションで決まったパターンの問い合わせだけやってるぶんには、問い合わせのパターン数だけ複合インデックを作ればいいし、負荷分散したければリードレプリカが簡単、ということでほとんどの場合MySQLでいいのですが... MySQLは個別のインデックス勝手に組み合わせてくれない、全パターン定義しないといけない 管理者が使う検索機能のよっては、想定したインデックスにうまくヒットしない条件に
はじめに こんにちは、川原です。 AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。 ポリシーの基本 ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。 例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
Gyazo + Amazon CloudFront で簡単☆高速スクリーンショット共有 個人用の Gyazo 環境向けに、クライアントに手を入れて直接 Dropbox や S3 へスクリーンショットをアップロードするというテクニックがある。自前サーバを管理することなく利用できて大変ナイスなものの、クライアント側で比較的重要な固有情報を含んだ状態になっているので、取り扱いが若干難しいと思った。 そこで AWS Lambda を利用して、S3 へのアップロードを行う署名付き URL の発行をそちらで行い、クライアントでは受け取った情報だけでアップロード処理が進めれるような体制を作ってみた。 処理の流れと役割 Gyazo スクリーンショットを撮る。 通常ならば Gyazo サーバへスクリーンショットをアップロードするところを、後述する AWS Lambda へ S3 アップロードのための署名付き
Lambdaファンクション AWS Lambdaの最も重要なコンセプトと言えます。利用できるプログラミング言語は執筆時点ではNode.jsのみですが、将来的には他の言語のサポートも予定されています。コードはマネージメントコンソールの画面上に用意されている組み込みのエディタを利用して書くことも可能ですし、ローカルPCなどで書いたコードをZip形式にしてアップロードすることも可能です。なお、ネイティブライブラリを含む各種ライブラリを利用することも可能であり、その場合は利用するライブラリをコードと一緒にZipファイルとしてまとめた上でアップロードする必要があります。 Lambdaファンクションではコードだけでなく、その実行環境に関する指定も行います。メモリ容量はデフォルトでは128MBとなっていますが、64MBごとに最大1GBまで設定が可能となっています。また、メモリ容量の変更に応じて利用可能な
以前AWS LambdaファンクションをGulpでデプロイというブログを書きましたが、今回はAWS Lambdaファンクションの管理ツールApexをご紹介したいと思います。 Apexとは @TJ Holowaychukさんが中心となって開発されている、AWS Lambdaファンクションをビルド、デプロイ、管理するためのツールです。Mediumでも語られていますが、TJ Holowaychukさんはサーバーレスなアーキテクチャが実現できるAWS Lambdaに魅力を感じつつも、AWS Lambdaのユーザビリティの低さに不満を持っており、その問題を解決するためにApexの開発に至ったようです。 Apexの特徴 AWS Lambdaがネイティブにサポートしていない言語をサポート(本ブログ記事執筆時点ではGolangをサポート) バイナリから簡単にインストール可能(CI/CDへの組み込みが容易)
前回の記事で、単純な静的サイトのオートデプロイフローまで完了した後の続き。 後編 「問い合わせフォームもサーバレスでDevOps!」 認証 AWS Cognito 処理 AWS Lambda 通知 AWS SES を利用して、もちろんサーバレスで。 Gibhubへのstaging/masterへのpush のみで、 CircleCI経由で各種環境へ自動デプロイを実現。 #前提 前回同様の続きなので、 s3site.proudit.jp -> 本番サイト st.s3site.proudit.jp -> ステージングサイト が、すでにGithub+CircleCiにてデプロイ可能である前提で進める。 #構築内容 Cognito準備 フォーム/JavaScript準備 Lambda準備 SES準備 CicriCIデプロイ処理修正 オートデプロイテスト #Cognito準備 CognitoはWeb
S3とLambdaとCognitoを使って、簡単でセキュアなお問い合わせフォームシステムを作ってみます。 記事執筆当時、Cognitoがバージニア/アイルランドのみ利用可能だったため、今回はS3/Lambda/Congito全部バージニア(us-east-1)に揃えています（S3とLambdaはリージョン揃える必要があります）。2015年9月以降、東京リージョンでもCognitoは利用可能となっています。 全体像 S3上にホスティングしているお問い合わせフォームから投稿すると、S3上にJSON形式で内容がuploadされます。ファイルがuploadされると、Lambdaがイベントフックして内容をGmailに送信する構造です。 お問い合わせ数の少ないサイトでは、これで十分でしょう。 SQLインジェクションとは無縁ですし、負荷も気にしなくて良いので、選択肢としてはありかなと思います。 0 準備
業務で製品の問い合わせフォームを作る機会があったので、まるまるAWSの機能を使ってみようかと。。 下記を参考にさせて頂きましたが、nodemailerの使い方がよく分かっていないので、メール部分はSESを使ってみました。SES以外の設定方法はこちらで S3 + Lambda + Cognitoを使って、簡単お問い合わせシステム構築 http://qiita.com/takuma_yoshida/items/3bd3af8b09307d25981a #1.SESの設定 1-1 メールアドレスを登録 まずは使うメールアドレスを登録。「Email Addresses」の「Verify a New Email Address」からメールアドレスを登録。設定すると登録確認用のメールが飛んでくるので、メール本文にあるURLをクリックして本登録する。登録がされるとStatusがverifiedになります
前回まで、Amazon Redshiftの機能や特徴について説明を行いました。今回からは実践編として、Amazon Redshiftクラスタを起動するところから、データのロード、SQLの実行やクラスタの操作まで説明していきます。今回は、Redshiftクラスタの起動と、自分のマシンからのRedshiftクラスタへの接続までを説明します。 今回のチュートリアルでは、最小構成（XLタイプのシングルノード／2TB）のRedshiftクラスタを起動しますが、この場合一時間あたり$0.85の費用（2013/5/3時点）が発生し、EC2の最小インスタンスの料金に比べてかなり高くなります。試される場合には、完了後にRedshiftクラスタをシャットダウンさせるなど管理にご注意ください[1]。 なお、Amazon Redshiftを使用するには、AWSのアカウントを事前に準備しておく必要がありますが、ア
モバイルから欲しい情報があって、サーバー立てるのも大げさだし最近良く聞くLambdaを使ってみることにしました。ちょっと調べたらいろいろわかりやすい情報が出てきて本当に助かりました。 手元で動かしてテスト 初めてのJavaScript、初めてのAWS Lambda ｜ Developers.IO AWS Lambdaのための関数のローカル開発とテスト – Qiita この二つを参考にしました。とりあえず、npmで必要なライブラリをインストールして、手元でテストをして動作確認します。index.jsはこういう感じに書きます。 index.js exports.handler = function(event, context) { ... }; 動作確認はこんな感じでやりました。本体ファイルはindex.jsです。それを取り出して、仮のeventとcontextを渡して実行しています。 te
今年の夏に発表されたAmazon API Gatewayから、モバイルアプリのバックエンドについてのアーキテクチャのあるべき形を検討しておりました。自分の中ではある程度の結論が出ていて、幾つか実験的に構築して満足する結果は出ております。ところが、先日のreInventでAWS Mobile Hubが発表されたことにより少し混乱することになりました。AWSが勧めるアーキテクチャはどんな形なんだと。ということで、一旦整理してみます。まずは、API Gateway・Mobile Hubを使ったパターンのそれぞれの比較です。 Amazon API Gateway API Gatewayを利用した場合は、モバイルアプリからのAWSリソースの利用はAPI Gatewayを経由することになります。また実際にはAPI Gateway⇒Lambda or API Gateway⇒Lambda⇒他のAWSリソ
Amazon.co.jp: Amazonのクラウドエンジニアが選ぶ技術書: 本
本 の優れたセレクションからオンラインショッピング。
Developers.IO 2015( http://devio2015.classmethod.jp/ )トラックC-3の資料です。
基礎からすぐできるAWSと題した簡易ブログシステム構築の４回目です。前回はWebサーバーインストール～ファイアウォール設定～DNS名前解決設定を実施しました。今回はDBサーバーインスタンス作成～接続確認～NATサーバーインスタンス作成～疎通確認を行います。 AWS上にVPCを一つ作成し、その中に公開用のVPCサブネットとプライベートのVPCサブネットを作成します。公開用のVPCサブネットにはWebサーバとDBサーバのインターネット接続用NATサーバを構築します。プライベートのVPCサブネットにはDBサーバを構築します。 作業は検証環境の作業端末から接続します。 ・検証環境の構成図 図１ 構成図 ・実施内容 AWSにアカウントが作成されているものとします。（今回は⑩～⑭まで。） ① VPC作成 ② VPCサブネット作成 ③ インターネットゲートウェイ作成 ④ ルートテーブル作成 ⑤ インスタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
