Amazon S3 will no longer charge for several HTTP error codes
Amazon S3 will make a change so unauthorized requests that customers did not initiate are free of charge. With this change, bucket owners will never incur request or bandwidth charges for requests that return an HTTP 403 (Access Denied) error response if initiated from outside their individual AWS account or AWS Organization. To see the full list of error codes that are free of charge, visit Billi
CloudFrontのS3 Originにはhostヘッダーを転送してはいけない - KAYAC engineers' blog
SREチームの長田です。 CloudFrontでstaticなファイルを配信しようとした時に少々ハマったのでそのメモです。 TL;DR CloudFront distributionのS3 Originは、Managed Policyの Managed-AllViewer を使うと機能しない。 何をしたのか statcなファイルを配信する要件があり、その対応としてCloudFront distributionのOriginにS3を設定しました。 CloudFrontのOrigin Access Identity(OAI)を作成し、S3 bucket policyにはこのOAIからのAPIリクエストのみを受け付けるよう設定しました。 docs.aws.amazon.com いざ配信用URLにHTTPリクエストすると以下のようなエラーになってしまいました。 <Error> <Code>Sign
Amazon S3 Update – Strong Read-After-Write Consistency | Amazon Web Services
AWS News Blog Amazon S3 Update – Strong Read-After-Write Consistency When we launched S3 back in 2006, I discussed its virtually unlimited capacity (“…easily store any number of blocks…”), the fact that it was designed to provide 99.99% availability, and that it offered durable storage, with data transparently stored in multiple locations. Since that launch, our customers have used S3 in an amazin
[Update] AWS DataSyncによるストレージサービス間のデータ転送にエージェントが不要となりました! | DevelopersIO
こんにちは。サービスグループの武田です。 AWS DataSyncというサービスをご存じでしょうか？オンプレミスのストレージ、Amazon S3、Amazon EFS、Amazon FSx for Windows File Serverとの間でデータ転送をするためのサービスです。これまではデータ転送に、仲介するDataSyncエージェントが必須でした。今回のアップデートで、ストレージサービス間であればエージェントが不要になりました！素敵！ ドキュメントに比較できるわかりやすい図がありましたので引用します。 日本語のドキュメントから。アップデート前はS3-EFS間でもエージェントが必要でした。 引用元：How AWS DataSync Works（日本語） こちらは英語のドキュメントから。アップデート後はストレージサービス間ではエージェントが不要に。 引用元：How AWS DataSync
![[Update] AWS DataSyncによるストレージサービス間のデータ転送にエージェントが不要となりました! | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/2b784a6042816e5213394d4af877132b593fe19d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Faws-datasync.png)
いつの間に！？既存オブジェクトを S3 レプリケーション出来るようになっていた！ | DevelopersIO
これまで S3 のレプリケーションにおいて、「既存オブジェクトはレプリケーション出来ない」とばかり思っていましたが、2019年11月頃にひっそりと既存オブジェクトのレプリケーションが出来るようになっていたのをご存知だったでしょうか?（私は先日、S3 の公式ガイドで見つけるまで知りませんでした） そういえば SDK のアップデートはあったよね 公式ブログでアップデートリリースを見た記憶がありませんが、そういえば11月頃の SDK リリース情報に「既存オブジェクトのレプリケーションをサポート」ってありましたよね。 Aws\S3 - Added support for S3 Replication for existing objects. This release allows customers who have requested and been granted access to re
オリジナルのS3バケットのバックアップシステムをCross Region Replicationに移行したはなし - KAYAC engineers' blog
SREチームの長田です。 Tech Kayac Advent Calendar Migration Trackの15日目です。 S3バケットのバックアップ Lobiでは投稿された画像ファイルをS3に保存しています。 S3に保存しているだけでは、S3から誤って削除した場合に復元することができません。 主に読み書きするS3バケットとは別に、バックアップ用のS3バケットを用意し、そちらに画像ファイルのコピーを保存しています。 バックアップの仕組みを用意した当時はAWS内にこれを実現する機能がなく、自前のLambda functionでコピーを行っていました。 Backup S3 objects with Lambda function S3バケットに画像ファイルがPUTされたイベントをLambda functionに通知し、 対象ファイルをダウンロードして別リージョンにあるバックアップ用のS3バ
AWS S3 APIのv2署名は6/24に廃止されず、まだ使える？（続報あり）｜TechRacho by BPS株式会社
続報1（2019/06/17）: 本記事公開後、以下の正式なアナウンスが公開されました🎉。これに油断せず、v4署名のライブラリにアップデートしましょう。 元記事: Amazon S3 Update – SigV2 Deprecation Period Extended & Modified | AWS News Blog Original Plan – Support for SigV2 ends on June 24, 2019. Revised Plan – Any new buckets created after June 24, 2020 will not support SigV2 signed requests, although existing buckets will continue to support SigV2 while we work with custo
2020年9月30日以前に作成済みの S3 バケットはパス形式廃止対象から除外されました | DevelopersIO
先日、2020年9月30日以降に S3 パス形式での API リクエストが受け付けられなくなる記事を投稿しました。 【注意喚起】 2020年9月30日以降、パス形式での S3 API リクエストは受け付けられなくなります。 その後、AWS 公式ブログにて、２０２０年9月30日以前に作成されている S3 バケットについては、パス形式廃止除外とする方針に変更したことが発表されましたので、あらためてシェアいたします。（前回のエントリーにも追記させていただきました） パス形式の廃止対象 Original Plan – Support for the path-style model ends on September 30, 2020. Revised Plan – Support for the path-style model continues for buckets created on
S3のアクセスログをRedshiftにロードする
AWSのログで遊ぼうシリーズ第2弾 – S3 x Redshift。 今回はS3のアクセスログを対象に、Redshiftにロードしてみます。 前提知識 S3アクセスログの有効化 方法は下記のドキュメント参照。 コンソールを使用したロギングの有効化 – S3開発者ガイド S3アクセスログのフォーマット S3のアクセスログは、スペース区切りで1行に1リクエストが記録されます。 各行には下記のフィールドが含まれます。（公式ドキュメントの抜粋です。） フィールド名 説明 bucket_owner 配信元バケット所有者の正規ユーザー ID。 bucket リクエストの処理対象のバケットの名前。システムで受け取ったリクエストの形式に誤りがあり、バケットを特定できない場合、そのリクエストはサーバーアクセスログに表示されません。 request_timestamp リクエストを受け取った時刻。形式は st
AWS S3で異なるアカウントが所有するバケット間をsyncする - Qiita
アカウントが異なるS3 bucket間を aws s3 sync したい場合の設定例。 前提 account: A bucket: AAAA account: B bucket: BBBB があったとして、AAAA → BBBB に aws s3 sync をしたい。 設定 B が AAAA に対して読み取ることを許可するため、AAAA の bucket policy に以下のような設定をします。 [ACCOUNT-ID-B] は B の aws acccount id (12桁の数字) です。 要するに arn:aws:s3:::AAAA/* に対して s3:GetObject arn:aws:s3:::AAAA に対して s3:ListBucket を許可ですね。 { "Version": "2008-10-17", "Id": "Policy1406622286590", "Stat
AWS News Blog
AWS Chatbot Now Integrates With Microsoft Teams I am pleased to announce that, starting today, you can use AWS Chatbot to troubleshoot and operate your AWS resources from Microsoft Teams. Communicating and collaborating on IT operation tasks through chat channels is known as ChatOps. It allows you to centralize the management of infrastructure and applications, as well as to automate and streamlin
AWS News Blog
Announcing General Availability of Step-by-Step Guides for Amazon Connect Agent Workspace At AWS re:Invent 2022 we announced the availability of step-by-step guides for Amazon Connect agent workspace in preview. My colleagues who collaborated to write the announcement post wrote about some of the challenges that contact centers face with training new agents to get up to speed with their agent desk
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
