AWSのアカウント間でAMIを共有するのをやってみる - Qiita
AWSの別アカウントどうしでAMIを共有するのをやってみたので手順をメモしておく。 最近は別リージョンへのAMIコピー機能も追加され、AMIを作りなおさなくて良くて便利。 全てManagement Console上で実施。 やってみた手順 AMIの共有 AMIを所持している方のアカウントでEC2のAMIを表示 共有するAMIを選択して「Edit」実施 「Permissions」を選択して「Add Permissions」ボタンを押下 「AWS Account Number」に共有先AWSアカウントのアカウント番号入力してチェック 共有されたAMIの利用 AMIを共有されたアカウントでEC2のAMIを表示(共有元と同じリージョンにする) 「Filter」が「Owned By Me」になっている場合は「Private Images」にすると共有されたAMIが表示される EC2する際も、AMI選
ISUCON2013の予選に参加して、全体5位だったのでやったことの報告 [GameCreator'sNote]
Instanceを作成 SpotInstanceでやろうとしたが、起動に時間がかかったので結局Ondemand Instanceにした。 最近のAWSは、Instance作成時に自分の公開鍵をインポートできることをこの時知った(昔はそんなことできなかった) 開くべきポートを、適切に開放する。(今回は、ローカルからベンチするだけなので、SSHポートの開放だけでよかった) 1-2. サーバ環境のチェック まずはログイン $ ssh ec2-user@ec2-175-41-201-33.ap-northeast-1.compute.amazonaws.com -p 22 SSHのポートは変更されているかもしれない 運営さんがサーバ内に設置しているREADMEをチェックした後、追加で以下の事項をチェックする OS ミドルウェア 起動済みサービス 物理スペック # メモリ量 -> MySQLの設定な
Amazon Cognitoについて - AWSが提案するモバイル時代のアカウント管理 - クックパッド開発者ブログ
モバイルファースト室の @rejasupotaro です。 AWS Summit 2014 でAWS Mobile Servicesのアップデートがありましたが、その中でも気になったAmazon Cognitoについて調べてみました。 Amazon Cognitoとは 今どきのモバイルアプリでは、単純に認証してAPIを叩くだけではなく、サービスにログインしていない状態でも一意なIDを持たせてデータを管理したり、ゲスト状態から会員登録をしたときにデータを引き継いだり、サービス間でシングルサインオンを提供したり、デバイス間で設定を共有できるようにするなど、ユーザーがどのデバイスからサービスにアクセスしてもストレスなく使えるようにするために様々な工夫を凝らす必要があります。 Introduction to Amazon Cognito これらの実装は複雑になりがちで、アプリを作っていると思ったら
訳：非推奨になったLinuxネットワークコマンドの代替コマンド - aws memo
これはちゃんとチェックしておかないとなぁ。 Deprecated Linux networking commands and their replacements « Doug Vitale Tech Blog ==== この記事で詳しく説明する非推奨のLinuxネットワークコマンドは：arp, ifconfig, iptunnel, iwconfig, nameif, netstat, route である。iwconfig以外の コマンドは、net-toolsパッケージという、数年間メンテナンスされていないパッケージに含まれている。これらのユーティリティによって提供される機能は、新しいipコマンドを主に使うiproute2 スイートで再提供され、改善され続けている。iproute2ソフトウェアのコードとドキュメントは、Kernel.orgとLinux Foundationで見ることができ
[技術ブログVol.9] AWSの海外リージョンのレイテンシと距離の関係 - DENET 技術ブログ
今回は、AWSの海外リージョンのレイテンシについてです。 AWSが出てくるまでは、IT業界で仕事をしていても、サンパウロのサーバにログインすることなんて全くありませんでしたが、今は海外のサーバを使うことも珍しくはない時代になりました。 では、海外サーバを使った時に、どれだけ遅延が出るのか、その遅延はサービス的に「使える」レベルなのか、ということが気になるところです。 「使える」なら、少しでも安くなるリージョンのサーバを使いたいですよね。 ということで、全リージョンでHTTPレスポンスを調べてみました。 また、各リージョンの地理的な位置がよく分かってなかったので、Tokyoからの直線距離も調べてみました。 検証環境 検証には、t1.microのインスタンスをCentOS6で立ち上げて、Apacheをyumでインストールし、httpd.confはデフォルトのものを利用しました。 そして、Tok
![[技術ブログVol.9] AWSの海外リージョンのレイテンシと距離の関係 - DENET 技術ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/1bded401032ab8870517482d5480e78c0cd621c5/height=288;version=1;width=512/https%3A%2F%2Fblog.denet.co.jp%2F2014%2F01%2Fregion_icon.png){kind=icon}
AWS Tokyo Regionのネットワークを調べてみた。 - めもおきば
AWSの東京リージョンがリリースされたということで、技術視点からネットワーク関係を探ってみました。 なお、利用者視点でのレイテンシやスループットについては、並河さんの記事が分かりやすいです。 上位ネットワーク まず最初に、インターネットとの接続方法、つまり上位ISPをざっくり知るために、実際にEC2上で立ち上げたインスタンスのIPアドレスをrobtexに突っ込んでみると、AS16509の175.41.192.0/18 AWS AsiaPac prefixというのが実際にインターネット上で流れている経路、つまりIPアドレスブロックでよさそうです。さらに、 AS16509は日本を含む全世界で使ってるけどAS38895はシンガポールでのみ。シンガポールと日本へのルーティングはそれぞれに割り当てた/18単位で、って感じかな。(そうなると、シンガポールだけ別のASにした理由がイマイチ分からないな)
amazon s3のバケットを空にする方法【NodeJS編】 | りぷろぐ
お久しぶりです。 リプレーションのインフラ担当SE、utunです。 数か月ぶりの更新なので、もうこのブログ見てる人はいないかも？ と思いつつ、ちょっとした気分転換に一つ書いてみようと思います。 最近個人的にホットな話題、「Amazon S3」について、書いていきます。 Amazon S3とは まぁ皆知ってると思うんだけど、Amazonさんが提供してる「超巨大オブジェクトストア」みたいなもの。 このスケールであの値段は、はっきり言って異常なレベル。 もはやこの分野で太刀打ちできる企業は居ないんじゃなかろうか・・・。 まぁAzureとかもあるにはあるけども。 しかし巨大ゆえに・・・ 無限にファイル置ける！ 無限にスケールできる！ って聞くと、インフラSE的には疑わずにはおれない訳です。 何かを犠牲にしてるんじゃないかってね。 そんな中で使っていて、よく考えれば当然なんだけど
EC2インスタンスのOpenSSLのHeartbleed Bug対応 - Qiita
した後、依存しているサービスをリスタートしてOKです。 opensslのバージョンが1.0.1eになったままになっているけど、パッチは当たっているから大丈夫だよって書いてあります。 Versionのところがopenssl-1.0.1e-37.66.amzn1以上かだけチェックはした方が良さそうです。 The updated package is openssl-1.0.1e-37.66.amzn1 Please note that even though this package is still named openssl-1.0.1e, it does contain the patches that were made available upstream for CVE-2014-0160.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Lv1から始めるWebサービスのインフラ構築
Amazon S3のBucketを削除する方法