DHCPはクライアントPCで使うけど、awsのdhcpはec2にdns設定を配るときに使う。 設定 vpnとか direct connect でオンプレと接続できたら、dhcpオプションセット使ってec2にdns設定配る。 windowsのad参加してるホスト作ったら、ドメイン名入れとく。参加なしのときは適当に名前入れる。 DNSはオンプレのDNSとか、指定されたものを入れとく。特に指定なかったら8.8.8.8とかでもええ。 dhcpオプションセットは編集できんから、更新は削除して作り直すとかせなアカン。 作り直したら、ec2-windowsホストやったらipconfig /renewしたら設定反映される。 やったことないけどec2-linuxやったらsudo dhclientかな。 ec2ホスト個別にDNS設定 パブリックとプライベートのサブネットを構成してるときは、DNS向き先に注意せんとアカンで。 パブリックのサブネットに存在するec2はプライベートのサブネットで見てるDNSが見えんことあるから、OSの中で個別に設定する。 windowsホストやったらgui画面でdnsの設定したらええんやけど、amazonlinux2023は/etc/resolv.confやない箇所をいじらな恒久設定にならん。 awsのre:Postで説明してる人がいる。作者さんありがとう。 静的 DNS サーバーを持つ EC2 インスタンスを設定する | AWS re:Post repost.aws ubuntuでも似たようなことやったような気がするけど、どうやったかな。 あと、クラスタ使ってるときもdns向き先変えて、個別のdnsサーバとかroute53の定義を優先的に見せたいときあるやろから注意。 ルーティングできてても名前解決できてへんかったら、cloudwatchログ書けへんかったりするし大事やで。 dhcpオプションセットを変更したら、ec2でping/nslookupぐらいはテストしとくクセをつけとこ。

rootユーザみたいなのあるやろけど、普段は使わんようにして一般ユーザを作る。 何でもできるポリシーをロールにつけて、作ったグループに許可をつけとく。 一般ユーザは作ったグループに所属させといて、構築のときは権限昇格して作業。 人が入れ替わったら、グループから削除＆ユーザ削除したらええ。 aws iamでの主な流れ グループとユーザを作っておいて、ポリシーとロールを作ったらグループにアタッチする。 規模が大きかったら、ちゃんと設計書とかマトリクスを書いといた方がええで。 アカウントのパスワードポリシー アカウントの パスワードポリシー は必要に応じて編集する。 パスワード１２文字は短い かもしれんな。 グループ作成 利用制限したいグループがあるとき作成する。 「インフラ」とか「アプリ」とか「テスター」とかその場に応じて作る。 「この人だけ許可」は、理由がない限りは個人にポリシーとかアタッチせず、グループにアタッチする。 APIみたいなの使うための対面やないユーザは、アクセスキーとか使うとき気をつけんとアカン。 ユーザ作成 まとめて作ること多いから、csvファイルダウンロードしとくと使う側に連絡しやすい。 「発行したで」の連絡で添付したら、ログイン先と認証情報渡せる。 ポリシー作成 権限昇格用のロール切り替え先を用意。 assume-policy-switchrole-GVIS-Admins 1 2 3 4 5 6 7 8 9 10 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::xxxxxxxxxxxx:role/switchrole-GVIS-Admins" ] } } なんでもできるポリシーを定義して、権限昇格で使う。 ...

RDSを定期的に停止させる。 停止いうてもRDSは一時停止しかできんし、手動起動した後に停止忘れても困るから毎晩動かす。 ルールとスケジュールの違い どっちも同じようなことができる。よー似てる。どう使い分けるねん？ 違いを説明されている方がおられた。作者さんありがとう。 EventBridgeルールとEventBridgeスケジュールの違い #＠AWS - Qiita qiita.com 「1対多」と「1対1」の違いがあるとはいうけど呼び出すAPIのことかな。 ペイロードに対象を複数指定はできたはず。 ec2やrds１つずつに指定して作ってくほうが運用的には楽やから、自分としてはスケジュール使う。 「このデータベースだけ停止時間遅くして」とかになったら苦しいしな。 cron式の設定 crontabっぽい書き方する。曜日に「*」やなくてなぜか「?」ってあるのが気持ち悪いなぁ。 しかもutc指定やから、朝７時はこう書く。 「月曜から金曜日」は「1-5」やなくて「MON-FRI」ってやるらしい。 スケジュールの画面に「次の１０個のトリガー日」が入ってたら、ちゃんと指定できてる。 1 2 3 4 5 6 Fri,1 Aug 2025 22:00:00(UTC+09:00) Sat,2 Aug 2025 22:00:00(UTC+09:00) Sun,3 Aug 2025 22:00:00(UTC+09:00) Mon,4 Aug 2025 22:00:00(UTC+09:00) Tue,5 Aug 2025 22:00:00(UTC+09:00) :(中略) utc指定苦手。いっつもここで確認しながら時間入れてる。作者さんありがとう。 時差計算ドットコム www.jisakeisan.com ターゲットの設定 RDSの対象を指定。APIにStopDBInstanceってある箇所をStartDBInstanceってしたら起動するもんも作れる。 あ、ロールは先に作っとかなアカンで。 ...

CPU利用率とか、ノードの死活監視はcloudwatchでできるんやけど、そのときにメール飛ばすことができる。 slackとかへの連携もできるんとちゃうかな。 まだ理解弱いけど、トピック作成、サブスクリプション作成して、初回登録のURLをクリックすることでメールが飛ぶようになる。 気づいたらまた書き足す。 トピック作成 まずはトピックを作る。 スタンダード選んで、名前と表示名を適当につける。 アクセスポリシーは後で細かい設定いじりたいときあるかもやから、アドバンストを選んだ。 データ保護ポリシーはベーシックでええ。 配信ポリシーは試行回数とかいじりたいときあるかもしれんけど、適当に入れとく。 アクティブトレースって何やろな。使わん設定にしとく。 トピック作成完了。arn(amazon resource name)をサブスクリプション作成で使うから別途で確認しとく。 サブスクリプション作成 作ってく。通知１つずつに作る必要があるから、代表メールアドレスを普段は登録する。 先に作ったトピックのarnとかメールアドレス入れる。 画面の下の方にある作成ボタンを押す。 「できたで」のメッセージが表示される。 サブスクリプションの確認 サブスクリプションは作っただけでは足りず、最初は保留中になる。有効期限は3日やったかな。 「サブスクリプションの確認」ってボタンを押すと、設定した宛先に確認メールが届くので、メールの中の確認URLをクリックする。 届いたメールの中にURLが入ってるからクリックする。 「確認できたで」の画面が表示される。 さっきまで「保留中」になってたサブスクリプションのステータスが「確認済み」に変わってくれる。 メールのテスト メール送信してみる。 件名とメッセージを入れとく。 最後に発行してメール飛んでくるのを確認。

oracleライセンス高いけど、awsでもoracle使える。 ec2ホストからoracle使わせたり、s3バケットに向かってデータポンプでのバックアップ取ったり。 rdsそのものを丸々バックアップするawsバックアップの指定もつけてく。 本体を作る前に、作成してくもんがあるから順に作る。 ポリシーとロールの設定 oracleデータポンプ用の出力先にnari-s3-bucketを作っておいて、rdsから使わせるポリシーを用意。 policy-nari-s3bucket - iam policy 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::nari-s3-bucket", "Resource": "arn:aws:s3:::nari-s3-bucket/*" } ] } 作ったポリシーをロールにつける。 ...