20211010のAWSに関する記事は14件です。

看護師からインフラエンジニアに転職して2年で14個資格を取得した話

こんにちは。パエリア王子です。 2021年10月でインフラエンジニアになってからちょうど2年になりましたので、自分の振り返りを含め、取得した資格や経緯について書いていきたいと思います。 私は地方に住んでいますが、入社時からクラウドエンジニアになりたいと思いながら勉強を進めていました。 資格のおかげもあって、現在はクラウドエンジニアとして働いています。 資格取得の賛否について エンジニア業界では資格より経験や実務という文化があります。 私もそう思います。 しかし、中には「資格だけ持っていてもなんの意味もない」という意見も聞かれますが、個人的には「持っていないよりは持っていたほうが良い」と思います。 確かに試験勉強だけでは仕事はできませんが、実務がないのであればせめて資格(取得によって得られる知識)くらいは持っていたほうがよい、と思うからです。 資格の中には模擬試験とほとんど同じ内容の試験で丸暗記だけで受かる試験もありますが、それでも何もしないよりはましですし、継続的に資格取得するだけでも勉強する意欲があることはアピールできるからです。 それでは、IT完全未経験の元看護師が2年間で取得した資格を紹介します。 2021年10月現在に取得しているIT資格 (おおよその勉強期間) (取得順) 1年目 1. CompTIA A+ (6週間) 2. CompTIA Network+ (4週間) 3. LPIC Level 1 (6週間) 4. CompTIA Server+ (3週間) 5. CompTIA Security+ (3週間) 6. CompTIA Cloud+ (4週間) 7. AWS認定ソリューションアーキテクトアソシエイト (6週間) 8. AWS認定システムオペレーション(SysOps)アドミニストレータアソシエイト (4週間) 2年目 9. Azure Fundamentals (6週間) 10. ORACLE MASTER Bronze 12c (6週間) 11. CompTIA CySA+ (3週間) 12. AWS認定デベロッパーアソシエイト (4週間) 13. AWS認定ソリューションアーキテクトプロフェッショナル (8週間) 14. AWS認定DevOps エンジニアプロフェッショナル (8週間) だいたい2ヶ月に1つ取得しているペースですね。 中には1つの資格を取るのに試験を2つ合格しなければいけないものもありますので、不合格を含め受験回数は20回近いです。おそらく通っている?試験会場の中ではかなり常連なのではないでしょうか。 全部を乗せるのは難しかったので、少しだけバッジを載せておきます。(個人的にはAWSの六角形がかっこいい) 私は、はじめにも書いたとおり入社時よりクラウドエンジニアを目指していました。 クラウドといえばAWSだと思っていたので、AWS SAAの取得を入社時からの目標にしていました。 とはいえ、完全未経験でITについて何も知らなかったので、基礎的な部分でLPICやCompiTIAシリーズを取得してからAWSの資格を取得したという流れでした。 完全初心者だと取得したい資格はたくさんあるけど、どれから取っていけばよいか悩むことがあると思います。 おすすめの資格取得の順番 個人的には概ね私が取得していった順番で取っていくのがおすすめですが、未経験者が最短でクラウドを学ぶのに効率よく知識をつけていきたいのであれば LPIC → CompTIA Network+(勉強だけでも可) → AWS クラウドプラクティショナー → AWS ソリューションアーキテクト-アソシエイト(SAA) の順番で取るのが良いと思います。 LPIC と CompTIA Network+ でサーバーとネットワークの知識をある程度つけてからクラウドの勉強をする方が理解が深まりますし、実際にAWSを使ってみようと思ったときにAWS(クラウド)の知識だけでは難しいと思います。 それぞれの資格の有用性 主観ですが、それぞれの資格の有用性についても簡単に書いていきます。 LPIC、というかLinuxはクラウド、オンプレ関係なくインフラエンジニアなら避けて通れないものなので、初めの方に取っておいてよかったです。実務でもその時の知識を使うことは多いです。 CompTIAシリーズどの資格も広く浅くという内容でした。取得した方がいいかと言われると悩みますが、未経験の私としてはIT全般の基礎知識はCompTIAシリーズで学べたのでよかったと思います。(ただ試験料がとても高いので、自費だとしたら取得はおすすめしません。) AWS SAAは実務未経験でも合格できる資格だと思うので、もしクラウドエンジニアになりたいなら早めに取るのが良いと思います。 その他のAWSの資格もきちんと勉強すれば取得自体は可能ですが、意外と取得者が多くないので取ることで、少し希少性をアピールできるかもしれません。(結局実務経験なしだとアピールとしては弱いかもしれませんが) Oracle Bronze は今は Oracle Bronze DBA という試験1つで資格取得できますが、せっかくなのでSQLについても勉強したかったので、旧試験の 12c を取りました。DBAの方が簡単という噂もあるので、評価的にも今はまだ DBA より旧試験の方が高そうです。悩みどころではありますが、私は 12c をおすすめします。 私の今後について 資格はある程度取得していますが、まだまだ経験や知識は足りないと感じています。 今後も資格勉強は続けていく予定で、まだ取得していないCCNAやマルチクラウドに対応できるようにAzureやGCPの資格を今後1年かけて取得していきたいと考えております。 また、将来的には構築、もしくはDevOps的な仕事をしていきたいと考えており、Pythonなどのプログラミング言語も勉強しています。 コードを書くこと自体は好きなので、もう少しだけ手を広げて勉強していって、来年には自分の得意分野を見出して、その分野に特化して勉強を続けていこうと今は考えています。 最後に、せっかくそこそこな数の資格を取得したので個人的に難しかった資格ランキングを発表します。 とはいえ、単純に初めの方に取得した資格はそもそもITの知識が乏しかったので、当時はすべてが難しいと感じていたので単純な比較は難しいですが。 難易度ランキング3位 LPIC Level 1 (102) 一般的な難易度はそれほど高くないと思いますが、Linuxって何?おいしいの?っていうところから始まったので、理解するのに苦労した記憶があります。 難易度ランキング2位 AWS認定システムオペレーション(SysOps)アドミニストレータアソシエイト AWSの試験で唯一2度受験した試験です。 SAAがそれほど難しくなかったので、たかをくくったことが直接の原因ですが、SAAに比べて個人で使えるサービスが少ないので、そういう意味でも難易度が高いと思います。 難易度ランキング1位 AWS認定DevOps エンジニアプロフェッショナル これは一番最近受験した試験ですが、一番難しいと感じた部分は報量の少なさです。 AWSは最近人気なので、本やネット上でも情報が探せますが、プロフェッショナルレベルの試験までであればこれが一番情報量が少ないです。 単純な難しさもありますが、勉強のしにくさという理由もあり、1位といたしました。 AWS資格についてはそのうち記事を書きたいと思います。 それでは、また次回。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RDS Proxy のリーダーエンドポイントに IAM 認証が使えない

どうやら IAM 認証が使えるのはメインの Read/write エンドポイントだけみたいですね。 メインのエンドポイントとリーダーエンドポイントそれぞれで cli でトークンを作成して接続してみましたが、リーダーエンドポイントのときは次のエラーになりました。 sql: FATAL: The IAM authentication failed for the role xxxxx. Check the IAM token for this role and try again. 「token の作成にメインエンドポイントを指定して、接続先をリーダーエンドポイントにする」みたいなトリッキーな方法も試してみましたが変わらず。 参考記事
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SAA 試験対策メモ

抜け漏れがあった用語や概念の整理。 個人的なメモです。 EC2 Amazon Elastic Block Store (Amazon EBS) EC2 インスタンスで使用するためのブロックレベルのストレージボリューム。 ソリッドステートドライブ (SSD) 汎用 SSD Provisioned IOPS SSD ハードディスクドライブ (HDD) スループット最適化 HDD Cold HDD リザーブドインスタンス 期限前のインスタンスをマーケットプレイスで販売できる 障害回復 AMIを取得して別リージョンにコピー EBSだと、EC2の設定自体は復元できない ゴールデンイメージ 必要なソフトウェア等がインストールされた状態のAMIを用意しておく AMI -スナップショットが含まれている AWS Auto Scaling 起動テンプレートの設定 その前にAMIが設定されている必要がある スケーリング ロードバランサ―だけでは対応できないため、インスタンスにAuto Scalingを適用する DynamoDB コスト最適 書き込みキャパシティを増強するよりはSQSで負荷を下げるほうがコスト最適。 ユースケース メタデータ・セッションデータ 一連のストリームデータ RDS MySQL CPU使用率100% リードレプリカ 複数DBにSharding が効果的。 Redshift クロスリージョンスナップショット プライマリークラスターがダウンしてもすぐに利用できる。スナップショットがセカンダリーリージョンにコピーされる。 拡張VPCルーティング データの移動をVPC内に制限できる S3 イベント バケット自体にイベント機能がある プレフィックス(ディレクトリ) 使用すると、毎秒 3,500 の PUT/COPY/POST/DELETE リクエストまたは 5,500 の GET/HEAD リクエストをサポート Standard IA 処理中のデータには不適切。 仮想ホスティング https://bucketname.s3.Region.amazonaws.com データ保護 バージョニングを有効化 削除したバージョンを元に復元可能 IAM 本番用AWSアカウント 開発者用のアカウントに分割 例えばIAMポリシーでインスタンス削除を無効にすると開発環境で支障をきたすので、タグでの制御がよい APIアクセスキー AWS CLI Windows PowerShell 用 AWS Tools APIから直接HTTP呼び出し EMR 厳密にはデータベースではない。 ネットワークACL あくまでアクセス制御であり、暗号化に用いるものではない。 SQS メッセージ保持期間 デフォルト4日間。60秒〜14日間に変更できる。 可視性タイムアウト 有効期限内は他のEC2インスタンスでは処理されない。 デッドキュー デフォルトではデットキューには送られない。設定が必要。 VPC DNS hostnames 有効化すると、DNS名を受け取る NATゲートウェイ パブリックサブネットに設置 Route53 CNAMEレコード ドメイン名、ホスト名。 RDSがフェイルオーバーすると、このレコードが使用される。 VPN Site-to-Site VPN カスタマーゲートウェイ Amazon Kinesis Kinesisストリーム ストリーミングデータの処理向き。数GBのファイルには不向き。 Amazon Kinesis Data Firehose 用途:S3へのログ配信を蓄積。その後、解析処理を実行。 Amazon Kinesis Data Analytics 解析のみ。 FSx Amazon FSx for Windows 最大 2 GB/秒 数百万の IOPS 一貫したミリ秒未満 Amazon FSx for Lustre スパコンなど。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon DynamoDBの新しいコンソールに対する不満点

はじめに 2021/8/25にAWS DynamoDBは新しいコンソール画面がデフォルトとなりました。 https://aws.amazon.com/jp/about-aws/whats-new/2021/08/amazon-dynamodb-console-manage-data-resources/ 見た目は非常にシンプルで良いのですが、如何せん使い勝手が悪いというのが印象です。 これから改善されていくとは思いますが、不満点について残します。 ※本不満は2021/10/7時点の元です。  すでに解決されている可能性もありますので、ご注意ください。 新しいコンソールに対する不満 クエリ/スキャンの結果がリセットされない DynamoDBでレコードの確認をよくする際に、パーティションキーでクエリ検索することがよくあります。 新コンソールでは「実行する」「元に戻す」があるのですが、「元に戻す」で検索結果がリセットされません。 旧コンソールでは他のテーブルに異動した後に戻ると検索結果がリセットされますが、新コンソールではリセットされません。 新コンソールではDynamoDBを再度開きなおす必要があります。 追加レコードが反映されない APIやプログラムで新しいレコードを追加した後、追加先のテーブルを確認しても反映されない場合があります。 旧コンソールではテーブル画面の右上にある更新ボタンをクリックすると、すぐに反映されます。 新コンソールでは更新ボタンがテーブル一覧の部分にしかなく、この更新ボタンをクリックしてもテーブルが再度読み込まれることは内容です。 最後に DynamoDBの左メニューの最下部には「ご意見をお聞かせください」という項目があり、新コンソールに対するコメントをフィードバックできます。 これにより、新コンソールが改善することを期待します。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】EC2インスタンスのSSH接続時のタイムアウト問題の解決

Operation timed out 発生 AWSで仮想サーバーであるEC2インスタンスを作成しました。 MACにターミナルでコマンドを打つ練習のため、SSHでネット接続を試みました。 ところが、下記画像のように接続がタイムアウトと表示されてしまいます。 EC2がSSH接続ができていません? 何故ぇ?((((;゚Д゚))))))) 結論:原因はVPC 結論として、原因は自分のVPC環境に問題がありました。 課金を避けるためにAWSで不要なリソースを削除した際に、 デフォルトのリソースの必要な部分まで削除してしまったのがタイムアウトを招いていました。具体的にはインターネットゲートウェイを.....。 VPCとインターネットを繋げる為の出入り口を自ら破壊してしまったので、接続が出来るわけがないという? そうなると、インターネット接続するために、デフォルトのVPCで必要なリソースを作り直して再度アタッチするか、全て自分の手で作り直してみるのも良いと思います。 自分は後者にしました。 VPCの主なリソース VPCの最低限必要なリソースが下記です。 ※今回、IPアドレスを固定しないのでEIPは不使用 リソース名 説明 VPC Virtual Private Cloudの略 インターネットの中で小分けに区切った空間内に必要なリソースを構築していく。 サブネット VPC内でさらに細かくネット空間を設定できる。公開用のアプリを載せるパブリックサブネットや、公開しないデータベースを載せるプライベートサブネットを用途に合わせて作成できる。 ルートテーブル サブネットに関連づける。サブネットからインターネットに向ける通信を決めるルール。通信経路(ルート)となる宛先とゲートウェイを組み合わせる。 インターネットゲートウェイ VPCにアタッチする。VPCとインターネットを接続し、通信を可能にする出入り口 ※超重要 ※下記はdrowioで作成した図です。 構成図を書くのも慣れが必要ですね((((;゚Д゚))))))) VPC関連のリソースを作成したらリソース間でアタッチを忘れずに 上記のリソースたちを作成しただけだと、まだバラバラなリソースが存在しているだけです。そのため、リソース間の紐付けが必要です。 ①ルートテーブルにインターネットゲートウェイをアタッチします。送信先はインターネットゲートウェイ作成時に0.0.0.0/0としています。 ②VPCにインタネットゲートウェイをアタッチします。 これでVPC用に作成したリソースたちを紐づけたので、あとはEC2インスタンスを新たに作成するときにネットワーク欄に今回作成したVPCを選択します。 SSH接続成功 EC2インスタンスを新たに作ったので、パブリックIPv4アドレスを使って、MACのターミナルで再度SSH接続を行なってみます。 今度はEC2インスタンスがちゃんとSSH接続できました。 デフォルトのVPCでは通常問題なくSSH接続できるはずが、自分でリソースを弄った結果, 接続がうまくいかずに「???」となっていました。 VPCを自分で作るときはリソースの設定やアタッチをする事も出てくるので、何故タイムアウトが起きたのかを記録に残したく書いてみました。 この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS Step Functions] EC2とRDS(Aurora)をグループ単位かつ指定した順番に起動/停止する

はじめに EC2とRDS(Aurora)を、グループ単位かつ指定した順番に起動/停止する仕組みを AWS Step FunctionsとLambda(Python 3.9)で作りました。 もう少し詳しく 作成した StepFunctions ステートマシン の詳細を説明します。 以下のように複数のEC2,RDS(Aurora)がある場合に、タグを使いをグループ化と起動順序を設定します。 タグに必要な情報を設定し、起動したいグループと命令(起動命令 or 停止命令)を指定すると、順番に従いリソースを起動or 停止します。 具体的な設定例も含め説明します。以下図のような構成でEC2,RDS(Aurora)を作成します。 ※図にはリソースごとのタグ情報を記載しています 各リソースにはこのようにタグを設定します。 リソース Nameタグ/DB識別子 Groupタグ BootOrderタグ Group2タグ BootOrder2タグ EC2 tmp1 test1 2 ec2only 1 EC2 tmp2 test2 2 ec2only 2 RDS(Aurora) database-a test1 1 - - RDS(Aurora) database-b test2 1 test2A 1 タグ名 Group,Group2はグループの区分け用のタグです。 タグ名 BootOrder,BootOrder2は起動順番を設定するタグです。 作成した StepFunctions ステートマシンは、実行する際にグループ分けのタグと起動順番のタグを指定することができます。これにより、1つのリソースに、グループ分けと起動順番のタグを複数することが可能にしました。 グループ test1 をすぐに起動する場合 グループ test1 に所属するEC2とRDS(Aurora)を起動します。 StepFunctions実行時の 実行入力 は ↓ です。 { "EXEC": "start", "DATE": "now", "GroupTag": "Group", "GroupValue": "test1", "BootOrderTag": "BootOrder" } ※参考※ 実行入力とは以下図のように、作成したStep Functions ステートマシンを実行するときに設定する引数のようなもので、JSON形式で記載します。     実行入力 の各要素の意味はこちら ↓ 要素 説明 EXEC 実行命令 start or stop DATE 実行日時 YYYY-MM-DDThh:mm:ss+09:00例 2021-10-09T21:40:00+09:00now ←即時実行の場合 GroupTag グループ分けのタグ GroupValue グループ名 BootOrderTag 起動順番のタグ 起動処理は、BootOrderタグの値を昇順で処理します。RDS(Aurora)から起動を開始し、すべてのDBインスタンスが起動完了した後に、EC2が起動開始します。EC2が起動を完了するとStepFunctionsの処理が完了します。 グループ test2 を指定した時刻に停止する場合 グループ test2 に所属するEC2とRDS(Aurora)を停止します。 StepFunctions実行時の 実行入力 は ↓ です。 { "EXEC": "stop", "DATE": "2021-10-09T21:40:00+09:00", "GroupTag": "Group", "GroupValue": "test2", "BootOrderTag": "BootOrder" } DATEに指定した日時(2021年10月9日21時40分)に命令(今回は停止命令)を実行します。 停止処理は、BootOrderタグの値を降順で処理します。EC2から停止を開始し、停止が完了した後に、RDS(Aurora)が停止を開始します。RDS(Aurora)が停止を完了するとStepFunctionsの処理が完了します。 グループ ec2only をすぐに起動する場合 グループ ec2only に所属するEC2を停止します。 StepFunctions実行時の 実行入力 は ↓ です。これまでの例ではグループ分け用のタグは Group でしたが今回は Group2 を使用します。 { "EXEC": "start", "DATE": "now", "GroupTag": "Group2", "GroupValue": "ec2only", "BootOrderTag": "BootOrder2" } グループ test2A をすぐに起動する場合 グループ test2A に所属するRDS(Aurora)を起動します。 StepFunctions実行時の 実行入力 は ↓ です。 { "EXEC": "start", "DATE": "now", "GroupTag": "Group2", "GroupValue": "test2A", "BootOrderTag": "BootOrder2" } 以上で使い方の説明はおわりです。 StepFunctions ステートマシン の紹介 概要 ソースはgithubに置きました。 StepFunctionsのフローです。 3種類のLambda(Python 3.9)スクリプトを使用します。 Lambda (GetTargetResources) 対象のリソース(EC2,RDS)の情報を取得し、起動(or停止)の順番に並べる 起動の場合:起動順場を示すタグ(BootOrderタグ)昇順に並べ替えます 停止の場合:起動順場を示すタグ(BootOrderタグ)降順に並べ替えます Lambda (ExecResource) 実行命令(start or stop)を実行する 実行結果をJSON要素 Response に登録する Lambda (StatusCheck) 対象のリソースの状態(起動中,停止中,初期化中など)を取得する 取得した状態をJSON要素 NextAction に登録する EC2のステータス別の判定 EC2のステータス判定は、インスタンスの状態(InstanceStatuses)(図赤枠)とステータスチェック(InstanceStatus,SystemStatus)(図青枠)で判定します。 EC2の状態判定について EC2の状態判定について、running以外はインスタンスの状態(InstanceStatuses)で判定することにしました。 InstanceStatuses 判定 NONE 起動命令(start)→WAIT停止命令(stop)→NEXT pending WAIT terminated SKIP stopping WAIT stopped 起動命令→WAIT停止命令→NEXT shutting-down WAIT running InstanceStatus, SystemStatusで判定 インスタンスの状態(InstanceStatuses)がrunningの場合は、ステータスチェック(InstanceStatus,SystemStatus)で判定します。 InstanceStatus--SystemStatus--命令 判定 備考 ok--ok--stop の場合 WAIT 起動かつ停止命令(stop) ok--ok--start の場合 NEXT 停止かつ起動命令(start) NONE--NONE--stop NEXT 停止かつ停止命令 NONE--NONE--start WAIT 停止かつ起動命令 impaired含む ERROR 障害発生 insufficient-data含む WAIT データ不足 not-applicable含む WAIT 未適用 initializing含む WAIT 初期化中 その他 WAIT RDS(Aurora)の状態判定について RDS(Aurora)には、DBクラスターとDBインスタンスがあります。DBクラスターを起動すると、DBクラスター配下のDBインスタンスも起動を開始します。指定したRDS(Aurora)の起動が完了したかの判定は、そのDBクラスター配下の全DBインスタンスの状態で判定します。 1つのDBクラスターに複数のDBインスタンスが存在する場合があるので、状態判定はそれら全てのDBインスタンスが起動した場合に起動完了と判定するようにします。 DBインスタンスごとに状態の判定は以下表のようにしました。 DB instance status 判定 available 停止命令(stop)→WAIT起動命令(start)→NEXT backing-up NEXT configuring-enhanced-monitoring WAIT configuring-iam-database-auth WAIT configuring-log-exports WAIT converting-to-vpc WAIT creating WAIT deleting WAIT failed ERROR inaccessible-encryption-credentials ERROR incompatible-network ERROR incompatible-option-group ERROR incompatible-parameters ERROR incompatible-restore ERROR insufficient-capacity ERROR maintenance WAIT modifying WAIT moving-to-vpc WAIT rebooting WAIT resetting-master-credentials WAIT renaming WAIT restore-error ERROR starting WAIT stopped 停止命令→NEXT起動命令→WAIT stopping WAIT storage-full ERROR storage-optimization WAIT upgrading WAIT 全DBインスタンスの状態を1つの変数(allRtnVal)に連結して格納し、以下表の判定条件で状態を判定します。 変数allRtnVal 判定 ERROR 含む ERROR WAIT 含む WAIT その他 NEXT 参考 DBインスタンスのステータス Viewing DB instance status SDK(boto3) EC2 https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html SDK(boto3) RDS https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html さいごに モタモタしてたらStep Functionがアップデートしてました。新機能を使って、今回作ったステートマシンをアップデートできたらまたQiitaで紹介しようと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

S3にアップした画像が表示されない

はじめに こちらの記事でなんとかS3への画像アップロードを実装したものの、なぜか表示がされない・・・というエラーにぶつかりましたのでメモを残していきます。 エラー内容  S3へのアップは問題なくできており、表示ができないというパターンです。 S3のバケットから保存されたファイルの詳細をみていきます。 オブジェクトURLをクリックするとこんな表示がされました。 調べてみると、どうやら画像へのアクセス許可がされていないようです。解消するためにはバケットポリシーを編集していく必要があります。 バケットポリシーの編集  バケット名をクリックして、アクセス許可のタブをクリックするとこんな画面が出てきます。 編集を押すと編集画面へ遷移します。 記入の仕方はこちらの公式ページから確認することができます。 今回の場合は匿名ユーザーに読み取り専用権限を付与することでなんとかなりそうです。 このように書いていきます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "PublicRead", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::バケット名/*” } ] } この時、自分で作ったバケット名をResourceに入れるようにしてください。 終わりに 無事に表示することができました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel+Amazon S3 画像をアップする方法

はじめに  Laravelでアプリを作ったのでHerokuで公開してホッとしたのも束の間、どうやらHerokuでは画像の保存ができないらしい・・・。 ということで今回はS3へ画像を保存する方法を取りたいと思います! 初心者の備忘録ですので、理解不足はご容赦ください。 AWSアカウントの作成  公式を参考にアカウントを作成しましょう。その際、access keyとsecret access keyが発行されるのでメモっておきましょう。 忘れた場合はこちらを参考にしてみてください。 S3のバケットを作る  こちらを参考にバケットを作成してください。ここに画像ファイルが保存されていきます。  その際に、ブロックパブリックアクセスをオフにしてください。 これでAWSの設定は完了です! パッケージのインストール  最初にAWS SDK for PHPをインストールします。 $ composer install aws/aws-sdk-php または $ composer require aws/aws-sdk-php 次に、flysystem-aws-s3-v3をインストールしていきます。 $ composer require league/flysystem-aws-s3-v3 laravel8の場合は $ composer require league/flysystem-aws-s3-v3:^1.0 このようにすることでインストールできます。 この辺りがうまくいかない場合はcomposer.jsonやcomposer.lockをゴニョゴニョする必要があるみたいです。エラーメッセージをよく読んで戦っていきましょう。 Laravelの設定  次に.envファイルを編集していきます。 このように書きます。 AWS_ACCESS_KEY_ID=最初に生成されたアクセスキー AWS_SECRET_ACCESS_KEY=最初に生成されたシークレットアクセスキー AWS_DEFAULT_REGION=バケットのリージョン AWS_BUCKET=バケット名 AWS_USE_PATH_STYLE_ENDPOINT=false これで設定は完了です。 コントローラーとビューの作成 次に、コントローラーに画像をアップする処理、ビューに画像を表示する処理を書いていきます。 controller.php public function store(Request $request) { $item = new Item(); if(empty($errors)){ $img = $request->file('img'); $path = Storage::disk('s3')->putFile('/test', $img,'public'); $item->img = $path; $item->save(); } return redirect()->route('home'); } データベースにはS3に保存された画像のパスが保存されます。 表示はこんな感じです。 index.blade.php {{ Storage::disk('s3')->url("$item->img") }}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Lambdaで取得した画像をKinesis及びFirehose経由でS3にアップロードする

Kinesisの動作確認のため、Lambdaから画像を流した時の個人メモ (参考)Lambdaで取得した画像をKinesis Firehose経由でS3にアップロードする (参考)Kinesis — Boto 3 Docs 1.9.96 documentation - Amazon AWS Kinesis 「データストリームの作成」を押下 シャード数は最小値として作成 作成されたことを確認 Kinesis Firehose 「配信ストリームを使用した処理」を押下し、Firehose作成画面に遷移する Lambdaで取得した画像をKinesis Firehose経由でS3にアップロードするにて 作成したFirehoseはインプット元として「Direct PUT」を選択したため、流用できない Kinesisから転送するので「Amazon Kinesis Data Streams」とし、流す先としてS3を選択 今回はS3 Buffer hintsを最小値に設定 他設定はLambdaで取得した画像をKinesis Firehose経由でS3にアップロードするを参照 作成されたことを確認 動作確認 コンソール画面からデモデータを送信 しばらくしたら送信を止める S3に出力されていることを確認 Lambdaで取得した画像をKinesis Firehose経由でS3にアップロードするのようにLambdaからPutRecordするとエラーとなる Firehose作成時に「Direct PUT」を選択していないから? { "errorMessage": "An error occurred (InvalidArgumentException) when calling the PutRecord operation: This operation is not permitted on KinesisStreamAsSource delivery stream type.", "errorType": "InvalidArgumentException", "requestId": "e48441e7-7cb2-41e8-adea-23fba73b12b6", "stackTrace": [ " File \"/var/task/lambda_function.py\", line 54, in lambda_handler\n result = put_to_firehose(img)\n", " File \"/var/task/lambda_function.py\", line 38, in put_to_firehose\n response = firehose.put_record(\n", " File \"/var/runtime/botocore/client.py\", line 386, in _api_call\n return self._make_api_call(operation_name, kwargs)\n", " File \"/var/runtime/botocore/client.py\", line 705, in _make_api_call\n raise error_class(parsed_response, operation_name)\n" ] } Lambda Python3.9にて作成 自動生成されたロールを選択 ロールにアタッチされているポリシーを以下のように修正 画像の取得元であるS3へのGetObjectを付与 今回は取得したバケットの別フォルダにアップロードする KinesisへのPutRecordを付与 logsはデフォルトのまま { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "kinesis:PutRecord", "s3:GetObject", "logs:CreateLogGroup" ], "Resource": [ "arn:aws:logs:(リージョン名):(AWSアカウント):*", "arn:aws:kinesis:(リージョン名):(AWSアカウント):stream/(ストリーム名)", "arn:aws:s3:::(バケット名)/*" ] }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:(リージョン名):(AWSアカウント):log-group:/aws/lambda/testingKinesis:*" } ] } ソース修正 lambda_function.py import os import logging import boto3 import json import random # ログ設定 logger = logging.getLogger(__name__) logger.setLevel(os.environ['LOG_LEVEL']) # 環境変数から取得 BACKET_NAME = os.environ['BACKET_NAME'] FILE_PATH = os.environ['FILE_PATH'] STREAM_NAME = os.environ['STREAM_NAME'] # S3から指定したバケット、フォルダ、ファイル名の画像を取得する # 取得できる画像サイズはLambdaのメモリーに依存 # return:画像のバイナリデータ def get_img_from_s3(): logger.debug('start get_img_from_s3()') s3 = boto3.client('s3') response = s3.get_object(Bucket=BACKET_NAME, Key=FILE_PATH) body = response['Body'].read() logger.debug('end get_img_from_s3()') return body # 画像をKinesisに流す # img:画像のバイナリデータ # return:プットした結果 def put_to_kinesis(img): logger.debug('start put_to_kinesis()') kinesis = boto3.client('kinesis') response = kinesis.put_record( StreamName=STREAM_NAME, Data=img, PartitionKey=str(random.randint(1,4)) ) logger.debug('end put_to_kinesis()') return response def lambda_handler(event, context): logger.debug('start lambda_handler()') img = get_img_from_s3() result = put_to_kinesis(img) logger.debug('end lambda_handler()') return result 環境変数設定 動作確認 Lambdaで取得した画像をKinesis Firehose経由でS3にアップロードすると同様 アップロードされたことを確認 感想 S3 Buffer hintsを最小値にしたことで1分たたずにS3にアップロードされた 厳密に1分ではなかった 連続で画像を流した場合は1ファイルとしてまとめられる 直接Firehoseに流した場合と同様
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

何となくわかった気になる週刊AWS - 2021/9/27週

はじめに こんにちは、なじむです。 DAS の試験勉強を進めていますが、かなり順調に分からないということが分かり、気持ちの良い激痛を感じている今日この頃です。 というわけで今週も張り切ってやっていきましょう!AWS Japan さんがまとめている週刊AWSで確認した内容の自分用メモ。 今回は9/27週のアップデートです。 9/27(月) Amazon Connect Wisdom の一般提供を開始 クラウド型コンタクトセンターを構築するサービスである Amazon Connect で、Amazon Connect Wisdom が使用可能になりました。 Connect Wisdom は、FAQ, ファイル, Wiki, 過去の通話履歴など、各所に分散したノウハウを Salesforce や ServiceNow に集約し、顧客への回答を迅速に行うためのサービスです。 イメージは以下です。右上の検索バーに質問を入力することで、集約したリポジトリから Wisdom が回答を検索します。 (出典) Amazon Connect の新機能: Voice ID、Wisdom、アウトバウンド通信 また、9/13(月) に GA となった Contact Lens for Amazon Connect と併せて使用することで、顧客とオペレータが会話をしている最中に、その会話内容から自動でリアルタイムに解決策を検索することも可能です。 これ凄く良い機能ですよね。 日本リージョン対応状況 東京:対応 大阪:未対応 Amazon Connect Voice ID の一般提供を開始 同じく Amazon Connect で、Amazon Connect Voice ID が使用可能になりました。 Connect Voice ID は、発話者の音声からその人が誰かを判別してくれる機能です。電話をかけた時に最初に行う「名前・住所・電話番号を教えてください。はい、本人確認が取れました」というやり取りがなくなるイメージでしょうか。 (出典) Amazon Connect の新機能: Voice ID、Wisdom、アウトバウンド通信 また、音声から本人かどうかを判断するので、なりすましのような被害を防ぐことも可能です。 ただ、例えば家族の誰かが電話した時とかはどういう対応になるんだろう。そこはやっぱり人間の判断が入るんだろうか。 日本リージョン対応状況 東京:対応 大阪:未対応 Amazon Connect が、通話、テキスト、E メール用の大量のアウトバウンド通信のプレビューでの提供を開始 更に Connect のアップデートです。 Connect の画面から顧客に電話をかける、メールを送信するといったことができるようになりました。スケジューリングして、大量の顧客にメールを送付したり電話をかけたりすることができます。また、電話の場合は自動的に電話をかけ、顧客が電話に出た場合のみオペレータに割り当てるようなので、オペレータの効率が非常に上がるのではないかなと思います。 マーケティングとして、顧客にメールを送ったり、里程をリマインドしたりといったことを、他のサードパーティ製のツールを使わなくても実現できるようになり、ツールが減ることによるオペレータの負担の軽減、経費の削減等につながるものと思われます。 こちらも以下の AWS ブログにまとまっていますので参照ください。 (出典) Amazon Connect の新機能: Voice ID、Wisdom、アウトバウンド通信 (2021/10/11 間違っていたので修正) - 日本リージョン対応状況 - 東京:非対応 - 大阪:非対応 Application Load Balancer が、ネットワークロードバランサーとの直接統合で、AWS PrivateLink および静的 IP アドレスを有効に ロードバランサーのマネージドサービスである ELB において、NLB のターゲットとして ALB が設定できるようになりました。 (出典) Application Load Balancer-type Target Group for Network Load Balancer 本アップデートにより NLB の特徴である 静的 IP や PrivateLink の設定を ALB でも疑似的に行えるようになりました。 嬉しい点として ALB の IP を固定化する運用をしなくて良くなった ALB の IP 固定化をするための Lambda を作成、管理しなくて良くなった Global Accelerator を使わなくてもよくなった PrivateLink 経由でアクセスできるようになった VPC ピアリングしなくても、他の AWS アカウントから ALB(Web アプリケーション)にアクセス可能に VPC の Cidr 重複なども気にしなくて OK 等が上げられます。 実際の画面は以下です。ターゲットグループに ALB の項目が追加されており、これを NLB のターゲットとして指定することで構築することができます。 やってみた系はクラメソさんのブログが参考になりました。 (参考) [アップデート] NLBのターゲットにALBを登録できるようになりました! ALB の IP アドレスを固定したい場合ってどんな時だろうと考えてみたのですが、 社内や何かしらの DNS に登録したい時に A レコードしか受け付けてもらえない場合 社内や他の AWS アカウントからアクセスする場合に、特定の IP アドレスしか受け付けてもらえない場合 とかでしょうか。 間違ってるかも…この辺は実運用をやったことが無い人の弱み… 日本リージョン対応状況 東京:対応 大阪:対応 9/28(火) Amazon EC2、全リージョンのリソースをすべて閲覧できるコンソールで Global View を提供開始 すべてのリージョンの EC2, VPC, サブネット, セキュリティグループ, EBS を一つの画面で確認できる EC2 Global View が使用可能になりました。 この機能、実は 2021/9/1 に実装されていたのですが公式に発表されたのがこの日でした。何でラグがあったんだろう。 実際の画面は以下です。 リージョンごとのサマリを確認 リソースの一覧を確認 リソースの詳細を確認 すべてのリージョンのリソースを集計するせいか、初回や画面更新時のアクセスは凄く重いです。 日本リージョン対応状況 ※グローバルサービス 東京:対応 大阪:対応 9/29(水) Amazon Managed Service for Prometheus is now Generally Available with support for alert manager and rules 監視ツールの OSS として Prometheus がありますが、Prometheus のマネージドサービスとして Amazon Managed Service for Prometheus が使用可能になりました。昨年の re:Invent でパブリックプレビューとして発表されていましたが、それが遂に GA となりました。また、パブリックプレビューの段階と比較して、以下の機能も追加になっています。 2021/8/31 に Amazon Managed Grafana も GA になったので、これでようかくという感じですね。 (参考) AWSは、SAML2.0 と Grafana v8.0 の機能を備えた Amazon Managed Grafana の一般向け提供を発表します アラートマネージャ 記録ルール アラートルール 実際の画面は以下です。 ワークスペースを作成すると、書き込み用の URL と読み込み用の URL が発行されます。Prometheus にメトリクスを送る Pods には書き込み用の URL を、可視化する Grafana には読み込み用の URL を設定してあげると可視化することができます。 やってみた系の記事は以下が参考になりました。投稿した後も更新を続けるの凄い。 (参考) Amazon Managed Service for Prometheus 触ってみた アラートマネージャとルールに関するやってみた系の記事は公式ブログが参考になりました。こちらも参照ください。 (参考) Amazon Managed Service for Prometheus Is Now Generally Available with Alert Manager and Ruler EKS があっても自分でやってみた系の画面出さないとな…とは思ってはいます。。。 日本リージョン対応状況 東京:対応 大阪:未対応 Achieve up to 34% better price/performance with AWS Lambda Functions powered by AWS Graviton2 processor Lambda で Graviton2 のプロセッサーが使用可能になりました。これにより、コストパフォーマンスが 34% 向上しているようです。ARM ベースの CPU で動く Lambda であれば、こちらを選択するのが良さそうです。 コストを比較してみると以下のようになっていました。コストだけで見ると ARM ベースの方が 20% 程度安くなっているので、パフォーマンスが 14% 程度向上している感じでしょうか。 (料金の単位は USD/msec) メモリ(MB) 料金(x86) 料金(Arm) 料金比較(Arm/x86) 128 0.0000000021 0.0000000017 81.0% 512 0.0000000083 0.0000000067 80.7% 1,024 0.0000000167 0.0000000133 79.6% 1,536 0.0000000250 0.0000000200 80.0% 2,048 0.0000000333 0.0000000267 80.2% 3,072 0.0000000500 0.0000000400 80.0% 4,096 0.0000000667 0.0000000533 79.9% 5,120 0.0000000833 0.0000000667 80.1% 6,144 0.0000001000 0.0000000800 80.0% 7,168 0.0000001167 0.0000000933 79.9% 8,192 0.0000001333 0.0000001067 80.0% 9,216 0.0000001500 0.0000001200 80.0% 10,240 0.0000001667 0.0000001333 80.0% (参考) AWS Lambda 料金 実際の画面は以下です。 日本リージョン対応状況 東京:対応 大阪:未対応 Amazon Redshift が、次世代の Amazon Redshift クエリエディタを発表 データウェアハウスのマネージドサービスである Redshift で、クエリエディタ v2 が使用可能になりました。v2 になったことで以下のことができるようになったようです。 保存したクエリのチーム内への共有 チームは IAM ユーザ or IAM ロールに付与された sqlworkbench-team タグの値で管理します。 保存したクエリのバージョン管理 グラフビューへの切り替え 実際の画面は以下です。 左のメニューから v1, v2 どちらか好きな方を起動できます。 比較画面は以下です。 クエリエディタ v2 の画面 クエリの共有。保存したクエリを右クリックして、[Share with may team] をクリック。 バージョン管理。保存したクエリを右クリックして、[Version history] をクリック。 グラフィカルビューは公式ブログを参照ください。やってみた系の記事です。 (参考) Introducing Amazon Redshift Query Editor V2, a Free Web-based Query Authoring Tool for Data Analysts 大阪リージョンだけ対応していないようです。 日本リージョン対応状況 東京:対応 大阪:未対応 横串検索の新しいデータソースとして、Amazon RDS for MySQL および Amazon Aurora MySQL データベースの一般提供開始を発表 データウェアハウスのマネージドサービスである Redshift で、RDS for MySQL, Aurora MySQL への Federated Query が可能になりました。 昨年の re:Invent でプレビューとして発表された機能が GA になったというアップデートです。 (参考) Amazon Redshift now includes Amazon RDS for MySQL and Amazon Aurora MySQL databases as new data sources for federated querying (Preview) Federated Query を使用すると、Redshift に作成した DB だけでなく、S3 や EC2 に構築した DB、RDS 等のデータを横断的にクエリできるようになります。 (出典) Amazon Redshift の新機能 – データレイクエクスポートとフェデレーテッドクエリー やってみた系の記事は Federated Query が GA した時(2020/4/16)の記事ですが、以下が参考になりました。GA 時点では PostgreSQL のみの対応だっため DB は違いますが、これを MySQL に置き換えてあげれば今回のアップデート内容が確認できるかと思います。 (参考) [新機能] Amazon Redshift Federated QueryがGAになったので試してみました 日本リージョン対応状況 東京:対応 大阪:対応 9/30(木) Amazon ECS による AWS Fargate のクロック精度のモニタリング AWS Fargate で実行している Amazon ECS タスクのシステム時間の精度(NTP サーバとの時刻のズレ)を Cloudwatch メトリクス(ClockErrorBound)でモニタリングできるようになりました。 (出典) Manage Amazon EC2 instance clock accuracy using Amazon Time Sync Service and Amazon CloudWatch – Part 1 ClockErrorBound の計算方法など、詳細は AWS 公式ブログを参照ください。 (参考) Manage Amazon EC2 instance clock accuracy using Amazon Time Sync Service and Amazon CloudWatch – Part 1 日本リージョン対応状況 東京:対応 大阪:対応 AWS Lambda now supports triggering Lambda functions from an Amazon SQS queue in a different account Lambda を実行するためのトリガーとして、他の AWS アカウントの SQS を指定できるようになりました。Lambda 管理用 AWS アカウントとかを用意するところも出てくるんだろうか。 使用するには権限周りの設定が必要になります。 Lambda に設定した IAM ロールに、対象の AWS アカウントの SQS を操作するための権限が必要 sqs:ReceiveMessage sqs:DeleteMessage sqs:GetQueueAttributes SQS のアクセスポリシーに、Lambda に設定した IAM ロールからのアクセス許可が必要 実際の画面は以下です。 「SQS キューの ARN を選択または入力します。」となっていて、他の AWS アカウントの SQS を指定できるようになっています。 日本リージョン対応状況 東京:対応 大阪:対応 AWS が AWS クラウドコントロール API の一般提供を発表 クラウドコントロール API が使用可能になりました。 これまで、サービス毎に API の仕様が異なり、例えば AWS CLI でリソースの一覧を参照する際、list-functions や describe-log-groups 等で言葉が違ったり、パラメータも異なっていました。 クラウドコントロール API が使用可能になったことで、 CLI で操作する際の文法が整うのでツールの開発や実行がしやすくなった Terraform や Pulumi 等、他の IaC ツールでの環境構築がより速く、より簡単になった と言ったメリットがあります。 CloudFormation Registry で利用可能になったら即使えるようになるのも嬉しいですね。 AWS CLI で実行するためには、2.2.43 以上のバージョンが必要になります。以下を参考に、それぞれの環境に応じた手順を実施してください。 (参考) AWS CLI バージョン 2 のインストール、更新、アンインストール 以下のような形で実行できます。既存の API の実行方法とも比較してみます。 Cloudwatch Logs ロググループの一覧取得 # Logs APIの場合 $ aws logs describe-log-groups { "logGroups": [ { "logGroupName": "API-Gateway-Execution-**********/v1", "creationTime": 1111111111111, "metricFilterCount": 0, "arn": "arn:aws:logs:ap-northeast-1:**********:log-group:API-Gateway-Execution-**********/v1:*", "storedBytes": 0 } ] } # CloudTrail API の場合 $ aws cloudcontrol list-resources --type-name AWS::Logs::LogGroup { "TypeName": "AWS::Logs::LogGroup", "ResourceDescriptions": [ { "Identifier": "API-Gateway-Execution-Logs_**********", "Properties": "{\"LogGroupName\":\"API-Gateway-Execution-Logs_**********\",\"Arn\":\"arn:aws:logs:ap-northeast-1:**********:log-group:API-Gateway-Execution-Logs_**********:*\"}" } ] } Lambda 関数の一覧取得 # Lambda APIの場合 $ aws lambda list-functions { "Functions": [ { "FunctionName": "test", "FunctionArn": "arn:aws:lambda:ap-northeast-1:**********:function:test", "Runtime": "python3.9", "Role": "arn:aws:iam::**********:role/amplify-login-lambda-**********", "Handler": "lambda_function.lambda_handler", "CodeSize": 299, "Description": "", "Timeout": 3, "MemorySize": 128, "LastModified": "2021-08-26T10:37:12.854+0000", "CodeSha256": "**********", "Version": "$LATEST", "TracingConfig": { "Mode": "PassThrough" }, "RevisionId": "**********-****-****-****-**********", "PackageType": "Zip", "Architectures": [ "x86_64" ] } ] } # CloudTrail API の場合 $ aws cloudcontrol list-resources --type-name AWS::Lambda::Function { "TypeName": "AWS::Lambda::Function", "ResourceDescriptions": [ { "Identifier": "test", "Properties": "{\"Role\":\"arn:aws:iam::**********:role/amplify-login-lambda-**********\",\"FileSystemConfigs\":[],\"FunctionName\":\"test\",\"MemorySize\":128,\"Runtime\":\"python3.9\",\"Description\":\"\",\"TracingConfig\":{\"Mode\":\"PassThrough\"},\"Timeout\":3,\"PackageType\":\"Zip\",\"Handler\":\"lambda_function.lambda_handler\",\"Arn\":\"arn:aws:lambda:ap-northeast-1:**********:function:test\",\"Architectures\":[\"x86_64\"]}" } ] } 出力内容は結構変わっています。また、当然ですが対応していないリソースタイプは操作できません。少し触った感じ、まだまだ対応していないリソースタイプも多いので、これからに期待かなと思いました。対応しているリソースタイプは以下を参照ください。 (参考) Resource types that support Cloud Control API 日本リージョン対応状況 東京:対応 大阪:未対応 Announcing General Availability of Amplify Geo for AWS Amplify 認証基盤やストレージ等、バックエンドをコマンド一つで作成し、アプリケーションの開発を xxx するサービスである Amplify で、地図などの位置情報サービスを簡単に追加できる Amplify Geo が GA となりました。 2021/8/3 に Developer Preview として発表されていましたが、それが GA になったというアップデートです。 (参考) Amplify Geo for AWS Amplify のデベロッパープレビュー発表 amplify add geo と実行することで、裏で Location Service が作成され、アプリケーション上に地図などの位置情報サービスを構築できます。 (参考) Add Maps to your App in 3 Steps with AWS Amplify Geo powered by Amazon Location Service 自分で検証する気力がありませんでした… 日本リージョン対応状況 東京:対応 大阪:未対応 ※Amplify に未対応 AWS が AWS Snowcone SSD を発表 AWS への データ転送やエッジコンピューティング、エッジストレージのサービスである Snow Family に、新しく Snowcone SSD が登場しました。 既存の Snowcone と比較すると以下の点が異なるようです。ディスク容量が増えて物理的な耐久がアップした感じでしょうか。 より高いスループットパフォーマンス より強力な耐振動性を備えたオペレーション 拡張された耐久性 増加したストレージ容量 (Snowcone SSD では 14TB、Snowcone では 8TB) その他の Snowcone のスペックや、その他の Snow Family との比較は公式ページが分かりやすいのでご覧ください。 (参考) AWS Snow ファミリー 実際の画面は以下です。 日本のリージョンで確認しましたが、まだ対応していないようです。Snow Family のこの画面に行くには住所を入力しないといけないのですが、アメリカのテキトーな住所が入力できなかったので確認できませんでした… アップデートのページに「2 vCPU、4 GB のメモリ」って書いてあるけど、2 vCPU と 4 vCPU のどっちが正しいんだろう…? 日本リージョン対応状況 東京:未対応 大阪:未対応 10/1(金) Amazon RDS for PostgreSQL Supports New Minor Versions 13.4, 12.8, 11.13, 10.18, and 9.6.23; Amazon RDS on Outposts Supports New PostgreSQL Minor Versions 13.4 and 12.8 Oracle や SQLServer といった RDB のマネージドサービスである RDS と、AWS のサービスをオンプレで実行できる Outposts の RDS で以下バージョンの PostgreSQL が使用可能になりました。 RDS for PostgreSQL PostgreSQL:13.4, 12.8, 11.13, 10.18, 9.6.23 RDS on Outposts for PostgreSQL PostgreSQL:13.4, 12.8 アップデートの概要はバグ修正のようです。 (参考) 13.4、12.8、11.13、10.18、9.6.23 がリリースされました 実際の画面は以下です(Outposts じゃない方の画面です) 日本リージョン対応状況 東京:対応 大阪:対応 感想 疲れました…知らないサービスばっかりです… やればやるほど知らないことが増えてきてちょっと自信をなくしていますが、分からないことが分かったという状態にはなって来ているので継続していきたいと思います。 実際に構築して運用となるとこの状態じゃダメだよなぁとも感じているので、何かしらの手を打たねば…
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

cloudwatchの詳細モニタリングと拡張モニタリングの違い

勉強前イメージ 違いってなんだっけ・・・? くっつけるとわからん 調査 詳細モニタリング とは EC2のモニタリングタイプで、データ取得間隔を1分で取れるもの 詳細は こちら を御覧ください EC2の以下の設定変更で詳細モニタリングを有効化できます。 拡張モニタリング とは RDSのモニタリングのタイプで、RDSを動かしているOSのCPUやメモリ・ディスクIOなどのメトリクスを取ることができます。 詳細は こちら を御覧ください RDSのDBの設定変更で以下のように拡張モニタリングを有効化することができます。 まとめ 要するに以下のモニタリングのタイプの変更ということになります。 詳細モニタリング → EC2 拡張モニタリング → RDS 勉強後イメージ EC2とRDSで違うってことか・・・ 前、個々でやったはずなのにくっつけるとごっちゃになるよね 参考 [AWS SAA対策] CloudWatchの詳細モニタリングと、拡張モニタリング 【CloudWatch】RDSのストレージ使用率を監視してみる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ALBだけで特定URLへのリダイレクトを完結させる方法

AWS環境にてリダイレクトの設定をRoute53や、.htaccessを使わずに ALBだけで完結させたかったのでメモ。サイトはSSL(https)化済。 リダイレクトはALBのリスナーから設定する。 ALBでの設定 ①http こっちはhttpsに飛ばす設定。リダイレクト先はデフォルト。 デフォルトアクション リダイレクト先 https://#{host}:443/#{path}?#{query} ②https こっちは存在しないページに対して特定のURLに飛ばす設定。リダイレクト先を直書き。 今回はサブディレクトリのページに飛ばしたかったので、サブディレクトリを入れています。 1 転送先 対象のインスタンス デフォルトアクション リダイレクト先 https://ドメイン名:443/サブディレクトリ名/? サブディレクトリの場合、最後に「/」がないとダメ。入れないと、リダイレクトのループが発生する。 リダイレクトもブラウザでキャッシュしてしまうことがあるらしく、それを外したい場合はChromeだと、 検証→Network→Disable cacheにチェック。 ここまでページ遷移が細かく追えるChromeすごい...
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ruby on Jetsでサーバーレス

これはなに? 普段からRubyを使っているのですが、バッチ主体のシステムを開発するにあたり安価にサーバーレスを使いたく、Ruby on Jetsを選択して半年ほど運用した上での共有です。 Ruby on Jets https://rubyonjets.com/ Ruby on Jetsの特徴 Railsライク書いたコードでAWSのアーキテクチャを扱えるフレームワークです。 これらのRailsに慣れた人なら見覚えのあるコマンド群が使える。 jets new jets generate scaffold jets db:migrate jets server jets console jets deploy jets routes jets call jets status jets url jets delete ActiveSupportやActiveRecordなども使えるので、Railsのコードをほとんどそのまま持っていけます。 console rails consoleと同じようなコンソールが使えます。 jets console デプロイ JETS_ENV=production jets deploy これにより、JetsがCloudFormationを構築し、AWS上に展開を行ってくれるためCloudFormationでポシャるとツラいが、Railsライクに書いたコードが以下のように展開されるのでLambdaが扱いやすい。 コントローラーやジョブのコードがAWS上でLambdaにデプロイされる。 routes.rbの内容がAPI Gatewayに展開される。 Lambdaの権限設定 application.rbで以下のようにご所望の権限を記述すれば設定できます。 config.iam_policy = [ { action: ["logs:*"], effect: "Allow", resource: [ "arn:aws:logs:#{Jets.aws.region}:#{Jets.aws.account}:log-group:*", ], }, { action: ["s3:Get*", "s3:List*"], effect: "Allow", resource: "arn:aws:s3:::#{Jets.aws.s3_bucket}*", }, { action: ["rds-db:connect"], effect: "Allow", resource: "!Sub arn:aws:rds-db:#{Jets.aws.region}:#{Jets.aws.account}:xxx:*/*", }, { action: ["secretsmanager:GetSecretValue"], effect: "Allow", resource: "!Sub arn:aws:secretsmanager:#{Jets.aws.region}:#{Jets.aws.account}:secret:#{config.project_name}/#{Jets.env}/*", }, ] カスタムドメイン こんな感じでカスタムドメインも設定できます。 config.domain.hosted_zone_name = "xxxx.co.jp" if Jets.env.production? config.domain.apex = true else config.domain.name = "#{Jets.env}.xxxx.co.jp" end config.domain.cert_arn = "arn:aws:acm:xxxxxxxxxx:certificate/xxxxxxxxxxxx" その他、細かいところもドキュメントを見れば代替はセッティング可能。 https://rubyonjets.com/docs/ 面倒なのはgem周り 前提として、gemのコードはLambdaの環境用にコンパイルする必要があります。 Jetsはデフォルトでは「Serverless Gems」というサービスを使っていて、このサービスからLambda用にコンパイルされたgemコードをzipでダンロードしてLambdaに展開する作りになっています。 そして、このサービスが無料版だとダウンロード数制限(30回/日)があります。 https://www.serverlessgems.com/ 無料で使いたい場合 通常なら課金してこれを使えば楽なんですが、回避する手法も用意されています。 独自にgemをコンパイルしてLambdaのレイヤーとしてプッシュすることで、以下のように自前でコンパイルしたgemをLambdaレイヤーとして利用可能です。 Jets.application.configure do config.gems.disable = true config.lambda.layers = [ "arn:aws:lambda:xxxxx:layer:gem-layer:xx", ] end このように独自のレイヤーでgemを利用する場合は、amazon/aws-sam-cli-build-image-ruby2.7のコンテナ内でbundle installし、zipにしてs3に転送する必要があり、ざっくりですが以下のような処理で可能です。 mkdir -p tmp/gemlayer/ cp Gemfile* tmp/gemlayer/ cd tmp/gemlayer mkdir -p lib mkdir -p bin docker run --rm \ -v $PWD:/var/layer \ -w /var/layer \ -e BUNDLE_GITHUB__COM \ -e HOST_UID=`id -u` \ -e HOST_GID=`id -g` \ amazon/aws-sam-cli-build-image-ruby2.7 \ bash bundle install --path ruby rm -rf lib/ruby/2.7.0/cache mv ruby/ruby ruby/gems zip -q -r zip.zip ruby/gems/ zip -q -r zip.zip lib zip -q -r zip.zip bin export HASH=$(md5sum zip.zip | cut -f1 -d ' ') aws s3 cp zip.zip s3://gemlayer-bucket-name/$HASH cd ../../ aws cloudformation update-stack \ --stack-name xxxx \ --template-body xxxx \ --capabilities CAPABILITY_AUTO_EXPAND \ --parameters ParameterKey=Hash,ParameterValue=$HASH 困ったこと 半年以上運用して結構使いやすいんですが、たまにCloudFormationでうまくデプロイできなかったときがツラかったです。 ※ なので、ロールバックしたりCloudFormationについてのナレッジもあると安心。 特にgemレイヤーを更新するデプロイ時にロールバックする羽目になると辛くて、Lambdaのレイヤーは最新バージョンのみ保持できてバージョン番号を巻き戻せないため、アプリのロールバック時に旧レイヤーバージョンが存在しない事態になりロールバックできなかったです。 このときはアプリのプロジェクト自体をdeleteして再度createする形になりました。 RDSやパラメーターストアなど永続化するべきものはアプリのプロジェクトに含まず構築していたので再作成も楽にできました。 それ以外はいい感じで、Slackボットやジョブをたくさん捌いてもサーバーレスならではの安価な利用ができています。 その他の選択肢 最近見知ったのでまだ使えていないのですが、RubyでサーバーレスをするにあたってRuby on Jets以外にも以下の選択肢も気になっています。 https://github.com/customink/lamby 現場からは以上です!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Certified Security - Specialty に合格しました

2021/10/09 に AWS Certified Security - Specialty 試験を受験して、無事に合格しました。試験対策とメモを残しておきます。 対策 要点整理から攻略する『AWS認定 セキュリティ-専門知識』を使って試験対策しました。この参考書に練習問題(40問)が用意されているので、まずは練習問題を解いて自分の苦手なサービスを明らかにするようにしました。その後苦手なサービスを参考書を使って理解するようにしました。私の場合は、KMS の理解があやふやだったので 4 章 の KMS の節を読み込みノートにまとめるようにしました。 所感 セキュリティ試験では、AWSサービスの深い知識を問われるというよりかは、サービスのセキュリティの基本的な知識を問われた印象です。「[要点整理から攻略する『AWS認定 セキュリティ-専門知識』]」を読み込んで各AWSサービスのセキュリティの基本的な知識を詰め込んだら、あとは、それらを組み合わせて問題文に答えるだけでした。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む