タグ

awsに関するsakurasakurasのブックマーク (12)

  • AWS Well-Architected – 安全で効率的なクラウドアプリケーション

    AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。 AWS Well-Architected Framework には、ドメイン固有のレンズやハンズオンラボ、そして AWS Well-Architected Tool が含まれています。追加コストなしで AWS マネジメントコンソールで利用できる AWS Well-Architected Tool は、ワークロードの定期

    AWS Well-Architected – 安全で効率的なクラウドアプリケーション
  • Slerがawsで運用してきた話

    SRX5000シリーズ for Cloud Builders ~Trailer version~ マクニカ&ジュニパー共同資料

    Slerがawsで運用してきた話
  • AWS News Blog

    Add your Ruby gems to AWS CodeArtifact Ruby developers can now use AWS CodeArtifact to securely store and retrieve their gems. CodeArtifact integrates with standard developer tools like gem and bundler. Applications often use numerous packages to speed up development by providing reusable code for common tasks like network access, cryptography, or data manipulation. Developers also embed SDKs–such

  • ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) | 株式会社ヌーラボ(Nulab inc.)

    私たちの元々の目的は「イミュータブルインフラストラクチャ」を構築する事ではなく、前編で紹介した課題を解決するための運用フローを構築することでした。それを開発のフェーズからコツコツと模索した結果として「イミュータブルインフラストラクチャー」に少しずつ近づいている、というのが正直なところです。

    ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) | 株式会社ヌーラボ(Nulab inc.)
  • ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) | 株式会社ヌーラボ(Nulab inc.)

    このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。

    ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) | 株式会社ヌーラボ(Nulab inc.)
  • Cookpad's deployment and auto scaling

    クックパッドのデプロイとオートスケール 2014.03.15 JAWS DAYS 2014 Immutable Infrastructure track http://jawsdays2014.jaws-ug.jp/speaker/i_naruta/

    Cookpad's deployment and auto scaling
  • 全Togetter&ブログレポートまとめ #jawsdays – JAWS DAYS 2014 参加レポート Vol.00 | DevelopersIO

    JAWS DAYS 2014は、トータルで1000人近いの参加者数となり、大盛況のうちにその幕を閉じました。関係者の皆様、参加者の皆様、ありがとうございました! 発表資料やイベントの公式な情報については、恐らくAWS/JAWS-UGの公式サイト側で近日中に何らかまとめられる事になると思われます。 そこで当エントリでは、それら以外の情報について"非公式まとめ"として情報を集約して行きたいと思います。 (※各種情報については暫くの間、適宜更新していく予定です。) 目次 開催前告知エントリ一覧 イベント関連のTogetter一覧 AWSチームメンバーによる参加レポート一覧 登壇者・参加者のレポート一覧 開催前告知エントリ一覧 今回JAWS DAYS 2014では、広報活動を兼ねての"『JAWS DAYS 2014』開催前告知"シリーズを書かせて頂きました。その数、約2ヶ月間で計16。イベント

    全Togetter&ブログレポートまとめ #jawsdays – JAWS DAYS 2014 参加レポート Vol.00 | DevelopersIO
  • #jawsdays の #最強のAWS で「ぜんぶ AWS でやらないワケ」という話をしてきた · takus's blog

    @hirose31 さん経由で @con_mame さんからお話をいただき、 JAWSDAYS 2014 の「これで最強AWSに」というセッションで話をしてきました。 内容としては、オンプレも AWS も運用してる立場から両者を比較してみてどうなのといった感じのお話です。 2014/03/15 JAWS DAYS 2014 - 『これで最強のAWSに』セッション #jawsdays #最強のAWS にツイートまとめがあるので、資料と一緒にご覧いただければと思います。 こんな話も出ていましたが、 AWS は必ずしも銀の弾丸ってわけではなく、どこの会社も悩ましい部分を抱えながら運用しているわけで、 @sgwr_dts さんの Roadworker のようにユーザ側でイケてる仕組みにするようなアプローチもありますが、このような機会を利用して AWS の中の人に直接フィードバックできたという意味で

  • Amazon EC2インスタンスガチャをやってみました - 元RX-7乗りの適当な日々

    歴史のあるクラウドサービスは、どこもそうなってしまう傾向があるとは思いますが、ホストサーバでの実CPUのアーキテクチャ・世代の違いで、サーバインスタンスのCPUパフォーマンスに微妙な差がついてしまいます。 2006年よりサービス提供しているAmazon EC2でもその傾向があることは割と知られていて、同じ性能だと思って並べて使っていたサーバインスタンスが、同じ処理量にもかかわらず使っているCPUリソースに差がついている、なんてことが起こります。 con_mameさんも、以下のエントリで書かれていますね。 EC2で同じECUだけどCPUは違う - まめ畑 昔は、us-eastでm1.smallのインスタンスをよく使ったもので、その頃はいつもAMDのOpteronプロセッサでしたが、最近では、ほとんどIntel Xeonですし。 ということで、現時点(2013/10)で、EC2インスタンスで使

    Amazon EC2インスタンスガチャをやってみました - 元RX-7乗りの適当な日々
  • AWS OpsWorksを使ってみた (技術編) - Tech-Sketch

    AWS OpsWorksを使ってみた(概要編) では、AWS OpsWorksの概要について紹介しました。今回の記事ではそれに補足して、前回触れられなかったOpsWorksの機能の詳細や、OpsWorksの初期構築処理の仕組みに関して把握できた範囲で紹介します。 OpsWorksの各種機能 前回の記事 でも特徴の所で簡単に触れましたが、OpsWorksにはChefによる自動構築以外にも様々な機能が用意されています。まずは前回掘り下げられなかったこれらの機能について、簡単に紹介していきます。 Auto Healing (障害自動復旧) Auto Healingは、インスタンスの障害を検知した際に代替となる新しいインスタンスを自動的に立ち上げる機能です。OpsWorksの各インスタンスではOpsWorks Agentと呼ばれるサービスが稼動しており、定期的にKeepaliveパケットを送信して

  • AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々

    昨日から、色々調べ始めています。今日はAWSの上位ネットワークまわり。特に東京リージョン(Asia Pacific (Tokyo) Region)。 現時点の情報のスナップショットとしてログがわりに残しておきます。 ASN (AS番号) まず、以下のサイトで調べてみると、、、 http://bgp.he.net/search?search[search]=Amazon&commit=Search この通り、Amazonが取得しているASNは10個ほど見受けられますが、中身を見ていくと、このうちAS16509にほぼ集約されていることがわかります。 AS16509に接続されているBGPのPeerの数は現時点で、v4が158、v6が10となっています。(公開情報のみ) Peerの内訳は以下のリンク先から確認できます。 http://bgp.he.net/AS16509#_peers ざっくり確認

    AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々
  • AWS - EC2からメール送信 | code up

    EC2インスタンスからのメール送信について。 記事は単一のEC2インスタンスからメールを送信する場合について記載しており、外部からEC2のメールサーバー(25番ポートでListenしているプロセス)にアクセスする場合、外部のSMTPサーバーが行っているOutbound Port 25 Blockingの話題、Amazon VPCで複数のインスタンスからメール送信するケースは扱っていない。 EC2からメールを送信する方法 インスタンスに標準でついてくる(のかな?今の環境は勝手に起動してた)SMTPサーバーを利用する Amazon Simple Email Service (Amazon SES)を利用する。ただし、薄くベータと書いてあるので注意 外部のSMTPサーバーを利用する SMTP制限; 25番ポート EC2インスタンスから外部(Outbound)に対する25番ポートの通信には一定の

  • 1