Amazon EC2のAvailability Zoneの名前はアカウント毎に違う
はじめに 先のエントリにて、EC2のデータ転送と課金の関係についてまとめました。EC2では、同一のAZ内に存在しているインスタンス間でのデータ転送は、プライベートIPを使ったものについては課金されません。 Scutum(スキュータム)はSaaS型のWAFなので、お客様のウェブサーバとScutumのWAFインスタンスの間にそれなりの量のトラフィックが発生します。そのため、この課金されないトラフィックをうまく使いたいと考えていますが、ここに落とし穴が潜んでいました。実は、EC2でのAZは、アカウント毎に指している実体が異なることがあるのです。 (クリックで拡大します) 発見に至ったきっかけ 先のエントリの内容を調査する段階で、私たちは2つの異なるAWSアカウントを用意しました。これは(ScutumがEC2でサービスを提供する場合には)、お客様のウェブサーバのインスタンスの管理アカウントと、Sc
EC2 AZ間のスループット計測 (netperf) - 雑多なインフラエンジニア日記
ここ(http://aws.amazon.com/jp/ec2/instance-types/instance-details/)に明確な数値が 書いてないので、インスタンスタイプ毎のAZ間のスループットを計測してみました。 東京リージョンの 1a から 1b、1c に対してnetperfで負荷を掛けています。 (AZはAWSアカウント毎にDC群が異なりますので結果は目安として下さい。) EIP間の通信ではない＆同一VPC内のプライベートネットワーク間の通信を 計測対象としています。 計測方法 ・各AZに small、large、xlarge インスタンスを立てて、 netperf -f M -H 対象ホスト でスループットを計測。 ・試行回数は30回とし、平均値を取得。 ・負荷掛け側/掛けられる側のインスタンスタイプは同じとする。 スループット計測結果 ・単位はMbps、30回の平均値。
EC2 to VPC: A transition worth doing. - Engineering at Kiip
Kiip recently completed a migration from EC2 to VPC. VPC exited beta and became generally available in all regions in August, and allows you to provision compute nodes within a virtual network in AWS. For anything more than simple websites, we believe migrating to VPC is something worth doing, or at the very least worth investigating. Because Amazon VPC is a new service and requires a substantial
suz-lab.com - suz lab リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
SESのDomainのverifyについて - temporal's diary
SESのDomainのverifiyでは何をどう設定すればよいのか、設定にどれくらいの時間がかかるのかという点にとまどうことがあります。 SESでは送信元となるEmailアドレスについて、あらかじめverify(有効性の事前確認)をされていなければなりません。verifiedされたEmailアドレスからのみメールを送信することが可能となります。verifyを実行すると対象となるアドレスに対して、SESから確認のメール(Amazon SES Address Verification Request)があり、メールの中にあるURLにアクセスすることで有効性の確認が行われ、verifiedになります。 複数のEmailアドレスからメールを送信する場合は、それぞれのEmailアドレス毎にこの作業を行うのは面倒です。DomainをverifyすればそのDomainからのメールはすべて送信可能となりま
SESを利用するにあたり必要な認識と対策(特にバウンス) - temporal's diary
AWSのSESを利用するにあたり、あらかじめ認識しないといけないことが2つあると思います。 場合により、SESを利用する権利を一時停止されてしまうことがある 権利を一時停止されてしまった(もしくは警告を受けた)際には、その原因を自分で調査して、AWSに原因と対策を英文で報告する必要がある また、あらかじめ以下いずれかの設定をしておく必要があります。(バウンスが多いために権利一時停止や警告を受けた場合原因調査のため) メール送信プログラム側でReturn-Pathを指定し、Return-Pathに対して返信されたメールを調べる(デフォルトではSourceアドレスに対して返信) Feedback NotificationsにてBounces SNS Notificationを指定し、SNS経由で通知されたバウンス情報を調べる 権利一時停止や警告を受けてしまった際に、主にAWSのUSのフォーラム
ちょっと内緒にしたいスポットインスタンスの話 - プログラマでありたい
ちょっと内緒にしたいような気がしますが、知っていたら確実に得をするAWS EC2のチップスがスポットインスタンスの活用です。まずスポットインスタンスとは？AWSのインスタンススポットのページを読むと大体解りますが、簡単に説明するとAmazonで余剰のEC2のインスタンスを入札制で大幅に安い値段でを利用する仕組みです。デメリットとしては、スポットインスタンスのインスタンス価格が入札価格を上回った場合、情け容赦なくインスタンスがストップされることです。ということで、Amazonの推奨としては以下のように、通常のインスタンスを補完するような位置づけとなっています。 オプションのタスク 遅延可能なタスク コンピューティング能力を追加することで高速化できるタスク 他の方法ではアクセスできない大量のコンピューティングインスタンスが必要になるタスク しかし、制約があるものの圧倒的に安いです。オンデマンド
AWS 導入事例：株式会社フリークアウト | AWS
AWS の導入により ETL 基盤の運用性が向上したことで、 システム部門本来の業務であるサービス・プロダクト開発に より注力できるようになったことは大きなメリットです。 日本のアドテクノロジー業界を牽引する株式会社フリークアウトでは、 DSP（Demand Side Platform）のコアワークロードのひとつである ETL （Extract / Transform / Load）基盤をオンプレミスから AWS へ移行しました。大規模な非構造化データを扱う ETL 基盤を Amazon EMR や Amazon Glue などを用いて構築することで運用性が大幅に向上し、調達のリードタイムやサイジングコストも減少しています。さらに、 ETL で処理したデータからの予測モデルを作成するために Amazon SageMaker を導入するなど、 DSP 基盤のクラウド化を推進しています。 オン
Amazon EC2インスタンスに簡単にSSHできるようになるツールec2sshを公開しました - 昼メシ物語
みんなが大好きなクラウドホスティングサービスのAmazon EC2ですが、インスタンスをバンバン立てたり落としたりしていると、ホスト名の管理が面倒になってきますよね。たとえば「さっき立てたインスタンスにSSHしたい！」と思ったら、consoleをひらいて、「ec2-xxx-xxx-xxx-xxx.compute.us-west-1.compute.amazonaws.com」なPublicDNSをターミナルにコピペして…みたいな面倒な事をやってしまいがちです。 これを避けるためには、~/.ssh/configをマメに更新したりするといいのですが、これはなかなか面倒な作業です。インスタンスは一旦StopしてRunし直すと、IPが変わってしまいますからね。 そこでec2sshの登場です ec2sshは、インスタンスのNameタグからホスト名を生成して、~/.ssh/configに書きこむツール
AWS News Blog
AWS Week in Review – New Open-Source Updates for Snapchange, Cedar, and Jupyter Community Contributions – May 15, 2023 A new week has begun. Last week, there was a lot of news related to AWS. I have compiled a few announcements you need to know. Let’s get started right away! Last Week’s Launches Let’s take a look at some launches from the last week that I want to remind you of: New Amazon EC2 […]
Amazon Route 53＋ELBでホスト名なし(zone apex)の運用もOKになったので試してみた - （ひ）メモ
先日、Amazon Route 53のベータがとれて正式版になったのと同時に、ELBと協調動作するための機能(Alias Resource Record Set)も追加されました。 New Route 53 and ELB features: IPv6, Zone Apex, WRR and more - All Things Distributed 【AWS発表】 クラウド上の名前解決サービスAmazon Route 53のベータをとり正式版に - Amazon Web Services ブログ 以前に書いた「Amazon ELBでホスト名なしのhttp://example.comを運用すると発生するいくつかの弊害」もこれで解消できそうだったのでちょっと試してみました。 Alias Resource Record Set ELBとの協調動作にはRoute 53で「Alias Resour
AWS Command Line Tool Python版 ｜ Developers.IO
軽量コマンドラインツールが出た！ 全国うん万人?のAWSデベロッパーの皆さん、ニュースです。AWSから提供されていたコマンドラインツールがPython版になって登場です。すでに12のサービスに対応しています。ただ単にJavaからPythonになったというレベルではありません。超軽量になったのです。今までのコマンドラインツールは、バックグラウンドでJVM(Java VM)が立ち上がっていました。コマンドが呼ばれる度にVMが初期起動するのでCPU使用率が非常に高く、サーバー運用時の定期呼び出しには大きな問題となっていました。仕方なく、RubyやPythonのSDKを使ってスクリプトを書くという毎日でした。Java好きな私ですので多少擁護しますと、Java版はRI(Reference Implementation)として、AWSの全てのAPIにアクセスするためのお手本として、今後も最初にSDKが
Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） | DevelopersIO
Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） [2013/02/15]記事のタイトルを変えました。 プライマリサイト（EC2ベース）からセカンダリサイト（S3ベース）へのDNSフェイルオーバーの記事となります。 Route 53へのフェイルオーバー機能とヘルスチェック機能の追加 先日のAWSよりRoute 53へのフェイルオーバー機能とヘルスチェック機能の追加に関しての発表がありました。 AWSでWebサイトなどをホストする場合、障害発生時に一時的にSorry Pageを表示したり、バックアップのWebサイトに切り替えたりといったことを自動的に行うことはこれまで比較的難しいかったと思います。 今回、Route 53にフェイルオーバー機能が追加されたことにより、プライマリサイトがダウンした際に、自動的に
Amazon VPCを使ったミニマム構成のサーバ環境を構築する | DevelopersIO
よく訓練されたアップル信者、都元です。AWSにおいては、ネットワーク環境をあまり気にせず、数クリックで簡単にサーバを構築できるのは一つのメリットだと言えます。しかし、本格的に運用するシステムに関しては、ネットワーク環境をコントロールする需要も出てきます。AWS Virtual Private Cloud (VPC)を使えば、AWS上に仮想ネットワークを定義し、その上に各種サーバを配置することができます。 深く考えずに非VPC環境に構築してしまったAWSサーバ環境は、簡単にはVPC環境に移行することはできません。従って弊社では、小さなシステムであっても、最初からVPC環境にシステムを構築することを推奨しています。「非VPCが許されるのは小学生までだよねー」とボスが申しておりました。かといって、ネットワークの構成をゼロから考えて構築するのもひと苦労であるため、本エントリーでは、システムの初期段
Amazon ELBでSorryサーバへのフェイルオーバーを実現する | DevelopersIO
AWSにおいて、ELBによるSorryサーバへのフェイルオーバーは、長らく待ち望まれている機能です。先日、Route53にDNSレベルでのフェイルオーバー機能が実装（下記）されました。 Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to EC2編） ただ、Route53を利用していない場合は、未だにヘルスチェック及びフェイルオーバーの機能は手組みする必要があります。無いなら作るしかないのです。わかりました、作りますよ。 前提 まず確認しておきたいのは、今回ご紹介するテクニックは、前述のRoute53によるフェイルオーバーと比べると、オモチャみたいなもんです。知ってますか？ 何と、Ro
CloudInitを使ってSSH公開鍵を自動設置する - okochangの馬鹿でありがとう
会社のブログで書いたこともあり（ステマ）、最近はCloudInitで自動構成の実験をしたりしてます。 サーバの自動構成はChefやPuppetが有名ですが、CloudInitも手軽に使えるのでなかなか良い感じ。 EC2インスタンスのUser Dataで指定しちゃえばOKなので結構カジュアルに使えると思います。 ちなみにCloudInitはAWSだけで使えるのではなく、RackspaceやEucalyptusでも使う事が出来ます。 EC2インスタンス起動時にSSHの鍵をひとつ指定しますが、ログインする人が複数いる場合、起動後にauthorized_keysに公開鍵を登録していくのは面倒ですよね。 インスタンスが少なければ気になりませんが、台数が多くなるとミスも増えてしまいます。 そういう場合は以下のようにUserDataに書いてあげると幸せになれるかもしれません。 #cloud-config
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How do I secure a staging server on EC2?
Email Definitions: Bounces | Amazon Web Services
サーバ構築自動化 On aws sqaleの場合
AWS Documentation