AWSが「Amazon S3 Files」を発表、S3バケットをファイルシステムとして利用可能に
AWSは4月7日（現地時間）、「Amazon S3 Files」の提供を開始した。 Amazon S3 Filesは、Amazon Simple Storage Service（S3）上のバケットをフル機能のファイルシステムとして扱える新サービスだ。従来はオブジェクトストレージとファイルシステムの違いを意識してワークロードを分けていたが、同機能により、S3バケットを直接ファイルとして編集・共有できるようになった。 S3 Filesを使用することで、Amazon EC2インスタンスやAmazon ECS、Amazon EKS、AWS Lambdaなどの各種コンピュートサービスから、S3バケットをネイティブなファイルシステムとして利用できる。Network File System（NFS）v4.1以降の標準操作に対応し、ファイルやディレクトリの作成・更新・削除が可能となる。また、低レイテンシな
これから本格化？ アクセスキー不正使用でのランサム事案がついに国内でも発生
直接の原因はクラウドサービスに対するアクセスキーが何らかの形で不正使用されたことです。ただし、どのような方法でアクセスキーが漏えいしたのかまでは分かっていません。ランサムウェアの侵入手口は電子メールやVPNからクラウドサービスそのものにまで拡大しています。これを踏まえると、マルウェアやパッチ適用、設定見直しだけでなく、クラウドサービスの基本的な運用も、大きな意味での「ランサムウェア対策」に含めなければならないでしょう。 ランサムウェアはクラウドからも？ アクセスキーを巡る運用を再考せよ クラウドにおけるアクセスキーの取り扱いは、これまで以上に重要になっています。過去にもトヨタモビリティサービスなどがアクセスキー漏えいに起因するインシデントを起こしています。 アクセスキーはクラウドサービスにアクセスするための認証情報であり、これを使う上では必ず生成し、利用するものです。当然、管理については慎
RDS Performance Insights が 2025 年 11 月 30 日に CloudWatch Database Insights へ統合されるみたいです | DevelopersIO
Google、自律型コーディングエージェント「Jules」をベータ公開
Googleは、同社が開発中の自律型のコーディングエージェント「Jules」ベータ版を公開しました。ウェイティングリストに登録したユーザーに対して順次公開が始まっています。 Julesは昨年（2024年）12月にGemini 2.0が公開されたタイミングで発表されていました。 参考：自律的にプログラミングをするAIエージェント「Jules」、Googleが発表。人間がタスクを与えると実装計画を作成、コードの生成や変更、バグフィクスなどを実行 Googleは日本時間の今夜（5月20日）、年次イベントのGoogle I/Oを開催します。Julesについてもそこで発表があると見られます。 Julesがベータ公開されたことで、Devinに代表される自律型のコーディングエージェント分野においてマイクロソフトのGitHub Copilot Coding Agent、AWSのAmazon Q Devel
【AWS re:Invent 2024】Generative AIによる未来のUXの広がりを感じた - カミナシ エンジニアブログ
はじめに カミナシでID管理・認証基盤を開発しているmanaty（@manaty0226）です。12/6までラスベガスで開催されていたAWS re:Invent 2024に初めて参加しました。今回は最終日のワークショップセッションとして開催された「Build generative AI-powered search with Amazon Aurora and Amazon RDS」を聴講したレポートをお届けします。 生成AIによる検索機能の拡張 このワークショップでは架空のEC企業Baize BazaarのECサイトにおける検索機能を作ります。単なる全文一致や部分一致検索ではなく、自然言語による問い合わせに対応したり、あらかじめ登録されたユーザーの嗜好に合わせた商品を検索結果として返すために生成AIを利用します。今回のワークショップで利用したコードはGitHubに公開されています。 ht
[新機能]Webサーバでの実装不要！ALBだけでリダイレクト出来るようになりました！ | DevelopersIO
今回は ELB の新機能のご紹介です。 Elastic Load Balancing で Application Load Balancer のリダイレクトおよび固定レスポンスのサポートを発表 これまでリダイレクトは、Web サーバー側で実装する必要がありました。代表的な例としては、昨今、Web サイトのセキュアな通信、検索ランキングの向上を目的とした、HTTP → HTTPS のリダイレクトは多くのWebサーバーで実装されていると思います。ALB を経由した場合、リダイレクトループを回避するために X-Forwarded-Proto ヘッダー を利用したリダイレクトループ回避の実装など、ちょっとした工夫が必要でした。 今回のアップデートによって、これらのリダイレクトを ALB 側で実装できるようになったということです！これは嬉しいですね！ なお、同時に発表された固定レスポンスの新機能につ
![[新機能]Webサーバでの実装不要！ALBだけでリダイレクト出来るようになりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/da1eaab5e3526d75eb26418bdcdcb74efebd32da/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F02%2Felb.png)
クラウドストレージ、特にオブジェクトストレージについて質問があります。 AWSを例に出すとS3への書き込み速度と読み込み速度はローカルのHDDとSSDの中間くらい出ている認識です。そのような性能を持っているのに25ドル/TBのような安価で提供できているのはどのような実装がされているのでしょうか？ | mond
クラウドストレージ、特にオブジェクトストレージについて質問があります。 AWSを例に出すとS3への書き込み速度と読み込み速度はローカルのHDDとSSDの中間くらい出ている認識です。そのような性能を持っているのに25ドル/TBのような安価で提供できているのはどのような実装がされているのでしょうか？ 軽く検索するとS3のレイテンシは1桁ミリ秒、帯域はクライアント側のネットワークがボトルネックになるまで(つまり100Gbpsレベル)出るようですね。しかも99.999999999%(11ナイン)の耐久性という数字は生半可な努力で出せる数字ではありません。 なぜそんな高速なストレージがこんなに安いのかというのは一言では「経済の力」となりますがもう少し噛み砕くといくつかの要素があります。 S3はまき餌かも知れないクラウドビジネス各社ではオンプレミスやコロケーションで顧客自身が契約している物理ハードウェ
多段 ssh するなら ProxyCommand じゃなくて ProxyJump を使おう
概要 AWS とかで踏み台ホスト経由（ここでは AWS っぽく bastion と呼ぶ）で ssh する必要があるなら ~/.ssh/config は↓みたいにしとくのが良いんじゃないかな？ Host bastion Hostname bastionのIPアドレス User bastionのユーザ名 # ↓は規定のファイルだったり ssh-agent 使ってれば不要 IdentityFile bastion接続用の秘密鍵ファイル名 # ↓の3つはWindowsでは使えないので諦めて ControlMaster auto ControlPath ~/.ssh/cp-%r@%h:%p ControlPersist 10m Host 好きな接続先名 Hostname 接続先のIPアドレス User 接続先のユーザ名 # ↓は規定のファイルだったり ssh-agent 使ってれば不要 Identi
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
OpenAI日本法人に｢AWSジャパン前社長｣が移籍
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
ログ調査基盤を構築してみた
こんにちは。 株式会社ココナラのインフラ・SREチーム所属の かず です。 システム運用において、有事の際に迅速かつ適切なシステム稼働状況の確認は欠かせません。 その手段の1つとして、ログの調査や分析の効率化は切っても切れない関係です。 システムが成長するにあわせ、ログの種類や量が多くなり、結果としてログの調査や分析が難しくなるのはよくある話かと思います。 弊社でもサービスのグロースに伴って、ログの種類や量が多くなり、結果としてログの調査や分析で課題を抱えていました。具体的には以下の2点です。 ログから原因調査を行うには、複数ログを横断・突き合わせが必要 ログの追跡に必要な情報がログに出力されない場合がある そこで、課題への対応としてログ調査基盤の構築を行いました。 本記事では背景や苦労したこと、効果についてご紹介します。 複数ログの横断調査実現に向けて ログ調査基盤の構築 苦労したこと
Google Cloud案件を1年半程度経験してみてAWSと比較しながら違いを整理してみた - NRIネットコムBlog
本記事は 【Advent Calendar 2023】 15日目の記事です。 🎄 14日目 ▶▶ 本記事 ▶▶ 16日目 🎅 はじめに 想定している読者 一覧 まとめてみて 参考 はじめに クラウド事業推進部の小野内です。昨年5月にキャリア入社してから早1年半以上が経ちました。 入社以降、AWS、Google Cloud のデータ分析基盤の開発・運用に関わっておりますが、現在はGoogle Cloud メインでやってます。 試行錯誤の毎日ですが、Google Cloud案件をどんどん盛り上げていきたい所存です。 1年ほど前の投稿記事では、 Google Cloudの学び方について触れましたが、本記事ではGoogle Cloud案件を1年半程度経験してみて、 AWSと比較しながら、Google Cloudの主要なサービスについて、違いを整理しました。 想定している読者 AWS案件に半年以
AWS ECS Fargate のCPU性能と特徴 | 外道父の匠
ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在
AWS、MariaDBの最上位スポンサーになったと発表。なぜMariaDBの大口スポンサーに？
Amazon Web Services（AWS）は、オープンソースとして開発されているリレーショナルデータベース「MariaDB」の最上位スポンサーとなるダイアモンドスポンサーになったことを明らかにしました。 AWS is now the first diamond sponsor of the MariaDB Foundation @mariadb_org AWS engineers are significant contributors to the #opensource databases that our managed services are built on and that our customers depend on. Read more: https://t.co/VWzxIQzdPK #AWSCloud pic.twitter.com/97va28nHKl —
【15分で確認】AWSでクラウド設計する時に覚えておきたい設計原則・アーキテクチャ３選 - Qiita
1. マイクロサービスアーキテクチャ マイクロサービスは、独立した小さなサービス群でソフトウェアを構築するアーキテクチャです。これにより、迅速なイノベーションと新機能の迅速な展開が可能となります。一方、モノリシックアーキテクチャは、全てが一つのサービスとして結合され、変更や障害が全体に影響を及ぼしやすいです。マイクロサービスは独立して動作するため、各サービスのアップデートやスケールが容易です。特徴として、自律性、特殊化、俊敏性、スケーリングの柔軟性、容易なデプロイ、技術的自由、コードの再利用、耐障害性が挙げられます。 マイクロサービスの概要に関しては以下の記事が非常にわかりやすくシンプルにまとめられているので、ぜひ読んで頂くのがベストです。なお、本記事ではマイクロサービス支えるアーキテクチャ・技術をAWSのリソースに絞って紹介します。 (1)API Gateway パターン API ゲート
「Datadog入れてみたらAWSの料金が爆発した話」@ゆるSRE勉強会 #1
ゆるSRE勉強会 #1 でお話しさせて頂いたLTの資料です！ https://yuru-sre.connpass.com/event/292063/
Amazon ECRとInspectorのイメージスキャン機能の違い - Qiita
脆弱性の検知対象 基本スキャンはオープンソースの Clair プロジェクトの CVE データベースを使用したスキャンを提供します。脆弱性の検知対象は OS パッケージのみです。 拡張スキャンは OS パッケージに加え、プログラミング言語パッケージの脆弱性を検知することが可能です。対応するプログラミング言語は以下のとおりです。 C# Golang Java JavaScript PHP Python Ruby Rust 脆弱性の検知タイミング 基本スキャンはイメージが Push された際にスキャンを起動する (Scan on push) か、手動でスキャンを開始することができます。そのため脆弱性を検知できるタイミングもそのどちらかになります。手動スキャンの実行は各イメージごとに24時間に1回に制限されます。 拡張スキャンではリポジトリに対し連続スキャンを利用することができます。連続スキャンは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon ECS & AWS Fargate 今昔物語 / past and present stories of Amazon ECS and AWS Fargate
AWS の最新情報
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
