TypeScriptのAWS CDKで設定値（Config）を渡す実装方法を考えてみた | DevelopersIO
AWS CDKではシステム環境（dev,stg,prdなど）の環境ごとに設定値を切り替える方法が何パターンかありますよね。今回TypeScriptを使う際にできるだけ型の恩恵を受ける実装パターンを考えてみました。 こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。 AWS CDKを使う時の設定値（Config）の渡し方に迷ったことはありませんか？ 私は何度もあります。 以下記事では弊社の佐藤が設定値の渡し方について2つの方法を提示してくれています。 私としても2. 外部ファイルの利用(TSファイル)による方法に以下のようなメリットを感じています。 TypeScriptの型の恩恵を受けることができる プログラミング言語によるインフラのプロビジョニングができるAWS CDKにおいて、TSファイルを使う方法は相性が良い（と私は思っています） アプリケ
Amazon VPCのサブネットマスクを確認するAWS Configカスタムルールを作成してみた | DevelopersIO
Amazon VPC における IPv4 アドレスのサブネットマスクの設定がルール化されている環境を想定して、サブネットマスクをチェックする AWS Config カスタムルールを作成してみました。VPC とサブネットのサブネットマスクをチェックします。 Guard を使用した Config カスタムルールの基本的な内容については次のブログが参考になります。 やってみた Guard を使用した AWS Config カスタムルールで次の内容をチェックしてみます。あまりない状況かもしれませんが、気になったのでサブネットのチェックも試してみます。 VPC IPv4 のサブネットマスクが/16であること IPv6 の割り当てがないこと サブネット IPv4 のサブネットマスクが/24であること IPv6 の割り当てがないこと VPC のチェック 1 つの例として、次の Guard ルールでサブネ
Organizations環境でConfigルールを展開する方法を確認してみた | DevelopersIO
確認してみた 前提条件 前提条件として、以下の設定は事前に行っています。 各アカウントでのConfig有効化 Organizationsの信頼されたアクセスの有効化 CloudFormation StackSets : AWS Organizations で信頼されたアクセスを有効にします。 - AWS CloudFormation Config : aws organizations enable-aws-service-access --service-principal config-multiaccountsetup.amazonaws.comの実行 CloudFormation StackSets CloudFormation StackSetsで展開する場合、ConfigルールをCloudFormationで設定する必要があります。 Configマネージドルールの場合AWSでC
AWS CLI を使用して、AWS Config が有効化されているリージョンを確認する方法を教えてください | DevelopersIO
困っていた内容 AWS Config を利用して AWS リソースの設定をモニタリングおよび記録してます。 しかし、AWS Config のベストプラクティス である全リージョンを有効化せず運用上やむを得ず、「有効化されているリージョン」と「有効化されていないリージョン」があります。 マネジメントコンソール上で有効化するべき対象リージョンを定期的にリージョン毎、確認作業を実施していますが時間も掛かり、確認ミスがあるのではと常に懸念しています。 上記について何か良い簡単な確認方法はないでしょうか。 どう対応すればいいの? AWS Config については以下の記載がございます。 AWS Config では、設定レコーダーを使用してリソースの設定変更を検出し、これらの変更を設定項目として取り込みます。AWS Config でリソースの設定を追跡する前に、設定レコーダーを作成する必要があります。
AWS Config 設定レコーダーと配信チャネル をCloudFormation で削除する | DevelopersIO
既存のアカウントをAWS Control Tower に登録する場合、事前にいくつかの作業が必要になります。 その中で、AWS Config 設定レコーダーまたは配信チャネルを削除する事が推奨されています。 登録する既存のアカウントにログイン可能な場合は該当のアカウントのCloudShellなどから CLIで削除する方法などもあり実施等が本ブログでも紹介されています。 コンソールから消せないConfigを全リージョンCLIから無効化する コンソールから消せないConfigを全リージョンCLIから無効化する 今回、手動の処理を挟まずAWS Config 設定レコーダーと配信チャネルを削除する必要があったため CloudFormationで実施できるようにCloudFromationのカスタムリソースで作成いたしましたので共有します。 また、既存のアカウントで、AWS Configを止める事が
Configルールを使ってパブリックアクセスが有効になっているRDSのDBインスタンスを自動修復する | DevelopersIO
はじめに AWS Configはリソース構成を記録・管理するサービスで、Config ルールでは管理しているリソースの評価ができます。その条件に違反しているリソースは非準拠としてフラグをつけられます。 Config ルールにはこの違反した非準拠のリソースに対して「修復」のアクションを定義でき、想定したリソースの状態へと自動修復する機能があります。 今回は パブリックアクセス可能なRDSインスタンスを自動で修復する(パブリックアクセスを無効にする) Configルールを作成してみました。 CloudFormationテンプレート StackSetsでマルチリージョン・マルチアカウントに展開できるよう、CloudFormationテンプレートで作成しました。 作成するリソース IAMロール 自動修復実行用 Configルール 修復アクション SSMドキュメント AWS提供のドキュメントではなく
Elastic Beanstalkに適用したキーペアを解除したいのですが、どうすれば解除出来ますか？ | DevelopersIO
困っていた内容 Elastic Beanstalkの環境において、キーペアの設定を行いました。 再度「キーペアをなにも適用していない」状態に戻したいのですが、 EBコンソール上からは「キーペアをなにも適用していない」状態にすることが出来ませんでした。 設定前の状況にするにはどのような操作が必要か教えてください。 どう対応すればいいの? コマンドラインオプションを使用する - JSON ドキュメントで設定オプションを変更するには (AWS CLI)を参考に、キーペアを削除する場合は以下のようにCLIコマンドを実行してください。 aws elasticbeanstalk update-environment --environment-name --options-to-remove Namespace=aws:autoscaling:launchconfiguration,OptionNam
使用していないセキュリティグループをAWS Configの自動修復アクションで自動的に断捨離してみた | DevelopersIO
みなさんは「検証だから」と自分に言い聞かせて雑に作ったセキュリティグループがどんどん、どんどん増えて、次第に消すのも面倒くさいと思うくらいにどうしようもなくなったことありませんか？ 私はあります。まさに今そういうお気持ちです。 「launch-wizard-20」 「launch-wizard-21..」 「launch-wizard-22....」 我ながらヒドい。 なんやかんやでセキュリティグループが95個もありましたが、ほとんど使っていない状態です。 今回はこの使ってないセキュリティグループをサクッと断捨離してしまおう！という手順のご紹介です。 先に3行まとめ AWS Configのマネージドルールで使われてないセキュリティグループを検出 AWS マネージドの修復アクションを使って自動修復（セキュリティグループA削除） 削除対象はEC2で使用されてないセキュリティグループになるので、
AWS CLI のコンフィグファイルと環境変数とコマンドラインオプションで指定できる内容をまとめて確認してみた | DevelopersIO
コンバンハ、千葉（幸）です。 ~/.aws/config、いじってますか？ ~/.aws/configの例 [default] region = ap-northeast-1 output = json [profile chiba] region = ap-northeast-1 output = json role_arn = arn:aws:iam::999999999999:role/chibayuki-role source_profile = jump-account mfa_serial = arn:aws:iam::000000000000:mfa/cm-chiba.yukihiro ~/.aws/configでデフォルトリージョンや出力形式、スイッチロールのための設定などを行う機会は多いかと思います。ここで設定可能な項目は他にもたくさんあり、その数は30個以上にのぼります
デフォルトセキュリティグループを自動で無効化する | DevelopersIO
デフォルトセキュリティグループを通信できる状態にしておくことは推奨されていません(チェック項目一覧（CIS v1.2.0） – insightwatchサポート)。 今回は自動で同一リージョン内のすべてのデフォルトセキュリティグループを無効化したいと思います。無効化はインバウンド、アウトバウンドのルールを全て削除することを意味します。 概要 AWS Configのマネージドルールであるvpc-default-security-group-closedを使用して、準拠していないデフォルトセキュリティグループを検知します。このルールでは下記の内容に違反しているかどうかが評価されます。 いずれの Amazon Virtual Private Cloud (VPC) のデフォルトのセキュリティグループでもインバウンドとアウトバウンドのいずれのトラフィックも許可しないことを確認します。 vpc-de
VPCのIPv4 CIDRブロック設定値をAWS Configのカスタムルールでチェックする | DevelopersIO
いわさです。 先日、VPCのIPv4 CIDRブロックへ設定する値を制限や統制する方法がないかと考えていたときに、AWS Configを使ってみようかと思いつきました。 そこでまずはConfigのカスタムルールを作成しVPCのCIDRをチェック出来るか確認してみることにしました。 Configは有効化する まずは、Configを有効化します。これをしないと始まらないので。 有効化の際に、VPCを監視対象リソースに指定することを忘れないようにします。 有効化したら、新規VPCを作成してみます。 少し時間がかかりますがタイムラインにイベントが表示されると思います。 履歴が表示されるようになったら、get-resource-config-historyコマンドを使って、イベント情報を取得しましょう。 後ほどLambda関数でオブジェクトにアクセスしますので構造を知っておく必要があります。 [cl
【AWS Config】EC2インスタンスに特定アプリケーションがインストールされているかチェックして通知する | DevelopersIO
はじめに 上記のように、EC2インスタンスに特定アプリケーションがインストールされているかどうかチェックを行い、 必要に応じて通知を行う仕組みを作りたいです。 これを実現するための仕組みを作って、試してみます(検証用 EC2インスタンスとして Amazon Linux 2を使用)。 先にまとめますが、以下のような構成図になります。 前提知識 前述の構成図の各要素説明します。 「インストールされているアプリケーション情報を収集する」ために必要なサービス この部分の説明をします。 主に AWS Systems Manager(SSM) の機能を活用します。 SSMは AWS環境の運用管理のために役立つ多種多様なサービス群の総称です。 SSMでできることはとっても多いので、今回使用するサービスに絞って説明します。 EC2インスタンスや オンプレミスサーバに SSMエージェント をインストールする
Config ルール・自動修復を使ってS3全バケットのデフォルト暗号化を自動的に有効化する | DevelopersIO
AWS Config は AWSリソースの構成を記録、管理するためのサービスです。 EC2インスタンスやセキュリティグループなど、AWSリソースが「いつ、どのような変更がされたか」 の履歴を記録してくれます。 また、 AWS Config ルール を利用して AWSリソースの構成の評価ができます。 AWSリソースのあるべき構成を条件としています。条件に違反しているリソースが検出されると 「非準拠」フラグが付けられます。 さらに、この「非準拠」リソースを 修復 することもできます。 "AWS Systems Manager オートメーション(SSM オートメーション)" という自動化を行うためのワークフローと連携して、 「非準拠」リソースが見つかれば SSMオートメーションを使ってあるべき構成へ自動修復する、便利な自動化が実現できます。 本記事では S3の全バケットのデフォルト暗号化を自動的
特定のIPセットが登録されたWebACLを抽出したいときはAWS Configの高度なクエリを使おう | DevelopersIO
こんにちは、岩城です。 AWS WAFのIPセットを削除しようとした際、WebACLに関連付けられているため削除できないことを示す以下メッセージが出力されました。 AWS WAF couldn’t perform the operation because your resource is being used by another resource or it’s associated with another resource. これを解決するには、当該IPセットを利用したルールが関連付けられたWebACLを特定し、そのルールを削除する必要があります。WebACLやそれに関連するルールの数が少なければ、マネジメントコンソールで1つずつ確認すれば良いかも知れません。ところが、数が多いと手動で確認するのは辛いです。 マネジメントコンソールやCLIなど調べましたが、現状AWS WAF独自の機
[アップデート] AWS Config 適合パックでプロセスチェックルールをデプロイできるようになりました | DevelopersIO
コンバンハ、千葉（幸）です。 AWS Config 適合パックにより、手動でのプロセスチェックを行うルールをデプロイできるようになりました！ Introducing process check rules with AWS Config conformance packs 自動的に準拠状況を確認できない非リソースに対する確認項目についても、Config ルールの一つとして管理できるようになりました。 何が変わったのか AWS Config 適合パックは、 Config ルールと修復アクションをテンプレートで定義し、一括で管理できる仕組みです。 デプロイされたルールにより各種リソースに対して評価が行われ、準拠状態にあるかどうかが判断されます。 ルールが何を基準に評価を行うかは、ソースルールとして設定したものにより決定されます。ソースルールには AWS マネジードルールかカスタムルール（ カス
CloudWatch Logsの保持期間をAWS Configでチェックして自動設定する | DevelopersIO
CloudWatch Logsは様々なログを格納することができて便利ですが、デフォルトでは保持期間が設定されません。 無駄なコストを抑えるために保持期間を「AWS Config」でチェックして、保持期間が設定されていなければ通知＆自動設定してみたいと思います。 AWS Configのルール作成 最初にAWS Configのコンソールから、CloudWatch Logsの保持期間をチェックするルールを作成します。 ログの保持期間をチェックするルールはAWSから提供されています。 検索ボックスで「cw-loggroup」などで検索して、該当のルール「cw-loggroup-retention-period-check」を選択してください。 必要に応じて名前や、トリガー、パラメーターを設定してください。トリガーの頻度（チェックする間隔）は「1時間」「3時間」「6時間」「12時間」「24時間」から
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Config best practices | Amazon Web Services