弊社で使っているAWSリソースの命名規則を紹介します | DevelopersIO
みなさんこんな画面を見たことありませんか？？ このような状態は避けるべきです。理由は以下の通り。 各リソースの役割がわかりにくい オペレーションミスが発生しやすい リソース削除などの判断が難しくなる 単純に見栄えが悪い そこで今回は弊社が環境を構築する際によく使う命名規則を紹介したいと思います。 新規でリソースを作成する際に参考にしていただけると嬉しいです。 ※AWSアカウントでシステムや環境を分離していたとしても、命名規則を守ったほうがリソースの見通しがよくなります。 リソース名から何を知りたいのかを考える みなさんはリソース名（主にNameタグ）から何を知りたいですか？？ 対象のリソースによっても異なりますが、共通で知りたいものは以下になるかと思います。 対象システム 環境(本番、検証、開発) また、リソースによってはこれ以外に知りたい情報もあるはずです。 Subnet、RouteTa
Handling AWS Bounce Notifications from Simple Email Service
Handling AWS Bounce Notifications from Simple Email Service About a year ago, I had to code a Rails application to handle bounce notifications from AWS SES. Amazon Simple Email Service is ridiculously easy to configure and use in a Rails application. As the instructions at the GitHub gem page explain, all you need to do is add the aws-ses Rails gem and create a configuration file called config/ini
https://blog.craftz.dog/de8cba5e50a5
You can find (just about) anything on Medium — apparently even a page that doesn’t exist. Maybe these stories about finding what you didn’t know you were looking for will take you somewhere new?
AWSコンソールのログイン用アカウントをIAMのベストプラクティスに従って作成してみた(設定編) | DevelopersIO
はじめに AWSチームのすずきです。 1つのAWSアカウントを複数の関係者で利用する環境で、AWSコンソールのログイン用アカウント(IAMユーザ)を AWSが公開しているベストプラクティスに従って作成する機会がありました。 多要素認証(MFA)や接続元IPアドレス制限などによる不正なログインの抑止と、 管理者権限が行使された際の通知を、AWSのサービスを利用して実現する方法について紹介させていただきます。 AWS Identity and Access Management ユーザーガイド: IAM のベストプラクティス 方針 AWSコンソールの認証パスワードが漏洩した場合でも、悪意をもった第三者によるシステム影響を抑える事を目標とします。 AWSの標準サービスを利用し、システムコストの発生や、管理者、作業者の作業効率が低下を抑えた対策をとる事とします。 AWS環境が不正に利用された場合で
Serverless Frameworkのプラグインを利用したLambda@Edgeのデプロイ | DevelopersIO
はじめに こんにちは、中山です。 少し前の話になりますが、CloudFrontのエッジロケーションでLambdaを動作させられるLambda@EdgeがGAになりました。めでたい。エッジコンピューティングのビックウェーブを感じます。 非常に可能性のあるLambda@Edge、とても便利なのですが個人的に少しだけ不満点があります。それはデプロイに手間がかかるという点です。Lambda@Edgeをデプロイするためには通常以下のフローを実施する必要があります。 CloudFrontディストリビューションの作成 Lambdaを作成してディストリビューションと関連付ける 適宜パーミッションを設定 Lambdaのコードを修正する度にディストリビューションを更新する 特に4番目が厳しい。執筆時点(2017/08/28)でLambdaとCloudFrontの関連付けはQualified ARNで指定する必
Amazon CloudFrontとAWS Lambda@EdgeでSPAのBasic認証をやってみる | DevelopersIO
どうも！大阪オフィスの西村祐二です。 特定のユーザにしかログインできないように、 サイト自体にBasic認証をかけたい時があると思います。 今回はS3でホスティングするSPAを想定して、 Amazon CloudFrontとAWS Lambda@Edgeを使ってBasic認証をかけたいと思います。 構成図 完成画面 完成後下記のような挙動になります。 ブラウザ上にURLを入力してアクセスすると、Basic認証の画面が表示されます。 認証が通ったら、S3に保存されているWEBページが表示されます。 作業手順 S3でSPA用のバケット作成 CloudFrontのディストリビューションを作成 Lambda@Edge用のLambda関数作成 作成したLambda関数でトリガーをCloudFrontに設定 S3での作業 SPAの静的ファイルを設置するためにバケットを作成します。 リージョンは「東京リ
Nuxt.js on AWS Lambda with Serverless Framework - mya-ake com
この記事についてこの記事はVue.js #2 Advent Calendar 2017 - Qiitaの 12 日目の記事です。 この記事では Nuxt.js（v2.6.2）を AWS Lambda で動かす方法について書いています。 Nuxt.js に関する説明もありますが、全体的にサーバー構築寄りの内容になっています。 しかし、Node.js で AWS にデプロイまでできる Serverless Framework というツールを利用しており、サンプルコード の npm scripts を実行するだけで AWS 上に環境を作れるようにしています。（AWS への登録と Credential の生成は必要です） ご興味のある方はそちらも参照してみてください。 また、先に断っておくとこの記事では API Gateway をエンドポイントとします。 API Gateway をエンドポイントす
Lambdaを使ってS3にアップロードされたファイルを自動的にEC2(Windows)内にダウンロード(同期)してみる | DevelopersIO
どうも！大阪オフィスの西村祐二です。 S3にアップロードされたファイルをEC2内に自動的にダウンロードしたいと思うことはよくあると思います。 自動化する方法はいろいろあると思いますが、 今回はLambdaとSSM、AWS CLIを使って自動化してみたいと思います。 さっそくやってみましょう。 構成図 今回、想定する構成が下記の図になります。 S3にファイルがアップロードされたら、LambdaからSSMを実行し、 EC2(Windows)にてAWSCLIのS3 Syncコマンドを実行します。 この構成の利点 私が思うこの構成の利点としては、 ・EC2側はAWS CLI設定とSSM Agentのインストールだけで済み、今後の運用不可が軽減されそう ・Lambdaの実装がSSMを実行する部分のみになる はじめはEC2にFTPサーバをたてて、LambdaでS3からファイルを取得し、EC2にコピーし
コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
概要 Lambdaは100msの実行時間単位でオンデマンドに課金されるため、立ち上げっぱなしのEC2インスタンスよりも、料金が安くなる可能性があることが一般に知られている。 しかし、以下の性質を満たすアプリケーションでは、EC2インスタンス上に構築したケースと比較して、Lambda上に構築したほうがコスト効率が悪くなるのではないかと考察してみた。 Lambda functionの実行時間のうち、ネットワークI/O時間が支配的である Lambda functionの実行終了を同期的に待たなければならない 複数のレコードをLambda functionの引数に渡すことができない Lambdaの基本コスト構造 まず、Lambdaのコスト構造を把握する。 Lambdaの料金表[1]によると、「functionに対する合計リクエスト数」と「functionの合計実行時間」に応じて料金が発生する。 後
ELBのスティッキーセッションについて調べてみた | DevelopersIO
はじめに 藤本です。 私事ですが、先週「AWS認定Sysopsアドミニストレーター - アソシエイトレベル」を受験しまして、 無事合格しました(8888 更に昨日「AWS認定デベロッパー - アソシエイトレベル」を受験しまして、 無事合格しました(8888 トリプルアソシエイトになりました。 今回はELBのスティッキーセッションがどういうものなのか理解できていなかったので調べてみました。 概要 ELBにクライアントとバインド先を固定するスティッキーセッションという機能があります。 HTTPレスポンスにELBでCookieを埋め込んで、 そのクッキーを基にバインド先のインスタンスを固定するというものです。 ELBのスティッキーセッションはCookieの有効期限設定が2種類あります。 任意の有効期限を指定する アプリケーションのCookieに従う スティッキーセッションを利用したい場合、 アプ
serverless + webpack + babel で AWS Lambda をナウく書く - scramble cadenza
イントロ 最近 AWS Lamdba を仕事で触っています。 serverless やら Apex なり色々あるわけですが、沢山ありすぎてよくわかりません。 今までは Apex の手軽さに甘えていましたが、そろそろ serverless が本気を出してきたという噂を聞き、serverless を使い始めています。 どうせ serverless を使うなら、もう全部使い倒してやろうということで、babel も意識高く使っていきたいわけです。 この記事では serverless + babel を使うところまでをまとめました。 環境 serverless@1.1.0 serverless-webpack@1.0.0-rc.2 webpack@1.13.3 serverless まずは雛形作成 # template 指定は必須 # `sls` は `serverless` コマンドの alias
Amazon VPC IPアドレス設計レシピ | DevelopersIO
はじめに AWSにはEC2やRDS、RedshiftなどVPCに対応したサービスが数多くあります。 これらのサービスを利用する場合、まずはVPCやサブネットを作成します。 VPCの作成ではIPアドレス(=CIDR)に何を指定するか迷う方が多いのではないでしょうか。 私がVPCとサブネットのCIDRを決める際に考慮しているポイントは、ざっと以下の通りです。 プライベートIPアドレス範囲から指定する VPNやDirect Connect利用時はオンプレミスとの重複に注意する VPCピア利用時はVPC間で重複できない 将来の拡張に対応可能なCIDRを選択する 最低でも/28以上が必要 CIDRブロックのうち、5IPは利用できない ELBを配置するサブネットは/27以上のCIDRかつ、少なくとも8個の空きIPを用意する それぞれの詳細をご紹介し、最後に優先順位をまとめます。 プライベートIPアドレ
【初心者向け】AWS IPアドレス設計で押さえておきたいポイント | DevelopersIO
こんにちは、梶です。 今日はAWSにおいてIPアドレス設計（ネットワークアドレス設計）で数年後ハマらないようにするために、ポイントを共有したいと思います。 特に、オンプレミスとAWS間を直接ネットワーク接続する際も、プライベートアドレスについて確認が必要です。 内容としてすごく地味だと思いますが、まとまった資料が無かったので作成してみました。 背景 「ネットワークアドレスを設計するときにはこのへんを考慮しておくと後々困らない」という内容があるといいよね。 と社内で声が上がりましたので作成してみました。 プライベートネットワークアドレス AWS VPCは作成開始時に決定したプライベートネットワークアドレスは、後から変更はできないため注意すること。 インスタンスへの固定IPアドレスの利用は避けること。 CloudFormationにおいてIPアドレスを固定することにより、メンテナンス上の問題が
最強のセキュリティでAWSマネジメントコンソールにアクセスする方法 | iret.media
シンジです。AWSへのログイン時、普通はアカウント名とパスワードを使いますよね？今時パスワードは危ないと思いませんか？そこで多要素認証ですよね。しかし、cloudpackは多要素認証すら使いません。何故なら、パスワードを入力するという行程がそもそも無いからです。 まず設備から揃えた まず社内インフラについては全てAWSに実装していますが、ここではDirect Connectを用いて専用線による接続を行っています。かつ、複数拠点を閉域網で閉ざされたネットワークを構成しています。 ではインターネットはどこから出入りするかというと、一度全ての通信は品川データセンターに集約されて、そこから単一のグローバルIPで通信するようになっています。 これによって、どの拠点からでもお客様環境にアクセスするIPアドレスは1つに完全固定出来るわけです。セキュリティグループの設計が楽になりました。将来的にはグローバ
【AWS 再入門】VPC 環境に踏み台サーバーを構築して SSH 接続してみよう | PSYENCE:MEDIA
前回の記事で EC2 と RDS によるミニマムなサーバー環境の構築手順をご紹介しました。 この環境はアプリケーション・サーバーがユーザー (Internet) からの HTTP リクエストを受け付けるだけでなく、管理者によるサーバーメンテナンスのための SSH 接続も受け付けるという構成になっています。AWS 再入門ということで、最初のお勉強としてはこれでも上出来かと思いますが、いくらミニマム構成とはいえ、これをこのまま本番運用するとなるとセキュリティの観点からイマイチよろしくありません。 ではどうするのが良いのか？ そもそもアプリサーバー自体が外部から直接 SSH 接続を受け付けること自体よろしくありません。外部からのSSH接続は、アプリサーバーとは別の専用サーバーが受け付けるべきです。そしてそのサーバーからアプリサーバーにSSH接続するといった二段階接続の構えをするというわけです。し
【AWS 再入門】EC2 + RDS によるミニマム構成なサーバー環境を構築してみよう | PSYENCE:MEDIA
フロントエンドエンジニアですが、AWS 始めてみます そんな訳で、UI デザイナー > Flex ディベロッパー > マークアップエンジニアと、今日までフロントエンド一辺倒で来た私 wakamsha ですが、とある事情から Amazon Web Services ( 以下、AWS ) と戯れてみることになりました。とはいえインフラ関連の知識がほぼゼロな自分が一からお勉強するというのもなかなかどうして学習コストがかかるので他の人にお任せするという選択肢もあったのですが、こんな機会でもない限りずっとやらないだろうということで、軽い気持ちで始めてみようかと思います。 それにしても、前職はAWSヒャッハーッ！な会社に属していたにも関わらず全くと言ってよいほど自分から触ろうとしなかったのに、人は変わるもんですねぇ…（適当）。 前提条件 AWS アカウントを取得済みである EC2 にキーペアを登録済み
【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみる | DevelopersIO
よく訓練されたアップル信者、都元です。今回のお題は久しぶりにVPCです。 この記事は、アップデート版が存在します。最新情報は【AWS】VPC環境構築ノウハウ社内資料 2014年4月版を参照してください。 VPCを利用する理由 弊社で構築するAWSのサーバ環境は、一部の例外を除いて全てVPCを利用しています。 突然ですが、筆者はあまり大規模なシステムに携わった経験がありません。大規模なプロジェクトだと「数百数千台のサーバがラッキングされ、それが論理的なネットワークで区切られていて」「複数のデータセンターが冗長化された専用線で結ばれて」等、正直ちょっと想像つかない世界があるんだと思います。よくわかんないですが。 (c)John McStravick. (CC BY 2.0 Licensed) 逆に、小さなシステムであれば、月々数万円でレンタルサーバを借りて「1台のマシンの中にWebサーバとDB
AWSで避けるべき5つの間違い | POSTD
今年からAWS（Amazon Web Services）クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈：（左から）DNS、CDN、静
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
１日１億イベントを捌く サーバーレスアーキテクチャ
Amazon Linuxがコンテナ化されたので、Macで動かしてみた。 - Qiita
