運用的関心事を実験的にAWS Lambda on VPCにお任せしてみたので所感 - tehepero note(・ω<)
2016 - 02 - 25 運用的関心事を実験的にAWS Lambda on VPCにお任せしてみたので所感 AWS Lambda Slack リリースした時はきれいだったコードも、運用に曝されることで汚くなっていったりしますよね。 ChatOpsな今のプロジェクトでは、「 とあるイベントが発生した際に、運用担当者が迅速に反応できるようSlackに通知してほしい 」という要望が出てきたりしています。以前であれば、メール通知してたところでしょうかね。 運用的関心事は移ろいやすい かつて Java で AOP が流行りだした頃に、ロギングだったり権限チェックだったりの処理を メソッド にweavingしたInterceptorに追いやるという、所謂「横断的関心事」を ビジネスロジック の本質から除外するという手法がありましたね。 自分が運用的関心事と言っているのは何のことかというと、 アプリ
AWS Summit Tokyo 2015 で、「freeeの急成長とAWS」というタイトルで発表しました - futoase
AWS Summit Tokyo 2015 www.awssummit.tokyo アマゾンデータサービスジャパン様 主催のAWS Summit Tokyo 2015 で、 freeeの急成長とAWS というタイトルで発表しました。 発表させていただいたプレゼンテーションの内容は、 「創業期から現在に至るまでのインフラの変化、AWSさんの各種クラウドサービスを利用しつつ、会社の急成長と共にどのような形に変わっていったのか」 となっています。 AWS Summit Tokyo 2015 freee // Speaker Deck プレゼンテーション資料の作成には、弊社CTO 横路を始め、 インフラチームによるレビュー、及び 弊社マーケティングチームによるヘルプなどがあり、 作成することができました。 無事、発表が時間内に収まる形でできたのでとても良かったです。 私が入社したのは2014年6月
Amazon VPC環境にメンテナンス用の踏み台サーバを構築する | DevelopersIO
よく訓練されたアップル信者、都元です。前回は「Amazon VPCを使ったミニマム構成のサーバ環境を構築する」と題して、Amazon VPCに小さなサーバ環境を構築しました。この環境は、アプリケーションサーバ（Webサーバ）がユーザからのHTTPを受け付けつつ、管理者によるメンテナンスのためのSSHの受け付けも兼ねている状態です。セキュリティの観点からは、あまり好ましい状態とは言えませんね。 そこで今回は、メンテナンスのための踏み台(bastion)サーバを構築し、よりセキュアな構成にしてみましょう。環境の構成図は右の通りです。まず、アプリケーションサーバはHTTPのみを受け付けるようにSecurity Groupを調整します。また、public subnetの中にもう一つサーバを起動し、踏み台として使います。こちらはSSHのみを受け付けるように調整します。踏み台サーバは常時起動しておく必
AWSで最低限セキュアな構成を組む - Qiita
最低限セキュアな構成とは 「最低限セキュアな構成」を次のように定義する。 Webサーバーやデータベースサーバーが直接、インターネットに公開されていない。 公開・非公開に関わらず、特定のポートのみインバウンドを受け付けている。 非公開のサブネットは特定のサブネットからのみインバウンドを受け付けている。 踏み台サーバーは必要な時のみ存在している。 この定義を満たす構成は次のようになる。 構築手順 ざっくりと以下の手順を踏む。 VPCの構築 パブリックSubnetの構築 Subnetの構築 Internet Gatewayの構築 Route tableの構築 プライベートSubnetの構築 Subnetの構築 パブリックSubnetにNATインスタンスを構築 Elastic IPのアロケートとNATインスタンスへの結び付け Route tableの構築 Auto Scaling Groupのため
AWS NATインスタンス構築とSerfによる冗長化 | Weboo! Returns.
2015.12.17追記：マネージドNATゲートウェイというサービスがリリースされました。 AWS VPCでプライベートサブネット内に起動したインスタンスは、インターネットと通信することができません。外部リポジトリやAmazon S3等の各種サービスも利用するためには、NATインスタンスを用意して外部との通信を中継する必要があります。 このためにAWSではNATインスタンス用のオフィシャルなAMIが提供されているのですが、わざわざ専用のインスタンスを稼働させるのは勿体ないので、ヴェッテルでは管理用サーバにNATインスタンス機能を持たせて併用しています。またNATインスタンスがSPOFにならないように障害が発生したら、自動的にフェイルオーバーするような冗長化も行っています。 ここでは、オフィシャルなAMIを利用せずに独自でNATインスタンスを構築する方法と Serf による冗長化の方法を紹介
Amazon VPCを使ったミニマム構成のサーバ環境を構築する | DevelopersIO
よく訓練されたアップル信者、都元です。AWSにおいては、ネットワーク環境をあまり気にせず、数クリックで簡単にサーバを構築できるのは一つのメリットだと言えます。しかし、本格的に運用するシステムに関しては、ネットワーク環境をコントロールする需要も出てきます。AWS Virtual Private Cloud (VPC)を使えば、AWS上に仮想ネットワークを定義し、その上に各種サーバを配置することができます。 深く考えずに非VPC環境に構築してしまったAWSサーバ環境は、簡単にはVPC環境に移行することはできません。従って弊社では、小さなシステムであっても、最初からVPC環境にシステムを構築することを推奨しています。「非VPCが許されるのは小学生までだよねー」とボスが申しておりました。かといって、ネットワークの構成をゼロから考えて構築するのもひと苦労であるため、本エントリーでは、システムの初期段
t2.microでNATインスタンスを作る - aws memo
2015/12/18追記 マネージドNATが出たので、わざわざNATを建てずにこちらをまず検討すると良いと思う。 Amazon Web Services ブログ: 【新機能】マネージドNATゲートウェイが利用可能に ーーー t2.microでNATインスタンスを建てようとするも、NAT用AMIは PVしかない(2014年7月11日時点)という理由で諦めてる人向けのメモ。 (NATインスタンスの建て方自体は、このページ末尾のSlideshareを参考に) 基本的にやることはPVもHVMも変わらず、 ip_forward有効にしているLinuxを起動 EC2の設定で src/dst checkをdisabledにしておく routing tableを適切に設定しておく これさえキチンとしていれば、たいていのLinuxで( Vyatta等を含む)動作するので、HVMかPVかはそもそも関係ない。(
AWS Solutions Architect ブログ
AWSソリューションアーキテクトの安川 (@thekentiest)です。 前の荒木 (@ar1)の投稿で、トンネル技術を使えばいろんなEC2-ClassicやEC2-VPCでサポートしていないプロトコルでも利用可能であるという話がありました。その投稿でも触れられていたとおり、トンネリングを使えばIP Multicast/BroadcastもEC2インスタンス間でやりとりする（しているかのように上位レイヤのアプリケーションに思わせる）ことができるので、トンネリングを使ってIP Multicast/Broadcastを前提としたアプリケーションやミドルウェアを動かす例も多く見られます。 トンネリングは汎用的で、様々なプロトコルを動作させる目的で使える点は優れています。しかし、通信のオーバーヘッドが伴うのはもとより、特定のノード間でトンネリングをする設定をしないといけないので、その部分が煩雑で
EC2でマルチキャスト
The document provides information about an AWS webinar on AWS Systems Manager presented by Solutions Architect Kayoko Ishibashi. It includes an agenda for the webinar covering an overview of AWS Systems Manager, demonstrations of key features like resource groups, inventory, automation, and security best practices. The webinar aims to help participants understand the overall capabilities of AWS Sy
AWS VPN (1) between VPC VPN G/W and Debian Linux (racoon, setkey, quagga) with NAT | 外道父の匠
AWS VPN (1) between VPC VPN G/W and Debian Linux (racoon, setkey, quagga) with NAT AWSのVPCにはVPN機能がついているので、利用すると社内など任意のサブネットとVPCの間を、Privateアドレスで暗号化通信できるようになります。 通常このVPC VPNは、ハードウェアルーターを用いて接続するべく、一般的なルータの設定ファイルを配布してくれる至れり尽くせりな環境なのですが、ウチは貧乏でLinuxが大好きなので、 Debian Wheezyで接続を試みるのでした。 ２つの方法 Linuxでは私が最初に構想した、綺麗で完全な冗長化構成はできないことがわかり、妥協案として２つの構成案ができたため、２つのエントリに分けて書くことにします。その２つの案とは、 綺麗な冗長化＋NAT 泥臭い冗長化＋非NAT で、まず
はじめてのAmazon VPC
こんにちは、牧野です。 最近、鎌倉の「コクリコ」というお店のクレープにハマっています。 今のところ、レモンシュガーとアンチョビサラダが一押しです。ほのかに甘い、縁がパリパリの生地に、強めの酸味や塩味がよく合います。 鎌倉に行くことがあれば、ぜひ試してみて下さい。 さて。 だいぶ前になりますが、AmazonのAWSを使う機会があり、その時にVPC(バーチャルプライベートクラウド)を使いました。今日はその話題です。 VPCは、クラウド上にプライベートなネットワークを用意し、その中にEC2サーバーを設置できるというものです。 まず、一つのローカルネットワークを作成し、さらにその中に複数のサブネットワークを作り、各ネットワーク内にサーバーを設置できます。あるサブネットは外部公開用、別のサブネットは内部専用というように、自由にネットワークを設定できます。 便利なのですが多少クセがあり、VPCとインタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
http://khanhman.com/?p=12
SSSSLIDE
カジュアルにVPC作った結果がこれだよ！