How an empty S3 bucket can make your AWS bill explode
Update AWS started investigating the issue: https://twitter.com/jeffbarr/status/1785386554372042890 Imagine you create an empty, private AWS S3 bucket in a region of your preference. What will your AWS bill be the next morning? A few weeks ago, I began working on a PoC of a document indexing system for my client. I created a single S3 bucket in the eu-west-1 region and uploaded some files there fo
NodejsFunctionのビルド時に依存関係を解決する3つの方法 - maybe daily dev notes
AWS CDK TIpsシリーズの記事。 タイトルの通り、AWS CDKのNodejsFunctionを使う時に依存関係を解決する方法が数パターンあるので比較してみる。 例 今回は、以下のTypeScriptのLambdaをデプロイするケースを考える。 // よくあるAPI GatewayのLambda Authorizer import { APIGatewayRequestAuthorizerHandler } from 'aws-lambda'; import { verify, decode } from 'jsonwebtoken'; export const handler: APIGatewayRequestAuthorizerHandler = async (event, context) => { const token = event.headers?.Authoriz
Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
AWS CDKのチーム開発時に実装時の考慮事項、意識合わせした点について - mazyu36の日記
はじめに 以下の記事でAWS CDKにおけるチーム開発のフローやテストについて記載した。 mazyu36.hatenablog.com mazyu36.hatenablog.com 今回は実装内容についてチーム内で意識合わせしておいた方が良いと思った点をまとめておく。 はじめに 前提 1. Stackの分割基準 極力Stackを分割しないパターン 共通的に使用するリソースを切り出すパターン Stack間参照を避けられない場合の対応 2. ConstructIdの命名規則 3. リソース名つけるか問題 インフラ担当者以外が参照することが多いリソースは名称をつける 他リソースは自動生成するが、判別するためにタグを付与する 4. 不要なリソース、ログの残存の回避 CloudWatch Logsのロググループ S3バケット KMS CMK おわりに 前提 チーム開発のフローの記事に記載した環境構成
CloudWatch LogsのログをBigQueryで分析できるようにする | MoT Lab (GO Inc. Engineering Blog)
次世代事業本部 データビジネス部 KUUグループ の田中です。 今回はシステムのログを分析をしやすくするためにAWSのCloudWatch LogsのログをGCPのBigQueryに転送する仕組みを構築し、BigQuery上で分析できるようにした話です。 はじめに株式会社ゼンリンと共同開発中の本プロジェクト（ニュースリリース）では、複数のモジュールに分割して開発したアプリケーションをAWS上にサーバレスで構築し、システム全体がスケーラブルかつ機能ごとの拡張性が高くなるように設計・開発を進めています。 全体像は弊社の渡部が登壇したDeNA TechConn 2021の「ドライブレコーダの動画を使った道路情報の自動差分抽出」をご覧いただくと、より具体的にイメージしやすいかと思います。 BigQuery上でログを分析したいシステムは現在開発中ですが実データを用いた検証や短期運用が始まっており、各
GitHub Actions To Amazon ECRをCDKで用意する
はじめに GitHub ActionsでDocker Imageをビルドして、ECRにPushするやつないかな。と調べたら素晴らしい記事が出てきたので、あっという間に終わってしまった。 新たに書く必要もない気はしつつ、該当の記事はTerraformを前提に置かれていたため、AWS CDK派の人向けに読み替えた手順を公開する。 CDK Github ActionsからECRへアクセスするために作成したいリソースは、以下だ。 IAMのOIDC Provider Github Actionsに利用させるIAM Role (任意)ECR Repository これをCDKで表現するとこうなる。 import * as cdk from "aws-cdk-lib"; import { Construct } from "constructs"; import * as iam from "aws-c
IAMユーザーにAssumeRoleの権限が無くてもスイッチロールできる（ように見える）のはなぜですか？ | DevelopersIO
困っていた内容 スイッチロールの信頼関係設定における AssumeRole権限について質問します。 自アカウントのIAMユーザーに、自アカウントのIAMロールにスイッチできるよう設定を行っています。 ロールの信頼関係を次のようにアカウント（ root = アカウント自体 の意味になります）で指定した場合、ユーザーに「sts:AssumeRole」のアクセス権限が必要だと認識しています。 arn:aws:iam::XXXXXXXXXXXX:root 一方で、ロールの信頼関係を次のようにユーザー名で指定すると、ユーザーに「sts:AssumeRole」のアクセス権限が無くてもスイッチロールできてしまいます。 arn:aws:iam::XXXXXXXXXXXX:user/username このような振る舞いの違いが起きるのはどうしてでしょうか？ ユーザー名で指定する方法でスイッチロールする場合、
AWSの静的ウェブサイトホスティングで入門するAWS Amplify(Console、CLI) － 概要編 - NRIネットコムBlog
小西秀和です。 この記事を書こうと思ったきっかけは、タイトルの通りAWS Amplifyの登場です。 AWS CLI、AWS CloudFormation、AWS Serverless Application Model(AWS SAM)、AWS Cloud Development Kit(AWS CDK)といったAWSインフラストラクチャをプログラマブルに操作するサービスが登場してきましたが、AWS Amplifyはこれまでとは違う新たなアプローチになっています。 今までAWS CLIは使っていたけど結局色々あってAWS CloudFormationはあまり使ってこなかったというケースでもAWS Amplifyがユースケースにマッチする可能性があるかもしれません。 今回はAWSのサーバーレスな静的ウェブサイトホスティングを題材にAWS Amplifyの特徴と簡単な使い方について書こうと思
Nginxのリバースプロキシ設定、転送先がCloudFrontの場合 | 稲葉サーバーデザイン
はじめに Nginxのリバースプロキシ設定で、さらに、転送先がAWS CloudFrontという場合の設定方法がすごく難しかったので、ここにまとめておきます。 要件 Nginx で、https://www.example.com/foo/～ へのリクエストを、 AWS側のCloudFront https://example8.jp/～ に転送するものとします。 構成図は以下のとおり。 CloudFrontディストリビューションには、CNAMEsとして example8.jp を指定し、CommonName: example8.jp の証明書を適用済み。 CloudFrontのバックエンドはEC2です。 Apacheであれば、以下の設定でOKなんですが、Nginxはけっこう複雑でした。 SSLProxyEngine On ProxyPass /foo https://example8.jp
個人的AWS ログ管理のベースライン - mazyu36の日記
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs（以下CW Logsと記載）とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、... - Sooey
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、である」調にしたため多少偉そうに見えるかもしれませんが、原文はとても誠実な表現で書かれていますので、その点は誤解なきよう。 一部、文意が汲めなかった部分は原文を併記していますので、ご意見・ご指摘などがありましたら@junyaまでお願いします（@irohirokiさん、アドバイスありがとうございます）。 Resolved: Widespread Application Outage Herokuを4年間運用してきて最大の障害 専用データベースを利用している大規模アプリケーションでは最大16時間のダウンタイム 共有データベースを利用している小規模アプリケーションでは最大60時間のダウンタイム アプリケーションのデプロイについてはプラットフォームの広範囲にわ
AWSのシステム構成情報を集めて構成図を自動生成してくれる「CloudMapper」、オープンソースで公開
AWSのシステム構成情報を集めて構成図を自動生成してくれる「CloudMapper」、オープンソースで公開 CloudMapperを用いることで、AWS上のシステムについて以下のような状況をすぐに把握することができると説明されています。 どのリソースがインターネットに公開されているか？ どのリソース同士がつながっているのか？ アベイラビリティゾーンが落ちたときでも十分堅牢なアーキテクチャか？ このアカウントはいくつのリージョンを利用しているか？ どれだけ大きないシステムを運用しているか？ CloudMapperを開発しているDUOは、セキュリティサービスを提供する企業。同社は自身もAWSユーザーで、さまざまなオープンソースのツールを試してみたものの満足できるようなものがなかったため、自社でCloudMapperを開発したとのこと。 CloudMapperの仕組みは、まずAWSコマンドライン
今日から始める人のためのKubernetes on AWSベストプラクティス - Qiita
今年一年Kubernetes on AWSをやってきて、kube-awsメンテナ目線で、「今日から、できるだけ楽に、安定して本番運用」するための個人的ベスト・プラクティスをまとめておきます。 TL;DR EKSはまだプレビュー申込の段階。実際に動くものがあるかもわからない。 EKSとkops、kube-aws、kubesprayなどは組み合わせて使うもの。代替えにはならない。 SaaSありなら分散ログ、分散トレース、リソースモニタリングはDatadogに寄せると運用が楽 istioは安心して本番運用できるフェーズではない(Service Meshが必要なら、まだLinkerdのほうがよい) アプリケーションにPrometheusエンドポイントを生やしてメトリクスを取れるようにすべき アプリケーションはOpenTracingやZipkin、Jaegerなどのトレーサを組み込み、Zipkin
aws-vault でアクセスキーを安全に - FLINTERS Engineer's Blog
あけましておめでとうございます。河内です。 数ヶ月前に aws-vault を使い始めて安全の高まりを感じるので紹介します。 AWSのサービス上では IAM Role をできるだけ使ってアクセスキーを使わないようにしていますが、ローカルでの開発時にIAMのアクセスキーを利用することはあります。 アクセスキーが漏れると困ったことになります。 本番環境で利用している AWS アカウントで漏れると、付与している権限次第では機密情報が漏洩したりサービスが壊される可能性があります。 また開発環境としてのみ利用しているAWSアカウントであっても、ビットコインのマイニングなどで容赦なくリソースを消費され高額な請求が来たりする可能性ががあります。 そのようなことが起きないようにアクセスキーは安全に管理する必要があります。 通常はAWS SDK のデフォルト参照先である ~/.aws/credentials
CodePipeline で ECS にデプロイできるようになり、Docker 環境の継続的デリバリも簡単になりました | DevelopersIO
ども、藤本です。 現地時間 2017/12/12、CodePipeline のデプロイにて、ECS を選択できるようになり、ECS Service にデプロイできるようになりました。 AWS CodePipeline Adds Support for Amazon ECS and AWS Fargate 早速、試してみました。 概要 AWS CodePipeline は AWS や AWS 以外の SaaS を繋ぎ合わせて継続的デリバリを実現、モニタリングするサービスです。今まで CodePipeline が連携可能なデプロイサービスには CodeDeploy、Beanstalk、CloudFormation、OpsWorks の 4つがありました。ここに ECS が加わりました。ECS へのデプロイには、今までの EC2 上のコンテナにも可能ですし、先日の re:Invent 2017
Amazon ECS ScheduledTaskで実現するスマートなDockerベースのバッチ実行環境 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 コネヒトでは、開発環境に続き、続々と本番サービスにもDockerを導入しています。 今回は、中々運用が大変なcronでスケジュール管理するような定期的なバッチ処理を、Amazon ECSのScheduledTaskを使ってDocker駆動な環境で構築した話です。 他の方法との比較やどのように実現しているのかについて紹介したいと思います。 今回対象とするバッチの種類 今回対象とするバッチ処理は、俗に言うスケジュール系のバッチ処理で、毎日00時00分や10分毎にサイクル起動等、事前に定義した時間に正確に動くことが期待されているものです。 ※ジョブキュー形式のバッチだと、AWS BatchやEBのWorkerもしくは、SQS + Cron on EC2で処理するほうがスマートかと思います。 実行方式の選定 上記要件のバッチを実現する基
RDBへのバッチクエリクライアントタスク
本記事は個人の意見であり、所属する組織の見解とは関係ありません。 こちらは AWS Fargate Advent Calendar 2017 の 12/4 分の記事です。 AWS Fargate を利用することで、従来のサーバーレス環境では工夫が必要であった長時間処理（業務処理的なバッチ）を、容易にサーバーレス環境で実現することが可能となりました。今回は、参考例として DB に対して長時間クエリが可能な仕組みを作成してみたいと思います。 構成概要 AWS Fargate 上で長時間タスクを実行する仕組みとして、下記の構成を作成してみます。 今回は SQL を実行する仕組みですが、メイン処理次第ではさらに複雑な処理の実行も可能と思っています。 Amazon S3 タスクのメイン処理の Python スクリプト、検索結果ファイルを格納します。 Amazon Aurora クエリ先のデータベース
AWSの新サービス群に対する一行所感 - プログラマでありたい
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな？認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか？ 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに（≒一人の人間）が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 / ideal-and-reality-when-implementing-cicd-for-ecs-on-fargate-with-aws-cdk
実践 AWS CDK 〜 いろいろな参照のカタチと使い分け 〜
