CreationPolicy 属性をリソースに関連付けて、AWS CloudFormation が指定数の成功シグナルを受信するかまたはタイムアウト期間が超過するまでは、ステータスが作成完了にならないようにします。リソースにシグナルを送るには、cfn-signal ヘルパースクリプトまたは SignalResource API を使用します。CloudFormation は、送信されたシグナル数を追跡できるように、有効なシグナルをスタックイベントにパブリッシュします。 作成ポリシーは、CloudFormation が関連するリソースを作成するときのみ実行されます。現在、作成ポリシーをサポートしているリソースは CloudFormation のみです。 スタックの作成に進む前にリソース構成アクションを待機する場合は、CreationPolicy 属性を使用します。たとえば、EC2 インスタン
一言で言うと 子スタックのチェンジセットが操作しづらい ので使いづらい。 いろいろ検索してみたけど日本語の結果が出てこなかったので検索用メモとして。 （こういうときにつけるタグってなんだろう。。。） nested stack1 とは ネストされたスタックは、他のスタックの一部として作成されたスタックです。 複数のスタックを連携させる方法としては出力値を用いたクロススタック参照2などもあるが、それよりももっと直接にスタックの親子関係を構築する仕組み。 使用例 以下のような複数のテンプレートがあるときに、 parent.yaml に対して aws cloudformation package を実行する package処理結果のyamlに対して aws cloudformation deploy を実行する という手順を踏むことで、子テンプレートの内容を含めてまとめて parent.yaml
大栗です。 CloudFormationはAWSインフラのオーケストレーションを担っており、Infrastructure as Codeで構成のバージョン管理ができる素晴らしいサービスです。しかし大きな難点がありました。それはCloudFormation外の変更を認識しないことで、テンプレートの変更時に意図しない環境になることでした。今回のアップデートでCloudFormation外の変更（ドリフト）も検出可能になり、その様な問題発生を抑止できるようになりましたのでレポートします。 New – CloudFormation Drift Detection AWS CloudFormation Now Supports Drift Detection Announcement: Introducing AWS CloudFormation Drift Detection! Detect ch
こんにちわ。大阪の市田です。 先日、CloudFormationのアップデートがあり、新たにクロスアカウントのVPCピアリング作成がサポートされました。 下記でウォークスルーが公開されていますので、今回はこちらの内容を元に試してみたいと思います。 Walkthrough: Peer with an Amazon VPC in Another AWS Account 手順 事前にピアリングをリクエストするリクエスターと、リクエストを受けるアクセプターのAWSアカウントを用意しておきましょう。 ウォークスルーではCloudFormationのサンプルが記載されています。その内容は以下の通りです。 1つ目のCloudFormationをアクセプター側で実行すると、下記のリソースが作成されます。 10.1.0.0/16のVPC クロスアカウント用のIAMロール テンプレートではアクセプター側のIA
困っていた内容 オリジンを S3 として CloudFront を使用している。 存在しないオブジェクトにアクセスすると HTTP ステータスコード 403 Forbidden が返ってきてしまう。 これを、HTTP ステータスコード 404 Not Found を返すようにしたい。 どう対応すればいいの？ オリジンとして設定している S3 のバケットポリシーに、s3:ListBucket アクションを許可する設定を追加します。 また、Resource 句にバケットのルートを追加します。 設定前 { "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 CodePipeline の概念 で使用される概念と用語を理解すれば、自動リリースプロセスのモデリングと設定が簡単になります AWS CodePipeline。を使用する際に知っておくべき概念をいくつか紹介します CodePipeline。 DevOps パイプラインの例については、「」を参照してくださいDevOps パイプラインの例。 では、次の用語が使用されます CodePipeline。 パイプライン パイプラインは、ソフトウェアの変更がリリースプロセスをどのように通過するかを記述するワークフロー構造です。各パイプラインは一連のステージで構成されています。 ステージ ステージは、環境を分離し、その環境での同時変更の数を制限するために使用できる論理ユニットです。
こんにちは、大前です。 久々に AWS MediaServices 以外の記事を書く気がします。 今回は、掲題のアップデートの紹介です。 Amazon EC2 Auto Scaling now supports Instance Refresh within Auto Scaling Groups どんなアップデートか Amazon EC2 Auto Scaling（以下 Auto Scaling）にて Auto Scaling Group 内のインスタンスを最新化する事が出来るようになりました。 今まで、 Auto Scaling Group の起動設定を変更（例えば、AMIの更新など）した後に既存のインスタンスを最新化するには一手間が必要だったりしたのですが、今回追加されたこの機能を使用するだけで、最新の起動設定で起動されたインスタンスに置き換える事が可能となりました。 今まで痒かった
AWS のクロスアカウント・オペレーションを楽にする地味なアップデートが AWS CLI にきました。 tl;dr [dst-role] role_arn = arn:aws:iam::123456789012:role/some-role credential_source=Ec2InstanceMetadata というようにクレデンシャル設定($HOME/.aws/credentials)の credential_source に Ec2InstanceMetadata を指定するだけで、インスタンスプロファイルから対象アカウントの IAM Role を assume 出来るようになりました。 ユースケース 特定のサーバーから複数のAWSアカウントのリソースを操作する事を考えます。 操作先の各 AWS アカウントに IAM クレデンシャルを発行すると、アカウントが増えた時のクレデンシャ
Host dev01 HostName i-xxxxxxxxxxxxxxxxx ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" Host web01 HostName i-xxxxxxxxxxxxxxxxx ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" #!/usr/bin/python import sys import subprocess import argparse from boto3.sessio
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのホスト名を変更しましたが、インスタンスを再起動、または停止してから起動すると、ホスト名が元のホスト名に戻ってしまいます。 簡単な説明 EC2インスタンスを再起動したり、停止してから起動したりしてもホスト名を維持するには、そのインスタンスに該当する設定ファイルにホスト名を追加します。 **注:**次の手順は RHEL 7、8、9と CentOS 7、8、9に適用されます。他のディストリビューションについては、後述のリソースを参照してください。 システムホスト名の変更 RHEL 5、 6、CentOS 5、 6、または Amazon Linux を実行している Amazon EC2 インスタンスに静的ホスト名を割り当てるにはどうすればよいですか? SLES を実行している Amazon EC2イン
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon EBS ボリュームを使用できるようにする Amazon EBS ボリュームをインスタンスにアタッチすると、ブロックデバイスとして公開されます。任意のファイルシステムでボリュームをフォーマットし、マウントできます。EBS ボリュームを使用できるようにすると、他のボリュームと同じようにアクセスできます。このファイルシステムに書き込まれるデータはすべて EBS ボリュームに書き込まれますが、デバイスを使用するアプリケーションには透過的になります。 EBS ボリュームのスナップショットは、バックアップ目的で作成したり、別のボリュームを作成する際のベースラインとして使用したりできます。詳細については、「Amazon EBS スナップショット」を参照してください。
大阪オフィスのYui(@MayForBlue)です。 S3+CloudFrontの構成で静的サイトを構築していてハマったところがあったので書き留めておきたいと思います。 CloudFrontのURLにアクセスしてもS3のURLにリダイレクトされる S3+CloudFrontの構成で静的サイトをホスティングしたのですが、CloudFrontで指定したドメインにアクセスしてもS3のオブジェクト自体のURLにリダイレクトされてしまう現象になりました。（今回はS3をオリジンサーバに設定して構築しました。） 例えば https://example.com/sample.html （CloudFrontで指定したドメイン） にアクセスしても https://example.s3.amazonaws.com/sample.html （S3のオブジェクトURL） にリダイレクトされてしまう状態です。 色々
よく訓練されたアップル信者、都元です。年末に Fitbit Alta HR を買いました。 睡眠や心拍がほぼ24時間体制でトラッキングされるって面白いですね。え？ アップルウォッうわなにをする はじめに さて、S3 + CloudFront で静的コンテンツ配信をしよう、というのはもう今さら言うまでもない鉄板構成だと思います。かつてAWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む）でご紹介した「横綱」パターンですね。 公開サイトとして、この構成を雑に作る場合 CloudFront を介して配信するということは基本的に公開サイトとして配信するユースケースが多いと思います。 つまり、原則としてはみんな CloudFront を介してコンテンツにアクセスして欲しいのですが、最悪 S3 に直接アクセスしてコンテンツを読まれたとしてもセキュリティ上は問題ない、ということです。 こ
CloudFormationで非クラスターモード（マルチAZ)の構成を試してみた。 プライマリーノード：1、リードレプリカ：2の3ノード構成でプライベートなVPCに配置する想定。 最終的には下記の公式ドキュメントのサンプルオペレーションをCloudFormation対応した感じ。 docs.aws.amazon.com 次のオペレーションでは、3 つのノード、1 つのプライマリ、2 つのレプリカを持つ Redis (クラスターモードが無効) レプリケーショングループ new-group を作成します。 一部抜粋だけどこんな感じになった。 ECacheSecurityGroup: Type: "AWS::EC2::SecurityGroup" Properties: GroupName: !Ref ECacheSecurityGroupName GroupDescription: Secur
コスト最適化のご相談をいただくなかで、NAT Gateway に不要なコストが掛かっているパターンが多くみられます。また、そのような環境に限って NAT Gateway にかなりのコストが掛かっていることを把握されていないケースも少なくありません。 今回は見落としがちな NAT Gateway で無駄なコストが発生してしまうケース、何処へのアクセスで NAT Gateway を浪費してるかを確認する方法、そしてどのような改善パターンがあるかをご紹介します。 （本記事中で記載の価格はいずれも、執筆時点の東京リージョン価格を参考にしています） 目次 よくある構成 NAT Gateway に関わる料金のおさらい NAT Gateway 料金 AWS データ転送料金 実際の料金例 何が NAT Gateway を使ってるのか見当がつかない データ通信の方向を確認 VPC フローログから NAT G
スタックでドリフト検出オペレーションを実行すると、スタックが予想されるテンプレート構成からドリフトしたかどうかが判断され、ドリフト検出をサポートするスタック内の各リソースのドリフトステータスに関する詳細情報が返されます。 AWS Management Console を使用してスタック全体のドリフトを検出するにはhttps://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソール を開きます。 スタックのリストから、ドリフト検出を実行するスタックを選択します。スタックの詳細ペインで、[Stack actions (スタックアクション)] を選択し、[Detect drift (ドリフトの検出)] を選択します。 CloudFormation により、選択されたスタックに対してドリフト検出が開始されたことを示す情報バ
これずっと今まで疑問に思っててログインする度にリージョン切り替えてたんですが、くそ簡単な方法でデフォルトリージョンを指定することができました。例えば、ぼくは主にアイルランドリージョンを使っているので、アイルランドリージョンをデフォルトにしたいです。 その時は https://console.aws.amazon.com/console/home?region=eu-west-1 とログインする前のURLに?region=eu-west-1とデフォルトにしたいリージョンをつければいいだけでした。 東京リージョンなら?ap-northeast-1ですね。 1日1回ログインするとすると年間コスト15分程度の削減ですが、ストレス軽減になりそうです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く