AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
個人的AWS ログ管理のベースライン - mazyu36の日記
AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs（以下CW Logsと記載）とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など
Best Practices for Tagging AWS Resources - Best Practices for Tagging AWS Resources
Publication date: March 30, 2023 (Document revisions) Amazon Web Services (AWS) allows you to assign metadata to many of your AWS resources in the form of tags. Each tag is a simple label consisting of a key and an optional value to store information about the resource or data retained on that resource. This whitepaper focuses on tagging use cases, strategies, techniques, and tools that can help y
GitHub - aws/aws-cdk: The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation. It offers a high-level object-oriented abstraction to define AWS resources imperatively using the power of modern programming languages. Using the CDK’s library of infrastructure constructs, you can easily encapsulate AWS best
AWSの新サービス群に対する一行所感 - プログラマでありたい
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな？認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか？ 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに（≒一人の人間）が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
概要 Lambdaは100msの実行時間単位でオンデマンドに課金されるため、立ち上げっぱなしのEC2インスタンスよりも、料金が安くなる可能性があることが一般に知られている。 しかし、以下の性質を満たすアプリケーションでは、EC2インスタンス上に構築したケースと比較して、Lambda上に構築したほうがコスト効率が悪くなるのではないかと考察してみた。 Lambda functionの実行時間のうち、ネットワークI/O時間が支配的である Lambda functionの実行終了を同期的に待たなければならない 複数のレコードをLambda functionの引数に渡すことができない Lambdaの基本コスト構造 まず、Lambdaのコスト構造を把握する。 Lambdaの料金表[1]によると、「functionに対する合計リクエスト数」と「functionの合計実行時間」に応じて料金が発生する。 後
ミドルウェア性能検証の手引き | 外道父の匠
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
クラウドサーバに対する脆弱性診断の事前申請について各社に問い合わせてみた結果 - VAddyブログ - 継続的セキュリティテストへの道 -
先日このようなブログ記事が公開されました。 クラウドサービスを脆弱性診断する時のお作法 とある企業において脆弱性診断をされている「とある診断員」さんのブログで、クラウドサービス（IaaS）の利用者が脆弱性診断をする際の注意点がまとめられています。 この記事の中に 脆弱性診断を実施する際には、ご自身の利用しているプラットフォームの事業者にちゃんと確認をした方が良いと考えます。 という言及があります。 VAddyはサーバー上のWebアプリケーションに対する脆弱性診断（ブラックボックステスト）を行うサービスですので、これに当てはまります。 上記のブログ記事ではAWS、Microsoft Azure、Google Cloud Platformのポリシーをまとめていただいているので、便乗して日本国内のクラウド事業者のポリシーについてまとめてみました。 主要クラウド事業者の脆弱性診断に関するポリシー
政府統一基準に準拠したAWSクラウド利用のセキュリティリファレンスを共同で提供開始
株式会社NTTデータ（本社：東京都江東区、代表取締役社長：岩本 敏男、以下：NTTデータ）、PwCあらた有限責任監査法人（東京都中央区、代表執行役：木村 浩一郎、以下：PwCあらた）、富士ソフト株式会社（本社：神奈川県横浜市、代表取締役 社長執行役員：坂下 智保、以下：富士ソフト）ら各社は共同で、内閣サイバーセキュリティセンター（以下：NISC）制定の政府統一基準に対応したセキュリティリファレンス（以下：リファレンス）を作成し、2017年3月23日より、政府機関向けに無償提供を開始します。本リファレンスは、クラウドサービス「アマゾン ウェブ サービス」（以下：AWS）環境におけるセキュリティ対応策の詳細を網羅的に提示しています。 NISCは2016年8月31日に、国内の政府機関が準拠すべき指針「政府機関の情報セキュリティ対策のための統一基準（平成28年度版）」（以下：「政府統一基準」）を改
Create a Professional Blog with AWS and Ghost
A professional blog is a great way to showcase your projects and knowledge in a consolidated place. There are a plethora of blog options to choose from, including Medium, Blogger, Tumblr, Wordpress, and many more. When I created my blog I decided to explore my options. I eventually landed on The Ghost Blogging Platform for various reasons, but mostly because it’s open source and maintained by rad
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Choosing a packaging mechanism for Java based AWS Lambda functions
GitHub - architect/architect: The simplest, most powerful way to build a functional web app (fwa)
DeNA の AWS アカウント管理とセキュリティ監査自動化
GitHub - cloudtools/stacker: An AWS CloudFormation Stack orchestrator/manager.
cloudtools/troposphere: troposphere - Python library to create AWS CloudFormation descriptions
GitHub - duo-labs/cloudmapper: CloudMapper helps you analyze your Amazon Web Services (AWS) environments.
GitHub - KoteiIto/node-athena: a nodejs simple aws athena client
GitHub - milo-minderbinder/AWS-PlantUML: PlantUML sprites, macros, and other includes for AWS components.
TechCrunch
GitHub - bdeitte/ghost-on-aws: Guide to installing Ghost on AWS