タグ

AWSに関するyagishitaのブックマーク (14)

  • CloudFormation超入門 | DevelopersIO

    AWSでインスタンスやVPC環境を作成するとき、コンソール上で作ろうとすると、似たような環境を何度も作ったり、大量に作ったりする時、非常に手間になってしまいます。 しかし、AWSにはそんな手間を一気に解消してくれるCloudFormaionという便利サービスがあります。 今回は、初めての人向けの超入門ということで「CloudFormationってどないやねん」という方向けに、まずは使ってみようというコンセプトで書いてみようと思います。 CloudFormation って何? 誤解を恐れつつ一言で言えば、「自動的にAWS上で作りたいものを作ってくれる」サービスです。というか、そういう環境を用意してくれるサービスです。 少し補足すると、自分が作りたい環境を定義したファイルを作って、その定義書を読み込んで自動で環境を作ってくれます。 今回は超入門ということで詳細な説明は割愛したいと思います。 A

    CloudFormation超入門 | DevelopersIO
  • [AWS Certificate Manager]東京でも無料でSSL証明書が使用可能になりました! | DevelopersIO

    ※:CloudFrontは米国東部 (バージニア北部)で設定を行うため、CloudFrontの全エッジロケーションでACMを使用できます。 早速試します ACMを設定する 設定の手順の詳細は、[ACM] SSL証明書発行時のドメイン認証メールをSESで受け取ってみたを参照して下さい。このエントリの「ACM設定」までを実施します。 東京リージョンでAmazon Linux 2016.03のEC2を起動して、以下のコマンドを実行します。(Webサーバのインストール、index.htmlの作成、Webサーバの開始) $ sudo yum install -y httpd $ sudo echo "AWS Certificate Manager" | sudo tee /var/www/html/index.html $ sudo service httpd start 次に、東京リージョンのEL

    [AWS Certificate Manager]東京でも無料でSSL証明書が使用可能になりました! | DevelopersIO
  • 日本きた!AWSでSSL証明書が無料、ワイルドカードも使えるし自動で更新 | ロードバランスすだちくん

    シンジです。HTTPS化で必要な証明書の発行がAWSだと無料!なのは前からだったのですが、ついに日にも来ましたよー!いやーまじで時代は変わるもんですね。もう何でもかんでも証明書使って暗号化しまくりましょう。 無償で証明書が使えるリージョンは以下の通り 米国東部(N.Virginia) 米国西部(N.カリフォルニア) 米国西部(オレゴン) EU(アイルランド) EU(フランクフルト) アジア・パシフィック(東京) アジア太平洋地域(ソウル) アジア・パシフィック(シンガポール) アジアパシフィック(シドニー) 南米(サンパウロ) ソースはこちら https://aws.amazon.com/jp/about-aws/whats-new/2016/05/aws-certificate-manager-now-available-in-more-regions/ EV グリーンバーには非対応な

    日本きた!AWSでSSL証明書が無料、ワイルドカードも使えるし自動で更新 | ロードバランスすだちくん
    yagishita
    yagishita 2016/05/17
    とうとう来ましたか
  • Application Performance  |  Google Cloud

    Integrated monitoring, logging, and trace managed services for applications and systems running on Google Cloud and beyond.

    Application Performance  |  Google Cloud
  • [公式チュートリアルではじめる]CircleCI+CodeDeployを使ったCD(継続的デプロイ) | DevelopersIO

    コンニチハ、千葉です。 公式チュートリアルにそって、CircleCIとCodeDeployを使ったCD(継続的デプロイ)をやってみました。 CodeDeploy単体だとS3のファイルをEC2インスタンスへデプロイするのみですが、CircleCIを利用することで、GitHubへのコミットをトリガーに、アプリケーションのリビジョン作成、S3へアップロード、デプロイするところまでを自動化することが可能です。CircleCI、CodeDeployが初めての人でもこれをやってみると雰囲気がつかめると思います。 CodeDeployを復習したい方はCodeDeploy入門が参考になると思います。 AWS環境の構築 継続的インテグレーションの最初のステップとして、CodeDeployの設定をします。具体的には、 EC2インスタンスの作成 CodeDeoloyにてデプロイメントグループ、ロールを設定 EC

    [公式チュートリアルではじめる]CircleCI+CodeDeployを使ったCD(継続的デプロイ) | DevelopersIO
  • Claudia.js を使った簡単マイクロサービス開発 | DevelopersIO

    最近流行りのサーバーレス・アーキテクチャでの開発は、複数のサービスを組み合わせて使うことが多いと思います。そのためデプロイや設定は複雑になりがちです。AWS でサーバーレス・アーキテクチャの代表と言えば、AWS LambdaAmazon API Gateway が思い浮かぶのではないでしょうか?今回ご紹介する Claudia.js は、それらのサービスを使用した開発をさらに加速する予感です。 Claudia.js とは? Claudia.js はマイクロサービスを簡単に開発するためのオープンソースのデプロイメントツールです。Claudia.js を使うと AWS LambdaAmazon API Gateway を使ったマイクロサービスを簡単に開発・デプロイすることができます。 さらに、Node.js 用の REST API をプログラミングするための Claudia API

    Claudia.js を使った簡単マイクロサービス開発 | DevelopersIO
  • Amazon EBSのアップデート – 新たなスループット最適化ボリュームとコールドボリューム | Amazon Web Services

    Amazon Web Services ブログ Amazon EBSのアップデート – 新たなスループット最適化ボリュームとコールドボリューム AWSチームは料金とパフォーマンスの両面でイノベーションを起こし、その成果をサービスという形でお客様にご提供する方法がないか日夜検討しています。多くの場合、こういった取り組みは経済的な要素と技術的な要素の間のジレンマに直面することになります。 AWSに限らずとも、こういったジレンマは頻繁に目にすることができます。たとえばストレージにおけるHDDとSSDのトレードオフはその良い例でしょう。今日のSSDをHDDと比較すると、SSDには価格あたりのIOPS値や1GBあたりのデータ転送スループット、レイテンシの短さという点で優位性があります。だからといってHDDに優位性が無いかというとそうではなく、記録密度向上のおかげで容量あたりのコストの面では大きな優位

    Amazon EBSのアップデート – 新たなスループット最適化ボリュームとコールドボリューム | Amazon Web Services
  • S3の静的ホスティングで内部確認用に使える認証を設定する | MONSTER DIVE

    ついに先日、消費税が8%にあがり、世の中は、駆け込み需要とやらで騒がれていたようですね。 3%の増税分より、4月以降の値引き幅に賭けて、なーんも買ってません。 そんな個人のコトよりも、めんどくさいのが、法人の方です。 うちが発行する請求書も届く請求書も、中身に応じて、5%だったり8%だったり、その見極めが、ややこしすぎて、迷惑極まりない状態です。 増税反対ではないのですが、もうちょっと、このあたりの事務処理のことも考えてくれませんかねぇ、国会議員の皆さん。 あぁ、これがまた1年半後に来ると思うと。。。 でも大手SIerさんは、その都度、儲かっていいのかもね!(現場は大変そうだけど。) さぁ、題! そんな「増税だぜ、NIPPON!」というタイミングで、我らがAmazon Web Service(以後、AWS)が、サービス提供開始から42回目の値下げだそうです。 3%の増税どころか、平均30

    S3の静的ホスティングで内部確認用に使える認証を設定する | MONSTER DIVE
  • CloudFront + S3 によるCDN (Cache Distribution パターン) 構築手順 | DevelopersIO

    渡辺です。 4月でも札幌は雪が降りますが、異常気象でもなんでもなく平常運転です。 今日は、いわゆるCache Distribution パターンでのCDN構築手順をまとめておきます。 CloudFrontの細かい設定は行いません。 S3を静的サイトホスティングで公開し、CloudFrontをキャッシュサーバとして設定し、独自ドメインで公開します。 構築手順 構築は以下の手順で行います。 S3バケットを作成し、静的サイトホスティングで公開する CloudFrontを作成し、オリジンにS3バケットを設定し、代替ドメインを設定する Route53に代替ドメインのCNAMEレコードを追加する S3バケットの設定 S3バケットを作成し、静的サイトホスティングで公開します。 S3バケット名は、最終的に公開するドメインとするのが無難でしょう(例: cdn.example.com)。 バケットを作成したな

    CloudFront + S3 によるCDN (Cache Distribution パターン) 構築手順 | DevelopersIO
  • GitHub - ritazh/s3proxy: :door: Access multiple storage backends via the S3 API

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - ritazh/s3proxy: :door: Access multiple storage backends via the S3 API
  • New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS | Amazon Web Services

    AWS News Blog New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS I am fascinated by things that are simple on the surface and complex underneath! For example, consider the popular padlock icon that is used to signify that traffic to and from a web site is encrypted: How does the browser know that it should display the green padlock? Well, that’s quite the story! It all starts with a

    New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS | Amazon Web Services
    yagishita
    yagishita 2016/03/22
    ここまでやるか!!
  • 【社内資料公開】AWSトラブルシューティングページまとめ/より早い原因把握のために心がけること | DevelopersIO

    はじめに こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。 さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。 トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。 A

    【社内資料公開】AWSトラブルシューティングページまとめ/より早い原因把握のために心がけること | DevelopersIO
  • AWSで避けるべき5つの間違い | POSTD

    今年からAWSAmazon Web Services)クラウドコンサルタントとして、中小規模のAWSデプロイの相談を受けています。その多くは典型的なWebアプリケーションです。ここで、ぜひ避けたい5つのよくある間違いを紹介します。 インフラストラクチャを手動で管理する。 Auto Scaling グループを使わない。 CloudWatchのメトリクスを分析しない。 Trusted Advisorを無視する。 仮想マシンを活用しない。 典型的なWebアプリケーションにおける間違いを防ぎたい人は、次に進んでください。 典型的なWebアプリケーション 典型的なWebアプリケーションは最低限次の要素で構成されているものを指します。 ロードバランサ スケーラブルなWebバックエンド データベース そしてこのアプリケーションは、次の図のような仕組みを持っています。 注釈:(左から)DNS、CDN、静

    AWSで避けるべき5つの間違い | POSTD
  • s3fsよりも高速に使えるgoofysを試してみた | DevelopersIO

    西澤です。S3バケットを直接マウントしてファイルシステムのように使いたいケースがありますが、s3fsはややパフォーマンスに難があります。Goで書かれていてs3fsよりも高速に動作することを売りにした"goofys"というツールを見つけたので、早速試してみることにしました。 s3fs-fuse/s3fs-fuse · GitHub GitHub - kahing/goofys: a Filey System for Amazon S3 written in Go 前提パッケージのインストール 今回はAmazon Linux(Amazon Linux AMI 2015.09.1 (HVM), SSD Volume Type)環境で検証を行いました。golangとfuseパッケージが前提として必要となりますので、下記のようにインストールします。 $ sudo yum install golang

    s3fsよりも高速に使えるgoofysを試してみた | DevelopersIO
  • 1