普段はインフラ寄りの仕事をしているエンジニアですが、Railsの環境構築やデプロイについてキャッチアップする機会があり、色々学ぶうちにブックマークが溜まってきました。 同様の内容を学習中の方の参考になればと思い、Qiita記事化します。 環境構築関連 Docker Rails 6.1のDocker開発環境構築をEvil Martians流にやってみた（更新）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社 クジラに乗ったRuby: Evil Martians流Docker+Ruby/Rails開発環境構築（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社 Nginx+Rails6.0+MySQL8.0+Adminer：docker-compose で rails new Ruby on Railsの開発環境をDockerで構築する方法(Rails 6.x) nginx + Rails (unicorn) + MySQL 環境を Docker で構築する - Qiita Docker イメージサイズを抑えながら Ruby on Rails + PostgreSQL の開発環境を作成する - bitA Tech Blog docker-compose+Nginx+Rails6 で静的コンテンツをNginxから配信する https://github.com/ledermann/docker-rails nginxとPumaを連携し、nginx + Puma + Rails6の開発環境を構築する手順 | Enjoy IT Life 【決定版】rbenv を使った ruby のインストール AWS EC2等 Ruby on Rails 6をAmazon Linux 2で動かす - サーバーワークスエンジニアブログ Amazon Linuxでrbenvをインストール - Qiita CentOS8上にnginxとpumaとRailsを手作業で構築した後に手動でデプロイする - もちゅろぐ 【Rails】Nginx, Puma な環境によるデプロイ&サーバーの勉強【AWS EC2】 - Qiita AWS Rails 6 + MySQL + Nginx な環境の作成方法 サーバー編 - たけログ EC2にRails環境構築（Ruby 2.6、Rails 6.0） - 欲望のおもむくままに RailsアプリをAWSにイチからデプロイするまでの手順メモ · Code of Duty CI関連 https://github.com/CircleCI-Public/circleci-demo-ruby-rails 自動デプロイ(CD)関連 ECS Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ Capistrano Capistrano公式ドキュメント CircleCI + Capistrano + AWS(EC2) + Railsで自動デプロイしてみた - Qiita はじめてのCapistrano - Qiita Capistranoでデプロイ自動化 - kumilog.net CapistranoでRailsデプロイ - kumilog.net https://github.com/capistrano/rails https://github.com/capistrano/rbenv multistage 環境で capistrano-rbenv を使うときは rbenv_path の扱いに注意！ - Hack like a rolling stone capistrano3でpumaの運用ー設定ファイルの管理どうする？ - Qiita Rails5+Puma+Nginxな環境をCapistrano3でEC2にデプロイする(後編) - Qiita ざくにく定食: capistranoでbundle installするまで AWS CodeStar CodeStarではじめるRailsアプリのCodeDeploy化 puma Pumaの使い方 まとめ - 猫Rails Puma の Daemonization が廃止された理由と、デーモン化したいときはどうするべきか - 完全に理解した.com Pumaの起動におけるpumaコマンドとpumactlコマンドの違い - Qiita ポートを指定してPumaを起動するとsocketファイルをlistenしなくなる - Qiita nginx commented nginx.conf for Ruby on Rails bundle config bundle config | Bundler日本語ドキュメント | Ruby STUDIO ログローテート 【Ruby on Rails】ログ出力とログローテートの設定まとめ【Logger】 - きゃまなかのブログ 【Rails】Railsアプリのログローテーション設定を行う - AUTOVICE devise Devise入門 64のレシピ - 猫Rails その他 不正な config/master.key が原因でRailsの起動に失敗するケースとその対処方法 - Qiita

CodeCommitとは AWSが提供するマネージド型のソース管理サービス。 Git の標準機能がサポートされており、Git からの移行が容易。 また、CodeCommitのリポジトリとGitHubやGitLabのリポジトリをミラーリングすることも可能。 CodeCommitへのリポジトリ作成手順 AWSマネジメントコンソールからCodeCommitのコンソールへアクセスする。 リポジトリの作成 を押下する。 以下の情報を入力して、作成 を押下する。 　リポジトリ名：任意の文字列 　説明　　　　：任意の文字列 　タグ　　　　：任意 自動的にリポジトリのページに遷移し、 成功 と表示されれば作成完了。 CodeCommitへの接続方法 事前準備 ローカルのPCからCodeCommitのリポジトリに接続するためには、AWSマネジメントコンソール上でGit認証情報を作成する必要がある。 詳細は公式のガイドを参照。 その作成方法は以下。（IAMユーザの作成とGitのインストールは実施済みの前提です。） ここでは、HTTPSで接続するための認証情報の作成方法を取り上げる。 AWSマネジメントコンソールからIAMのコンソールへアクセスする。 対象のユーザの詳細画面に遷移し、 認証情報 タブから AWS CodeCommit の HTTPS Git 認証情報 の 認証情報を生成 を押下する。 自動的に認証情報が生成されるため、表示された認証情報を控えるか、 証明書のダウンロード を押下してcsvファイルとして保存する。 CodeCommitへの接続と操作 前述の事前準備が完了したら、通常のGi操作と同様にCodeCommitリポジトリに対しても git clone や git commit などを行うことができる。 初回の操作時に認証情報の入力を求められるため、事前準備で払い出した認証情報を入力すればよい。 GitHubとCodeCommitの連携方法 CodeCommitはGitHubやGitLabとミラーリングを行うことが可能。 ここでは、GitHubとのミラーリングについて説明する。 設定手順 GitHubとのミラーリングを行うための設定手順を示す。 大まかな流れとしては、 SSHキーの作成 AWSへの公開鍵の登録 GitHubリポジトリのSecrets設定 GitHub Actionsの設定 となる。 SSHキーの作成とAWSへの公開鍵の登録 以下のコマンドを実行して、SSHキーを作成する。 パスフレーズは必ず空で作成する。 ssh-keygen -t rsa -b 4096 -C "GitHubアカウントのメールアドレス" SSHキーを作成したら、IAMのコンソールから対象のIAMユーザに公開鍵を紐付ける。 AWS CodeCommit の SSH キー の SSH パブリックキーのアップロード から、作成したXXX_rsa.pubの中身をアップロードする。 GitHubリポジトリへのSecrets設定 ミラーリングにはGitHub Actionsを使用するため、GitHubのActions secretsに以下の2つを設定しておく。 変数名は任意。 SSH秘密鍵 Name：CODECOMMIT_SSH_PRIVATE_KEY Value：SSHキー秘密鍵（作成したXXX_rsa）の内容を貼り付ける SSHキーID Name：CODECOMMIT_SSH_PRIVATE_KEY_ID Value：SSHキーID（公開鍵をAWSに紐付けた際に表示されたSSHキーID[APKA…]） GitHub Actionsの設定 Secretsの設定まで完了したら、GitHubリポジトリにGitHub Actionsのワークフローを登録する。 .github/workflows/main.yml を作成し、以下の内容で保存する。 name: Mirroring on: [ push, delete ] jobs: to_codecommit: runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v1 - uses: pixta-dev/repository-mirroring-action@v1 with: target_repo_url: ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/xxxxx ssh_private_key: ${{ secrets.CODECOMMIT_SSH_PRIVATE_KEY }} ssh_username: ${{ secrets.CODECOMMIT_SSH_PRIVATE_KEY_ID }} target_repo_urlの値は、対象のCodeCommitリポジトリのSSH URLに変更する。 これにより、GitHubへのプッシュを契機としてCodeCommitへのミラーリングが自動的に行われるようになる。

昨日中断するまでは起動していたはずの＄　rails serverを再開しようとしたら qiita.rb Could not find gem 'puma (= 3.9.1)' in any of the gem sources listed in your Gemfile. Run `bundle install` to install missing gems. 出たよと思いつつ、とりあえず＄　bundle installをしてみる。 quitta.rb $ buindle install Command 'buindle' not found, did you mean: command 'bundle' from snap ruby (3.0.2) command 'bundle' from deb ruby-bundler See 'snap info <snapname>' for additional versions. 豪快にスペルを間違えるも、本人はなんかエラー出てるなと流し見して気づかず、$ bundle installではない。と決めつけて、ググる。 エラーは本当によく読もう（笑） 　 なので、最初にスペルミスをしなかった場合の結果が分からないのが悔しい。 また次のエラーで会いましょう。 それはさておき、私が解決した方法は、こちらの記事を参考にしました。 実際にこのコマンドを上から入力して解決しましたが、なぜ解決したのかはわかりません。 もっと勉強していけばわかるようになると思っていますが、足踏みしていられないので試しました。 quitta.rb #remove user-specific gems and git repos $ rm -rf ~/.bundle/ ~/.gem/ # remove system-wide git repos and git checkouts $ rm -rf $GEM_HOME/bundler/ $GEM_HOME/cache/bundler/ # remove project-specific settings and git repos $ rm -rf .bundle/ # remove project-specific cached .gem files $ rm -rf vendor/cache/ # remove the saved resolve of the Gemfile $ rm -rf Gemfile.lock # try to install one more time $ bundle install

はじめに AWS SOAに試験ラボという名の実技試験が導入されてはや数ヶ月が経ちました。 Web上では合格された方をちらほら見かけますが、Qiitaでは合格記事がまだ少なめだったので投稿します。 結果はかなりギリギリでした。1000点満点であと24点足りなければ泣いていました。 筆者スペック AWS使用歴：1年半 AWS保有資格：クラウドプラクティショナー(CLF)、ソリューションアーキテクト(SAA)　※いずれも2020年10月に取得。 普段使うAWSサービス:VPC、EC2、ECS、RDS、S3、IAM、Cognito 触ったことのあるAWSサービス：Cloudwatch、Route53、ELB、System manager、DynamoDB、Elasticache、SES 試験ラボについて 以下の記事がとても参考になります。 上記記事にもある通りで、試験ラボとは「実際に画面上でAWSマネジメントコンソールまたはAWS CLIを操作して指定されたタスクを完了する」課題のことです。 AWSマネジメントコンソールとは、AWSを実際に使ったことのある方ならご存知のこの画面ですよね。 試験本番では、全55問の選択問題完了後、自動的にWindowsマシンのデスクトップ画面及びAWSマネジメントコンソールが立ち上がるイメージです。これが中々やっかいでした。。。 試験時間の配分についてはちょっと特殊だったのでAWS公式サイトからの引用も踏まえつつ説明します。 セクションと時間 新しい AWS 認定 SysOps アドミニストレーター – アソシエイト 試験は 2 つのセクションに分かれており、試験時間は 180 分になります。第 1 セクションには多肢選択法と複数回答の問題が含まれ、第 2 セクションには試験用ラボが含まれます。 第 1 セクションを終えた後、第 2 セクションに移る前に、自分の回答を確認することができます。第 2 セクションの試験用ラボを開始すると、第 1 セクションに戻って答えを見直したり、変更したりすることはできません。 試験を受けるときは、時間配分を計画してください。試験の開始時に、第 2 セクションで試験用ラボを何回行う必要があるかが提示されます。ラボに取り組む時間が足りなくならないように、各試験用ラボの完了には 20 分程度の時間を確保することをお勧めします。つまり、試験用ラボが 3 つある場合は、多肢選択法と複数回答の問題の第 1 セクションを完了した残りの試験時間が 60 分になるようにしましょう。なお、試験用ラボを完了して次の試験用ラボに進んだ後、完了した試験用ラボに戻って、行った内容を変更することはできません。 これを読むとわかりますが、なんと試験ラボの課題は2〜3個あります。 しかしながら2021年10月時点では、私を含めてほとんどの方が2個だけのようです。 公式は1問あたり20分は確保してねと言っていますが、私の推奨する確保時間は30分です なので試験ラボの問題が2問のときは、第一セクションの選択問題を120分で完了して、残りの試験ラボに1時間使えるような時間配分を推奨します。 試験時間180分の配分（筆者のおすすめ） セクション 時間 注意点 選択問題 120分 試験ラボ1に進むと選択問題には戻れなくなる（進む前に十分な見直しを！） 試験ラボ１ 30分 試験ラボ2に進むと試験ラボ1には戻れなくなる(見直し！) 試験ラボ2 30分 試験ラボ1問あたりに30分確保する根拠として以下があります。 AWS環境がラグいため操作性が悪い 筆者は試験センターで受検したのですが、AWSの操作性はあまりよくありませんでした。具体的には0.5〜1秒程度のラグが常につきまとう感じです。正直言ってストレスがたまるので、余裕を持った時間が必要になります。 問題文の表示領域が狭く、こなすべきタスクを把握するのに時間がかかかる。 これは実際の試験ラボの画面を見ると理解できるかと思います。なので公式より引用します。 こんな感じで1画面中にコンソール画面エリアと問題文エリアが表示されます。これ結構見にくいです。 とはいえ、AWS側もそこは配慮してくれていて、表示領域を任意で広げられたり、文字サイズを大きくできたりが可能などと親切設計にはしてくれています。それでも結構手間取るので、十分な時間の確保をおすすめします。 シンプルに問題が難しい わりとこれが一番です。生半可なAWSスキルだと普通に返り討ちにあいます。しかしながら選択問題を8割以上解けるレベルであるならば、使ったことのないサービスでも問題文からヒントを冷静に手繰り寄せて、ギリギリ合格まで狙えるかもしれません。 勉強方法 選択問題の勉強 AWS WEB問題集で学習しよう(ベーシックプラン：4480円(税抜)) 公式の有料模擬試験(PearsonではなくPSIでしか受検できないので注意！) 筆者はまずAWS WEB問題集の有料プランに加入して、ひたすら模擬問題を解き続けました。時間としては10日間、毎日3〜4時間ほど使った感じです。 こちら結構おすすめです。有料プランがわりと良いお値段なのがネックですが、3ヶ月分使えるのと、プロフェッショナル版(5580円(税抜))であればほぼAWS全試験の問題を解きまくれるので最高です。筆者は今後AWS全冠を狙うことにしたのでプロフェッショナル版を登録しました（決して回し者ではありませんのでご了承ください。）。 Web問題集の#50〜#91までを2周した後、試験の当日にAWSの公式模擬試験を受けました。 公式模擬試験は、SAAなどの他試験においては、「25問しか問題ないのに2000円もお金取られる！」と評判ですが、SOAに関してはなんとフルの55問の解説付き問題を解けてお値段据え置きです(20USD)。また、本番でも1割ほど同じ問題が出たのでぜひ解くことおすすめします（過去にAWS試験を合格された方ならば、無料の模擬試験クーポンを取得しているはずです！） あとは他の方の合格体験記を見て勇気をもらい続けました。勉強開始前に見ておくとイメージが湧くと思います。 試験ラボの勉強 実際の試験ラボの操作になれるため、受検申込後に使用可能になる「試験ラボのサンプル」をやりました。 こちら、自分のPCで試験ラボによる試験を体験できるサービスとなっています。 受検申し込み後に送付されるメールに案内が書かれているので忘れずに1回は触っておくとよいと思います。 （※2021年12月31日までに申し込んだ人が対象となっているようです。受検希望の方は早めの申込をおすすめします。） あとはこちらの記事を一通り眺めました。 それ以外は対策らしい対策はしませんでした。とはいえギリギリでなんとかなっただけだと思います。 全くAWSを触ったことの無い方は、こちらのUdemy教材でハンズオン形式でAWSを触っておくことをおすすめします（筆者は1年前にこちらを1周しています）。 受検後の感想 10日間のみという準備期間に加えて試験ラボという新制度もあって、かなりギリギリの結果になってしまい反省しています。 総合的な難易度としてはAWS SAAより1段階上かな、という印象です。 試験ラボについては、最初の1問目がかなり難しめで（ぼやかしていうとS3バケットにまつわる色んな設定をしろ！的な問題）、2問目がSAAの試験対策で散々やったようなVPC周りの問題だったので2問目に助けられた感じです。 ですが試験ラボによってAWSのリアルな操作に対する客観的な評価をしてもらえた気がするので、改めて自信も付きました。 今後も試験ラボは他AWS試験で必須になっていく気しかしないので、そうなる前にできるだけ早めに他のAWS試験も制覇していこうと思います！

この記事の目的は？ CloudFront + AWS WAFは非常に汎用性のある構成であるにも関わらずCloudFormation自動作成の記事が少なかったので、実装方法を記載します どんなものを実装できるの？ 特定のIPのみアクセス可能なCloudFrontをyamlから作成できます 構成 注意することその1 CloudFront+WAFの構成を作る上で気をつけなければいけないのが作成順序です CloudFrontを作ってからWAFを作って、関連付けるのではなく WAFを作ってからCloudFrontを作って、関連付けるのが正しいです 理由：CloudFrontディストリビューションはARNでWAFを参照できますが、WAFはCloudFrontを参照する機能が無いからです 注意することその2 WAFをCloudFormationで作成する場合、CloudFormationを実行するリージョンは米国東部 (バージニア北部)us-east-1で実行して下さい その他リージョンで実行しても失敗してしまいます 参考元：https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-wafv2-webacl.html For CLOUDFRONT, you must create your WAFv2 resources in the US East (N. Virginia) Region, us-east-1. 作ってみた 実現したいことはこの３つ アクセスを許可させたいIP群のリストを作成する そのリストにあるIPのみアクセス可能なWAFを作成する 作成したWAFをCloudFront用コードから参照して関連付けられるよう、WAFのARNの値を出力できるようにしておく さっそく、CloudFormationのコードをyamlで作成します CloudFormationをyaml言語で作成 wafv2.py AWSTemplateFormatVersion: '2010-09-09' Description: WAF by Cloud Front Parameters: Resources: WebACL: # WAF本体はこの WebACL で作成します Type: AWS::WAFv2::WebACL Properties: Name: WebACL_test Scope: CLOUDFRONT # CloudFront用のWAFなのでScopeは CLOUDFRONT にしましょう DefaultAction: Block: {} VisibilityConfig: SampledRequestsEnabled: true CloudWatchMetricsEnabled: true MetricName: webaclcloudfront Rules: # WAFのアクセス制御の具体的な方法はこの Rules で設定します - Name: rules-proxy-test Priority: 0 Action: Allow: {} Statement: IPSetReferenceStatement: Arn: !GetAtt WAFIPSet.Arn # ここでは後述の WAFIPSet で作成したIP情報のARNを参照するようにしています VisibilityConfig: SampledRequestsEnabled: true CloudWatchMetricsEnabled: true MetricName: rules-proxy-test WAFIPSet: # アクセスを許可したいIPはこの WAFIPSet で設定します Type: AWS::WAFv2::IPSet Properties: Name: wafipset-test Scope: CLOUDFRONT # WebACLと同じくここもCLOUDFRONTと指定します IPAddressVersion: IPV4 Addresses: # 許可させたいIPをこの Addresses に記載します - xxx.xxx.xxx.xxx/32 - yyy.yyy.yyy.yyy/24 - zzz.zzz.zzz.zzz/28 Outputs: CloudFrontWAF: Value: !GetAtt WebACL.Arn # WAFのARNを CloudFrontWAF という論理名で出力して、CloudFrontから参照できるようにします CloudFormationで読み込んだらリソースが作成されました 1および2を実現できました アクセスさせたいIPのリストを作成する (WAFIPSet) そのIPリストを元にIPでアクセス制御できるWAFを作る(WebACL) 3を実現できました 作成したWAFをCloudFront用コードから参照して関連付けられるよう、WAFのARNの値を出力できるようにしておく(CloudFrontWAF) 実装までにつまずいたところ 最初はStatementの設定を以下のようにしていました Statement: IPSetReferenceStatement: !Ref WAFIPSet CloudFormationにインポートしたら、以下のようなモデル検証エラーが発生 原文 Resource handler returned message: "Model validation failed ( #/Rules/0/Priority: expected type: Number, found: String #/Rules/0/Statement/IPSetReferenceStatement: expected type: JSONObject, found: String #/Rules/0/VisibilityConfig/SampledRequestsEnabled: expected type: Boolean, found: String #/Rules/0/VisibilityConfig/CloudWatchMetricsEnabled: expected type: Boolean, found: String #/VisibilityConfig/SampledRequestsEnabled: expected type: Boolean, found: String #/VisibilityConfig/CloudWatchMetricsEnabled: expected type: Boolean, found: String)" (RequestToken: f1cbb0f3-5861-59ab-ffbc-36c56447b5b0, HandlerErrorCode: InvalidRequest) 和訳 リソースハンドラーが返すメッセージ： "モデルの検証に失敗しました（ ＃/ Rules / 0 /優先度：期待されるタイプ：数値、検出されました：文字列 ＃/ Rules / 0 / Statement / IPSetReferenceStatement：期待されるタイプ：JSONObject、検出されました：文字列 ＃/ Rules / 0 / VisibilityConfig / SampledRequestsEnabled：期待されるタイプ：ブール値、検出：文字列 ＃/ Rules / 0 / VisibilityConfig / CloudWatchMetricsEnabled：期待されるタイプ：ブール値、検出：文字列 ＃/ VisibilityConfig / SampledRequestsEnabled：期待されるタイプ：ブール値、検出：文字列 ＃/ VisibilityConfig / CloudWatchMetricsEnabled：予期されるタイプ：ブール値、検出：文字列） エラーの原因は戻り値の指定の仕方 ちゃんとAWS公式リファレンスに書かれていました 参考元：https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-wafv2-webacl.html 参照 Refリソース名、物理ID、および範囲を含むリソースのため、次のようにフォーマットされました：name|id|scope 例：my-webacl-name|xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx|REGIONAL Fn :: GetAtt Arn Web ACLのAmazonリソース名（ARN） 戻りの値は!Refではなく!GetAttで指定する必要があるようです コードを以下のように書き直して再度CloudFormationで実行したところ、成功しました！ Statement: IPSetReferenceStatement: Arn: !GetAtt WAFIPSet.Arn 終わりに CloudFront＋WAFというありふれた構成であるにも関わらず、その構成をCloudFormationで実現する情報がウェブにはほぼ皆無だったため、非常に難儀しました なので今後似たような状況で苦しんでいる方々のために、なるべく最小構成でコードを作っております 今回の調査のため色々なblogを巡回しましたが、答えは最初からAWS公式リファレンスにすべて書かれており、改めてAWSドキュメントの完成度の高さに感動しました 補足 参考になったページ

はじめに AWS SAMを試すため、LocalStackへデプロイしようとしたら、通常のsamコマンドでは、おそらくデプロイ先のエンドポイントURLを変更できないため、LocalStackへデプロイできませんでした。 そこで、LocalStackが提供するsamlocalコマンドを使用するとデプロイできました。 また、ローカル環境をあまり汚したくなかったため、Docker (+ Docker Compose) のみで試しております。 この記事は以上のことについて、備忘録としてまとめたものです。 前提条件 DockerとDocker Composeがインストールされていること。 やってみた LocalStackを起動させておく $ git clone https://github.com/localstack/localstack.git Cloning into 'localstack'... remote: Enumerating objects: 23149, done. remote: Counting objects: 100% (1772/1772), done. remote: Compressing objects: 100% (619/619), done. remote: Total 23149 (delta 1241), reused 1611 (delta 1134), pack-reused 21377 Receiving objects: 100% (23149/23149), 9.99 MiB | 16.35 MiB/s, done. Resolving deltas: 100% (16797/16797), done. $ cd localstack $ docker-compose up -d Pulling localstack (localstack/localstack:)... latest: Pulling from localstack/localstack c91cc7261d92: Pull complete Digest: sha256:74323cb3ef6709f9732802e74c80b3b997359d25e603955b708efae61633b1df Status: Downloaded newer image for localstack/localstack:latest Creating localstack_main ... done 開発環境としてPythonコンテナを起動し、中に入る # Pythonコンテナ内からLocalStackコンテナを名前解決可能にするため、「--link localstack_main:localstack」を設定している $ docker run --rm -it --link localstack_main:localstack python:3.8 bash Unable to find image 'python:3.8' locally 3.8: Pulling from library/python bb7d5a84853b: Pull complete f02b617c6a8c: Pull complete d32e17419b7e: Pull complete c9d2d81226a4: Pull complete 3c24ae8b6604: Pull complete 8a4322d1621d: Pull complete a03ef301ddd7: Pull complete a4c591fc96f3: Pull complete 799e70ce6240: Pull complete Digest: sha256:b39ab988ac2fa749273cf6fdeb89fb3635850824419dc612c8a21ff4c7961b8b Status: Downloaded newer image for python:3.8 Pythonコンテナで事前設定を行う # ホームディレクトリへ移動する (任意) root@151ed9cb109a:/# cd root@151ed9cb109a:~# pip install awscli aws-sam-cli aws-sam-cli-local # ・・・(省略) Successfully installed Flask-1.1.4 Jinja2-2.11.3 MarkupSafe-2.0.1 PyYAML-5.4.1 Werkzeug-1.0.1 arrow-1.2.1 attrs-21.2.0 aws-lambda-builders-1.8.1 aws-sam-cli-1.33.0 aws-sam-cli-local-1.1.0.1 aws-sam-translator-1.39.0 awscli-1.21.2 backports.zoneinfo-0.2.1 binaryornot-0.4.4 boto3-1.19.2 botocore-1.22.2 certifi-2021.10.8 chardet-4.0.0 chevron-0.14.0 click-7.1.2 colorama-0.4.3 cookiecutter-1.7.3 dateparser-1.1.0 docker-4.2.2 docutils-0.15.2 idna-2.10 itsdangerous-1.1.0 jinja2-time-0.2.0 jmespath-0.10.0 jsonschema-3.2.0 poyo-0.5.0 pyasn1-0.4.8 pyrsistent-0.18.0 python-dateutil-2.8.2 python-slugify-5.0.2 pytz-2021.3 pytz-deprecation-shim-0.1.0.post0 regex-2021.10.23 requests-2.25.1 rsa-4.7.2 s3transfer-0.5.0 serverlessrepo-0.1.10 six-1.16.0 text-unidecode-1.3 tomlkit-0.7.2 tzdata-2021.4 tzlocal-4.0.1 urllib3-1.26.7 watchdog-2.1.2 websocket-client-1.2.1 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv WARNING: You are using pip version 21.2.4; however, version 21.3.1 is available. You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command. # LocalStack用プロファイルを設定する root@151ed9cb109a:~# aws configure --profile=local AWS Access Key ID [None]: dummy AWS Secret Access Key [None]: dummy Default region name [None]: ap-northeast-1 Default output format [None]: # samlocal用に設定する root@151ed9cb109a:~# export LOCALSTACK_HOSTNAME=localstack # samlocal用に設定する root@151ed9cb109a:~# export EDGE_PORT=4566 SAMサンプルアプリケーションを作成する root@151ed9cb109a:~# sam init --runtime python3.8 SAM CLI now collects telemetry to better understand customer needs. You can OPT OUT and disable telemetry collection by setting the environment variable SAM_CLI_TELEMETRY=0 in your shell. Thanks for your help! Learn More: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-telemetry.html Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice: 1 What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) 2 - Image (artifact is an image uploaded to an ECR image repository) Package type: 1 Project name [sam-app]: Cloning from https://github.com/aws/aws-sam-cli-app-templates AWS quick start application templates: 1 - Hello World Example 2 - EventBridge Hello World 3 - EventBridge App from scratch (100+ Event Schemas) 4 - Step Functions Sample App (Stock Trader) 5 - Elastic File System Sample App Template selection: 1 ----------------------- Generating application: ----------------------- Name: sam-app Runtime: python3.8 Architectures: x86_64 Dependency Manager: pip Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./sam-app/README.md SAMサンプルアプリケーションをLocalStackへデプロイする root@151ed9cb109a:~# cd sam-app root@151ed9cb109a:~/sam-app# SAM_S3_BUCKET_NAME=sam-bucket # SAMのソースコードアップロード用S3バケットを作成する root@151ed9cb109a:~/sam-app# aws s3 mb s3://${SAM_S3_BUCKET_NAME} \ --endpoint-url http://${LOCALSTACK_HOSTNAME}:${EDGE_PORT} \ --profile local make_bucket: sam-bucket root@151ed9cb109a:~/sam-app# samlocal deploy \ --stack-name sam-stack \ --s3-bucket ${SAM_S3_BUCKET_NAME} \ --profile local Uploading to c6ce8fa8b5a97dd022ecd006536eb5a4 847 / 847 (100.00%) Deploying with following values =============================== Stack name : sam-stack Region : ap-northeast-1 Confirm changeset : False Deployment s3 bucket : sam-bucket Capabilities : null Parameter overrides : {} Signing Profiles : {} Initiating deployment ===================== Uploading to d3c4a0926d7588147cfdc9906b4e375a.template 1068 / 1068 (100.00%) Waiting for changeset to be created.. CloudFormation stack changeset ------------------------------------------------------------------------------------------------------------- Operation LogicalResourceId ResourceType Replacement ------------------------------------------------------------------------------------------------------------- + Add HelloWorldFunction AWS::Lambda::Function False + Add HelloWorldFunctionRole AWS::IAM::Role False + Add HelloWorldFunctionHelloWo AWS::Lambda::Permission False rldPermissionProd + Add ServerlessRestApi AWS::ApiGateway::RestApi False + Add ServerlessRestApiDeployme AWS::ApiGateway::Deployme False nt510f4c1a20 nt + Add ServerlessRestApiProdStag AWS::ApiGateway::Stage False e ------------------------------------------------------------------------------------------------------------- Changeset created successfully. arn:aws:cloudformation:ap-northeast-1:000000000000:changeSet/samcli-deploy1635154640/fa450628 2021-10-25 09:37:20 - Waiting for stack create/update to complete CloudFormation events from changeset ------------------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason ------------------------------------------------------------------------------------------------------------- CREATE_COMPLETE AWS::CloudFormation::Stac HelloWorldFunctionRole - k CREATE_COMPLETE AWS::CloudFormation::Stac ServerlessRestApiProdStag - k e CREATE_COMPLETE AWS::CloudFormation::Stac ServerlessRestApiDeployme - k nt510f4c1a20 CREATE_COMPLETE AWS::CloudFormation::Stac ServerlessRestApi - k CREATE_COMPLETE AWS::CloudFormation::Stac sam-stack - k CREATE_COMPLETE AWS::CloudFormation::Stac HelloWorldFunctionHelloWo - k rldPermissionProd CREATE_COMPLETE AWS::CloudFormation::Stac HelloWorldFunction - k ------------------------------------------------------------------------------------------------------------- CloudFormation outputs from deployed stack -------------------------------------------------------------------------------------------------------------- Outputs -------------------------------------------------------------------------------------------------------------- Key HelloWorldApi Description API Gateway endpoint URL for Prod stage for Hello World function Value https://x3ovhxtd7l.execute-api.ap-northeast-1.amazonaws.com/Prod/hello/ Key HelloWorldFunction Description Hello World Lambda Function ARN Value arn:aws:lambda:ap-northeast-1:000000000000:function:sam-stack-HelloWorldFunction- fd0867a1 Key HelloWorldFunctionIamRole Description Implicit IAM Role created for Hello World function Value arn:aws:iam::000000000000:role/sam-stack-HelloWorldFunctionRole-4bd323a3 -------------------------------------------------------------------------------------------------------------- Successfully created/updated stack - sam-stack in ap-northeast-1 実行確認として、LocalStackにデプロイされたAPI Gatewayへリクエストする # デプロイされたREST API IDを取得する root@151ed9cb109a:~/sam-app# REST_API_ID=$( aws apigateway get-rest-apis \ --query items[0].id \ --output text \ --endpoint-url http://${LOCALSTACK_HOSTNAME}:${EDGE_PORT} \ --profile local ) root@151ed9cb109a:~/sam-app# curl http://${LOCALSTACK_HOSTNAME}:${EDGE_PORT}/restapis/${REST_API_ID}/Prod/_user_request_/hello/ {"message": "hello world"}

以下のように aws:sourceVpce や aws:SourceIp を利用して、特定のIPやVPC Endpointからのアクセスに限定したECRを作成することができます。 ただ、下記のようなCloudformaitonのテンプレートをそのままデプロイすると以下のメッセージが発生してデプロイできません。 Resource handler returned message: "You are about to set a repository policy that will prevent you from setting another one in the future. Use the force parameter to override this exception. Resources: MyRepo: Type: AWS::ECR::Repository Properties: RepositoryPolicyText: Version: "2012-10-17" Statement: - Sid: Deny Effect: Deny Principal: "*" Action: - ecr:* Condition: StringNotEquals: aws:sourceVpce: - vpce-xxxxxxxxxx NotIpAddress: aws:SourceIp: - 100.100.100.100/32 これは aws ecr set-repository-policy の --force オプションに当たる設定が必要とのことです。 回避策をAWSサポートに問い合わせたところ、 aws:CalledVia = [cloudformation.amazonaws.com] のようにCloudformationからの呼び出しを許可することで事象を回避できました。 Resources: MyRepo: Type: AWS::ECR::Repository Properties: RepositoryPolicyText: Version: "2012-10-17" Statement: - Sid: Deny Effect: Deny Principal: "*" Action: - ecr:* Condition: StringNotEquals: aws:sourceVpce: - vpce-xxxxxxxxxx aws:CalledVia: - cloudformation.amazonaws.com NotIpAddress: aws:SourceIp: - 100.100.100.100/32 ググっても出てこなくて時間を使ってしまったので、こちらに残しておきます。

久々にNextいじって、いい感じにできたのでデプロイした時。 22 error Exit status 1 23 error Failed at the nomulog_v2@1.0.0 build script. 23 error This is probably not a problem with npm. There is likely additional logging output above. ??? なんぞこれ。 調べてみるとwebpack.config.jsにmodeを追加する必要があるらしい。 だが、webpackとかいじったことがなくさっぱりなのである。 とりあえずトップレベルにwebpack.config.jsを作って記事にあったコードを入れてデプロイしてみるも変化なし。 そもそもlocalでは動作してるんだよなぁと思って再度実行したところ。 動けNext! なぜ動かん!! さっきまで動いてたはずのNext君が砕け散ったのである。スイカバーが刺さったのである。 たぶん、今まではビルドコマンドたたかずにテストしてたからなのかなとか思っているが正直覚えていない。 いったい何が原因なのかわからないが、迷宮に突き落とされたので同にか脱出しようといろいろ試していく。 やったことリスト(覚えてる限り) モジュールの削除と再インストール Nodeのバージョンアップ webpackとwebpack-cliをインストール 新しくプロジェクト立てて原因調査 モジュールをひとつづつ入れてどれが影響してるか確認 npmのバージョンアップ npm install sass next.config.jsの修正 *.scss -> *.module.scss 上からやった理由とか結果を載せてく。 モジュールの削除と再インストール とりあえず依存関係の問題でなんか動かんのやろ、とか思ってnode_modulesとpackage-lock.jsonを削除して再インストールしてみる。 $ npm cache clean --force $ npm install --save-dev 結果は変わらず。 Nodeのバージョンアップ 何となくバージョンのせいかと思いバージョンアップしてみる。 Nodeのバージョンアップは、公式から新しいインストーラーを持ってきて実行すればいいので割愛。 結果は変わらず。 webpackとwebpack-cliをインストール どうやらwebpack4からはcliがいるとのことなのでこれを入れてみる。 $ npm install webpack --save-dev $ npm install webpack-cli --save-dev 確かこれを実行した段階でエラー内容が変わった気がする。 残念なことに詳しいエラーは覚えていないが、SASSがコンパイルできないよ!みたいなエラーだった気がする。 今まで実行できてたのに謎だったので、新しく環境立ち上げていろいろ試すことにした。 新しくプロジェクト立てて原因調査 もしかしたらそもそも動かないんじゃないか…とすべてを疑い始めたのでnpm create-next-appで新しくプロジェクト作って実行してみた。 もちろん動く。 モジュールをひとつづつ入れてどれが影響してるか確認 やっぱりモジュールのせいかと思って、一個ずつインストールしては実行を繰り返してみた。 もちろん動く。 npm install --save @zeit/next-sass node-sassを実行後、 そういえばnext.configにもSASSの設定あったなーと思い、 next.config.js const withSass = require('@zeit/next-sass') module.exports = withSass({ cssModules: true }) とやったところ、おんなじエラーが出た。 npmのバージョンアップ もしかしてバージョンのせいではと思い(n回目)バージョンアップさせてみるも変化なし。 npm install sass あきらめずにバージョンが悪い!という固定概念の元調べ続けた結果、 どうやらNextが普通にSCSSをコンパイルできるらしいことを知った。昔の私はなんでこれしてなかったんだろう。わからん。 ということで $ npm install --save-dev sass インストールして、config.jsをもとに戻した。 またまたエラーが変わって確か TypeError: Cannot read property 'tap' of undefined が出てきたと思う。 next.config.jsの修正 原因がwebpakc4のせいらしく、webpack5を使いましょう、的なことだった。 なのでnext.config.jsを修正する。 next.config.js module.exports = { future: { webpack5: true, }, reactStrictMode: true, } するとエラーが変わり、 Global CSS cannot be imported from files other than your Custom <App>. Please move all global CSS imports to pages\_app.tsx. となった。 *.scss -> *.module.scss 上記の原因は、scssファイル名にmoduleが含まれてないとglobal CSS扱いになって、global CSSは_app.tsxでしか使えないよ!とのこと。 なのでファイル名を変更していった。もちろん対応するimport部分も修正。 こいつ... 動くぞ！ ようやくlocalでの実行ができるようになりました。 いろいろやったので直接的な原因がどれなのかさっぱりですが、多分@zeit/next-sassあたりが大きかったと思います。 localで今まで動いてたのはきっとデプロイ->実行という流れを試してなかったからだと思います。(next startしかやってない) ちゃんとデプロイもできたので万々歳ですね。 まだ出来上がってないですがデプロイできた時はうれしいものです。 引き続き躓きながら開発できればいいかな。 (何とでもなるはずだ!)

背景 画面からだと１つずつしか削除できずめんどくさかったから AWS OrganizationのマスターアカウントからAWS Configを適応されている場合は「OrgConfigRule-ABCDEFG」みたいなルールがあったり、SecurityHubが作成したルール（「securityhub-access-keys-rotated-xxxxx」みたいな名前）があるがそれらは削除できずエラーになるので特に問題はない（本当は分岐したりするべきだけど時間がなかったので省略） 各種バージョン $ aws --version aws-cli/2.1.30 Python/3.8.8 Darwin/20.6.0 exe/x86_64 prompt/off スクリプト #!/bin/bash PROFILE="profile-1234" RULES=$(aws configservice describe-config-rules \ --query 'ConfigRules[].ConfigRuleName' \ --profile ${PROFILE} --output text) echo "" for RULE in ${RULES} do # 削除できなければExceptionに入るのでエラーは捨てる POLICY=$(aws configservice delete-config-rule \ --config-rule-name ${RULE} \ --profile ${PROFILE} 2> /dev/null) if [ $? -gt 0 ]; then echo "cannot be deleted ${RULE}" else echo "remove complete ${RULE}" fi done 出力結果 cannot be deleted aws-config-rule01 remove complete aws-config-rule02 remove complete aws-config-rule03 : :

はじめに AWS認定試験取得に向けてAWSの知識を整理するためのまとめです。 今回はAmazon CloudTrailについてまとめます。 CloudTrailとは AWSアカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。 CloudTrailを利用することでAWSインフラストラクチャ全体でアカウントアクティビティをログに記録し 継続的に監視、保持できます。 (誰がいつ、どんな操作をしたのか記録する) 特徴 CloudTrailは全てのAWSアカウントで有効化されていて アカウントの作成時点からアカウントアクティビティを記録します。 過去90日分のアクティビティを表示、ダウンロードできます。 (90日以上保存する場合は、S3へ保持する） マルチリージョン設定 ある一つのアカウントで、複数のリージョンから1つのS3バケットにログファイルを 配信するように設定できます。 1つの設定ですべてのリージョンに適用されるため、既存リージョンにも新しくサービスを起動したリージョンにも適用されます。 ログファイルの暗号化 CloudTrailではデフォルトで指定されたS3に配信されるすべてのログファイルをS3の サーバー側暗号化(SSE)を使用して暗号化します。 AWS KMSキーで暗号化することもできます データイベント データイベントログを有効化することで、オブジェクトレベルのAPIアクティビティを記録し 誰がリクエストを行ったか、どこでいつリクエストされたかなどの詳細情報を受け取ることができます CloudTrail Insights リソースプロビジョニングの急上昇、IAMアクションのバースト、 または定期的なメンテナンスアクティビティのギャップなど、 AWSアカウントの異常なアクティビティを特定します。 AWS組織全体でCloudTrail Insightsイベントを有効にするか もしくはCloudTrailtここのアカウントで有効にできます。 統合 Lambdaと統合すると、CloudTrailからS3バケットにログが書き込まれると、 Lambda 関数が呼び出され、CloudTrail により記録されたアクセスレコードを処理したり、 CloudWatch Logsと統合するとCloudTrailで記録された管理とデータのイベントを CloudWatch Logsに送信しイベントをモニタリングできるようになります。 その他 CloudTrail は S3 バケットに約 5 分ごとにログファイルを送信します。 そのアカウントに対してAPI呼び出しがない場合、CloudTrail はログファイルを送信しません。 複数のアカウントの保存先として、1つのS3バケットを設定できます。 料金 基本的に無料で利用を開始することができます。 S3 に配信されたデータイベント量、CloudTrail Insightsで分析したイベント量に応じて 従量課金となります。 参考サイト

はじめに AWS Organizations (組織) の登場で、AWSアカウントの作成はコマンド一発で自動化出来るようになり、それを書いたブログ等は山ほどあります。 しかし、AWSアカウントの「削除」を自動化する記事が全く有りません。 AWS CLIの説明書を読んでも作成する create-account は有りますが削除するコマンドは無し。 むしろやりたいのはこっちなのに。。 経緯 勉強会やハンズオンで一時的に使用するAWSアカウントを量産します。 これはAWS CLIでも aws organizations create-account --email foo@bar.net --account-name hoge とコマンド一発で完了します。 問題はここからで、勉強会終了後に量産したAWSアカウントを全て削除したい。 これはリソースの削除は手間がかかるからです。サービスコントロールポリシーで作成可能なリソースを制限していたとしてもそもそも面倒です。 AWSアカウントを削除すれば全てのリソースが一括削除されますから、これがスマートですよね。 （厳密には課金が停止するだけで、後はAWSが任意のタイミングでリソースを削除するのですが課金が停止されればこちらとしてはそれで良い） ちなみにIAMユーザを使わないのは、同一AWSアカウントを複数人で共有するとリソースが競合が発生するからです。 結論 できない 何故できないのか AWS OrganizationsにはAWSアカウントを削除するコマンドは無く、組織からAWSアカウントを排除する remove-account-from-organization しか有りません。 これは単独AWSアカウントになる事を意味しますが、AWS Organizationsで作成したAWSアカウントにはクレジットカード情報等の情報がAWSアカウント作成を実行したマスターアカウントから引き継がれていない為そのままでは組織から排除出来ず、これらを手動で登録する必要があります。 これが原因です。 どうしてこうなった 単独AWSアカウントにすると決済情報が等が必要なのはそうですが、マスターアカウントからそれらを引き継いだAWSアカウントを作成するようにすれば済む話です。 百歩譲って、組織に所属した状態のままAWSアカウントを削除できれば組織に所属している間はマスターアカウントが支払うのですから問題無いはずです。 どうしてこうなった。。 まとめ AWSアカウントの削除は自動化できない。

どんな時に読み込まれないのか Chromeの開発者ツール(F12)でページを見たときに、 下記のエラーメッセージが出ていれば、後述する対処法に従うことで解決する可能性が高いです。 Refused to execute script from '<スクリプトのURL>' because its MIME type ('binary/octet-stream') is not executable, and strict MIME type checking is enabled. 原因 読み込もうとしたファイルのMIMEタイプが実行不可能なタイプ( binary/octet-stream )であるため 現在閲覧中のWEBサーバーで厳格なMIMEタイプ判別を行っているため エラー説明文のままですが… 説明 binary/octet-stream は、正体不明のバイナリーファイルに用いられます。 厳格なMIME判別を行うWEBサーバーにおいて、このタイプはダウンロードされるのみで、 ブラウザ上で実行されないために、当該のJavaScriptファイルは読み込まれません。 S3アップロード時(PUT)のContent-Typeの既定値が binary/octet-stream らしく、 一部のファイルはこれが原因で表示されないみたいです。 何がトリガーで binary/octet-stream が設定されるのかはよくわかってません。すいません 解決方法 Step1. S3でファイルのContent-Typeを application/x-javascript に変更する ※HTMLファイル上の記述に以下のように type="text/javascript"を追加しても意味はないです。S3でメタデータを編集する必要があります <script src="common/js/common.js"></script> ↓ <script type="text/javascript" charset="utf-8" src="common/js/common.js"></script> S3コンソールで以下の操作をします Amazon S3 > {S3バケット名} > common > js を開く common.js にチェックを入れて、 アクション > メタデータの編集 をクリック ※バケット名やディレクトリ名は皆さまのお使いの環境で読み替えてください メタデータ タイプ: システム定義 キー: Content-Type 値: binary/octet-stream -> application/x-javascript に変更 メタデータの編集ボタンを押す ※ディレクトリ内のファイルを一括で変更するには以下のようにします Amazon S3 > {S3バケット名} > common > js を開く ディレクトリ左上にあるチェックボックスをクリックして一括チェック後、 アクション > メタデータの編集 をクリック ※バケット名やディレクトリ名は皆さまのお使いの環境で読み替えてください メタデータの追加 タイプ: システム定義 キー: Content-Type 値: application/x-javascript メタデータの編集ボタンを押す これにより、もともと定義されていた Content-Type の値が上記で設定した値に上書きされます。 Step2. CloudFrontのキャッシュを削除する メタデータを編集しても、キャッシュが削除されなければ反映されません。 ブラウザのキャッシュを削除しても、CDNサーバー上にキャッシュが残っているので無意味です。 CDNサーバー上のキャッシュを削除する必要があります。 以下の操作でCDNサーバー上のキャッシュを削除します。 CloudFront > ディストリビューション > {ディストリビューションID} キャッシュ削除 > キャッシュ削除を作成 をクリック オブジェクトパスを追加 /common/js/common.js ※ディレクトリ名やファイル名はお使いの環境で読み替えてください キャッシュ削除を作成 をクリック ステータス: 進行中 が 完了済み になるまで待ちます ※一括でキャッシュ削除するなら以下のようにします オブジェクトパスを追加 /common/js/* キャッシュ削除を作成 をクリック ステータス: 進行中 が 完了済み になるまで待ちます Step3. 動作確認 ステータスが完了になった後、改めてChromeで当該ページを開くと、 ちゃんと読み込まれるようになると思います。 開発者ツール(F12)を開いた状態でページをリロードした後、 開発者ツールの ネットワーク タブを開き、ちゃんと読み込まれていなかったJavaScriptファイルをクリック、 ヘッダー > レスポンスヘッダー > content-type の値が application/x-javascript に変わっていればOKです。 参考URL https://qiita.com/hihats/items/33872f88cf21b5aca952 https://kenjiszk.hatenablog.com/entry/2014/05/08/090733 http://norm-nois.com/blog/archives/2968 https://qiita.com/baby-0105/items/0356b0af4ab4585d86c4

初めに 利用中のクラウドから、他クラウドにリソースを移行したい時、インスタンスの移行は重要なタスクになります。AWS EC2インスタンスをOCI（Oracle Cloud Infrastructure）に手動で移行する方法を紹介します。少しお役に立てれば幸いです。 事前準備 EC2インスタンス（停止中の状態）(この例は、"Red Hat Linux 8"を利用する。) S3バケット （インスタンス・イメージ格納用） S3バケットにACLをアタッチ (方法はSTEP-1にある。) rcloneのインストールとセットアップ (AWS/OCIに接続済) ステップ 1. EC2インスタンスをS3にエクスポートする 2. AWS S3からOCIオブジェクト・ストレージにEC2のイメージをコピー 3. OCIオブジェクト・ストレージからイメージをインポートする 4. インポートされたイメージでOCIインスタンスを作成 STEP-1は、AWS側で実施します。STEP-3とSTEP-4は、OCI側で実施します。 STEP-2の実施場所は、クラウド/On-Pか、どこでもOKです。(この例は、"OCI Cloud Shell"で実施します。) 1. EC2インスタンスをS3にエクスポートする インスタンスを停止してから、「AWS CLI」のコマンドを実行します。 この例では「AWS CloudShell」を使用します。 (「AWS CLI」は実装済) エクスポートタスクは「AWS CLI」でのみ実行できます。（AWSコンソールからはできません。） エクスポートのコマンド例 aws ec2 create-instance-export-task --description 'AWS-To-OCI' --instance-id <instance_id> --target-environment vmware --export-to-s3-task DiskImageFormat=vmdk,ContainerFormat=ova,S3Bucket=aws-2-oci パラメータの意味 --description: 任意の内容を入力。 (最大255文字) --instance-id: EC2インスタンスのID --target-environment: 可能な値は、"citrix"、"vmware"および"microsoft"です。 ("vmware"を指定) DiskImageFormat: イメージのフォーマット。(OCIでサポートされている"vmdk"フォーマットを指定。) ContainerFormat: ディスクイメージとメタデータを組み合わせるために使用されるフォーマット。("ova"を指定.) S3Bucket: S3バケット（イメージ格納用） 以下のエラーが発生した場合 [cloudshell-user@ip-10-0-104-80 ~]$ aws ec2 create-instance-export-task --description 'AWS-To-OCI' --instance-id <instance_id> --target-environment vmware --export-to-s3-task DiskImageFormat=vmdk,ContainerFormat=ova,S3Bucket=aws-2-oci An error occurred (InvalidParameter) when calling the CreateInstanceExportTask operation: Access denied to the bucket aws-2-oci [cloudshell-user@ip-10-0-104-80 ~]$ 対策：アクセス制御リスト(ACL)をS3バケットにアタッチする必要があります。 AWS S3-> Your_Bucket -> Pemissions -> Access control list (ACL) -> Edit 以下のように読み取り/書き込みアクセスを許可します。 「Grantee」で、AWSドキュメントをご参照いただき、適切なリージョン固有の正規アカウントIDを指定します。 ACLをS3バケットにアタッチした後、正常にエクスポートできるようになりました。 [cloudshell-user@ip-10-0-86-145 ~]$ aws ec2 create-instance-export-task --description 'AWS-To-OCI' --instance-id <instance_id> --target-environment vmware --export-to-s3-task DiskImageFormat=vmdk,ContainerFormat=ova,S3Bucket=aws-2-oci { "ExportTask": { "Description": "AWS-To-OCI", "ExportTaskId": "export-i-07e203dc1703757fd", "ExportToS3Task": { "ContainerFormat": "ova", "DiskImageFormat": "vmdk", "S3Bucket": "aws-2-oci", "S3Key": "export-i-07e203dc1703757fd.ova" }, "InstanceExportDetails": { "InstanceId": "<instance_id>", "TargetEnvironment": "vmware" }, "State": "active" } } AWSコンソールでの確認 エクスポートタスクの開始時に、ファイル"vmimportexport_write_verification"が作成されます。 エクスポートタスクが完了すると、ファイル"<export_task_id>.ova"が作成されます。 エクスポート時間は、インスタンスのサイズによって異なります。このテストは30分もかかりませんでした。 2. AWS S3からOCIオブジェクト・ストレージにEC2のイメージをコピー コピー方法はたくさんあります。例えば、WEBコンソールか、CLI/SDKでファイルをダウンロード・アップロードします。この例では、「OCI Cloud Shell」にインストールされるrcloneを利用します。rlconeのインストールとセットアップは、ここで省略します。手順がほしい方は、以下のブログをご参照ください。（インストールとAWS/CLIへの接続方法を含みます。） バケット内のイメージファイルを確認 liu_wei@cloudshell:~ (ap-tokyo-1)$ rclone listremotes aws: oci: liu_wei@cloudshell:~ (ap-tokyo-1)$ rclone ls aws:aws-2-oci 1253826560 export-i-07e203dc1703757fd.ova 0 vmimportexport_write_verification liu_wei@cloudshell:~ (ap-tokyo-1)$ AWSからOCIにイメージをコピー liu_wei@cloudshell:~ (ap-tokyo-1)$ rclone --verbose copy aws:aws-2-oci/export-i-07e203dc1703757fd.ova oci:Target_Bucket 2021/10/11 03:52:18 INFO : export-i-07e203dc1703757fd.ova: Copied (new) 2021/10/11 03:52:18 INFO : Transferred: 1.168Gi / 1.168 GiByte, 100%, 67.478 MiByte/s, ETA 0s Transferred: 1 / 1, 100% Elapsed time: 18.2s liu_wei@cloudshell:~ (ap-tokyo-1)$ rclone ls oci:Target_Bucket 1253826560 export-i-07e203dc1703757fd.ova liu_wei@cloudshell:~ (ap-tokyo-1)$ OCIコンソールからイメージファイルを確認 ファイルサイズがなぜ違うと思ったら イメージファイルのサイズは、OCIコンソールでGiB （1 GiB = 1024³ バイト）単位で表示されます。AWSコンソールで表示されるGB単位（1 GB = 1000³ バイト）より少し小さいです。 3. OCIオブジェクト・ストレージからイメージをインポートする Menu -> Compute -> Custom Images -> Import image 必要な情報を入力し、インポートを開始します。（「準仮想化モード(Paravirtualized mode)」を選択します。） 「Work requests」画面で状態を確認できます。 インポート・タスクには12分近くかかりました。 4. インポートされたイメージでOCIインスタンスを作成 Menu -> Compute -> Instances -> Create Instance -> Change image 「Image source」で、「Custom images」を選択してから、インポートされたイメージファイルを指定します。 その他の必要な情報を入力し、作成を開始します。 作成はすぐ完了します。 SSH経由で新しいインスタンスに接続する ログイン・ユーザーは移行元インスタンスと同じで、デフォルトは「ec2-user」です。秘密キーは、新しいインスタンスを作成する際に使用したもので、移行元インスタンスの秘密キーと違ってもよいです。 [ec2-user@imported-instance-from-aws ~]$ pwd /home/ec2-user [ec2-user@imported-instance-from-aws ~]$ ll total 4 -rw-rw-r--. 1 ec2-user ec2-user 4 Oct 8 07:17 this-is-EC2-instance.txt [ec2-user@imported-instance-from-aws ~]$ エクスポート/インポートの制限事項 ここまで、インスタンス移行のタスクは完了です。エクスポートとインポートにはいくつかの制限がありますので、ご注意ください。(リンクをクリックし、制限事項の詳細をご参照。) 以上 ドキュメント AWS オフィシャル・ドキュメント VM Import/Export を使用して VM としてインスタンスをエクスポート OCI オフィシャル・ドキュメント カスタムLinuxイメージのインポート 関連記事 RcloneでAWS S3からOCIオブジェクト・ストレージにデータをコピー OCI Cloud Shellにrcloneをインストールする

AWS EC2にSSHでリモート/ローカルフォワーディングして気づいたこと プライベートアドレスで立ち上げた計算機1(Ubuntu)のHTTP(80)を、SSH(22)だけ開いているAWS EC2の8080ポートへリモートフォワーディングして、そこへプライベートアドレスの計算機2(Windows)の8080ポートへローカルフォワーディングしようと考えた。 計算機1：Ubuntu ← private address(IP1) 計算機2：Windows ← private address(IP2) 計算機3：AWS EC2 ← グローバルIP(外向き：IP_AO)＋private IP(内向き：IP_AI) EC2はUbuntuを採用、SSH(22)しかポートは開いてない EC2のセキュリティポリシー(インバウンド) もSSH(22)しか開いてない 実験1 まずはリモートフォワーディング： 計算機1(Ubuntu) $ ssh -R IP_AO:8080:localhost:80 username@IP_AO 続いてローカルフォワーディング 計算機2(Windows) $ ssh -L 8080:IP_AO:8080 username@IP_AO すると、リモートフォワーディングの方はできているが、ローカルフォワーディングの方で、Open channel的なエラーがでる。すなわち、計算機2（Windows）でブラウザからlocalhost:8080としても計算機1（Ubuntu）のWEBページは閲覧できない。 実験2 まずはリモートフォワーディング： 計算機1(Ubuntu) $ ssh -R IP_AO:8080:localhost:80 username@IP_AO 続いてローカルフォワーディング 計算機2(Windows) $ ssh -L 8080:IP_AI:8080 username@IP_AO 実験1との違いはIP_AIのところ。些細なことだけど気づきにくい。これで計算機2（Windows）でブラウザからlocalhost:8080として計算機1（Ubuntu）のWEBページが閲覧できた。

使用方法 aws-ecs-exec Sample-Cluster task-id container-name bash関数 function aws-ecs-exec() { command aws ecs execute-command --cluster $1 \ --task $2 \ --container $3 \ --interactive \ --command "/bin/sh" } 説明 毎回コンテナに入るときのコマンドをぐぐりながらやってたので、bash関数化したら楽かなと思いました。 subnetの指定はいるんだっけ？とrun-taskとごっちゃになったりしてたので。。 --command "/bin/sh"この箇所は動いているDockerイメージによって変わると思うので適宜変更してください。

Docker 1.11 以上なら https://github.com/awslabs/amazon-ecr-credential-helper を使うことで、docker-login が 普通にECRに対しても認証できます。 今回の方法は、一旦 docker login したあとも、12時間経過したら再度 docker loginを叩かないといけません。 本当になんらかの理由でアップデートできない場合、というのが今回の内容です。 get-login-password を使った方法 aws-cliをv2にあげるのは簡単なのでとりあえずaws-cli2をあげておく docker 1.7 だと -password-stdin というオプションは存在しないが、こんな感じでいける docker login --username=AWS --password=`aws ecr get-login-password --profile profile` --email=shida@example.com 0123456789.dkr.ecr.ap-northeast-1.amazonaws.com あとは、通常通り docker push や pull できる

はじめに DVA取得に向けてのDynamoDBをBlack Beltや過去のセッション等を参考に少しまとめてみました。 DynamoDB とは？ フルマネージドな NoSQLDB。 特徴としては以下の通り。 3 箇所の AZ にデータが自動的にレプリケーションされる仕様(=Single Point Of Failure の心配がない) データは必要に応じて自動的にパーティショニングされる ストレージの容量制限なし(=従量課金制であるが、ディスクやノードの増設は自動で行われる) スループットはそれぞれ読み書きごとにキャパシティを割り当てる方式(プロビジョンドスループット)でその割り当ての総量で従量課金、オートスケーリングも可。 基本的にはプロビジョンドで使うが、オンデマンドでの利用も可。主にどうしてもキャパシティを予測できない場合のサンプル期間としての利用に適している トランザクション機能や多少のクエリ機能はあるが、RDB に比べるとそれらの点では劣る反面上記のようにスケーラビリティの面では優れている DB としての特徴 引用: AWS BlackBelt Amazon DynamoDB 基本的には Table-Items(RDS におけるレコード)-Attributes(RDS におけるカラム)という構造。 RDS と大きく異なる部分は Attributes に入るデータ型に制限がない(RDS であるなら例えば name のカラムは character でないといけない、id なら int……など)ことと、ソート用のキーの作り方にある。 詳しくは後述。 スループットはそれぞれ読み書きごとにキャパシティを割り当てる方式(プロビジョンドスループット)でその割り当ての総量で従量課金 結果整合性モデルであり、その強度を強くするオプションもある(ただし、その場合読み出しのコストが上がる。通常の結果整合性は 0.5 リクエストに対してより強い結果整合性は 1 リクエストとなる) 自動で 3 つの AZ にレプリケーションされるので、Write 処理は 2 つの AZ において書き込みが完了した場合に初めて肯定応答が返る Key-Value 或いは Value の部分に JSON・XML も入れられることからドキュメント指向 DB としても利用できる データがパーティショニングされるので、RDS と比べて目的のデータへのアクセスが早い反面、複数のパーティションを跨ぐような検索には向かない(=故に複雑なクエリは NG) 主キーの構成要素となりうる Partition、Sort キーに該当する Attribute 以外のそれは事前の定義はいらない(put 時に自動で格納される) TTL を設定することで有効期限が切れている Item を自動削除できる(即解除ではなく 48 時間は期限切れ Item として表示されてしまうので Query 等で取得しないように設定する必要がある) DAX(DynamoDB 用のインメモリキャッシュ)を使って高速なキャッシングもできる Key と Index Index はそれぞれプロビジョニングしたスループットやストレージとは別にさらにそれらを用意しないといけない。 Partition Key まず Primary Key だが DynamoDB においては Partition Key と呼ばれる。 Attributes の中から最も一意になるような要素がこれに該当する、普通は id とか。 なぜ Partition Key と呼ばれるかというと前述の通り、DynamoDB は Table の概念はあるもののそれを必要に応じて分割するという機能があるためどの Partition にその Item が格納されているかを示す要素が必要になるからというわけである。 3 つの AZ にレプリケーションされるということと合わせると以下のような例がわかりやすい。 引用: AWS BlackBelt Amazon DynamoDB Sort Key 次に Sort Key。 これは Partition Key と合わせてその Attribute でパーティション内をソートしたいといった場合に設定する。 また RDB における複合主キーのように Partition Key + Sort Key で 1 つの Primary Key と見なすという処理もできる。 具体的な例は下図の通り。 引用: AWS BlackBelt Amazon DynamoDB Local Secondary Index Sort Key 以外に絞り込むを行いたい場合にこれを設定できる。 ただし、LSI はテーブル作成時にしか作成できないので設計時に考慮すべきである。 で、これを設定するとテーブルから Index が作成されてそこを検索できるようになる……という代物。 以下公式から引用。 引用: AWS デベロッパーガイドよりローカルセカンダリインデックス こういうテーブルがあったとする。 で、このテーブルの LastPostDateTime を LSI に指定すると以下の通り Index が作成される。 引用: AWS デベロッパーガイドよりローカルセカンダリインデックス これで必要に応じてこの Index も検索できるようになり、元のテーブルでは Scan などの全件検索等でやらなければいけなかったところが解消される……といったメリットが有る。 ただし、各 Partition Key ごとにそのテーブルとインデックスのサイズの合計が 10GB にならなければならないため必然的に Partition Key と LSI は相互に依存した作成数の制限がある。 Global Secondary Index 今度はそもそも設定した Partition Key ではソートに不都合が出るという場合にその代わりとして別の Attribute から設定し、それを基に index を作る。 これは前述までの通り、基本的には Partition(+Sort)key でしか DynamoDB では検索ができない(=パーティション毎の検索にしか向かない)という点の 1 つの解消策のような感じ。 以下公式から引用。 引用: AWS デベロッパーガイドよりグローバルセカンダリインデックス こういうテーブルがあったとする。 このテーブルの場合は UserID、または UserID+GameTitle をキーとしてしか検索ができないので例えば Meteor Blasters のスコアだけを抽出したい(2 件データはあるが別パーティションに存在する) といった条件の場合全件検索を行わないといけない。 これではコストもかかるし、アクセスも遅いという問題が生じる。 そこで、GSI として GameTitle、その Sort Key として TopScore を指定して Index を作ると以下のような Index ができる。 引用: AWS デベロッパーガイドよりグローバルセカンダリインデックス これで前述の条件(他の GameTitle の場合でも)の際にはこちらの Index を使えば Scan を使わずに済むという寸法。 ちなみに UserID も射影といって自動的にテーブルから Index にコピーされる。 スループットについて DynamoDB は前述までの通り基本的にスループットについて Read・Write それぞれに容量を割り当てるようにプロビジョニングする形でスループット性能を決めるのが特徴。 それぞれ Read Capacity Units、Write Capacity Units と呼ばれ計算方法は RCU……1 秒あたりの読み込み項目数 × 項目のサイズ(4kB 単位で計算される)× 整合性強度(通常なら 1/2、強い整合性であれば 1) WCU……1 秒あたりの読み込み項目数 × 項目のサイズ(1kB 単位で計算される) 例えば A = 2KB の Item を 1 秒あたり 1000 回強い整合性で読み込む = (2/4 → 1(小数点以下は切り上げ)) × 1000 = 1000RCU A を通常の結果整合性で読み込む = 1 × 1000 × 1/2 = 500RCU 6KB の Item を 1 秒あたり 1000 項目書き込む = 6000RCU 512B の Item を 1 秒あたり 1000 項目書き込む = (0.512 / 1 → 1(小数点以下は切り上げ)) × 1000 = 1000RCU という計算になる。 前述の通り Auto Scaling ができるが、従量課金であることと急激な上昇でスケーリングが追いつかなかった場合はバーストキャパシティが消費されそれもなくなるとバーストキャパシティが貯まるまで処理は中断される。 参考: DynamoDB Auto Scaling によるスループット容量の自動管理 参考: バースト容量を効率的に使用する パーティショニング スループットに関連するのがパーティショニングの仕組み。 DynamoDB はプロビジョニングされたスループットを確保するためにパーティショニングを行う。 問題はパーティションが作られた場合、プロビジョニングされたスループットは各パーティションに均等に割り振られるという点。 これで各パーティションの性能を均等化しているが、Partition Key を適当に設計してしまうとアクセスされる Key に偏りが発生するためその仕組みが無意味になってしまうことに注意。 解決策としては Adaptive Capacity を導入することが考えられる。 Adaptive Capacity はあるパーティションにスループットが集中してしまった場合、通常均等で割り当てられるスループットを負荷がかかっているパーティションへ集中的に割り当てる仕組み。 Amazon DynamoDB の adaptive capacity が不均一なデータアクセスパターンに対応する仕組み（または、なぜ DynamoDB について知っている情報が古くなっているのか） パーティショニングとスループットの関係性 よってパーティションの数はストレージの容量とスループットで決まることになる。 具体的には 1 つのパーティションにつき、実際の RCU/3000RCU + 実際の WCU/1000WCU のキャパシティユニットを割り当てられる(もちろん RCU のみとかでも可) 1 つのパーティションには 10GB までデータを収められる ストレージサイズとスループット、どちらを基準してパーティション数を決めるかは大きい方を基準とする 例えば スループット…… 5000RCU/3000RCU + 500WCU/1000WCU = 3(≒ 2.17 小数点の場合切り上げ) ストレージサイズ…… 8GB/10GB = 0.2 = 1 この場合だとスループットの方を基準としてパーティションを 3 つ作るということになる。 なお、各パーティションのキャパシティユニットは RCU…… 5000/3 WCU…… 500/3 となる。 よってこのことから キャパシティが増加した場合……パーティション数が増える キャパシティが減少した場合……各パーティションあたりのキャパシティが減少する(キャパシティエラーを起こす危険性がある) という点には注意しないといけない。 Item 操作について DynamoDB は API を用いてアクセスする。 で、そのアクセスの仕方は扱う言語によって SDK が用意されているのでそれに従って行う。 Get/Put/Update/Delete は Partition Key と Sort Key を指定して対象 Item を決定する。 Put と Update に関しては以下も Topic として参照したい。 【AWS CDK】AWS AppSync で DynamoDB を直接 UpdateItem するマッピングテンプレートを使いたい 読み込み操作 GetItem GetItem オペレーションは、指定された主キーを持つアイテムの属性セットを返します。一致するアイテムがない場合、GetItem はデータを返さず、応答に Item 要素はありません。 GetItem は、デフォルトで eventually consistent read を提供します。アプリケーションで一貫性の高い読み取りが必要な場合は、ConsistentRead を true に設定します。強い一貫性のある読み取りは、最終的に一貫した読み取りよりも時間がかかる場合がありますが、常に最後に更新された値を返します。 つまり、一般的な Get 操作に当たるもの。 一貫性の高い読み取り(結果整合性をより強くした読み取り)はコスト増になるので注意。 BatchGetItem BatchGetItem オペレーションは、1 つまたは複数のテーブルから 1 つまたは複数のアイテムの属性を返します。要求されたアイテムは主キーで識別します。 1 回の操作で最大 16 MB のデータを取得でき、その中には 100 個のアイテムが含まれることもあります。 BatchGetItem は、応答サイズの制限を超えた場合、テーブルのプロビジョニングされたスループットを超えた場合、または内部処理の障害が発生した場合に、部分的な結果を返します。 部分的な結果が返された場合、オペレーションは UnprocessedKeys の値を返します。この値を使用して、次に取得するアイテムから操作を再試行することができます。 つまり、目的の Item を一括で Get するアクション。 ただし 1 回の操作で得られるのは 16MB 分のデータ(Item 換算でおよそ 100)まで 16MB を超えた場合・キャパシティの上限に引っかかった場合・何らかのエラーが発生した場合は取得できた分だけデータが返る 中断された結果は UnprocessedKeys で返ってきてこれを利用して続きを再試行することができる という特性がある。 TransactGetItems TransactGetItems は、1 つのアカウントとリージョン内の 1 つまたは複数のテーブル（インデックスからではない）から複数のアイテムを原始的に取得する同期操作です。TransactGetItems の呼び出しには、最大 25 個の TransactGetItem オブジェクトを含めることができ、それぞれのオブジェクトには、アカウントとリージョンのテーブルから取得するアイテムを指定する Get 構造が含まれます。 TransactGetItems の呼び出しは、複数の AWS アカウントまたはリージョンのテーブルからアイテムを取得することはできません。トランザクション内のアイテムの合計サイズは、4MB を超えることはできません。 DynamoDB は、以下のいずれかに該当する場合、TransactGetItems リクエスト全体を拒否します。 競合する操作が、読み取り対象のアイテムを更新中である。 トランザクションを完了するためのプロビジョニング容量が不足している。 無効なデータ形式などのユーザーエラーが発生している。 トランザクション内のアイテムのサイズの合計が 4MB を超えてはならない。 つまり ある 1 つのアカウントとその 1 リージョン内の DynamoDB リソース(1 テーブル or 複数のテーブル)から複数の Item を Get するアクション Index に対しては行えない Get された Item は TransactGetItem オブジェクトとして取得され、1 回のアクションで最大 25 個、4MB までのサイズで取得できる 読み取り対象のアイテムに競合している操作がある(ex. Update 処理が先に行われていた)・トランザクションを行うためのキャパシティの不足・その他エラーの場合リクエストは Deny となる となる。 Query クエリ操作は、主キーの値に基づいてアイテムを検索します。複合プライマリ・キー（パーティション・キーとソート・キー）を持つテーブルまたはセカンダリ・インデックスにクエリを実行できます。 KeyConditionExpression パラメータを使用して、パーティション・キーに特定の値を指定します。Query オペレーションは、そのパーティション・キーの値を持つテーブルまたはインデックスのすべてのアイテムを返します。オプションで、KeyConditionExpression にソート・キーの値と比較演算子を指定することで、Query オペレーションの範囲を狭めることができます。Query の結果をさらに絞り込むために、オプションで FilterExpression を指定することができます。FilterExpression は、結果の中でどの項目を返すかを決定します。その他の結果はすべて破棄されます。 Query オペレーションは、常に結果セットを返します。一致する項目が見つからない場合、結果セットは空になります。結果を返さないクエリは、そのタイプの読み取り操作の最小数の読み取り容量ユニットを消費します。 つまり 複合主キーを持つテーブルまたは LSI・GSI に対して Partition Key を用いてクエリを実行できる Partition Key に加えて、Sort Key や比較演算子を用いることでより詳細なクエリを行え、FilterExpression オプションで返り値をフィルタリングできる 結果が空だった場合でも返り値として結果セットが返り、最小値ではあるが RCU を消費してしまう となる。 Scan Scan オペレーションは、テーブルやセカンダリインデックスのすべてのアイテムにアクセスすることで、1 つ以上のアイテムとアイテムの属性を返します。DynamoDB が返すアイテムの数を少なくするには、FilterExpression オペレーションを用意します。 スキャンされたアイテムの総数がデータセットの最大サイズ制限である 1MB を超えた場合、スキャンは停止し、結果は次の操作でスキャンを継続するために LastEvaluatedKey 値としてユーザーに返されます。結果には、制限を超えたアイテムの数も含まれます。スキャンの結果、フィルタ条件を満たすテーブルデータがないこともあります。 1 回の Scan 操作では、設定された最大アイテム数（Limit パラメータを使用した場合）または最大 1MB のデータを読み取り、FilterExpression を使用して結果にフィルタリングを適用します。応答に LastEvaluatedKey がある場合は、結果セットをページ分割する必要があります。詳細は、『Amazon DynamoDB Developer Guide』の「Paginate the Results」を参照してください。 つまり 全件取得のアクションに当たるが同時に全件走査を行う処理であるのでデータの総件数と取得したい件数にアンマッチがある場合は無駄なアクションとなってしまう Query と同じくフィルタリングはできるが、Key ではなく Attribute でしかフィルタリングできない(逆に Query は Key でしかできない) 全件取得のアクションではあるが、取得できるデータセットの最大サイズはフィルタリング前のデータセット換算で 1MB まで 1MB を超えた場合、スキャンが停止され LastEvaluatedKey としてそれまでの結果が返されるのでそれを使って再試行する必要がある Limit=10 の場合、Scan(10 件取得)→ フィルタリング……という処理になる、つまり取得した件数に対してフィルタリングが行われる LastEvaluatedKey が返ってきた場合、Pagenation を行う必要がある 書き込み PutItem 新しい項目を作成するか、古い項目を新しい項目で置き換えます。新しいアイテムと同じ主キーを持つアイテムが指定したテーブルにすでに存在する場合、新しいアイテムは既存のアイテムを完全に置き換えます。 条件付きのプット操作（指定された主キーを持つアイテムが存在しない場合に新しいアイテムを追加する）や、既存のアイテムが特定の属性値を持つ場合に置き換えることができます。ReturnValues パラメータを使用して、同じ操作でアイテムの属性値を返すことができます アイテムを追加する際には、主キーの属性が唯一の必須属性となります。属性値は NULL は許容できません。 空の String および Binary 型の属性値は許可されています。 String および Binary 型の属性値は、その属性がテーブルまたはインデックスのキー属性として使用されている場合、0 より大きな長さを持つ必要があります。 セットタイプの属性値を空にすることはできません。 空の値を持つ無効なリクエストは ValidationException 例外で拒否されます。 つまり Put 処理を行うアクションで Create ではなく置き換え処理の場合は問答無用で新しい Item として置き換えを行う Put 処理については条件つき操作も一応はできる 必ず主キーが必要な操作になる となる。 UpdateItem 既存のアイテムの属性を編集したり、まだ存在していない場合は新しいアイテムをテーブルに追加したりします。属性の値を入れたり、削除したり、追加したりすることができます。また、既存のアイテムに対して条件付きの更新を行うこともできます（新しい属性の名前と値のペアが存在しない場合はそれを挿入し、既存の名前と値のペアが特定の期待される属性値を持っている場合はそれを置き換える）。 また、ReturnValues パラメータを使用して、同じ UpdateItem 操作でアイテムの属性値を返すことができます。 つまり Update 処理を行うアクション、PutItem との違いは置き換えではなく Attribute 単位での更新処理になる点 条件付き操作もできる となる。 TransactGetItems TransactWriteItems は、最大 25 個のアクションリクエストをグループ化する同期書き込み操作です。これらのアクションは、異なるテーブルのアイテムを対象とすることができますが、異なる AWS アカウントやリージョンを対象とすることはできず、2 つのアクションが同じアイテムを対象とすることはできません。例えば、同じアイテムに対して ConditionCheck と Update の両方を行うことはできません。トランザクション内のアイテムの合計サイズは、4MB を超えることはできません。 アクションは原始的に行われ、すべてが成功するか、すべてが失敗するかのどちらかにしかならない。 アクションは以下のオブジェクトによって定義されます。 Put - 新しいアイテムを書き込む PutItem オペレーションを開始します。この構造体は、書き込まれるアイテムの主キー、それを書き込むテーブルの名前、書き込みが成功するために満たさなければならないオプションの条件式、アイテムの属性のリスト、条件が満たされない場合にアイテムの属性を取得するかどうかを示すフィールドを指定します。 Update - 既存のアイテムを更新するために UpdateItem オペレーションを開始します。この構造体は、更新されるアイテムの主キー、それが存在するテーブルの名前、更新が成功するために満たされなければならないオプションの条件式、更新される 1 つ以上の属性を定義する式、および条件が満たされない場合にアイテムの属性を取得するかどうかを示すフィールドを指定します。 Delete - 既存のアイテムを削除する DeleteItem オペレーションを開始します。この構造体は、削除されるアイテムの主キー、それが存在するテーブルの名前、削除が成功するために満たす必要のあるオプションの条件式、および条件が満たされない場合にアイテムの属性を取得するかどうかを示すフィールドを指定します。 ConditionCheck - トランザクションによって変更されていないアイテムに条件を適用します。この構造体は、チェックされるアイテムの主キー、それが存在するテーブルの名前、トランザクションが成功するために満たさなければならない条件式、および条件が満たされない場合にアイテムの属性を取得するかどうかを示すフィールドを指定します。 DynamoDB は、以下のいずれかに該当する場合、TransactWriteItems リクエスト全体を拒否します。 いずれかの条件式の条件が満たされていない。 進行中の操作が同じアイテムの更新を行っている。 トランザクションを完了するためのプロビジョニング容量が不足している。 トランザクションでの変更により、アイテムのサイズが大きくなりすぎた（400KB 以上）、ローカルセカンダリインデックス（LSI）が大きくなりすぎた、または同様の検証エラーが発生した。 トランザクション内のアイテムのサイズの合計が 4MB を超えた。 無効なデータ形式などのユーザーエラーがあります。 つまり 最大 25 のアクションリクエストを 1 つのトランザクションとして一括に処理してくれるアクション(同期処理として実行される) ある 1 アカウント及びその 1 リージョンの DynamoDB リソースに対してしか実行できないが、異なるテーブルに対して行える 行えるアクションは Put・Update・Delete・ConditionCheck で同じ Item に 2 つのアクションを行うことはできない(1Item1 アクション) トランザクションとして処理するので、アクションのうち 1 つでもエラーが出た場合はリクエスト全体が Deny となる となる。 BatchWriteItem BatchWriteItem オペレーションは、1 つまたは複数のテーブルに複数のアイテムを入れたり、削除したりします。BatchWriteItem を 1 回呼び出すと、最大で 16MB のデータを書き込むことができ、25 件の書き込みまたは削除要求を構成することができます。書き込まれる個々のアイテムは、最大で 400KB になります。(ただし、Update に当たるアクションは行えない) BatchWriteItem で指定された個々の PutItem と DeleteItem の操作は原始的ですが、BatchWriteItem 全体では原始的ではありません。テーブルのプロビジョニングされたスループットを超えたり、内部処理に失敗したりして、リクエストされたオペレーションが失敗した場合、失敗したオペレーションが UnprocessedItems レスポンス・パラメータで返されます。お客様は、リクエストを調査し、必要に応じてリクエストを再送することができます。通常は、BatchWriteItem をループで呼び出します。反復ごとに未処理のアイテムをチェックし、すべてのアイテムが処理されるまで、それらの未処理アイテムで新しい BatchWriteItem リクエストを送信します。 要求内のすべてのテーブルのプロビジョニングされたスループットが不十分なために、どのアイテムも処理できない場合、BatchWriteItem は ProvisionedThroughputExceededException を返します。 BatchWriteItem を使用すると、Amazon EMR などからの大量のデータの書き込みや削除、他のデータベースから DynamoDB へのデータのコピーなどを効率的に行うことができます。このような大規模な操作のパフォーマンスを向上させるために、BatchWriteItem は、個々の PutItem や DeleteItem の呼び出しと同じようには動作しません。例えば、個々の Put や Delete リクエストに条件を指定することはできませんし、BatchWriteItem はレスポンスに削除されたアイテムを返しません。 並行処理をサポートするプログラミング言語を使用している場合は、スレッドを使用してアイテムを並行して書き込むことができます。アプリケーションには、スレッドを管理するために必要なロジックを組み込む必要があります。スレッドをサポートしていない言語では、指定したアイテムを 1 つずつ更新または削除する必要があります。いずれの場合も、BatchWriteItem は、指定されたプットおよびデリート操作を並列に実行するので、アプリケーションに複雑さを持ち込むことなく、スレッドプールアプローチのパワーを得ることができます。 並列処理によりレイテンシーは減少しますが、指定されたプットとデリートの各リクエストは、並列処理されてもされなくても、同じ数のライトキャパシティユニットを消費します。存在しないアイテムに対する削除操作は、1 つの書き込み容量ユニットを消費します。 以下の 1 つ以上の項目が当てはまる場合、DynamoDB はバッチライト操作全体を拒否します。 BatchWriteItem リクエストで指定された 1 つ以上のテーブルが存在しない。 要求でアイテムに指定された主キー属性が、対応するテーブルの主キースキーマの属性と一致しない。 同じ BatchWriteItem 要求で、同じアイテムに対して複数の操作を行おうとしています。たとえば、同じ BatchWriteItem リクエストで、同じアイテムの配置と削除を行うことはできません。 リクエストには、ハッシュキーとレンジキーが同一のアイテムが 2 つ以上含まれています（実質的には 2 つのプット操作になります）。 バッチ内に 25 個以上のリクエストがあります。 バッチ内の個々のアイテムが 400 KB を超えています。 リクエストの合計サイズが 16MB を超える。 つまり 1 つのテーブルまたは複数のテーブルの複数の Item に対して Write 処理(Delete も含むが Update は行えない)を行えるアクション 個々の Item ごとに Put また DeleteItem を行いそれぞれに成功フラグは個別に管理されている(1 つのアクションが失敗しても全体がその時点で Deny になるわけではない) 失敗したアクション(リクエスト)は再送することができる 並列処理を行う場合レイテンシーの減少が期待できるが、並列処理に指定されたリクエストは実際に並列処理が行われたかに関わらずその分の WCU を消費する NULL な Item に対して削除処理を行ってしまった場合でも WCU を 1 消費する 条件によっては BatchWriteItem 全体が Deny になる(リクエストの合計サイズが 16MB を超える等 BatchWriteItem リクエスト自体に対してのエラーの場合) となる。 DeleteItem テーブルの主キーで 1 つの項目を削除します。項目が存在する場合や、期待する属性値がある場合には、その項目を削除する条件付きの削除操作を行うことができます。 項目を削除するだけでなく、ReturnValues パラメータを使用して、同じ操作で項目の属性値を返すこともできます。 条件を指定しない限り、DeleteItem は冪等な操作であり、同じアイテムや属性に対して複数回実行しても、エラーレスポンスは発生しません。 条件付き削除は、特定の条件を満たした場合にのみアイテムを削除するのに便利です。これらの条件が満たされた場合、DynamoDB は削除を実行します。それ以外の場合は、アイテムは削除されません。 つまり Delete 処理を行うアクション 削除した値を返すこともできる 条件付き削除もできる となる。 ユースケースとして Lambda と一緒に使う DynamoDB Stream を有効にしてモニタリングを行い、それと Lambda を併用して以下のようなケースで利用することが考えられる。 書き込みを検知したら値チェックを行い、Lambda を使って別テーブルの更新や通知を実行する DynamoDB の更新状況の監査ログを S3 に保存 ゲームデータのランキング集計を非同期に実行する 書き込みに対する負荷調整 SQS・Kinesis と併用して書き込みリクエストをキューやストリームで Worker として受け取り、それを必要に応じてスケーリングさせることで特定キー(パーティション)への偏りを防ぐ 同時アクセス数に応じてスループットを増加するか、Key・Item サイズ・リクエストレートごとに RCU/WCU を再検討する DynamoDB を利用する上で大切なこと アクセスパターン(実装したい機能とそれを実現するアクション)を洗い出しておく アクセスパターンを元に基本となる Primary Table を作る 洗い出したアクセスパターンから Query Condition(アクセスパターン毎にそれぞれどう Query を投げれば適切にデータを取得できるかを当該 Index・利用する Key・Filter の内容等々とセットにした表)を作成する Query Condition を参考に、Primary Table から GSI 等の Index を作る。 参考 Amazon DynamoDB Deep Dive | AWS Summit Tokyo 2019 【AWS Black Belt Online Seminar】Amazon DynamoDB Advanced Design Pattern

2021/10/23に SAP を受験し、ぎりぎりで合格できました。 試験対策としては、「WEB問題集で学習しよう」と「AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説」をそれぞれ解いて、分からなかったサービスについてあとで復習するといった感じでした。DOP や specialty で問われるサービスも、難易度を下げて出題されるので、SAP を受ける前にそれらの資格を取っておくと、SAP 試験で点数を稼ぐことができるのではないでしょうか。 Kinesis Data Streams 「Amazon Kinesis Data Streams のよくある質問」 S3 署名付き URL を使用したオブジェクトのアップロード AWS Key Management Service (SSE-KMS) に保存されている CMK でサーバー側の暗号化を使用してデータを保護する Amazon S3 ストレージクラス Amazon S3 イベント通知 IAM SAML 2.0 フェデレーティッドユーザーが AWS Management Console にアクセス可能にする ID プロバイダーとフェデレーション カスタム ID ブローカーアプリケーションを作成するユーザーのフェデレーション IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 ウェブ ID フェデレーションについて SAML 2.0 ベースのフェデレーションについて DynamoDB ウェブアイデンティティフェデレーションのポリシー例 Storage Gateway AWS Storage Gateway とは Auto Scaling Auto Scaling グループへの Elastic Load Balancing ヘルスチェックの追加 SNS モバイルプッシュ通知 RDS 別の AWS リージョンでのリードレプリカの作成 RDS on VMware とは何ですか? VPC DHCP オプションの変更 EC2 Elastic Network Interface Dedicated Hosts と ハードウェア専有インスタンス の違い Billing and Cost Management AWS Organizations の一括請求 (コンソリデーティッドビリング) Route53 ホストゾーンの使用 プライベートホストゾーンの作成 Data Pipeline よくある質問 CloudHSM AWS CloudHSM の SSL/TLS オフロードでウェブサーバーのセキュリティを向上させる EC2 Linux 拡張ネットワーキング プレイスメントグループ クラスタープレイスメントグループ EC2 インスタンスで拡張ネットワーキングを有効化および設定するにはどうすればよいですか? スプレッドプレイスメントグループ インスタンスのプレイスメントグループの変更 Ops Works Ops Works スタック Direct Connect AWS Direct Connect ロケーションのクロスコネクトのリクエスト EFS Amazon EFS でのデータの暗号化 CloudFront 署名付き URL と署名付き Cookie を使用したプライベートコンテンツの提供 CloudFront オリジンフェイルオーバーによる高可用性の最適化 Lambda@Edge を使用したエッジでのカスタマイズ Systems Manager ハイブリッド環境で AWS Systems Manager を設定する RedShift Amazon Redshift スナップショット Amazon Redshift のよくある質問 CloudHSM AWS CloudHSM のベストプラクティス AWS Config AWS Config とは CloudWatch Events Amazon CloudWatch Events とは AWS Application Discovery Service 検出されたデータ AWS Snowmobile よくある質問 AWS Snowball AWSDatabase Migration Service とAWS Snowball Edge を使用した大規模データストアの移行 AWS Directory Service IAM統合 Lambda クォーター Amazon VPC に接続されている Lambda 関数にインターネットアクセスを許可するにはどうすればよいですか? 障害復旧 パイロットライト 不正アクセス DDOS 攻撃

実現したいこと Route53でドメインを取得したので、AWS Certificate ManagerでSSL証明書を発行したい 手順 AWSのコンソールでCertificate Managerを開く 「証明書をリクエスト」をクリック 今回は「パブリック証明書」の発行を選択して、「次へ」をクリック 完全修飾ドメイン名(例: www.example.com)を入力。検証方法はDNS検証を選択 「リクエスト」をクリックすれば証明書の申請ができる 証明書一覧から作成した証明書詳細画面を確認し、ドメインからRoute53でCNAMEのレコードを作成しておく 証明書のステータスが発行済になったら完了 備考 DNSとは Domain Name Systemの略 IPアドレスとドメイン名の紐付けする仕組み CNAMEとは Canonical Name recordの略 DNSで定義されるそのドメインについての情報の種類の一つ あるドメイン名やホスト名の別名を定義する 別名は「エイリアス」（alias）と呼ばれる 参考 DNS CNAMEレコード 【Canonical Name record】