はてなブックマーク

data "archive_file" "post-slack" { type = "zip" source_dir = "./source_code/post-slack" output_path = "./source_code/post-slack.zip" } resource "aws_lambda_function" "post-slack" { filename = "${data.archive_file.post-slack.output_path}" function_name = "post-slack" role = "arn:aws:iam::※※※※※※※※※※※※:role/service-role/lambda-basic-execution" handler = "main.lambda_handler" source_code_hash = "${dat

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 2018年11月12日のリリース時から気になっていた Amazon Aurora カスタムエンドポイント をようやく試すきっかけができたので、いろいろ検証してみた結果と考察の備忘録。 定時バッチの重い参照系クエリによる長時間DB負荷を、カスタムエンドポイントを使えばサービス用DBから分離できるのか、というのが今回の検証の目的。 2. 使うべきかどうかの最重要ポイント リリース内容はいい感じに書いてあるけど、実際は「目的」「コスト」「スケールアウト/イン」「フェイルオーバー」といった要素を総合的に考慮して、利用すべきかどう

1. 概要 AWS ElastiCache Redis の クラスターモード無効 で次の挙動を把握したい エンドポイント レプリカノードのスケールアウト/イン マルチAZ ノードのスペックアップ/ダウン フェイルオーバー Terraform の設定の理解や、実行手順を確認したい 2. 検証するElastiCacheの構成 ElastiCache のサブネットグループは次の３つのAZを選択 ap-northeast-1a ap-northeast-1c ap-northeast-1d Redis の クラスターモードは「無効 (disabled)」を選択 小中規模のサービスで利用することを想定しているため 3. クラスターモードが無効の場合の機能や注意点 レプリカノードのスケールアウト(追加)、スケールイン(削除) が可能 ノードタイプのスケールアップ、スケールダウンが可能 データのパーティ

1. 概要 Amazon EFS のルートディレクトリ（/）を、AWS Fargate (プラットフォームバージョン 1.4.0）から起動したタスクの /efs にマウントする。 動作確認のために、タスクから df コマンドの標準出力を、 /efs/df.txt へリダイレクトする。 確認用 EC2 から /efs/df.txt を表示する。 2. 構成図 3. 設定手順概要 (1) タスクと確認用EC2用のセキュリティグループ（Security Group A）を作成する (2) EFS用のセキュリティグループ（Security Group B）を作成する (3) EFS のファイルシステムと、マウントターゲットを作成する (4) 確認用EC2を作成して、EFS を EC2 にマウントする (5) Docker イメージを作成して、ECR に PUSH する (6) Amazon ECS

2. ユーザーにパスワード変更を許可する設定（IAMユーザー全体に影響する設定） パスワードポリシー設定で、「ユーザーにパスワードの変更を許可する」にチェックする。 これにチェックしておけば、AWSによる管理の「IAMUserChangePassword」ポリシーをアタッチしなくても、自身がパスワードを変更できるようになる。 3. 開発者Aさんに PowerUserAccess 権限を与えることにする 注意点その１：AdministratorAccess とか、PowerUserAccess ポリシー AWSによる管理の AdministratorAccess ポリシーも、 PowerUserAccess ポリシーも、IAM 操作権限がない。 なので、AWS管理者がIAM周りの作業を行うためには、AdministratorAccess ポリシーに加えて、IAMFullAccess ポリシー

はじめに 2020年1月、ようやく EC2 の バックアップ/リストア を支援する AWS Backup EC2 が リリースされた。 AWS Backup を使った EC2 のバックアップは、スケジュールしたタイミングあるいは即座に、タグあるいはインスタンスIDで指定した EC2 の [AMI](Amazon マシンイメージ (AMI) ) を取得する。 取得した AMI をライフサイクル管理（期限が切れたAMIを削除、あるいはコールドストレージへ移行（費用削減のため））したり、DR用途で異なるリージョンへコピーしたりといったバックアップ管理をしてくれる。 スケジュールしたタイミングでバックアップ・・・バックアッププランを作成する 即座にバックアップ・・・オンデマンドバックアップを作成する ただ、リストア機能はちょっと微妙（というか「復元」という定義は人それぞれ違うからそう思うのかな・・

※ 2020/2/25 追記 2020年1月、ようやく EC2 の バックアップ/リストア を支援する AWS Backup EC2 が リリースされた。 私も、これまでこの自作バックアップを使っていたけど、AWS Backup EC2 へ移行した。 AWS Backup EC2 を実運用へ導入したときのあれやこれや 概要 EC2タグ "AMI-Backup-Generation = n(世代数)" が付いている EC2インスタンスのイメージ (AMI+Snapshot) を定期的に作成する。 AMIの作成と登録解除を行なうLambda (関数名： ec2-image-backup)と、登録解除されたAMIのスナップショットを削除するLambda（関数名：delete_snapshot_after_ami_deregister）の２つを作成して動かす。 設定した世代数よりも古くなった AM

$ ls -laRh terraform 〜 terraform/anyservice/anyenv/awsconfig/.terraform/plugins/darwin_amd64: total 354416 drwxr-xr-x 4 nishimura.toru staff 128B 2 14 20:14 ./ drwxr-xr-x 3 nishimura.toru staff 96B 2 4 20:16 ../ -rwxr-xr-x 1 nishimura.toru staff 79B 2 14 20:14 lock.json* -rwxr-xr-x 1 nishimura.toru staff 173M 2 14 20:14 terraform-provider-aws_v2.48.0_x4* 〜 この terraform-provider-aws_vナンチャラ は、Terraf

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 私が現在行っている AWS Billing and Cost Management 設定がかなりレガシーなものになっているので、新しめの設定へ移行する。 AWS Billing and Cost Management 設定やること/やらないことリストをアップデートする。 設定を CloudFormation, Terraform 化できるところは作成する。 2. やること/やらないことリスト 2.1. やることリスト アカウントの請求情報の表示を IAM ユーザーに許可 手動で設定する。（要ルートユーザー） Cost E

AWX事始め個人的備忘録 1. 想定 やってみること ローカル環境で playbook を作成してVMマシンで実行・確認しながら開発を行う。 作成した Playbook ファイルを GitLab サーバのブランチへ Push する。 （イベントリーファイルは push しなくても良い） AWXサーバの設定を行う AWXサーバからターゲットサーバへ ansible-play を実施する。 Playbook のあるGitリポジトリ git@GitLabサーバ:ansible/getting-started.git 実行する Playbook simple-playbook.yml 2. 構成 3. AWX設定概要 GitLab にある Ansible のリポジトリを AWX サーバへクローンする設定 「認証情報」設定 ・・・ AWXサーバとGitLabサーバのSSH接続用キーペアの秘密鍵を登録

概要 Amazon ECS タスクのスケジューリングは、CloudWatch イベント機能を使っているので、CloudWatch イベント利用時の注意点を考慮する必要がある。 cron式はUTC 参照：タスクのスケジューリング (cron) 例えば、cron式で cron(0 10 * * ? *) と設定した場合、毎日 10:00 (UTC) に実行する。 日本時間で毎日 10:00 に実行させるには、cron式で cron(0 1 * * ? *) と設定する（JST=UTC+9）。 スケジュールされた期間に対して同じルールを複数回トリガーする可能性がある 参照：1 つのイベントに応じてルールが複数回トリガーされました タスクの起動タイプ(ECS/Fargate)によらず、上記挙動が発生する可能性がある。これは、CloudWatch Events の仕様なので、どうしようもない（実際に

概要 AWS Fargate で起動したコンテナからあるサーバへの接続をIPアドレスで制限をかけたいが、普通にFargateを設定したコンテナでは、割り当てられるグローバルIPアドレスはコロコロ変わり固定ではない。 AWS Fargate で VPC 内に作成されたコンテナからインターネットへ出るときに AWS NATゲートウェイを経由させることで、NATゲートウェイに割り当てたEIPがコンテナの接続元IPアドレスとして固定することができる。接続先のサーバではそのEIPを設定することでアクセス制限を行うことができるようになる。 構成概要 構成内容 Amazon ECR Dockerイメージレジストリ ECR リポジトリの作成は、AWS CLI で行う Amazon Fargate コンテナ実行環境 ECR からイメージを pull する VPC Internetゲートウェイをアタッチする

概要 AWS Fargate には、スケジュールルールに従ってタスクを実行できる機能がある。 スケジュールルールは次の２通りある。どちらもスケジュールルールに従って毎回新しいコンテナが起動して終了する。 固定された間隔で実行 Cron式 この「タスクのスケジューリング」機能を使って、これまで EC2 上の crond で起動して実行していたバッチ処理を、コンテナ化して AWS Fargate に移行してみる。 今回 Fargate に移行するバッチの概要 Elasticsearch の インデックスを１日１回削除するバッチ。 サーバのアクセスログを Fluentd で Elasticsearch に送ってKibanaで可視化している。１日分のアクセスログを１つのインデックスに格納していて、30日前のインデックスファイルを削除するバッチを１日1回実行している。 バッチは bash スクリプト

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #1. はじめに AWS を安全に利用するためには、AWSアカウントを発行してすぐに何かを始める前に、まずは　IAM のドキュメント をよく読んでおく必要がある。 しかし、ドキュメントは文量が多いので、個人用に概要と最低限設定しておくべきことをまとめておく。 ちなみに、AWSのセキュリティに関する責任分界点は、責任共有モデルにある。AWS利用者（お客様）がIAMを適切に設定・運用・管理する必要がある。 #2. 関連用語と、AWS推奨設定 ##2.1 ルートユーザー（または root アカウント, ルートID, root ID） AWSア

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ##1. 概要 SSL証明書のインストール作業や更新作業は地味だけど、失敗や更新を忘れると大障害になる。私も過去に２、３回くらいSSL証明書作業で失敗して大反省した経験がある。 昔のSSL証明書作業のことを思い出して書いてもいまさらなので結論から言うと、Amazon で発行して AWS Certificate Manager (ACM) で管理が理想。とはいえ、ACM にはいろいろ制約があり、条件を満たしていないと自動更新できない。すべてのSSL証明書でACMの恩恵を受けることはできないけど、AWSを利用しているのであれば、可能な限りA

0. はじめに Amazon CloudWatch Logs サービスを理解、活用するために、Amazon CloudWatch Logs ユーザーガイド を一読して、個人用に概要と最低限設定しておくべきことをまとめる。 補足は、Amazon CloudWatch の よくある質問 の よくある質問を参考にしている。 0.1 概要、注意点など (1) CloudWatch Logs 特徴 (2) IAMポリシー、IAMロール IAMロールの注意点 (3) CloudWatch Logs エージェント CloudWatch Logs エージェントは、Amazon Linux または Ubuntu を実行する Amazon EC2 インスタンスでログデータを CloudWatch Logs に自動送信する方法を提供する。 前提条件 リファレンス サポートしているログローテート エージェントを停

概要 Aurora 1.14 強制アップグレード通知が来たので、AWSドキュメントの隙間をAWSサポートに聞いたことをまとめる。 Amazon Aurora は定期的に更新をリリースします 更新の案内 https://forums.aws.amazon.com/forum.jspa?forumID=60 過去の更新履歴 http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.html 更新（アップグレード）必須のものもあれば、利用者の判断に任せる場合もある。 最近だと、 Aurora バージョン 1.13 ・・・必須ではありません。 Aurora バージョン 1.14 ・・・既存の Aurora DB クラスターの必須アップグレードです。 アップグレードします（しなさい

#0. はじめに AWS CloudTrail サービスを理解、活用するために、AWS CloudTrail User Guide (Version 1.0) を一読して、個人用に概要と最低限設定しておくべきことをまとめる。 補足や日本語訳は、AWS CloudTrail の よくある質問と、Google翻訳を参考にしている。 Trail=痕跡、証跡 ##0.1 CloudTrail設定したこと 初めて CloudTrail を使うための設定 イベントセレクター設定(デフォルト設定のまま) CloudTrailログをCloudWatch Logsへ送信する設定 ルートアカウント認証情報を使用してAWSマネジメントコンソールにサインインしたときに通知する MFAを使用していないコンソールサインインが発生したときに通知する CloudTrail ログを Amazon ES へ送る #AWS C