Takashi Iwamoto

Strands Agentsは、AWSが公開したオープンソースのAIエージェントSDKです。数行のコードでAIエージェントが作れます。セッション管理機能を使うと、会話履歴やAIエージェントの状態が永続化できます。組み込みの保存先はローカルファイルシステムとS3です。今回は、Strands Agentsを単なるS3 KVSクライアントとして使ってみます。LLMは呼び出しません。そういう使い方が便利な場合もあるでしょうから。Strands Agentsをすでに利用中のアプリケーションで、何かしらのデータを永続化したい場合プロトタイピングでシンプルなKVSを使いたい場合 1. ...

Strands AgentsをLLM抜きでS3 KVSクライアントとして使ってみる

Cloud Operator Days Tokyo 2025https://cloudopsdays.com/

復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた

2025-07-10Study Hack #02https://hireroo.connpass.com/event/359432/

IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて

2年でここまで成長！AWSで育てたAI Slack botの軌跡

本日、GitHub Advanced Security認定を受けて合格しました。https://www.credly.com/badges/9f7bdda5-af4c-4d26-bbd4-f5a373de0f35/public_url受験料はメンテナー月間のセキュリティチャレンジでもらったバウチャーのおかげで無料でした。本来は99 USDです。バウチャーをもらうまでのステップは下記のとおりでした。3つのエクササイズを実施（リポジトリをforkして指示に従う）Introduction to Repository ManagementSecure Your Repositor...

GitHub Advanced Security認定をタダで取得した方法

Amazon Q CLIでゲームを作るとTシャツがもらえるイベントが開催されているので、ぼくも作ってみました。盤面に置かれている赤い球を2つの手球で順に弾き、最終的に3つの球で作られる三角形の大きさがスコアになるゲームです。所要時間は、Amazon Q CLIやPygameのインストールを含めて2時間半ほどでした。ただし、どんなゲームを作るか決めるのに1時間くらい要した形です。Amazon Q CLIの書いてくれたコードは、下記リポジトリで公開しています。READMEやLICENSEも書いてもらいました。https://github.com/iwamot/amazon-q-bi...

Amazon Q CLIでゲームが簡単に作れた

Hi, I'm Takashi Iwamoto (@iwamot), an AWS Community Builder (Cloud Operations).When I looked for prior examples of building ChatOps on AWS, most of them used Lambda.However, I had a hunch that we could get rid of Lambda by using the Custom Actions feature of Amazon Q Developer in chat applications (formerly AWS Chatbot), which was announced in November 2023.After trying it out, I was able to build a fairly practical architecture.In this post, I'll walk you through how I built AWS ChatOps without Lambda.Before we dive in, let me touch on why I want to avoid Lambda.In a word: "Because it makes operations easier."If you don't use Lambda, you never have to worry about runtime end‑of‑life. The more ChatOps targets you have, the more the cost of those EOL updates will hurt.Here's what I actually built.The main AWS services I used are these three:Amazon EventBridge – event detection & routingAmazon SNS – notification deliveryAmazon Q Developer in chat applications – Slack notifications & Custom ActionsAnd the overall architecture looks like this:An EventBridge rule detects the CodeDeploy deployment state‑change event.The event is transformed with an input transformer and routed to an SNS topic.The message is delivered to an Amazon Q Developer Slack channel.The notification message and Custom Action buttons appear in Slack.A user picks one of the Custom Actions.The corresponding CodeDeploy command is executed (e.g. continue-deployment, stop-deployment).To show Custom Action buttons in chat apps like Slack, you first need to create the Custom Actions themselves.There are two ways to define Custom Actions:Create them directly in the chat applicationCreate them with the Amazon Q Developer in chat applications APII chose the API method because I wanted to manage everything as IaC. If you create the action in the chat UI, it seems that the resource is owned by AWS and not created inside your own AWS account.If you go the API route, you'll also need to associate the Custom Actions with the chat channel yourself.The steps are:Call the CreateCustomAction API to create the action.Call the AssociateToConfiguration API to attach it to the chat channel.Below is how I implemented it in Terraform. (It's a bit long, so I've collapsed it.)locals {  custom_actions = {    SwitchTasks = {      button_text = "🔁 Switch task sets"      criteria = [        {          operator      = "EQUALS"          value         = "blue-green-deployment"          variable_name = "ActionGroup"        },      ]      variables = {        "ActionGroup"  = "event.metadata.additionalContext.ActionGroup"        "DeploymentId" = "event.metadata.additionalContext.DeploymentId"        "Region"       = "event.metadata.additionalContext.Region"      }      command_text = "codedeploy continue-deployment --deployment-id $DeploymentId --region $Region --deployment-wait-type READY_WAIT"    }    RollbackDeployment = {      button_text = "🔙 Rollback"      criteria = [        {          operator      = "EQUALS"          value         = "blue-green-deployment"          variable_name = "ActionGroup"        },      ]      variables = {        "ActionGroup"  = "event.metadata.additionalContext.ActionGroup"        "DeploymentId" = "event.metadata.additionalContext.DeploymentId"        "Region"       = "event.metadata.additionalContext.Region"      }      command_text = "codedeploy stop-deployment --deployment-id $DeploymentId --region $Region --auto-rollback-enabled true"    }    TerminateOldTask = {      button_text = "🧹 Terminate old task set"      criteria = [        {          operator      = "EQUALS"          value         = "blue-green-deployment"          variable_name = "ActionGroup"        },      ]      variables = {        "ActionGroup"  = "event.metadata.additionalContext.ActionGroup"        "DeploymentId" = "event.metadata.additionalContext.DeploymentId"        "Region"       = "event.metadata.additionalContext.Region"      }      command_text = "codedeploy continue-deployment --deployment-id $DeploymentId --region $Region --deployment-wait-type TERMINATION_WAIT"    }  }}resource "awscc_chatbot_custom_action" "this" {  for_each = local.custom_actions  action_name = each.key  attachments = [    {      button_text       = each.value.button_text      criteria          = each.value.criteria      notification_type = "Custom"      variables         = each.value.variables    },  ]  definition = {    command_text = each.value.command_text  }  tags = [    for key, value in merge(data.aws_default_tags.this.tags, { "Name" = each.key }) : {      key   = key      value = value    }  ]}# In this example we set custom_action_groups = ["blue-green-deployment"]variable "custom_action_groups" {  description = "A list of Custom Action group names to associate specific AWS Chatbot actions with the specified Slack channel configuration."  type        = list(string)  default     = []}locals {  action_group_map = {    "blue-green-deployment" = ["SwitchTasks", "RollbackDeployment", "TerminateOldTask"]  }  selected_actions = distinct(flatten([    for group in var.custom_action_groups :    lookup(local.action_group_map, group, [])  ]))  action_arns = {    for k, v in {      for action in local.selected_actions :      action => try(        one([          for id in data.awscc_chatbot_custom_actions.this.ids : id          if endswith(id, "/${action}")        ]),        null      )    } : k => v if v != null  }}resource "null_resource" "associate_actions" {  for_each = local.action_arns  triggers = {    action_arn  = each.value    chatbot_arn = aws_chatbot_slack_channel_configuration.this.chat_configuration_arn  }  provisioner "local-exec" {    command = "aws chatbot associate-to-configuration --resource ${self.triggers.action_arn} --chat-configuration ${self.triggers.chatbot_arn} --region us-west-2"  }  provisioner "local-exec" {    when    = destroy    command = "aws chatbot disassociate-from-configuration --resource ${self.triggers.action_arn} --chat-configuration ${self.triggers.chatbot_arn} --region us-west-2"  }}variable "sns_topic_arn" {  description = "The SNS topic to notify when the blue/green deployment is ready for validation."  type        = string  nullable    = false}variable "deployment_group_name" {  description = "The name of the deployment group targeted by ChatOps."  type        = string  nullable    = false}variable "green_url" {  description = "The URL for validating the green environment."  type        = string  nullable    = false}resource "aws_cloudwatch_event_rule" "this" {  description    = null  event_bus_name = "default"  event_pattern = jsonencode(    {      detail = {        deploymentGroup = [          var.deployment_group_name,        ]        state = [          "READY",        ]      }      detail-type = [        "CodeDeploy Deployment State-change Notification",      ]      source = [        "aws.codedeploy",      ]    }  )  force_destroy       = false  name                = "${var.deployment_group_name}-deployment-ready"  name_prefix         = null  role_arn            = null  schedule_expression = null  state               = "ENABLED"  tags = {    "Name" = "${var.deployment_group_name}-deployment-ready"  }}resource "aws_cloudwatch_event_target" "this" {  arn            = var.sns_topic_arn  event_bus_name = "default"  force_destroy  = false  input          = null  input_path     = null  role_arn       = aws_iam_role.this.arn  rule           = aws_cloudwatch_event_rule.this.name  target_id      = "sns"  input_transformer {    input_paths = {      "account"         = "$.account"      "deploymentGroup" = "$.detail.deploymentGroup"      "deploymentId"    = "$.detail.deploymentId"      "region"          = "$.region"      "time"            = "$.time"    }    input_template = replace(replace(      jsonencode(        {          content = {            description = trimspace(              <<-EOT              *Deployment group:* <deploymentGroup>              *Deployment ID:* <deploymentId>              *Account:* <account>              *Region:* <region>              *Time:* <time>            EOT            )            nextSteps = [              "Check if the app works correctly at ${var.green_url}",              "If all looks good, switch task sets. If not, trigger a rollback",              "Once validated, terminate the original task set",            ]            textType = "client-markdown"            title    = ":large_blue_circle::large_green_circle: Deployment is now ready for validation"          }          metadata = {            additionalContext = {              ActionGroup  = "blue-green-deployment"              DeploymentId = "<deploymentId>"              Region       = "<region>"            }            enableCustomActions = true          }          source  = "custom"          version = "1.0"        }      ),    "\u003c", "<"), "\u003e", ">")  }}With this in place, Slack now shows the following notification, and the entire Blue/Green deployment can be operated using just the Custom Action buttons.As you can see, this solution works quite well, but one issue is that we can't control the order of the Custom Action buttons.Sometimes they show up as "🧹 Terminate old task set", "🔙 Rollback", "🔁 Switch task sets", in that order. The screenshot above just happened to be in the desired order.If we could control that order, I'm sure this approach would be solid enough to become a go-to ChatOps pattern. I've already submitted a feature request to AWS Support, and I'm hopeful it will be addressed in the future.That was an example of ChatOps built with Amazon Q Developer in chat applications Custom Actions.When you build it without Lambda, operations get easier. The unresolved button‑ordering issue remains, but if you can live with that, it's already perfectly usable.I plan to expand our ChatOps coverage with this method, and I hope it inspires you to try it out yourself.

AWS ChatOps Without Lambda? Yes, You Can!

2025-05-14シネマ de LT会〜あなたのナレッジ大上映〜https://aeon.connpass.com/event/352070/

名単体テスト 禁断の傀儡（モック）

2025-04-16Ops-JAWS Meetup34 Organizations & ControlTowerhttps://opsjaws.connpass.com/event/348813/

クォータ監視、AWS Organizations環境でも楽勝です✌️

2025-03-28ENECHANGE I/O Day アウトプット大会（社内イベント）

Cline、めっちゃ便利、お金が飛ぶ💸

開発組織を進化させる！AWSで実践するチームトポロジー

2025-01-23Findy Tools 1周年記念 感謝祭https://findy-tools.connpass.com/event/339331/

始めないともったいない！SLO運用で得られる3つのメリット

2025-01-15持っててよかった！！AWS認定資格！https://aws-startup-community.connpass.com/event/340735/

あなたの人生も変わるかも？AWS認定2つで始まったウソみたいな話

2024-12-25ENECHANGE I/O Day LT⼤会（社内イベント）

効率的な技術組織が作れる！書籍『チームトポロジー』要点まとめ

◯沼袋.nighthttps://shirayanagiryuji.connpass.com/event/325230/2024-11-09

AWS⼊社という選択肢、⾒えていますか

If you want to change the network settings for an Amazon ECS service using blue/green deployment with AWS CodeDeploy, you need to edit the AppSpec file and trigger a new deployment.Without knowing this method, you'd either have to recreate the entire ECS service or give up on changing the network settings.For ECS services using blue/green deployment with AWS CodeDeploy, you cannot directly change the network settings.When you try to make changes by calling the ECS UpdateService API, you will encounter the following error:InvalidParameterException: Unable to update network parameters on services with a CODE_DEPLOY deployment controller. Use AWS CodeDeploy to trigger a new deployment.This error message indicates that you need to trigger a new deployment with CodeDeploy, as noted in the documentation.For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new AWS CodeDeploy deployment. For more information, see CreateDeployment in the AWS CodeDeploy API Reference.UpdateService - Amazon Elastic Container ServiceNow that we know we need to trigger a new deployment, the question remains: how exactly should we do that?The answer is to "edit the AppSpec file and then trigger a new deployment." If you trigger it without editing the AppSpec file, the network settings won't change.In the case of appspec.yml, edit it as shown below.        NetworkConfiguration:          AwsvpcConfiguration:            Subnets: ["subnet-1234abcd","subnet-5678abcd"]            SecurityGroups: ["sg-12345678"]            AssignPublicIp: "ENABLED"AppSpec File example - AWS CodeDeploySpecify the subnets, security groups, and whether or not to assign a public IP address for the ECS tasks in the AppSpec file.When doing so, you need to specify all three: Subnets, SecurityGroups, and AssignPublicIp.All or none of the settings under NetworkConfiguration must be specified. For example, if you want to specify Subnets, you must also specify SecurityGroups and AssignPublicIp. If none is specified, CodeDeploy uses the current network Amazon ECS settings.AppSpec 'resources' section (Amazon ECS and AWS Lambda deployments only) - AWS CodeDeployAfter editing the AppSpec file, trigger a new deployment, and the network settings will be applied. The new ECS tasks in the green environment should start with the specified network configuration.Once the deployment is complete, you can safely remove the NetworkConfiguration from the AppSpec file.As described, even for Amazon ECS services using blue/green deployment with CodeDeploy, you can change the network settings by editing the AppSpec file and triggering a new deployment.I almost ended up recreating the ECS service because I wasn't aware of this method. I hope this article helps those in a similar situation.

How to Change Network Configurations for Blue/Green Amazon ECS Services

2024-10-18ENECHANGE Tech Talk（社内勉強会）

40代後半で開発エンジニアからクラウドインフラエンジニアにキャリアチェンジし、生き残れる自信がようやく持てた話

2024-09-25ENECHANGE I/O Day LT⼤会（社内イベント）

DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール

2024-09-11今さら聞けない！ オフィス・開発でのAI活用https://urahara-agile.connpass.com/event/328607/

RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果

In this article, I’ll introduce an SLO error budget monitoring system that I built entirely using AWS services.This system is based on the multi-window, multi-burn-rate alerting method proposed in the Site Reliability Workbook. It sends alerts to Slack when the SLO error budget burn rate exceeds a certain threshold.expr: (        job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)      and        job:slo_errors_per_request:ratio_rate5m{job="myjob"} > (14.4*0.001)      )    or      (        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6*0.001)      and        job:slo_errors_per_request:ratio_rate30m{job="myjob"} > (6*0.001)      )severity: pageexpr: (        job:slo_errors_per_request:ratio_rate24h{job="myjob"} > (3*0.001)      and        job:slo_errors_per_request:ratio_rate2h{job="myjob"} > (3*0.001)      )    or      (        job:slo_errors_per_request:ratio_rate3d{job="myjob"} > 0.001      and        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > 0.001      )severity: tickethttps://sre.google/workbook/alerting-on-slos/The Site Reliability Workbook recommends combining multiple time windows and burn rates to create more accurate alerts. For example, if you only alert based on a short time window, you may get too many false positives. On the other hand, if you rely on a longer time window, it may take too long for an alert to trigger or recover. By using both short and long windows, the system can generate more precise alerts.For more detailed explanations of this alerting method, I encourage you to check out the Site Reliability Workbook, which is available for free. Personally, I believe that strictly following these guidelines is the best way to monitor service reliability.The primary motivation behind this monitoring system was to solve the problem of "alert fatigue." As an operations engineer, I was constantly bombarded with alerts that didn’t actually require any action.Previously, we monitored CPU and memory usage metrics directly, which led to alerts even when the service itself was running smoothly. For example, we would receive a Slack alert if the CPU usage of a web server exceeded 90%, regardless of whether there were any issues with availability or latency.However, even if the CPU usage was high, if the service remained available and responsive, there was no need for intervention. Over time, receiving alerts for issues that didn't require action caused fatigue and increased the risk of missing critical alerts. Missing an important alert could damage service reliability and lead to a loss of users.To address this, I decided to focus only on critical indicators—such as availability and latency—and set up an SLO-based monitoring system that tracks the error budget burn rate.At first, I considered using third-party monitoring tools like New Relic or Datadog. However, after investigating these tools in early 2023, I found that it was either impossible or very difficult to implement the kind of SLO monitoring I needed with their existing features. I worked with support teams from both platforms, but we couldn't come up with a viable solution.On the other hand, by combining AWS services such as Amazon CloudWatch, I could implement the necessary monitoring and at a much lower cost—around $20 per month.Since most of our workloads are hosted on AWS, building the monitoring system directly on AWS made it easier to integrate everything into a single console. AWS also offers a high degree of flexibility in terms of combining services, giving us more room to scale and customize compared to third-party tools like New Relic or Datadog.Here’s an overview of the system’s architecture:Although it may look a bit complex at first glance, the core workflow is simple:EventBridge Scheduler triggers a Lambda function at regular intervals.The Lambda function runs an Athena query to aggregate ALB access logs.The results are stored in both CloudWatch custom metrics and RDS.CloudWatch composite alarms use these metrics to trigger alerts based on the SLO conditions.The Lambda function is triggered by EventBridge instead of an S3 file save event. This is because when there is heavy traffic, multiple log files are saved to S3, which could result in the aggregation process being run multiple times unnecessarily.We use RDS to store the aggregated results in order to reduce Athena scan costs. For more details on these optimizations and custom metric definitions, please refer to my presentation at JAWS PANKRATION 2024.Since we introduced this system, alert fatigue has significantly decreased. I personally noticed a reduction in the number of unnecessary alerts that required no action.Additionally, the development team has become more invested in the reliability of the services. Now, when an alert is triggered, the team takes the initiative to tune performance or even revise the SLOs when necessary.As of September 2023, this system is monitoring 7 services and 12 critical user journeys.To streamline operations, I developed an internal Terraform module that allows us to quickly accommodate additional monitoring requests from the development team. While the module itself is private, this is an actual example of its interface, which could be useful as a reference if you plan to implement a similar module.module "slomon" {  source = "git@github.com:enechange/terraform-modules.git//slomon-for-alb?ref=v0.53.0"  environment_name              = "prod-enechange"  alb_access_logs_s3_url        = local.alb_access_logs_s3_url  sns_topic_names_for_paging    = ["cto-incident-enechange"]  sns_topic_names_for_ticketing = ["cto-alert-enechange"]  critical_user_journeys = {    input1_submit = {      http_method     = "POST"      path            = "/try/input1_submit"      dashboard_order = 1      slo = {        availability_target   = 95.0        latency_p95_threshold = 4.0        latency_p50_threshold = 3.0      }    }  }}This Terraform module also includes Athena queries for analyzing historical data, allowing us to quickly set SLOs based on past performance.At present, this monitoring system meets all of our needs. However, if CloudWatch's Application Signals feature evolves to support the required conditions for SLO monitoring, this custom system may no longer be necessary. In that case, we would likely transition to a fully managed solution.Likewise, if New Relic or Datadog introduce features that support the kind of SLO monitoring we need, we may consider switching to them. These APM tools generally offer better capabilities for diagnosing root causes of performance degradation compared to CloudWatch.Ultimately, we will continue to assess the best solution for our needs and adapt our system as new tools and services emerge.In this article, I introduced an SLO error budget monitoring system that I built using AWS services only.By implementing this system, we were able to reduce alert fatigue and increase the development team’s focus on service reliability.I hope this article provides useful insights for those dealing with similar challenges around alert fatigue.

Implementing SLO Error Budget Monitoring with AWS Services Only

2024-09-06Cloud Operator Days Tokyo 2024https://cloudopsdays.com/closing/

Amazon CloudWatchでSLOを監視してみた　CODT 2024 クロージングイベント版

2024-08-24 - 2024-08-25JAWS PANKRATION 2024https://jawspankration2024.jaws-ug.jp/en/

Cost-Effective SLO Error Budget Monitoring with Athena and CloudWatch

Cloud Operator Days Tokyo 2024https://cloudopsdays.com/

Amazon CloudWatchでSLOを監視してみた

2024-06-14ENECHANGE Tech Talk（社内勉強会）

AWS Protonの概要

Key Resultにはアクションを置くべきでない？「OKRのKey Resultにはアクションを置くべきでない」との意見を目にします。Perdoo は Objective を達成するために必要な仮説であり、施策であるアクションのことを Initiative とよんでいる。OKR の利用において Key Result の内容が Initiative になってしまっているということがよくあるようです。Objective頻繁にバズるブロガーになるKey Results月に2回以上はてなブックマーク50以上の記事があるInitiatives月に20記事を...

OKRのKey Resultにはアクションを置いてもよい

AWS CodeBuildプロジェクトで「自動再試行の上限」を設定できるようになりました。https://docs.aws.amazon.com/codebuild/latest/userguide/auto-retry-build.htmlこの記事の方法は、その設...

CodeBuildの失敗ビルドを自動的にLambdaで再試行する

コールドスタートに4～5秒かかるPythonのLambdaコンテナ関数があり、改善策を調べていたら、AWS公式ブログに下記の記述を見つけました。AWS が提供するベースイメージは、Lambda サービスによってプロアクティブにキャッシュされます。つまり、ベースイメージは近くの別のアップストリームキャッシュにあるか、ワーカーインスタンスキャッシュにすでに存在しています。はるかに大きいにもかかわらず、キャッシュされないかもしれないサードパーティのベースイメージと比較するとデプロイ時間が短くなる可能性があります。コンテナイメージとしてパッケージ化された Lambda 関数の最適化 | A...

Lambdaコンテナ関数ではAWS提供ベースイメージを使う

AWS LambdaのPythonコードでBugsnagを使う際、デフォルトの「asynchronous=True」のままだと、通知が飛びませんでした。深く追ってはいませんが、非同期的な通知より先にLambda関数が終了してしまうのでしょう。「asynchronous=False」を指定したところ、意図どおり通知が飛ぶようになりました。以下、参考リソースです。By default, requests are sent asynchronously to BugSnag. If you would like to block until the request is done, y...

AWS LambdaのPythonコードでBugsnagを使う際は「asynchronous=False」にする

Terraformで、特定の条件下でのみブロックを指定したい場面があります。たとえば、AWS Budgetsの予算を示すaws_budgets_budgetでは、予算タイプによってcost_filterブロックの要否が異なります。条件ごとにリソースを定義してもよいのですが、テンプレートが冗長になりがちです。下記の例では、try関数を使って、必要なときのみcost_filterブロックを指定してみました。すっきりしていて読みやすく感じます。locals {  budgets = {    # RDSリザーブドインスタンスのカバレッジ予算。cost_filtersが必要    r...

Terraformのtry関数をdynamicブロックの作成条件に使う

「AWS App Runner Advent Calendar 2022」の5日目の記事です。はじめにApp Runnerの学習目的で、tDiaryをデプロイしてみました。実運用を想定したものではありませんが、VPC内のリソースに接続するサンプルとして、参考になれば幸...

AWS App Runnerを学ぶためtDiaryをデプロイしてみる

Terraformのawsプロバイダが未対応のAWS Chatbot、awsccなら対応しているとのことで、試してみました。https://hi1280.hatenablog.com/entry/2022/08/06/191154既存のSlackチャネルをインポートするところから始めようと、ドキュメントを見たところ、下記のように書かれていました。Import is supported using the following syntax:$ terraform import awscc_chatbot_slack_channel_configuration.example &l...

awsccでChatbotのSlackチャネルをterraform importする

AWS Transfer Familyサーバーで、SETSTATコマンドを無視できるようになりました。2022年6月のことです。https://aws.amazon.com/jp/about-aws/whats-new/2022/06/aws-transfer-family-expands-server-configuration-options-set-clients/ファイルをアップロードするとき、ファイル転送クライアントは SETSTAT コマンドを発行してリモートファイルの属性を変更します。ただし、SETSTAT コマンドはオブジェクトストレージシステムと互換性がないため、...

AWS Transfer FamilyサーバーでSETSTATコマンドを無視する

AWS Transfer Familyのドキュメントに誤りがあったので、報告したら、直してもらえました。下記のアクセスポリシーが修正対象なのですが、どこが誤りか分かりますか。{    "Version": "2012-10-17",    "Statement": [        {            "Sid": "AllowListingOfUserFolder",            "Action": [                "s3:ListBucket"              ],            "Effect": "Allow...

AWS Transfer Familyのドキュメントの誤りを直してもらった

CodeBuildトリガーの実体はEventBridgeルールなんですね。ドキュメントにも書いてありました。CodeBuild は、ビルドトリガーに Amazon EventBridge ルールを使用しますhttps://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/trigger-create.htmlなので、TerraformのAWSプロバイダでトリガーを作る場合は、aws_codebuild_projectではなく、aws_cloudwatch_event_ruleやaws_cloudwatch_event_ta...

CodeBuildトリガーの実体はEventBridgeルール

運営中サービスで提供しているフィードの構文が正しいか気になったので、バリデータを探したところ、W3C Feed Validation Serviceが見つかりました。さっそく検証すると、下記の指摘が。Errorelement must be an RFC-822 date-timeWarningMissing atom:link with rel="self"item should contain a guid elementEnsure description precedes content:encodedpubDateの日時がRFC 822形式でなかっ...

W3C Feed Validation Serviceを使ってフィードを修正した

Terraform で list の末尾要素を参照するには、公式ドキュメントにある通り element 関数と length 関数を組み合わせます。To get the last element from the list use length to find the size of the list (minus 1 as the list is zero-based) and then pick the last element:> element(["a", "b", "c"], length(["a", "b", "c"])-1)c引用元：element - F...

Terraform で list の末尾要素を参照する

AWSがデジタルバッジの発行を始めたので、さっそく取得してみました。取得したのは以下2つのバッジです。2022年2月現在は、この「AWS Learning: Block Storage」と「AWS Learning: Object Storage」のみが存在します。https://www.credly.com/badges/5b9371f0-9c6c-413a-b099-1aff5dafbc17/public_urlhttps://www.credly.com/badges/3c35fc05-c3c1-4d82-b79a-250e5b4714cc/public_urlいずれのバッ...

AWSストレージのデジタルバッジを2つ取得した #AWSTraining

Elastic Beanstalk の CLI で使える eb deploy コマンド には --nohang オプションがあります。現時点ではなぜかドキュメントに書かれていないオプションですが、ヘルプに書かれています。$ eb --versionEB CLI 3.20.2 (Python 3.7.2)$ eb deploy --helpusage: eb deploy <environment_name> [options ...]Deploys your source code to the environment.positional argument...

eb deploy には --nohang オプションがある

AWS BugBust re:Invent Challenge とはAWS re:Invent 2021 のイベントとして AWS BugBust re:Invent Challenge が開催されました。簡単に言うと「指定されたバグを多く修正すると賞金や賞品がもらえるコンテスト」です。詳しくは AWS ブログの記事をご参照ください。https://aws.amazon.com/jp/blogs/news/help-make-bugbusting-history-at-aws-reinvent-2021/ 修正したバグの例ぼくもこのイベントに参加して 129 件のバグを修正...

AWS BugBust re:Invent Challenge で修正したバグの例と最終成績

問題「Amazonの採用面接」と「高度情報処理技術者試験の午後Ⅱ論述問題」の共通点は何か。15字以内で答えよ 解答例STAR形式で問われる（11字） 解説Amazonの採用面接には「行動に基づく面接」が含まれています。応募者は自身の経験を「どのような状況で、どのようなタスクを引き受け、どのような行動をし、どのような結果を得たのか」という順序で具体的に説明しなければなりません。一方、高度情報処理技術者試験の午後Ⅱ論述問題では下記の構成の出題がよく見られます。設問ア　あなたが携わった個別システム化構想の策定において、背景となった事業目標、事業戦略に掲げられてい...

「Amazonの採用面接」と「高度情報処理技術者試験の午後Ⅱ論述問題」の共通点は何か。15字以内で答えよ

東京リージョンを含め Graviton インスタンスが使えるリージョンであれば Elastic Beanstalk でも Graviton インスタンスが使えるようになりました。Release: Elastic Beanstalk supports AWS Graviton instance types based on 64-bit Arm architecture on November 24, 2021 - AWS Elastic BeanstalkElastic Beanstalk now offers support for Graviton on all of th...

Elastic Beanstalk で Graviton インスタンスが使えるようになった（東京リージョンでも）

Elastic Beanstalk の 2021-11-19 付のリリースにより、Ruby プラットフォームで Ruby 3 が使えるようになりました。Release: Elastic Beanstalk Amazon Linux platform updates on November 19, 2021 - AWS Elastic BeanstalkAdded a new platform branch, Ruby 3.0.Platform Version and Solution Stack NameAMILanguagePackage Manager...

Elastic Beanstalk の Ruby プラットフォームで Ruby 3 が使えるようになった

us-east-1 など 6 つのリージョンの Elastic Beanstalk で Graviton インスタンスが使えるようになりました。Release: Elastic Beanstalk supports first wave of Graviton gradual rollout on October 13, 2021 - AWS Elastic BeanstalkGraviton は AWS が開発した Arm ベースのプロセッサです。特に第 2 世代の Graviton2 は x86 ベースのインスタンスと比べる形でコストパフォーマンスの良さが強調されています。...

[追記あり] Elastic Beanstalk で Graviton インスタンスが使えるようになった（東京リージョンはまだ）

リリースチェッカーというサービスを個人で運営しています。先日、HTTPS化のため、Let's Encryptのサーバ証明書を導入しました。手順は簡単だったのですが、事前に準備しておけば、もっとスムーズに進められたはずです。準備しておくべきだった3つの項目をご紹介します。...

Let's Encrypt導入前に準備すべきこと

エラーの原因と回避方法は「[Django]DjangoのテストをDEBUG=Trueで実行する」と同じです。状況が少し違ったので、新たな記事を書くことにしました。エラーが起きた状況Django 2.0 での開発中、manage.py test myapp を実行したと...

Takashi Iwamoto

Strands AgentsをLLM抜きでS3 KVSクライアントとして使ってみる

復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた

IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて

2年でここまで成長！AWSで育てたAI Slack botの軌跡

GitHub Advanced Security認定をタダで取得した方法

Amazon Q CLIでゲームが簡単に作れた

AWS ChatOps Without Lambda? Yes, You Can!

名単体テスト禁断の傀儡（モック）

クォータ監視、AWS Organizations環境でも楽勝です✌️

Cline、めっちゃ便利、お金が飛ぶ💸

開発組織を進化させる！AWSで実践するチームトポロジー

始めないともったいない！SLO運用で得られる3つのメリット

あなたの人生も変わるかも？AWS認定2つで始まったウソみたいな話

効率的な技術組織が作れる！書籍『チームトポロジー』要点まとめ

AWS⼊社という選択肢、⾒えていますか

How to Change Network Configurations for Blue/Green Amazon ECS Services

40代後半で開発エンジニアからクラウドインフラエンジニアにキャリアチェンジし、生き残れる自信がようやく持てた話

DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール

RAGもファインチューニングも使わない素朴なAIチャットボットを職場に導入した結果

Implementing SLO Error Budget Monitoring with AWS Services Only

Amazon CloudWatchでSLOを監視してみた　CODT 2024 クロージングイベント版

Cost-Effective SLO Error Budget Monitoring with Athena and CloudWatch

Amazon CloudWatchでSLOを監視してみた

AWS Protonの概要

OKRのKey Resultにはアクションを置いてもよい

CodeBuildの失敗ビルドを自動的にLambdaで再試行する

Lambdaコンテナ関数ではAWS提供ベースイメージを使う

AWS LambdaのPythonコードでBugsnagを使う際は「asynchronous=False」にする

Terraformのtry関数をdynamicブロックの作成条件に使う

AWS App Runnerを学ぶためtDiaryをデプロイしてみる

awsccでChatbotのSlackチャネルをterraform importする

AWS Transfer FamilyサーバーでSETSTATコマンドを無視する

Strands AgentsをLLM抜きでS3 KVSクライアントとして使ってみる

復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた

IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて

2年でここまで成長！AWSで育てたAI Slack botの軌跡

GitHub Advanced Security認定をタダで取得した方法

Amazon Q CLIでゲームが簡単に作れた

AWS ChatOps Without Lambda? Yes, You Can!

名単体テスト 禁断の傀儡（モック）

クォータ監視、AWS Organizations環境でも楽勝です✌️

Cline、めっちゃ便利、お金が飛ぶ💸

開発組織を進化させる！AWSで実践するチームトポロジー

始めないともったいない！SLO運用で得られる3つのメリット

あなたの人生も変わるかも？AWS認定2つで始まったウソみたいな話

効率的な技術組織が作れる！書籍『チームトポロジー』要点まとめ

AWS⼊社という選択肢、⾒えていますか

How to Change Network Configurations for Blue/Green Amazon ECS Services

40代後半で開発エンジニアからクラウドインフラエンジニアにキャリアチェンジし、生き残れる自信がようやく持てた話

DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール

RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果

Implementing SLO Error Budget Monitoring with AWS Services Only

Amazon CloudWatchでSLOを監視してみた CODT 2024 クロージングイベント版

Cost-Effective SLO Error Budget Monitoring with Athena and CloudWatch

Amazon CloudWatchでSLOを監視してみた

AWS Protonの概要

OKRのKey Resultにはアクションを置いてもよい

CodeBuildの失敗ビルドを自動的にLambdaで再試行する

Lambdaコンテナ関数ではAWS提供ベースイメージを使う

AWS LambdaのPythonコードでBugsnagを使う際は「asynchronous=False」にする

Terraformのtry関数をdynamicブロックの作成条件に使う

AWS App Runnerを学ぶためtDiaryをデプロイしてみる

awsccでChatbotのSlackチャネルをterraform importする

AWS Transfer FamilyサーバーでSETSTATコマンドを無視する

名単体テスト禁断の傀儡（モック）

RAGもファインチューニングも使わない素朴なAIチャットボットを職場に導入した結果

Amazon CloudWatchでSLOを監視してみた　CODT 2024 クロージングイベント版