ElastiCacheでValkeyがサポートされたけど何が良いのか検証してみた - CyberAgent SRG #ca_srgメディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、Amaz
AWSアカウントを取り違えないための試み - KAYAC Engineers' Blog
SREチームの長田です。 皆さんは操作するAWSアカウントを取り違えたことはありますか？ 私はあります。 カヤックのSREは複数のプロダクトを担当することも多く、 ひとつのプロダクトでも環境(本番、ステージング、開発、etc.)ごとにAWSアカウントを分ける場合があり、 扱わなければならないAWSアカウントが多くなる傾向にあります *1。 今回はうっかり別のアカウントのリソースを削除してしまったーといったオペレーションミスを減らすために個人的に行っている、 「気をつける」以外の対策を紹介します。 間違いに気づくための対策 対象のアカウントが操作の対象として正しいかどうかは、結局は操作している本人にしか分かりません *2。 そのため、「アカウント取り違え自体をなくす」のではなく、 「アカウントを取り違えていることに気づきやすくする」ための対策をしています。 AWSコンソール用の対策 AWSコ
「攻めた」AWS Fargate Spot比率の見直し時 - Hatena Developer Blog
AWSの東京リージョンでFargate Spotを「中断されたら困る」割合で利用している場合、2024年10月は見直し時かも知れません。 はてながECS Fargateで運用しているWebサービスの多くは、状況に応じてリクエスト数≒負荷が増減します。 これに対して、リクエストを受け持つECSサービスのタスク数をオートスケールさせてコスト最適化を図っています。 ボトルネックはCPUで、CPU使用率を追跡していることが多いでしょうか。 オートスケールで追跡する使用率にはスケールアウトまでの間の負荷に耐えるための余裕を持たせます。 この余裕の部分をSpotタスクで確保することで更にコストを削減できます。 AWS Fargate Spotの発表で示されているユースケースでは以下に該当します。 また高可用性を求められるウェブサイトやAPIサーバーのように、ECSサービスの一部となるタスクに対してもF
[アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました | DevelopersIO
[アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました いわさです。 AWS CloudFormation は Git リポジトリとスタックを同期させて、簡易的な CI/CD 環境を用意することが出来ます。 今朝のアップデートでこちらが強化され、CloudFormation がプルリクエストにスタックへの変更内容をコメントしてくれるようになりました。 Git 同期では CloudFormation が特定のブランチを監視し、変更が発生すると自動でスタックがプロビジョニングされるような動きとなっているのですが、このアップデートではユーザーが作成したプリリクエストのマージ先が監視対象のリポジトリだった場合、マージ前でスタック変更セットの内容をプルリクエスト上でコメントしてくれます。 これによってレビュー
![[アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/9275d181cd999971b068c70e3626e94ee8ad0343/height=288;version=1;width=512/https%3A%2F%2Fimages.ctfassets.net%2Fct0aopd36mqt%2Fwp-thumbnail-dcbaa2123fec72b4fafe12edd4285aaf%2F178121bca8a805d8af9e86e4e4bbe732%2Faws-cloudformation)
オラクルとAWSが「Oracle Database＠AWS」発表、AzureやGoogleに続く“分散クラウド”提携
米オラクルと米Amazon Web Services（AWS）が2024年9月9日（米国時間）、戦略的パートナーシップに基づく新たなオファリング「Oracle Database＠AWS」を発表した。AWSデータセンターに配置されたインフラを用いて、オラクルが「Oracle Exadata Database Service」や「Oracle Autonomous Database」を提供する。 オラクルでは、“分散クラウド／マルチクラウド戦略”に基づき、すでにMicrosoft Azure（Oracle Database＠Azure）やGoogle Cloud（Oracle Database＠Google Cloud）との間で同様のパートナーシップを実現している。 Oracle Database＠AWSの提供によって、AWSクラウドで稼働するアプリケーションからOracle Database
こんにちは、Amazon Macie: コンテンツを自動的に発見、分類、保護する | Amazon Web Services
Amazon Web Services ブログ こんにちは、Amazon Macie: コンテンツを自動的に発見、分類、保護する Jeffと私が初めてこのサービスを聞いたとき、私たちはMacieという名前の意味が知りたくなりました。もちろん偉大な研究者であるJeffは、Macieという名前を調べ、二つの意味があることを発見しました。フランス語とイギリス英語両方からの語源があり、典型的な少女の名前で、様々な意味を持っていました。Macieの一つめの意味は”武器”を意味する名前です。もう一つの意味は、力強く、さっぱりとした、優しい人の表す名前です。ある意味、これらの定義はふさわしいです。本日、私たちはAmazon Macieという新しいセキュリティサービスの提供開始を喜んで発表します。機械学習によって、AWS上に保存された機密情報の特定し、データ侵害、情報漏えい、Amazon Simple S
Web アプリケーションにおける Amazon ECS / AWS Fargate アーキテクチャデザインパターン - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは。AWS Container Hero の新井です。 Amazon ECS の登場から間もなく 10 年が経ちますが、その間、ECS ⾃体の進化に加えて、さまざまな AWS マネージドサービスとの連携が可能になりました。 現在では、コンテナベースのワークロードを活⽤することで実現できないことを探す⽅が難しいほど、柔軟なアーキテクチャが構築できるようになっています。 しかし、⾃由度が⾼い分、要件に合ったアーキテクチャを模索する際には、迷うことも多いでしょう。 AWS上でシステムを適切に構築するためには、あらかじめサービス間のつなぎ⽅やパターン、その特徴を把握しておくことが重要です。 これにより、フィージビリティを迅速に確認でき、その後のトライアンドエラーのサイクルを加速させることができます。 今回は、最新の AWS サービスアップデートを踏まえつつ、Amazon ECS / AWS
AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう | Amazon Web Services
Amazon Web Services ブログ AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう 通常、組織はAWS サービスを活用してワークロードのオブザーバビリティと運用の優秀性を高めています。しかし、多くの場合、オブザーバビリティメトリクスが提供されたときのチームが取るべき対応は不明確であり、どのメトリクスに対処が必要で、どのメトリクスがノイズにすぎないかを理解することは難しい場合があります。たとえば、アラームがトリガーされるまで 10 分以上かかる場合、根本的な問題を軽減するためにチームが取れる対処が遅れてしまいます。この問題への理想的な解決策は、ネットワークの障害を防ぐために、オブザーバビリティメトリクスからアラームの起動までの時間を短縮することです。実装やアーキテクチャの制限により、メトリクスデータは常に CloudWatch
Elasticsearch is Open Source, Again
Search and analytics, data ingestion, and visualization – all at your fingertips.
Amazon ECS provides the ability to restart containers without requiring a task relaunch - AWS
Amazon ECS provides the ability to restart containers without requiring a task relaunch Amazon Elastic Container Services (Amazon ECS) now improves container resiliency by giving you the ability to define a flexible container restart policy for restarting individual containers locally, without requiring a full task relaunch. With local container restarts, Amazon ECS can recover your containers fro
Security best practices when using ALB authentication | Amazon Web Services
Networking & Content Delivery Security best practices when using ALB authentication At AWS, security is the top priority, and we are committed to providing you with the necessary guidance to fortify the security posture of your environment. In 2018, we introduced built-in authentication support for Application Load Balancers (ALBs), enabling secure user authentication as they access applications.
Lambda zipアーカイブデプロイを深堀りしてコールドスタートを速くしよう - KAKEHASHI Tech Blog
ここ最近のトレンドとして、Vercel, Cloudflareとサーバレスにおけるコールドスタート高速化周りでしのぎを削っており Lambdaも様々な取り組みがなされています。それでもLambdaはシェアが大きいこともあり、コールドスタートが話題になることは多いです。この記事では、あまり語られないファイルサイズの観点からコールドスタート高速化にアプローチします。 zipアーカイブに着目するモチベーション Cold Start時はS3からコード一式をダウンロードするため、サイズが小さいほうがCold Startが短くなります。 また、解凍後のファイルサイズが250MBまでという制限もあります。こちらは上限緩和不可能です。なお直接アップロードする場合はzipのサイズは50MBまでで、これ以上だとS3バケットを準備してそちらにアップロードする必要があります。 とにかく不要なものを削ればCI/CD
NATゲートウェイの通信内容を調査して対策し、コストを約60％削減した話 - ZOZO TECH BLOG
はじめに こんにちは。WEARバックエンド部SREブロックの春日です。普段はWEARというサービスのSREとして開発・運用に携わっています。本記事では、約60％のコスト削減に成功したNATゲートウェイの通信内容の調査方法と通信量の削減方法についてご紹介します。 目次 はじめに 目次 背景 コストの把握 NATゲートウェイの通信内容の把握 CloudWatchメトリクスでの確認 VPCフローログでの確認 リゾルバーでのクエリログでの確認 調査結果をもとにNATゲートウェイ経由での通信量を削減する AWSサービスとの通信 Datadogとの通信 WEARのAPIとの通信 ECRパブリックリポジトリとの通信 結果 まとめ 背景 ZOZOではより効果的な成長を目指してコストの最適化を進めています。コストの増大はサービスの拡大を鈍化させる原因となるため、常に最適な状態に保つことが必要です。WEARで
correction of error (COE) を開発すべき理由 | Amazon Web Services
Amazon Web Services ブログ correction of error (COE) を開発すべき理由 アプリケーションの信頼性は非常に重要です。サービスの中断はマイナスのお客様体験となり、お客様の信頼とビジネス価値を低下させます。Amazon で学んだベストプラクティスの 1 つは、インシデント発生後の分析のための標準的なメカニズムを持つことです。これにより、インシデント発生後にシステムを分析し、今後の再発を防止することができます。また、インシデントの発生は、システムおよびプロセスがどのように機能するかについて理解を深めるのにも役立ちます。その知識は、特定のインシデントの再発防止だけでなく、他のインシデントシナリオに役立つアクションにつながることがよくあります。このメカニズムは、Correction of Error (COE) プロセスと呼ばれています。事後分析は COE
AWS ECS で実行するバッチ処理を Cluster Auto Scaling を使ってコスト最適化する - Hatena Developer Blog
システムプラットフォームチームで SRE をしている id:chaya2z です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の6月号です。先月は id:MysticDoll さんの Postfixのログ監視で注意すべきSMTPのステータス仕様について でした。 ECS で実行するバッチ処理を、インスタンス数を最適化する仕組みである ECS Cluster Auto Scaling を使ってコスト最適化した取り組みを紹介します。 ECS の起動タイプに EC2 を使う背景 はてなでは、ECS の起動タイプとして Fargate ではなく EC2 を使用しているサービスがあります。そのサービス例として、バッチ処理があります。バッチ処理のジョブには数秒・数分で終わるものもあれば、数時間かかるものがあります。 EC2 起動タイプを選ぶ理由は、タスク終了までのタイムアウト待
【AWS SDK for JavaScript v3】DynamoDB操作のあれこれをTypeScriptで理解する
この記事で解決すること SDK for JavaScript v3を用いてDynamoDBを操作する時に使用するライブラリの違い @aws-sdk/client-dynamodb： DynamoDBClient @aws-sdk/lib-dynamodb： DynamoDBDocumentClient やりたいこと SDK for JavaScript v3を用いてDynamoDBにデータを挿入するLambda関数コードを書きます。 環境 Lambda Node.js 20 APIGateway, DynamoDB （AWS SAMによるデプロイ、APIGatewayコンソール上からテスト） AWS SDK for JavaScript v3でのDynamoDB操作について AWS SDK for JavaScript v3では、操作したい各リソースごとにライブラリをインストールして使用し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Technology that powers Lambda / AWS Lambda を支える技術
https://docs.aws.amazon.com/security
東京リージョンのAuroraにGraviton3(r7g)が来たぞー！簡単な性能検証結果と注意すべき点 - CyberAgent SRG #ca_srg
AWS Secrets Manager announces open source release of Secrets Manager Agent - AWS