よく訓練されたアップル信者、都元です。AWSにおけるクレデンシャルには大きく「管理コンソールにログインするためのパスワード(Sign-In Credentials)」と「APIアクセスを行うためにAPIキー(Access Credentials)」の2種類があることをご紹介しました。そして、前者Sign-In Credentialsのセキュリティを強固なものにする手段として、MFAの活用についてもご紹介しました。 本当は怖いアクセスキー しかし実は本当に怖いのは、後者Access Credentialsのセキュリティです。アクセスキーはMFAによる保護に向いていません。設定を工夫すれば、「MFAによる認証を経なければアクセスキーを使えないようにする」ことも可能です。しかし、一般的には「プログラムが使う認証情報」であることが多いため、MFAの認証コードがなければAPIが叩けない、というのは受
よく訓練されたアップル信者、都元です。AWSを利用していると、APIキーの利用は必要不可欠です。数多くのAWSアカウントを扱っていれば、たまたまAPIキーは利用せず、管理コンソールへのパスワードだけで済んでしまうケースもあるかもしれませんが、これはごく例外的な状況です。しっかりとAWSを使いこなしている以上、APIキーを管理する機会が必ずあります。 鍵管理が大変 というわけで、皆さんは自分用のAPIキーを数多く管理しているわけですが、その管理は行き届いているでしょうか。少なくとも「失くしたwww」なんていう事態は是非避けたいものです。大丈夫すか? では、とあるキーがありましで、それが書き込まれている場所を全て挙げられますか? あちこちのファイルに書き込んだりしていませんでしょうか。aws-cli用の設定ファイルはもちろん、環境変数設定用の~/.bash_profileの中、シェルのhist
AWS News Blog New – Set Preferred Payment Currency for your AWS Account With customers in 190 countries, AWS is truly a global phenomenon. Today we are making the AWS bill payment process more powerful, by adding support for credit card payments in eleven additional currencies. This support comes in addition to our existing support for US Dollars (USD). This will relieve your accounting department
前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます?って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか? みんななんかやってますか? というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい
昨年11月のイベント「AWS re:Invent 2014」で発表されたAmazonクラウドの新機能「AWS Lambda」は、これまで限られたユーザーのみ試すことができる限定プレビューの状態でした。その限定が終わり、誰もが利用できるようになったことをAWSの公式ツイートが知らせています。 AWS Lambda Preview is now available to all customers - no additional sign-up needed. http://t.co/DVnnWAAN1g pic.twitter.com/PADdVionYd — Amazon Web Services (@awscloud) 2015, 1月 15 AWS Lambdaは、利用者がインスタンスを立ち上げたりランタイムを用意したり起動状況や負荷を監視するといった手間をかけることなく、Amazon
公式ドキュメントでは gm でサムネイルを作っているが node-imagemagick が入っているのでそのまま貼れば一応動く。 node-imagemagick はメンテされてないので gm を使ったほうがいいとは思う。 元画像用のバケットと、そのバケット名に -thumbnail のサフィックスを付けたサムネイル用バケットが必要。 S3 バケットを作る バケットとファンクションは同じリージョンに作る必要がある。 今回は US Standard に作った。 Lambda ファンクションを作る Lambda function code var fs = require('fs'); var im = require('imagemagick'); var aws = require('aws-sdk'); var s3 = new aws.S3({apiVersion: '2006-03
AWSアカウントを安全に運用したいなら最低限これだけはやっとけというTIPSです。 0.AWSのアカウントの種類 AWSアカウントを作ったときには、AWSのrootアカウントしか存在していません。 このままだと「メールアドレス」「パスワード」で「AWSリソースの操作が何でも」できてしまいます。 そこで管理コンソールへのログインはMFA(Multi-Factor Authentication)を利用したうえで、root以外にIAM Userというアカウントを作成し、限定した権限で利用することが強く推奨されています。 rootアカウント:AWSアカウント作成時に作成される何でもできるユーザー IAMユーザー:権限を限定して設定できるユーザー 1.Authyのセットアップ 2段階認証を導入するためにハードウェア型のMFAデバイスか、ソフトウェア型のVirtual MFAが使用可能です。今回はVi
cloudpackエバンジェリストの吉田真吾(@yoshidashingo)です。 今回発表になった Amazon RDS for Aurora。最大の特徴はストレージが従来のRDS(Multi-AZ)における「完全同期なミラーディスク型のレプリケーション」方式でなく、「Quorumベースの非同期レプリケーション」方式が採用された点です。 Quorumの概念 Quorum自体の概念の説明はWikiなどを参照してください。ノード間で投票を行い、定足数が揃った処理を実行/破棄するという考え方です。 Quorum - Wikipedia 同期型のミラーディスク型から非同期のQuorum型へ Aurora以外のRDSのMulti-AZ配備は、マスターノードのディスクへの書き込みをブロックレベルでスタンバイ側に適用する完全同期なフィジカルレプリケーションを行っています。これにはいくつかの課題が考えら
CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障
日本時間 2014/11/27 の AM9時〜AM11時頃まで、全世界的に Amazon CloudFront に障害がありました。 CDNとして CloudFront を利用しつつ、障害時にはフェイルオーバーする方法をまとめました。 S3 CloudFrontのOriginがS3でない場合は、この項の設定は関係ありません。 CloudFrontのOriginとしてS3を使う場合、以下のようにします。 file.example.jp のような、使いたいドメイン名で S3バケット を作る Static Website Hosting を有効にしておく ドメイン名のバケットで Static Website Hosting が有効になっていないと、後述の Route53 の Alias Target に設定できません。 Health Check Route53 の Health Checks を
AWS re:Invent 2014 - Breakout Session 1日目が終了しました! 忘れないうちに本日の内容についてまとめておきます. 「AWS re:Invent 2014」とは 私自身,今回初参加となる「AWS re:Invent 2014」について簡単にまとめます. AWS re:Invent 2014とは,Amazon Web Service (AWS; http://aws.amazon.com/jp/) に関する世界最大のイベントで,AWSに関する知識はもちろん,クラウドサービスについての基本的知識から業界の最先端の動向まで,幅広く知ることが出来るカンファレンスです (※私的意見). 3回目の開催となる今回は,世界63カ国から13,500人以上の方が参加しているそうです.この数は1回目開催時の約2倍にあたるそうで,この規模の変化だけに着目しても,現在AWSが世界
re:Invent 2014 breakout session 1日目 個人的にメモっておきます。 Keynoteでは、AuroraがでたりConfigだったりCodeDeployだったりがでました。細かい機能の話は参照しておいて、所感中心で。 聴いたセッションは以下のとおり。 SDD406 -- Amazon EC2 Instances Deep Dive SDD415 NEW LAUNCH: Amazon Aurora: Amazon’s New Relational Database Engine BDT403 - Netflix's Next Generation Big Data Platform BDT402 -- Performance Profiling in Production: Analyzing Web Requests at Scale Using Amazon
Amazon SageMaker Geospatial Capabilities Now Generally Available with Security Updates and More Use Case Samples At AWS re:Invent 2022, we previewed Amazon SageMaker geospatial capabilities, allowing data scientists and machine learning (ML) engineers to build, train, and deploy ML models using geospatial data. Geospatial ML with Amazon SageMaker supports access to readily available geospatial dat
Filesadvisory-108.txt (signed advisory file) xsa108.patchAdvisory-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2014-7188 / XSA-108 version 4 Improper MSR range used for x2APIC emulation UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= The MSR range specified for APIC use in the x2APIC access model spans 256 MSRs. Hypervisor cod
はじめに こんにちは植木和樹です。8月23日にcloudpackさん主催のcloudpack night #7に参加してきました。夜8時すぎから始まった懇親会では、AWSを利用している各社の気合の入ったライトニングトークを聞くことができました。その中で「Roadworker」というツールをクックパッド株式会社の菅原さんが紹介されていました。 「cloudpack Night #7で発表しました / Roadworkerというツールを作りました」 このツールは一言でいうとRoute53(DNS)のレコードをChefやPuppetのようにコードで管理できる(もちろん冪等性も!)というものです。素晴らしいですね。動作デモの様子が上記ページにあるYoutubeの動画で紹介されていますが、とても簡単にDNSレコードをコードで管理できる様子がわかります。 それでは早速試してみましょう! 準備するもの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く