Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Amazon S3 インベントリを使用してストレージを管理できます。例えば、ビジネス、コンプライアンス、および規制上のニーズに対応して、オブジェクトのレプリケーションや暗号化のステータスを監査およびレポートするために使用できます。また、Amazon S3 同期 List API オペレーションのスケジュールされた代替手段として Amazon S3 インベントリを使用し、ビジネスワークフローやビッグデータジョブを簡素化、高速化できます。Amazon S3 インベントリは、List API オペレーションを使用してオブジェクトを監査しないため、バケットのリクエストレートには影響しません。 Amazon S3 インベントリは、カンマ区切り値 (CSV)、Apache Optimized Row Columnar (ORC)、または Apache Parquet 出力ファイルを通じて、S3 バケッ
こんにちは、虎塚です。 先日のAWSアップデートによって、CloudTrailでS3オブジェクトレベルのロギングができるようになりましたので、ご紹介します。 これまでもS3バケットレベルでの操作はCloudTrailで記録できましたが、オブジェクトへのアクセスのロギングはサポートされていませんでした。 今回のアップデートで、S3オブジェクトのPutやDeleteといった操作がCloudTailで追跡、記録できるようになりました。 S3オブジェクトレベルのロギングの概要 今回のアップデートに伴い、CloudTrailにイベントセレクタという新しい概念が登場しました。次の流れでイベントを捕捉し、ロギングします。 アカウント内でなんらかのイベントが起きる CloudTrailが全trailでイベントセレクタを評価する 各trailは、イベントセレクタの設定にしたがってロギングする (S3バケット
2016年1月から、AWSで無料のSSL証明書が発行できるようになりました。企業のコーポレートサイト等の静的サイトでも、SSL化するのが一般的になりつつありましたが、無料でSSL証明書が取得できるようになったことで、SSL化しない理由がなくなりました。やっておくと、少し詳しい人にも、それっぽく見えますし(笑) やりたいこと AWSのS3上にコーポレートサイトを作っておいて、Certificate ManagerでSSL証明書を発行して公開するっていうのが、ほとんど無料に近い金額でできるようになります。じゃあ、やっておこう。ひと昔前では考えられなかったようなリッチな構成が、ほとんど無料!すごい時代になったもんだ。 で、以下がやりたいことです。4つ目は、SEO対策的なアレです。 S3上にコーポレートサイト(静的サイト)を作る 独自ドメイン(ここでは、example.comとします)で公開する
今回の課題 こんにちは植木和樹です。本日のお題は「現在運用しているFTP/SFTPサーバーをAmazon S3でリプレースしたい」です。 外部関係業者とのファイルのやりとりにFTP/SFTPサーバーを使っているケースは数多くあると思います。社内にあまったパソコンにLinuxをインストールしてFTPサーバーを自前で運用していることもあるかもしれません。しかしデータのバックアップやハードウェアの故障などで手を取られている担当者の方がいらっしゃるのではないでしょうか。 そんな時はAmazon S3。99.999999999% の堅牢性と、99.99% の可用性を提供するストレージサービスです。 しかしFTPは長い運用実績の歴史があるサービスです。FTPで求められる様々な運用ニーズにS3はどこまで応えられるでしょうか?今回はその点を検証してみました。 FTPに求められる要望 以下にいくつかの代表的
re:Invent 2016はAWSの利用が一段回上に上がる素晴らしい発表が多かったです。さて今回取り上げるのはAthenaです。 https://aws.amazon.com/jp/blogs/news/amazon-athena-interactive-sql-queries-for-data-in-amazon-s3/ すでに素晴らしい資料があるのでそちらをご参照ください。ざっくり個人的な理解は、Google BigQueryのAWS版という雑な印象です。 https://www.slideshare.net/GanotaIchida/re-growth2016osaka-amazonathena-70077024 https://data.gunosy.io/entry/aws-athena-vs-bigquery 今回はS3をStatic website hostingしている場
Amazon S3 の Amazon CloudWatch メトリクスは、Amazon S3 を使用するアプリケーションのパフォーマンスを理解して向上させるのに役立つことがあります。Amazon S3 で CloudWatch を使用する方法は複数あります。 バケットの日次ストレージメトリクス バケットストレージは、CloudWatch を使用してモニタリングできます。これは、Amazon S3 からのストレージデータを収集し、読み取り可能な日次のメトリクスに加工します。これらの Amazon S3 のストレージメトリクスは 1 日に 1 回報告され、すべてのお客様に追加料金なしで提供されます。 リクエストメトリクス Amazon S3 リクエストをモニタリングし、オペレーションの問題をすばやく特定して対応します。メトリクスは、処理のレイテンシーの後に 1 分間隔で使用できます。これらの
Amazon Web Services ブログ S3 ストレージ管理アップデート – 分析、オブジェクトのタグ付け、インベントリ、メトリクス 本日、皆様がお持ちのストレージとそのアクセスパターンを詳しく知るための 4 つの S3 機能についてご説明したいと思います。何をどのくらい保管しているのか、どのように使用しているのかを知ることができ、その結果として、S3 ストレージクラスの使用に関する情報に基づいた意思決定を行うことができます。これらの機能は、バケットに何十万、何千、何百万、何十億というオブジェクトを持っていても、S3 を使用するすべての人にとって価値があります。 以下が概要です: S3 分析 – オブジェクトの格納状況と取得パターンを分析し、その結果を使って、最適なストレージクラスを選択することができます。あなたは S3 コンソールで表示される分析の結果を検査したり、お好みの BI
すぐに確認できるよう、メモとしてブログに残しておきます。 まずは設定の変更をしていないS3です。 【リクエスト】 GET /cdn.suz-lab.com/sample.txt HTTP/1.1 Host: s3.amazonaws.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Ke
最近子どもの水いぼを取る際に、麻酔テープが健康保険適応内である事を知った小室@福岡です。 AWSのドキュメントの一つに、Articles & Tutorialsという物が有ります。これはAWSの中の人、また使っているユーザーがこのように使うといいよ、とAWSをよりよく使える方法を教えてくれる場所です。 サーバーワークスでは、日々のAWSのドキュメントの確認だけではなく、このようなArticles & Tutorialsを読みより深くAWSのサービスについて理解を深めようと個々に担当し、社内発表会を行っています(始めたばかりだけどね!)。 今回私が訳してみたのはこちらです。 Best Practices for Using Amazon S3 この記事は2008年に投稿(更新2009年)されており、現在とは少し違うかもしれませんが、とても参考になりましたので、ご紹介したいと思います。 ※これ
はじめに 某WebメディアをGoogleのPageSpeed Insightsにて解析したところ、「画像にCache-Controlが設定されてないぞ」と怒られました。メディア内の記事には大量の画像が使われていて、それらの画像はS3にアップロードされたものを直接参照しています。 CloudFront使えよと言われて片付けられそうな案件ですが、リリース時からそんな準備万端で始められるような事業ばかりでもないわけです。既存のシステムをCloudFrontで置き換えようと思うと、もちろん画像のURLも変更されます。それに伴いシステムにも改修は入りますし、記事内に埋め込まれた画像のURLを頑張って置換する必要があります。ちょっとそれ時間かかる、ということで暫定的にS3に置いたコンテンツにCache-Controlを付けてみました。 これ書いてるうちに結局CloudFrontに移行したけどまあいいや
ブラウザのJavaScriptから直接S3にアップロードする方法。 サーバサイドに実サーバがあれば、サーバにアップ=>サーバからS3にアップするのが何も考えなくていいので楽だと思うのですが、AWS API Gateway / lambda等を使うシステムだと、そういう中継ができないので、大きなファイルなどをアップロードする場合はブラウザから直接S3にアップロードする形が必須になります。 そんな時に必要な手順を調べました。 軽く調べてみると、 JavaScript内にAWSのAccessKey/SecretKeyを埋め込んで、aws-sdk経由でアップロード サーバサイドでS3の編集権限のあるユーザでS3の署名付きURLを取得し、ブラウザサイドに送る サーバサイドでS3の編集権限のある時限ロールをSecurity Token Service(以下STS)で取得、それによりS3の署名付きURL
S3 にブラウザから直接ファイルをアップロードする方法について試してみました。 S3 には直接 POST でアップロード可能なので、HTML の Form を使ってアップロードを行います。 この際に、Policy と Signature というものが必要で、これらをアップロードしたファイルと同時に S3 に渡すことで、認証を行う仕組みになっています。 事前準備 S3 バケットの作成 自身の AWS のアクセスキーとシークレットキーを手元に用意 Policy と Signature の作成 最初に Policy Document を作成し、S3 へダイレクトアップロードする際の制約を定めます。 Policy Document は以下のような形式です。 {"expiration": "2013-08-17T00:00:00Z", "conditions": [ {"bucket": "buck
実際に実行すると以下のような URL が生成されます。 https://YOUR_BUCKET.s3.amazonaws.com/YOUR_KEY では、この URL を使って S3 にオブジェクトを登録してみましょう。 $ export URL=https://YOUR_BUCKET.s3.amazonaws.com/YOUR_KEY # generated pre-signed URL $ echo abcde > test.txt $ curl -D - -X PUT --upload-file test.txt $URL HTTP/1.1 100 Continue HTTP/1.1 200 OK x-amz-id-2: 9J3B1F6kcpjEszB8w0RJCyOlJPdjWyNDHxRhiQ0bl9NmZGD64iysF/e9Wr9vDWxj4MN1KyOoIlo= x-amz
{ "Statement":[ // S3ホームディレクトリでバケット一覧を表示するために必要 { "Effect":"Allow", "Action":[ "s3:ListAllMyBuckets" ], "Resource":"arn:aws:s3:::*" }, // バケットに対する操作を許可 { "Effect":"Allow", "Action":[ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource":"arn:aws:s3:::bucket" }, // オブジェクトに対する操作を許可 { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource":"arn:aws:s3:::bucket/*"
AWS では、リソースはユーザーが操作できるエンティティです。Amazon Simple Storage Service (S3) では、バケットとオブジェクトが元の Amazon S3 リソースです。すべての S3 のお客様のバケットには、オブジェクトが含まれている可能性があります。新機能が S3 に追加され、リソースもさらに追加されましたが、すべてのお客様がこれらの機能固有のリソースを使用しているわけではありません。Amazon S3 リソースの詳細については、「S3 リソース」を参照してください。 デフォルトでは、すべての Amazon S3 リソースはプライベートです。さらにデフォルトでは、リソースを作成した AWS アカウントのルートユーザー (リソース所有者) と、必要なアクセス許可を持つそのアカウント内の IAM ユーザーは、作成したリソースにアクセスできます。リソース所有者
おまけ 今回調査に使ったシェルスクリプト載せておきます。 権限毎にバケット何個も作って、オブジェクトも作って、アクセスしてみて、終わったら削除してという感じのものです。 #!/bin/bash UNIQ=$(date +'%Y%m%d%I%M%S') alias aws='aws --region ap-northeast-1' BUCKET_PREFIX=akeri-acl-test-$UNIQ- TARGET_PRINCIPAL="arn:aws:iam::123456789012:user/s3acltest" TARGET_MAIL="example@example.com" # create Bucket Policy Document UPLOADFILE=akeridayo.txt IAM_USERNAME=s3acltest echo "akeridayo" > $UPLO
Amazon S3でCross-Origin Resource Sharing(CORS)というものが使えるようになっていたようなので、クロスドメインで取得した画像をCanvasで利用する目的で実際に使ってみました。 Cross Origin Resource Sharingってなんだろう ブラウザではセキュリティのためにSame Origin Policyによって、他のオリジン(プロトコルとドメインとポート番号の組)へのデータ送受信を原則禁じています。 このセキュリティ上の制限を回避するのには一般的には以下のような方式があります。 ReverseProxy ( 過去のtech-sketch ) JSONP これに加えてCORSという手法が提案されて標準化される方向に向かっており、記事を書いている時点では勧告候補のようです。 CORSによって、自分のWebアプリケーションで他のオリジン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く