データアナリティクス事業本部の武田です。今日は、AWS RDSを7日以上停止するためのとても簡単な設定方法をご紹介します。 検証用に作ったAWS RDSを７日間以上停止したい AWS RDSは稼働時間によって課金されるシステムです。使わないのであれば停止しておきたいところですが、AWSの設定で、停止後7日間で自動的に起動されてしまいます。 この設定のため、私は毎週金曜夕方にAWSコンソールにログインして手動で停止するという面倒なことをしておりました。うっかり忘れると課金されてしまいます。 (注)今回停止させるのは検証用です。パッチ等のことは考えなくていい環境なので、長期間停止させますが、本番環境の長期間停止はパッチ適用ができなくなってしまうので、ご注意ください。 AWS RDSを７日間以上停止する手順（王道版） AWS公式サイトでは、下記のような手順で停止する方法を解説していました。 AW

TiBとTBで比較してみると、 1TiB≒1,099.5GBなのに対して1TB=1,000GB、およそ100GBの差分が出ますので、 大容量のEBSを扱うときは注意が必要です。 コンソール画面での確認 コンソール画面でGiB表記を確かめてみます。 EBS作成画面 図のように、GiB単位で構築するストレージのボリュームサイズを割り当てる容量を指定します。 RDS作成画面 こちらもGiB単位で構築するRDSのストレージに割り当てる容量を指定します。 ストレージ費用試算の注意点 EBSやRDSの容量に対する課金の単位はGBベースですので、注意しましょう。 たとえば予算を1,000GBの容量で試算していた場合、 リソース作成時に1,000GiBの容量を指定してしまうと実際には約1,099.5GBの容量となるため、 予算を超過してしまう恐れがあります。 2023/01/24　追記 上記は誤りで、EB

社内で年齢詐称疑惑の絶えない、インターネット老人会員の水島が大阪からお届けします。 皆さんにとってインターネットとは何でしょうか。情報源…憩いの場…金の生る木…実家のような安心感……？ 私にとってインターネットとは、IPv4とIPv6です。夢のない話ですね！ 今回はお仕事とは全く関係ありません、自宅のインターネット回線のお話です。 涙なしでは語れません。諸行無常のインターネットの世界、お気に入りだったISPのサービス終了を何度か経験されている会員の皆様も多くいらっしゃると思いますが、先月いっぱいで長年愛用してきた固定IPv4が使える安価なプロバイダーが、惜しまれつつもサービス終了となってしまいました。 自宅で固定IPv4アドレスを必要とする活動をされている方はまだまだいらっしゃると思います。このままでは、「IPアドレスを持つ者はすべて対等にサービスを提供できる」という本来のインターネットの

AMIのイベントを検知したいな こんにちは、のんピ(@non____97)です。 皆さんはAMIのイベントを検知したいと思ったことはありますか? 私はあります。 具体的にはAMIのイベントを検知して以下の処理を簡単に実装したいなと思っていました。 AMIの作成が完了したら別リージョンにAMIをコピーする AMIの登録解除をしたら関連付くEBSスナップショットを削除する 特に1つ目の処理を実装する場合、AMIの作成が完了したのか定期的にAMIの状態をポーリングする必要がありました。 今回、AMIの作成や登録解除などのイベントがAmazon EventBridgeに送信されるようになりました。 これにより、上述した処理が簡単に実装できそうです。 早速試してみたので紹介します。 対象のAMIのイベント 対象のAMIのイベントは以下の3つです。 available : AMIが利用可能になった f

こんにちは。MAD事業部のきんじょーです。 最近Rustの入門書を読んだので、何かに使ってみようと模索していました。 その中で、Rustでヘッドレスブラウザを動かすライブラリを検証したのでこの記事にまとめます。 ヘッドレスブラウザとは ヘッドレスブラウザはGUIを持たないWebブラウザです。 一般的なブラウザと同じく、HTMLを解析しJavaScriptを実行できますが、GUIを持たないため、CLIやプログラム上から操作を行います。 主に以下のような用途で用いられます。 WebアプリケーションのE2Eテストの自動化 Webページのスクリーンショット取得 JavaScriptの自動テスト Webページで行うワークフロー処理の自動化 Webページのクローリング 古くはPhantomJSやCasperJSなどを用いていましたが、現在では主要なブラウザもネイティブでヘッドレスモードを搭載しています

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程のアップデートで CloudFront の IP アドレスが Managed Prefix List でサポートされました。これにより CloudFront を経由しない不正なアクセスを簡単に弾くことが可能になります。CMS など CloudFront を使う機会が多いサービスではぜひご利用ください。また CloudFront で AWS WAF を使ってセキュリティを向上している場合の迂回路を塞ぐことができます。 Amazon CloudFront now supports a managed prefix list CloudFront を経由しないアクセス 今まで AWS で CloudFront を経由したアクセスだけ強制させる場合は、CloudFront ではカスタムヘッダを付与して、その値を ALB や Web サーバで

こんにちは！コンサル部のinomaso(@inomasosan)です。 複数のAWSアカウントへ同時にログインするために、別々のブラウザを利用するのはちょっと面倒ですよね。 Google Chromeであれば、複数のAWSアカウントへマッハでログインできるので、小技を紹介していきます。 結論 Google Chromeのシークレットモードを利用することで、ログインセッションがクリアされた状態のブラウザを別ウィンドウで立ち上げ、 複数AWSアカウントにログインできます。 やってみた 通常のウィンドウでAWSアカウントにログイン後に、右上のメニューから新しいシークレットウインドウをクリックします。 ブラウザの右上にシークレットと表示されていることを確認します。 あとは、いつもの手順で別のAWSアカウントへログインするだけです。 まとめ 知っていると少しだけ作業が捗る小ネタでした。 複数AWSア

こんにちは、AWS事業本部コンサルティング部のたかくに（@takakuni_）です。 今回はCloudFormationの「ドリフト検出」の仕様についてご紹介したいと思います。 結論 ドリフト検出は、「スタックで記載しているプロパティ」と「実際のリソースの設定値」の差異を検出する機能 ドリフトで検出させたい設定値はデフォルトと同一でも明示的に指定が必要 ドリフト検出とは スタックによって作成されたリソースの変更点を検知する機能になります。 CloudFormation スタック全体のドリフトを検出 新 – CloudFormation ドリフト検出 AWS CloudFormationで手動で行った変更が検出可能になりました！！！ ドリフトを検出する際の考慮事項 実践 事前準備 今回は以下のようなコードを準備しました。EC2インスタンスを作成するコードになります。 ImageId、Inst

Slack はとても便利ですが、チャットというツールの特性上、自分が送ったメッセージを相手がどのように受け止めるか、リアルタイムに把握することが難しいという特性を持っています。 特に、ネガティブな言葉は目にするだけで生産性が下がるという研究結果があるため、普段から使用しないよう気をつける必要があります。 この点については塩谷が詳しくまとめていますので、ご参照ください。 チームで成果を出すためには心理的安全性が必要で、そのためには礼節とHRTが不可欠だ、という話をしました ただし、無意識下で言葉が選択されることも多く、送信したメッセージを後で読み返してみたらネガティブワードが含まれてしまっていた、ということが多々ありました。 そこでこれを検出し、メッセージ送信者にフィードバックできないかと思い Slack bot を作ってみました。 できたもの ネガティブワードを含んだメッセージを Slac

DevelopersIO 2021 Decade で「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 スライド 話した内容 なぜ人類は OAuth 2.0 に入門し続けるのか なぜ OAuth 2.0 をチームに根付かせたいのか 開発フローとしてコードレビューがある 仕様がわからないと、レビューができない コードと仕様のすり合わせのために仕様が分かる必要がある OAuth 2.0 はまあまあややこしい OAuth 2.0 では登場人物が4人いて、それぞれがいろんなやりとりをします。 それぞれのやりとりにパラメーターがあるので、誰が誰にどういう値をどうして送る、みたいなところまで考えるとまあまあややこしいのですが、このややこしいシーケンスを完全に頭に入れると学習がスムーズに進むと思います。 勉強会について 以下をゴールに設定しました。 各ロール

困っていた内容 セキュリティグループのインバウンドルールの編集を行おうとしたところ、 You may be missing IAM policies that allow DescribeSecurityGroupRules. You are not authorized to perform this operation. のメッセージが表示され、インバウンドルールの編集ができませんでした。 最近、特に設定を変更した覚えはないのですが、なぜこのようなエラーが発生するのでしょうか？ 対処方法を教えてください。 どう対応すればいいの? 先日より、セキュリティグループの各ルールにリソース識別子(Security group rule ID)が付くようになりました。 AWSからのアナウンスはこちらになります。 新しいセキュリティグループルール ID を使用してセキュリティグループルールを簡単に管

困っていた内容 コスト削減のため ECS コンテナインスタンス（EC2）を停止しましたが、いつの間にか「終了状態」になり、新しいコンテナインスタンスが起動しました。 コンテナインスタンスでは通常の EC2 のように終業時に停止して、始業時に開始するといったコスト削減はできないのでしょうか。 どう対応すればいいの? Auto Scaling を利用した自動終了・開始をお試しください。 ECS クラスターを作成する際に「EC2 Linux + ネットワーキング」を選択すると、自動的に Auto Scaling も作成されます。Auto Scaling によりコンテナインスタンスの起動数が自動的に制御されるため、EC2 を直接停止しても、自動的に終了状態になり、新しいインスタンスが作成されます。 そのため、コンテナインスタンスを特定時間だけ起動したい場合は、Auto Scaling の機能を使用

昨今、アクセスキーの漏洩から不正アクセスなどのセキュリティ事故の話が多いですね。AWS外部からAWSリソースを操作するために発行していたアクセスキーが不要になってアクセスキーを無効化したとしましょう。 その無効化したアクセスキーを使ってAWSリソースへアクセスしたらCloudTrailなどにログが残り「無効化したアクセスキーが使われている」と検知できるのか？と気になりました。 今回検証対象のアクセスキーについて IAMユーザのアクセスキーは、アクセスキーIDとシークレットキーの組み合わせにより、利用期間に期限設定がなく永続的に使える認証情報です。期限はないのですがアクセスキーを有効にする（使える状態）か、無効にする（使えない状態）かは設定できます。 アクセスキーを利用する場合の推奨事項 アクセスキーを発行する元のIAMユーザの権限を最小化する アクセスキーを定期的にローテーションして利用す

YoutubeとTwitterに同時投稿が可能に！Adobe Premiere Pro Beta版新機能を試してみた。 せーのでございます。 今日はAdobe Premiere ProのBeta版に大幅な変更と新機能がリリースされたのでご紹介します。 この機能はBeta版での実装です。製品版では詳細仕様が変更される可能性があります。 UIが大幅変更 今回注目すべき大きな変更は UIが大幅に変更 ソースのインポート方法が変更 書き出し方法の変更 です。 これらの機能を試すのに適切な動画はないかな、と探していたところ、ちょうど使っても誰にも怒られなさそうな動画を見つけたので、これを使うことにします。 やってみた Beta版をインストール まずはAdobe Premiere Pro Betaをインストールします。 Beta版は昔Apple M1に対応した時に喜んでダウンロードしたのですが、他の機

こんちは､テクニカルサポートチームの丸屋 正志です｡ ■ご注意ください このポリシーでは「IAMユーザーと同じ名称でMFA設定を行う場合」のみMFA設定の許可が与えられています。 2022/11よりMFA設定時に任意の名称を指定できるようになっており、上記の名称と異なるMFA名を指定した際にエラーになる場合があります。（上述のセキュアポリシー以外でMFA設定の許可が与えられていればエラーは発生しません。） （参考情報） https://aws.amazon.com/jp/about-aws/whats-new/2022/11/aws-identity-access-management-multi-factor-authentication-devices/ 1. AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵

まずまとめ できた図がこちら AWS Systems Manager(SSM) を理解しようとする上で厄介なのは、 「インスタンス管理(左部分)」で使う機能群、それぞれに関連性があること だと思っています。 なので以降の説明は、 図の左半分 インスタンス管理 の説明が大半です。 さっそく インスタンス管理で使える機能を上から舐めていきましょう。 #1 なにはともあれマネージドインスタンス なにはともあれ EC2インスタンスを マネージドインスタンス 化するところから始まります。 マネージドインスタンスにするために、ざっくりいうと 3つの作業が必要です。 SSM エージェント をインストールすること 適切なIAMインスタンスプロファイル※ をアタッチしていること SSM関連エンドポイント※ へのアウトバウンド方向の通信ができること ※ 詳細は以下参照 EC2 インスタンスが AWS Syst

こんにちは(U・ω・U) AWS事業部の深澤です。 タイトルの通りですが、AKIBA.AWS ONLINE #03 -「TerraformとCloudFormationどちらを採用すべき？」というタイトルで登壇してきましたので資料を公開します。 資料 まとめ まずは大前提として状況と比較しましょう。新しい技術にはどうしても学習コストが伴います。新しくて最新の技術がチームにとって必ずしも最適解であるとは限りません。また作って終わりではなく運用が大切です。それぞれの特徴をチームで理解し運用していけるかというのも大切な観点です。 発表で取り上げた観点と特徴を表にまとめるとこんな感じです。 観点 Terraform Cloudformation

俺達はいつまでも立ち尽くし見つめていた━━━　数多の IAM ロールが移ろうように連鎖していく、そのさまを。 コンバンハ、「 IAM ロールはお面」おじさんです。 この世で最も大切なもの、それは繋がりであり、そして連なりですよね。 ということで、早速 IAM ロールで 10 連鎖してみました。 いや、せっかくなので 100 連鎖くらい行ってみましょうか。そうしましょう。興奮してきたな。 まとめ IAM ロールはそんな連鎖させるようなもんじゃない。 手始めに IAM ロールを 101 個作ろう 早速、 100 連鎖のために IAM ロールを 101 個作ります。 「 100 連鎖なのに 101 個なの？」と思うかもしれませんが、ヤマタノオロチの「股（首と首の間）」は 7 個しかありませんよね。（「岐」は 8 個あるんですけどね。）それと同じです。 101 個くらいの数なら「温かみのある手作業

どのような事前準備をしているか 有事の際は想定外のことが発生しやすく、事前準備をしていないと冷静な対応が難しくなります。 いきなりしっかりした事前準備をすることは難しいので、徐々に成熟度を上げていきます。 本章では以下の観点で、事前準備についてご紹介します。 手順書 自動化 訓練 手順書 フローやチェックリストを含む手順書を準備しています。 手順書の内容は後述します。 分かりやすい手順書を準備することも重要ですが、その手順書への導線づくりも大切にしています。 運用周りのドキュメントは数が多く、目的のドキュメントが埋もれてしまい他のメンバーが見つけられない場合があるからです。 周知に加えて、ドキュメントの階層を見直したり、特定チャンネルに手順書の URL をピン留めしておくなど、手順書に辿り着きやすくする工夫をしています。 分かりやすい手順書の書き方については、以下のブログが参考になります。

Amazon が所有するものがあるほか、カスタマー側で作成することもできます。他のアカウントと共有したり、パブリックに公開することもできます。 詳細は以下を参照してください。 AWS Systems Manager ドキュメント - AWS Systems Manager Amazon が所有するドキュメントのタイプを確認する 今回は以下の AWS CLI コマンドを使用し、 SSM ドキュメントをリスト化します。 list-documents — AWS CLI 2.1.29 Command Reference 先に結論から言うと、 Amazon が所有するドキュメントは 250個以上あります。 一気に出力しても分かりづらいので、まずはどういったドキュメントタイプが用意されているかを確認します。 aws ssm list-documents\ --filters Key=Owner,Va