コンバンハ、千葉（幸）です。 Xvoucherは学習や資格認定プログラム販売のプラットフォーマーです。AWS認定試験バウチャーのAWS認定再販業者およびディストリビューターでもあります。 Xvoucherのビジネスアカウントを作成することで、組織としてAWS認定試験バウチャーの購入や配布を行えます。 今回は以下のページの記載に則り、ビジネスアカウントを作成してみました。 Xvoucherのビジネスアカウントを作成するとは 今回やりたいことを説明するために、簡単にXvoucherの関連用語を押さえておきます。簡単に言うと、以下のイメージです。 Xvoucherでは人に紐づくアカウントを作成できます。人に紐づくアカウントでは大まかに以下2種の役割があります。 Customer（顧客）: 平たく言うとバウチャーの管理者 Candidate（候補者） : 平たく言うとバウチャーの利用者 ビジネスア

コンバンハ、千葉（幸）です。 みなさん、Amazon Athena（以降 Athena） 、使ってますか？ Athena を利用すれば Amazon S3（以降 S3） 上のデータに対してクエリを実行できます。S3 バケット上に出力された各種ログに対して Athena でクエリをかけて必要な情報を取得する、というのはよくある使い方です。 最近 S3 バケット上の AWS CloudTrail（以降 CloudTrail）ログを Atena でクエリしたい機会がありました。 「Athena ってデータをスキャンした量に応じて課金されるよな。1 TB スキャンして 5 USD くらいの料金だったよな。」という理解でいたので、1 USD もかからないくらいの料金でおさまるだろうと踏んでいました。 結果、15回強のクエリを行って約 20 USD のコストが発生しました。 スキャン量だけを気にするの

インターネットゲートウェイ、NAT ゲートウェイは IPv4 向けに用いるものと同じコンポーネントであり、（ゲートウェイそのものとしては）IPv6 向けに独自の設定変更をする必要もありません。 2種のインターネットゲートウェイの構成イメージは以下の通り。 NAT ゲートウェイの IPv6 向けの構成イメージは以下の通りです。 4. IPv6 on VPCへのインバウンド VPC 上の IPv6 リソースへ外部のクライアントが接続することを考えた場合、大前提としてクライアント側で IPv6 に対応している必要がある VPC 上での IPv6 を持つ主要なリソースのうち、「IPv6のみ」に対応しているのは限定されたもののみ 上記2点を踏まえると、VPC 上のリソースで外部向けのサービスを公開しているのであれば、「IPv6のみ」の構成を取るのはハードルが高い。 IPv4も共存させる必要がある 2

AWS STS のサービスエンドポイントとしてグローバルエンドポイントとリージョナルエンドポイントがあります。デフォルトではグローバルエンドポイントが使用されますが、リージョナルエンドポイントの使用が推奨されています。一体それはどういうことなのか、整理してみます。 コンバンハ、千葉（幸）です。 AWS Security Token Service (STS) は、一時的な認証情報を提供するサービスです。 AWS STS に対して一時的な認証情報払い出しのリクエストを行う際、リクエスト先となる AWS サービスエンドポイントには以下の2種類があります。 グローバルエンドポイント リージョナルエンドポイント デフォルトでは前者のグローバルエンドポイントが使用されるものの、後者のリージョナルエンドポイントの利用を推奨する、という記述が各種ドキュメントにあります。 👇 デフォルトでは、AWS S

コンバンハ、千葉（幸）です。 当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の33日目のエントリです。 このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合いいただければ幸いです。 では、さっそくいってみましょう。今回のテーマは『AWS Identity and Access Management (IAM) Access Analyze

上記の要素から構成される ARN の例は以下です。 EC2 インスタンス：arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abcdef1234567890 VPC：arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0e9801d129EXAMPLE IAM ユーザー：arn:aws:iam::123456789012:user/johndoe ※ awsパーティションの IAM のリソースの ARN にはリージョンコードが含まれません AWS リソースは ARN によって全世界の中で一意に特定できる、ということを覚えておきましょう。 参考：Amazon リソースネーム (ARN) - AWS Identity and Access Management AWS リソースへのアクセスとは ここでの A

Mac のメモアプリのメモを iCloud 上に保存していたのですが、Google アカウント上に移してみたくなりました。手順はシンプルなものの少し迷ったのでまとめておきます。 コンバンハ、千葉（幸）です。 Mac 標準のメモアプリでは、メモをローカルにもクラウド上（iCloudやGoogleアカウントなど）にも保存できます。メモをローカルでなくクラウド上に保存することによって、複数端末での利用や端末の入れ替え時に同期が容易、というメリットがあります。 一方で、業務利用の端末の場合、データの保存先が制限されるケースもあるでしょう。今回は、iCloud の利用が制限を受けることを想定し、iCloud上に保存していたメモをGoogleアカウントに移動する機会がありましたのでその手順をまとめておきます。 今回やりたいこと 簡単に言うと、やりたいことはこうです。 メモアプリに iCloud のみが

コンバンハ、千葉（幸）です。 Savings Plans（以下 SP）は、1年か3年の一定期間の利用をコミットすることで割引を受けられる仕組みです。EC2 インスタンスや Fargate、Lambda 関数などが対象になります。 SP の購入時には「タイプ」や「リージョン」、「コミット額」などいくつかのパラメータを指定することになります。金額も大きくなりがちなため、うっかり誤った内容で購入すると悲しいことになります。 今回のアップデートにより、購入から7日以内であれば返品（実質的な購入のキャンセル）をできるようになりました。 とはいえいくつか条件はあり、無条件に返品できるわけではないので注意してください。 このブログでは、SP の返品機能の詳細のまとめと、実際に SP の購入→返品を試してみた内容を記します。 Savings Plans の返品についてまとめ 原則、購入から7日間以内の S

コンバンハ、千葉（幸）です。 DevelopersIO、みなさん読んでますか？わたしは読んでます。（そしてたまに、書いてます。） DevelopersIO は（主に）技術的な内容が記載された「やってみたブログ」です。ブログなので、基本的には一度きり、一方向の情報発信です。そんなブログ記事について、書いた本人がもう少し深掘りして話してみよう、という勉強会が立ち上がりました。 DevelopersIO や Zenn を運営しているクラスメソッドのエンジニアが、ブログ記事を書いた本人が解説をするオンラインの勉強会です。ブログを書いた当時の背景や、記事の深掘りなどを行います。 いつもは読むしかできないブログに直接質問を投げかけていただき、それをもとにディスカッションなどができればと考えています。ご興味のあるテーマの際はぜひ参加ください。 この勉強会は今後も継続開催されていく予定です。今回は第一弾と

コンバンハ、IAMロール *1です。 わたしは IAM ロールが好きです。EC2 もそこそこ好きです。そんな中、OpsJAWS Meetup#27 EC2の運用と監視が開催されました。 Ops な皆さん、こんにちは！ EC2 使ってますか？使っていますよね。誰もが使ったことがある基本的なサービスですし、今でも活躍の場は多いと思います。 EC2 の運用と監視について改めて学び直します。 EC2 がテーマのようです。EC2 がテーマなのですが、わたしはどうしても IAM ロールの話がしたいです。 EC2、運用……と言えば Systems Manager…… Systems Manager でノード管理するには SSM エージェントが必要…… SSM エージェントが AWS API を実行するには IAM ロールの権限が必要！ …… よし、繋がった！ ということで、「SSMエージェントはIAMロ

これらのアクションを Lambda や CodeBuild、Event Bridge と組み合わせたシナリオも学べます。全体のアーキテクチャ図のイメージは以下です。 （https://github.com/aws-samples/aws-iam-refining-policy-permissionsより引用） ワークショップの流れ 大きく以下の 3つに分けられます。 AWS CLI でのコマンドの実行 シナリオ1. 中央セキュリティチーム シナリオ2. DevOps エンジニア 2,3 は以下のレポジトリから関連リソースをデプロイする必要があります。 Deployment using AWS CDK v2 Clone this repository Install AWS CLI v2 Install Python 3.11 Install AWS CDK Install Docker D

コンソールだと「秒」って表示されてるけど実際は「マイクロ秒」だったりしない？と気になったことがあったので確認しました。 コンバンハ、千葉（幸）です。 AWS マネジメントコンソールの CloudWatch 画面でメトリクスをグラフ描画する場合、単位（Unit）を自動的に表示してくれます。 例えば以下のような形です。（ここではSeconds（秒）と表示。グラフの上限は10） ここで、グラフ描画しているメトリクスSuccessfulReadRequestLatencyのUnit はMicrosecondsであるとドキュメントに記載されています。（2024/02/20時点。） Serverless cache metrics - Amazon ElastiCache 10,000,000 マイクロ秒を 10 秒に変換して表示してくれていることを期待しますが、もしかして 10 マイクロ秒を表してい

コンバンハ、千葉（幸）です。 CloudTrail 証跡でデータイベントを記録する際に、対象のリソースを限定できます。 S3 のデータイベントを記録する場合は、S3 バケットを限定できます。さらに、バケットの中のプレフィックスまで限定できます。 ここで、指定するプレフィックスの末尾は/で区切られている必要があるのかが気になりました。別の言い方をすると、/で区切られた階層を「フォルダ」と呼ぶとしたときに、同一フォルダ内の同じ接頭辞を持つファイルおよび子フォルダをまとめて指定できるのかが気になりました。 具体例を出すと、以下のオブジェクトがある場合にプレフィックスとしてhoge/test（末尾に/が含まれない）を指定すると、どのオブジェクトが記録対象になるのかを知りたいです。 % aws s3 ls chibayuki-prefix-test --recursive 2024-02-19 18

Backlog の Wiki 一覧を表示するコマンドの確認と、Wiki の添付ファイルを一括出力する Bash スクリプトの作成をやってみました。 コンバンハ、千葉（幸）です。 Backlog では Wiki を利用できます。Wiki は階層構造を取ることができ、Backlog 画面の右側で以下のように構造を確認できます。 階層構造は折りたたまれて表現されているため、全量を確認するにはそれぞれを展開して確認が必要です。もっと手軽に全体構造を把握したいと考えました。 また、Wiki にはファイルを添付できます。あらかじめアップロードされた「共有ファイル」へのリンクを張るのとは別に、Wiki ページ自体にファイルを添付できます。 プランによって保存できる容量に上限があることもあり、添付ファイルのデータ容量を気にする機会があるかと思います。Wiki の個別のページを1つずつ添付ファイルを確認して

コンバンハ、千葉（幸）です。 Backlog では ファイル を利用できます。ここでの「ファイル」を、課題や WIki への添付ファイルと区別するために、以降は共有ファイルと呼びます。 共有ファイルとして保存したデータは、Backlog画面の「ファイル」から確認したり、課題や WIki からリンクできます。 プランによって保存できる容量に上限があることもあり、共有ファイルのデータ容量を気にする機会があるかと思います。Backlog 画面から都度ディレクトリを深掘って確認していくのは手間がかかるので、Backlog API を使って一括で一覧取得する Bash スクリプトを作ってみました。 Backlog API 利用に向けた前提知識と準備 今回のブログで用いるスクリプトでは、以下の情報を必要とします。事前に発行/確認を行なってください。 Backlog スペース ID Backlog プロ

ここでの障害発生箇所の「インスタンス内部」とは、アプリケーションの動作に必要なプロセスの障害などを指します。インスタンスそのものは正常稼働している状態です。 #1 の場合、ELBのヘルスチェックに失敗し、インスタンスはルーティングの対象外になります。EC2 インスタンスの置き換えは発生しないため、不要なインスタンスが残り続けることになります。 #2 の場合、ELB のヘルスチェックの失敗を契機に Auto Scaling Group によるインスタンスの置き換えが発生します。このケースにおいては、望ましい状態です。 #3,#4のように障害が発生箇所が「依存関係との接続」の場合、シャローヘルスチェックによって検出されません。ELB は引き続きインスタンスにトラフィックをルーティングするため、グレー障害が発生します。 #3,4 のケースへの対策として、ディープヘルスチェックを導入することを考え

Performance Schema 自動管理下になっているかどうかは、DB インスタンスに適用されているパラメータグループによって判別できます。以下の状態になっている場合、自動管理下にあります。 performance_schemaパラメータについて、以下の両方を満たしている 値が0である sourceがsystemである なお、それぞれが有効/無効のいずれの状態であるかの確認手法は以下のとおりです。 Performance Insights：マネジメントコンソールなどから確認可能 Performance Schema ：DB接続した上で、SHOW VARIABLESで確認 今回確認したかったこと 今回確認したかったことは以下です。 Performance Insights および Performance Schema が無効状態の Amazon RDS for MySQL DB インス