JMESPath チュートリアルでプロジェクションを理解する | DevelopersIO
渡辺です。 前回に引き続き、AWSCLIのqueryオプションで利用できるJMESPathのチュートリアルを紹介します。 今回のチュートリアルを終わらせると、かなり細かい抽出まで可能になるのでしょう。 プロジェクション（投射） プロジェクション（投射）は、JMESPathのキーとなる機能のひとつです。 イメージしずらいですが、要素をイイ感じにArrayに変換していくことができます。 リストのプロジェクション ワイルドカードを使った[*]はJSONのArrayに投射します。 [ {"first": "James", "last": "d"}, {"first": "Jacob", "last": "e"}, {"missing": "different"}, null ] JMESPath Result
【AWS】小ネタ aws-cliでIAM RoleのTrust Relationship（信頼関係）を表示・更新する | DevelopersIO
はじめに こんにちは植木和樹です。今回はIAM RoleのTrust Relationship（信頼関係）をaws-cliを用いて設定する方法を備忘録としてまとめました。 IAM Roleを使いましょう！ IAM Roleは非常に便利な機能でクラスメソッドでは様々な場面で利用しています。特に複数のAWSアカウントをaws-cliで管理するケースで威力を発揮します。 例えばプロジェクトごとにAWSアカウントを分けている場合、通常であれば各アカウント毎にIAMユーザーを作成して個別にログインしたりアクセスキーを用いてアクセスするかと思います。しかしこの方法だとAWSアカウント と IAMユーザーの掛け算の数だけパスワードやアクセスキーを管理しなければならず、AWSアカウントやユーザー数が増えると煩雑になります。 そこで、マネージメントコンソールを利用する場合はSwitchRoleを、aws-c
Amazon ElastiCache for Redisの通信暗号化とクライアント認証をやってみた | DevelopersIO
2017年10月末のアップデートにより、Amazon ElastiCache for Redis が通信の暗号化とクライアント認証に対応しました。 通信の暗号化(encryption in-transit)を使うと アプリとRedis間の通信(encrypted connections) プライマリ↔レプリカなどのRedis間の通信(encrypted replication) が暗号化されます。 また、Redis の AUTH コマンドによるクライアント認証にも対応したため、認証レベルを強化できます。 これらの機能追加により、個人を特定できる情報(PII)など機密度の高い情報を扱うシステムでAmazon ElastiCache for Redisを導入しやすくなりました。 それでは、実際に使ってみましょう。 なお、同時に機能追加された、保管時の暗号化は次のブログをご確認下さい。 Amaz
ECSでごっつ簡単に機密情報を環境変数に展開できるようになりました！ | DevelopersIO
従来アプリケーション側で必須だった機密情報の復号化が、マネージドな仕組みで実現できるようになりました。 これでついにあんな秘密やこんな秘密をコンテナに渡しやすくなりますね — ポジティブな Tori (@toricls) 2018年11月16日 先日のアップデートで、ECSコンテナ内への機密情報の受け渡しが非常に簡単になりました。 従来は機密情報の展開にアプリケーション側での処理が必要だったものが、マネージドな仕組みで実現可能となっているので、既存ECSユーザーには必見のアップデートとなっております。 参考：AWS Launches Secrets Support for Amazon Elastic Container Service あんなことやこんなこと！？ ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ / 従来の方法の面倒くささ（自前で機密情報を展開していた
Terraform で ElastiCache for Redis を正しく定義する | はったりエンジニアの備忘録
Terraform で ElastiCache for Redis を定義するには少しコツが必要です。社内で間違った定義がコピペされていたので、忘れないようにポイントをまとめておきます。目新しい内容ではなく、ほとんどは公式ドキュメントにちゃんと載っています。 Terraform で ElastiCache for Redis (cluster mode disabled) を定義するには aws_elasticache_cluster と aws_elasticache_replication_group の 2 つのリソースがあります。 基本的には aws_elasticache_replication_group を使えば良いです。 Multi-AZ で可用性を高めるなら number_cache_clusters を 2 以上にして automatic_failover_enable
Amazon RDS Under the Hood: Multi-AZ | Amazon Web Services
Amazon Web Services ブログ Amazon RDS Under the Hood: Multi-AZ Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。 Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-
RDS のメンテナンス時の再起動とフェイルオーバーについて - ablog
RDSのメンテナンス時にDBが再起動されるか？ されるときとされないときがある。 ハードウェアメンテナンス メンテナンスの時期と影響を受けるアベイラビリティーゾーンを含む、スケジュールされたハードウェアメンテナンスウィンドウについての E メール通知を受け取ります。シングル AZ 配置は、ハードウェアのメンテナンス中に、数分間利用できなくなります。アベイラビリティーゾーンがメンテナンスの影響を受けている場合、インスタンスがフェイルオーバーするのにかかる時間 (通常は約 60 秒) の間、マルチ AZ 配置は利用できません。セカンダリアベイラビリティーゾーンのみが影響を受ける場合、フェイルオーバーもダウンタイムもありません。 OS のメンテナンス 次のメンテナンスウィンドウで予定されている OS のメンテナンスは、希望のメンテナンスウィンドウを調整することで延期できます。[Defer Upg
Amazon RDS のメンテナンスにどう立ち向かうべきか
RDS for PostgreSQL にシステムアップデートがやってきましたね。 Upgrade now available for your Amazon RDS PostgreSQL database instances 今回のアップデートは必須なので猶予期間の間に必ず適用する必要があります。 Multi-AZ 構成にしていれば自動的にフェイルオーバーしますが、60 〜 120 秒のダウンタイムは避けれません。 プロダクション環境の RDS で同様のメンテナンスは何度か経験しましたが、オフタイム（主に休日）にメンテナンスを計画しその度にエンジニアが待機していました。当日はメンテナンスに切り替えて見守るだけなのですが、メンテナンス告知など諸々の調整や休日出勤でそれなりの保守コストがかかっています。お客様にも迷惑をかけるしエンジニアにも負担を強いていたのです。 この機会に、実装やアーキテク
【5分でわかる】スペックアップ＆メンテナンス時のRDSの動作
どうもBogartです！ 今回はAWS入門者向けにAmazon RDSのスペックアップやメンテナンス時の動作について、簡単な図で説明していきたいと思います。Multi-AZ構成時の障害発生時の動きは資料としてよく見つかるものの、サービスの拡大によるスペック変更やメンテナンス発生時の動きは文章のみのものが多い印象があったのでまとめてみました。 はじめに ~ 障害発生時の動作 ~ 前提条件としてAmazon RDSのAurora以外のDBエンジンを利用していた場合の説明となります。 Auroraの動きはまた別途改めてご紹介出来ればと思います。 まずおさらいとしてMulti-AZ構成時における障害発生時の動きを図にします。 障害発生時にフェイルオーバーが発生し、フェイルオーバーが実行される1~2分程度のダウンタイムでスレーブがマスターに昇格し、サービス全体の耐障害性を高めます。ただしフェイルバッ
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
Amazon S3 セキュリティベストプラクティスの実践（権限管理のポリシー) – 前編 | Amazon Web Services
Amazon Web Services ブログ Amazon S3 セキュリティベストプラクティスの実践（権限管理のポリシー) – 前編 はじめに AWS では、サービス毎にセキュリティのベストプラクティスを公式ドキュメントとして提供しています。本記事では AWS を利用したシステムのセキュリティの検討や実装に関わる皆様を対象に、AWS の代表的なストレージサービスである Amazon Simple Storage Service (S3) を題材にとりあげて、公式ドキュメントで紹介しているベストプラクティスの実装方法をできるだけ具体的に解説したいと思います。 IT セキュリティにおいては、一つの脆弱性や悪意がセキュリティ事故に直結しないようにシステムを多層的に保護する事が重要です。AWS においても、サービスが提供する機能を適所でご利用いただければ多層化されたセキュリティ保護策を、クラウ
AWSで目指した理想のCI/CDを別視点で考察してみる（データ保護観点） - How elegant the tech world is...!
はじめに 前回のブログでは、マルチアカウントにおけるIAMユーザーの設計戦略についてご紹介しました。 今回は少しテーマを変え、以前筆者がJAWS DAYS 2020で登壇させていただいたCI/CDの内容を基に、データ保護の観点からの設計~実装を取り上げたいと思います。 ※少々お硬い内容を含みますが、AWS CI/CDセキュリティを考える上で一つのポイントになるはずなので、ご興味をお持ちの方は是非お付き合いください。m(_ _)m 前回ご紹介したCI/CD内容のおさらい JAWSDAYS2020にて「金融サービス向けに理想のCI/CDを追い求めたお話」というタイトルで、筆者が担当するサービスのCI/CD設計をご紹介いたしました。 ここで、「理想」という点についてもう一度振り返ると、それは「CI/CD導入により期待すること」と、「業務特性として守らなければならないこと」の両立でした。 高アジリ
Amazon ECS タスクメタデータエンドポイントバージョン 4 - Amazon Elastic Container Service
Amazon ECS コンテナエージェントは、各コンテナに環境変数を注入します。これは、タスクメタデータエンドポイントと呼ばれ、コンテナにさまざまなタスクメタデータと Docker 統計を提供します。 タスクメタデータとネットワークレートの統計は CloudWatch に送信され、 AWS Management Console で表示できます。詳細については、「Container Insights を使用して Amazon ECS コンテナをモニタリングする」を参照してください。 Amazon ECS は、以前のバージョンのタスクメタデータエンドポイントを提供しています。新しいタスクメタデータエンドポイントバージョンを今後作成する必要がないように、追加のメタデータをバージョン 4 の出力に追加できます。既存のメタデータが削除されたり、メタデータのフィールド名が変更されたりすることはありませ
AWS アカウント間の Amazon EventBridge イベントの送受信 - Amazon EventBridge
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS アカウント間の Amazon EventBridge イベントの送受信 EventBridge AWS アカウントのイベントバス間でイベントを送受信するように設定できます。 EventBridge アカウント間でイベントを送受信するように設定すると、 AWS アカウントのイベントバスにイベントを送受信できるアカウントを指定できます。また、イベントバスに関連する特定のルールからのイベントや、特定のソースからのイベントを許可または拒否することもできます。詳細については、「Amazon EventBridge リソースポリシーによるクロスアカウントアクセスの簡素化」を参照してください。 を使用する場合 AWS Organizations、組織を指定して、その組織内
New – Cross-Account Delivery of CloudWatch Events | Amazon Web Services
AWS News Blog New – Cross-Account Delivery of CloudWatch Events CloudWatch Events allow you to track and respond to changes in your AWS resources. You get a near real-time stream of events that you can route to one or more targets (AWS Lambda functions, Amazon Kinesis streams, Amazon SNS topics, and more) using rules. The events that are generated depend on the particular AWS service. For example,
IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 - AWS Identity and Access Management
このチュートリアルでは、ロールを使用して、お客様が所有する作成および開発という異なる AWS アカウント のリソースへのアクセスを委任する方法について説明します。特定のアカウントにあるリソースを別のアカウントのユーザーと共有します。このようにクロスアカウントアクセスを設定することで、お客様はアカウントごとに IAM ユーザーを作成する必要がなくなります。また、ユーザーは、異なる AWS アカウント のアカウントのリソースにアクセスするために、あるアカウントからサインアウトして別のアカウントにサインインする必要がなくなります。ロールを設定した後、AWS Management Console、AWS CLI、API からロールを使用する方法について説明します。 IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。たとえば、標準 aws パ
CloudTrail のログに何かされたら気づける仕組みを考えた - sorta kinda...
令和元年もよろしくお願いします。那須です。 久々に AWS の普段気にしないことの勉強をしています。 普段気にしない AWS サービスといえば、やっぱり CloudTrail ですよね？ CloudTrail のドキュメントを改めて読み返していたら、↓こんなドキュメントを見つけました。 docs.aws.amazon.com ログを S3 や CloudWatch Logs に書き込めるのはご存知だと思いますが、その出力されたログがそもそも改ざんされない前提で運用されてませんか？ 私はそうしてました。 今回は、CloudTrail のログが改ざんされたり削除されたりした場合に気づける仕組みを考えてみましょう。 CloudTrail ログファイルの整合性チェックスクリプト このためだけに EC2 インスタンスを起動するのもちょっと違うなーと思うので、Lambda で動くようにしてみました。
Webhook を使用して Amazon SNS メッセージをパブリッシュする
Webhook を使用して Amazon SNS メッセージを Amazon Chime、Slack、または Microsoft Teams にパブリッシュする方法を教えてください。 Webhook を使って、AWS 環境を Amazon Chime チャットルームや Slack チャンネル、Microsoft Teams チャンネルに接続しようと思います。Amazon Simple Notification Service (Amazon SNS) から Webhook に通知を送信する方法を教えてください。 簡単な説明 Amazon SNS を使用して Webhook URL などの通知メッセージを HTTP エンドポイントまたは HTTPS エンドポイントに送信することができます。ただし、一部の Webhook では HTTP サブスクリプションまたは HTTPS サブスクリプション
【新機能】WorkSpacesのログインイベントのトラッキングが可能になりました | DevelopersIO
大栗です。 WorkSpacesでログインイベントのトラッキングが可能になりました。早速試してみます。 Amazon WorkSpaces now lets you track login events using Amazon CloudWatch Events WorkSpacesのログインイベント WorkSpacesでは今までCloudTrailを経由したCloudWatch Eventsでイベント通知が可能でした。しかし、CloudTrailの情報はWorkSpacesのAWS APIの呼び出し情報であるため、WorkSpacesを使用しているエンドユーザの利用状態については取得することができませんでした。 今回ログインイベントがCloudWatch Eventsでサポートされたので、各エンドユーザのログイン状況が分かるようになりました。ただし今回サポートされたイベントはログイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20190130 AWS Black Belt Online Seminar AWS Identity and Access Management (AWS IAM) Part2
