サマリ Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。 SSRFとは SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。 最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得する
HPCジョブはIntel ハイパースレッディングを無効化すると、性能が改善することがあります。 AWS ParallelClusterを使ってクラスターを構築している場合、設定ファイルからHTを無効化できます。 HT の効果はワークロードに依存するため、HTの有効・無効を評価の上、最終的な方針を決めてください。 ハイパースレッディングを無効化して性能改善 ハイパフォーマンスコンピューティング(HPC)では、インテルのハイパースレッディング(HT)を無効化することで性能が改善するケースが多々あります。 インテルが AWS と執筆した HPC ワークロードのパフォーマンスに関するホワイトペーパー([1])でも、HTの無効化が推奨されています。 同ホワイトペーパーで引用されている記事([2])では、HT を無効にすることが効果的なユースケースとして、浮動小数点演算を多用するHPCジョブが挙げられ
ので、メモ。 Spot fleet launches Spot instances in the lowest priced Availability Zone 本日(2015年7月24日)からSpotフリートの機能にて、spot fleet launch specificationで指定した複数のVPCサブネットもしくはAZの中で最も安いAZにSpotインスタンスを起動するようになりました。以前は、複数サブネットの中で最安値のサブネットに起動したい場合には、自分自身で最安値のAZを決定し、Spotフリートリクエストを実行する必要がありました ということで、spot fleet launch specificationの記載方法の自由度が増しました。 設定例(spot.json) ここでは、 C3.8xlargeかCC2.8xlargeを、subnet-aaaaaa (AZ-a)か sub
Simpline Blogdelete-on-terminationを後から変更するのがとても大変 2015.03.23 エンジニアブログ EC2起動時にはけっこう目立つEBSボリュームのDelete on Terminationだけど、AWSマネージメントコンソールから追加Volume追加する時に設定変更できる箇所が見当たらない。設定は見えるのだけど、変更できるインターフェースがどうも無さそう。 困ったときのAWS CLI CLIでできるかもと思ってやってみたらできました。 # 事前確認 $ aws ec2 describe-instances --instance-id $INSTANCEID \ --query Reservations[].Instances[].BlockDeviceMappings[] [ { "DeviceName": "/dev/xvda", "Ebs":
やり方についてはドキュメントを読むと良い. docs.aws.amazon.com option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Immutable HealthCheckSuccessThreshold: Ok IgnoreHealthCheck: false Timeout: "600" 設定ファイルでやるならばこういった設定を書き,.ebextensions/ 以下に deploy.config みたいな名前で放り込んでデプロイするとImmutable deployがされる. 最初は素朴なhealth checkベースのrolling deployを試していたのだけど,JavaのApp serverと相性が悪いのか (私はJavaを書いています) 上手くhealth checkが通らない時があり,また
AWS VPC内のLinuxでは、拡張ネットワーキング(Enhanced Networking)という機能が使えます。利用条件はあるものの、この機能を有効にするだけでネットワークが速くなるので有用なのですが、何がどれくらい速くなるのか気になったので計測してみました。 この機能自体は2013年末に発表されたものなので、目新しくはないです。ただ、公式の説明やその辺の情報を調べても、イマイチ情報がわかりやすくまとまっていない部分があったので、設定についてもまとめ直してみました。 デフォルトと拡張ネットワーキングの性能比較 この機能のON/OFFによって、変化するのは通信のレイテンシであり、最大Bandwidthが変わるわけではありません。また、インスタンスタイプによってレイテンシの変化量が変わるわけでもありません。 そのため、ここで載せるのは1つのインスタンスタイプにおいて、バージョン違いを含め
仮想化を使っていると仮想ディスクを大きくする話は良く見るのですが Windows でディスクを小さくする話をあんまり見なかったのでちょっと試してみました。といっても近頃の Windows ならばパーティションを小さくすることくらい簡単です。 「コンピュータの管理」から「ディスクの管理」を探しだせば右クリックで縮小ができます。http://www.atmarkit.co.jp/fwin2k/win2ktips/941diskshrink/diskshrink.html おっと、こんなページもありました。 で、問題は EC2 の場合なんかです。EBS ボリュームは今のところ後からサイズ変更ができません。サイズを変更しようと思うとスナップショットを撮ってそこからボリュームを作り直したりする必要があります。更にスナップショットからより大きなボリュームは作れるのですが、元のボリュームよりも小さなボリ
Summary VPC 内にたてた ELB(internet-facing/internal) のプライベート IP アドレスをコマンドラインツールの AWS-CLI から調べる方法をメモ。 tl;dr : EC2 DescribeNetworkInterfaces を使う EC2 サービスには DescribeNetworkInterfaces という NIC 向けの API が存在する。この API を使うと ELB のグローバル/プライベート IP アドレスを確認できる。 NIC 一覧からお目当ての ELB を突き止めるには? ELB インスタンスの NIC の設定は aws が裏でやっているためか、ELB のNIC は Attachment => InstanceOwnerId が “amazon-elb” となっている。 また NIC の Description も aws が勝
aws cliには API 呼び出し後、特定のステータスになるまでポーリングする wait コマンドがあります。 例えば ec2 インスタンスを起動する API を呼び出し後、インスタンスの起動が完了するまで待つには $ aws ec2 wait instance-running --instance-ids xxx のようにします。 この wait 機能が実装されるまでは #!/bin/bash instance_id=$(aws ec2 run-instances –image-id ami-12345 \ --query Reservations[].Instances[].InstanceId \ --output text) instance_state=$(aws ec2 describe-instances –instance-ids $instance_id --query
こんにちは。フレクトの大橋です。 ベターホームレシピ(http://bhmb.jp)では、MySQLを会員やレシピデータ用の インスタンスと、Cicindela用のインスタンスを同一のサーバにそれぞれ データをEBSに置いて運用しています。 レプリケーションなど信頼性向上のための施策をしているのですが、 運用上大事なのはバックアップです。 そこで、今日はEBS上のMySQLのデータのスナップショットを 整合性を失わずにバックアップする方法についてベターホームレシピでの 実運用の事例をもとに紹介します。 ■ 本題の前に・・・、Amazon RDSについて そもそも直接MySQLをEC2上にインストールしなくても、日々機能が強化されている Amazon RDSを使えばよいのではないか、という考えもあります。はい、その通りです。 特に最近はMulti-AZ機能なども提供され、安心感があります。
2. 自己紹介 菅原 元気 (@sgwr_dts / id:winebarrel) 白金台のほうから来ました ● クックパッド株式会社勤務 ● インフラエンジニア ● Ruby・AWS関連ツールを公開しています ○ https://bitbucket.org/winebarrel/ ○ https://github.com/winebarrel/ 6. EC2の天井 事例③ APIのInternal Server Error New! API叩きすぎるとInternal Server Error DescribeTagsは特に弱い :::::::: ┌─────────────── ┐ :::::::: |DescribeTagsやられたようだな・・ │ ::::: ┌───└───────────v───┬┘ ::::: |フフフ…奴はAPI四天王の
ここでは、EC2の上でinnodbをチューニングして使うという観点でTIPSをまとめてみた。 RDS便利だから使おうぜってのは今回の話のスコープには含みません。 あと、innodbについて、割りとちゃんと調べてみたのは初めてだったりするので、間違ってる点など見つけたらぜひご指摘くださいませ。 innodb関連 バッファプール ワーキングセットを乗せておくオンメモリのバッファ領域。読み書き共にこの領域を経由して実施される。 参照時はバッファプール上でデータを探して、なければテーブルスペースから取得する。(そのデータはバッファプール上に格納される) 書き込み時はリクエストを受け付けてワーキングセットを更新し、ログの書き込みへ移行する。 設定はinnodb_buffer_pool_size 監視はSHOW ENGINE INNODB STATUSか、mysqladmin extended-sta
最近、TerraformやCloudFormationみたいに、JSONや独自DSLなどでかっこよくAWSを管理するツールがいろいろ出てきてます。 こういうツールは便利そうだなとは思うんですが、なんかふと、ユーザがホントに求めているものはコレなんだろうか?と思いました。 なんだかんだ言って、一番多く使われているサーバ管理ツールは『Excelサーバ一覧』なのではw? じゃあExcelで同じようなことが出来ればそれが一番いいのでは?と。 というわけで、Excelは手元になくてキツイので、今回はGoogleスプレッドシートでAWSのサーバ構成管理をやってみました。 使い方 事前準備 サンプルのスプレッドシートをコピーする 『ツール』 -> 『スクリプトエディタ』 -> config.gsを編集 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYにAWSのアクセスキーを
多くのサーバータスクとプロセスにとって、Amazon EC2 インスタンスでの一貫して正確な時刻のリファレンスが不可欠です。システムログのタイムスタンプは、問題が発生した時期やイベントの時系列を特定する上で重要な役割を果たします。AWS CLI または AWS SDK を使用してインスタンスからリクエストを行う際に、これらのツールによって自動的にリクエストに署名されます。インスタンスの日時設定が不正確な場合、署名の日付とリクエストの日付が一致しないことがあり、その場合は AWS がリクエストを却下します。 これに対処することが重要なため、Amazon は Amazon Time Sync Service を提供しています。このサービスはすべての EC2 インスタンスからアクセスでき、さまざまな AWS のサービス で利用されます。このサービスは、各 AWS リージョン で衛星接続された基準
SR-IOV enabledな c3/i2 インスタンス使うときのNICドライバのパラメータをどうしたらいいかわからなかったので軽く検証してみた。 NICのドライバパラメータ(InterruptThrottleRate)をチューニングすることで、例えばHAProxyを使ってるような高pps環境でCPUの割り込み負荷を削減できる。 ELBの代わりにHAProxy使ってる噂は結構聞いたりする。 - クックパッドでのVPC移行について - Cookpad's deployment and auto scaling // Speaker Deck みんなELBからhaproxyに移行してる #jawsdays— kenjiskywalker (@kenjiskywalker) March 15, 2014 前提 c3インスタンス 2013年の11月くらいにでた新しいインスタンスタイプ SSD Xe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く