既に S3 アップロードされているファイルの メタ情報 を変更する場合、通常は S3 の Management Console にある Properties で設定でき、設定可能なメタ情報には、 Content-Type, Content-Encoding, Content-Language, Cache-Control, Expires 等があります。 今回は、既に S3 にアップロード済の大量のファイルに対し、一括でメタ情報の変更を行い、 CloudFront のキャッシュを削除するまでの手順をまとめます。 実行環境 以下は ruby 2.1.2p95, Ruby AWS SDK ver2 を使用する前提で説明しています。 手順 今回は my-bucket という名前のバケットの、 mydir/images/... 以下にある、 500件程度のjpegファイル の Cache-Cont

各サービスに加え、サポート費用、消費税諸々含め300万以上の課金が発生しました。 幸い今回の事象はラックの検証環境上で発生した事象のため、お客様への影響はなかったものの、これが「もしお客様環境で起きていたら......」と考えると背筋が凍ります。 事象の原因 今回上記(A)(B)の仕組みを定期的に実行する想定で各々EventBridgeルールの設定をしましたが、(B)のEventBridgeルールの設定に考慮漏れがありました。 具体的には、以下のように記載をしていました。 EventBridgeルールの作成時、イベントパターンのフォームから生成したJSONとなります。 ※ S3にオブジェクトが配置されたら後続処理を実施するというテンプレートを使用しました。 テンプレートの内容を深く理解せず、そのまま流用したことが本事象の発端となっていました。 ※ ただ、EventBridgeでは、ルールが

Lambda(Python)からS3へファイルをアップロードしたり、読み書きしたりすることがあったので書き記しておきます。 権限周りの話は以前こちらに書いてあるので参考にして下さい　↓↓↓ Client APIとResource APIの違い ・Client APIはレスポンスが辞書型なので必要な情報を取り出しにくい ・Client APIはHTTP API 操作との 1 対 1 のマッピングが提供される ・Resource APIの方がオブジェクト指向っぽく書ける ・Resource APIが用意されていないことがあるサービスもある ＊ Resource APIはresponse.bodyというようにオブジェクトを取得してから属性を参照できると書いてあったが自分はなぜかレスポンスが辞書型であった。よく分からない。 S3にファイルをアップロードする ＊ 上書きするときもs3.put_obj

はじめに AWS（S3）に画像データを保存する必要性や手順をまとめたいと思います。 現状、herokuを用いてアプリのアップロードを行なっていますが、アップロードされた画像はアプリケーションのディレクトリに保存されていました。 しかし、ユーザーがアップロードした画像データは、アプリがデプロイまたは再起動（24時間に1回自動で行われる）される度に、消えてしまう仕様になっています。 そこで、ストレージサービス（画像等の膨大になるであろうデータを別途保管できる場所、サービスのこと）を利用することで、画像を長期的に保存することができるようになります。 ストレージサービスには様々な種類がありますが、今回はAWSが提供しているS3というサービスを使用します。 S3（Amazon Simple Storage Service）とは S3とは、AWSが提供するサービスの一つです。 （インターネット上にデー

Twitterでツイート検索するAPIを試してみるでツイートの取得を重複させないようにmax_idとsince_idを使います。 since_idをどこで持つのが一番面倒じゃないかなと考えて、「そうだLambdaの環境変数に持たせればLambda関数で完結する」と思ってやってみました。 boto3のupdate_function_configurationでできました。 考慮事項としては、既存の環境変数そのものの上書きなので、既存の環境変数も設定してあげないとです。 secret_name = os.environ.get('SECRET_NAME') level = os.environ.get('LOG_LEVEL', 'ERRO') since_id = os.environ.get('TWITTER_SINCE_ID', 0) def update_environ(function

こんにちは、上野です。 Lambda関数をワンクリックでURL公開できる機能が出ました！ aws.amazon.com 今までのLambda Lambda関数を（AWS認証無しの）HTTPS経由で実行するには、Lambdaの前段にAmazon API Gatewayを設置する必要がありました。 API Gatewayは便利で高機能なのですが、設定項目も多く、初めて触る方には難しい部分もあるかと思います。 今回の機能で、Lambdaのメニューから機能をONにするだけHTTPS公開できるようになりました。 やってみる Lambdaの作成画面に、「関数URLを有効化」のメニューが追加されているので、これをONにします。 初期状態では認証が必要なAWS_IAMが選択されていますが、今回はまずどれだけ簡単に公開できるかを試すため、NONEを選択します。 ※画面のとおり、URLを使用して全世界からLa

Amazon Web Services ブログ AWS Lambda Function URLs の提供開始: 単一機能のマイクロサービス向けの組み込み HTTPS エンドポイント 多くの企業や組織は、AWS Lambda を使用して回復力があるスケーラブルなアプリケーションを構築するために、マイクロサービスアーキテクチャの採用を進めています。これらのアプリケーションは、ビジネスロジックを実装する複数のサーバーレス関数で構成されています。各関数は、Amazon API Gateway や Application Load Balancer などのサービスを使用して、API エンドポイント、メソッド、およびリソースにマッピングされます。 しかし、Lambda 以外の追加のサービスを学習、設定、および運用することなく、関数の前に HTTPS エンドポイントを設定するための簡単な方法だけが必要な

コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR