AmazonのクラウドコンピューティングサービスであるAWSが提供するストレージサービス・Amazon S3では、写真や動画などのデータをアップロードするためにバケットを作成する必要があります。このS3バケットを空の状態にしていると、AWSの請求額が爆発的に増加してしまうという問題を、ソフトウェアエンジニアのMaciej Pocwierz氏が報告しました。 How an empty S3 bucket can make your AWS bill explode | by Maciej Pocwierz | Apr, 2024 | Medium https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1 Pocwierz氏はクライアント向けに作成

はじめに AWSアカウント作成時、デフォルトのVPCが一つ作成されます。 このデフォルトVPCを使用することで、すぐにEC2などのリソースを作成することができるという利点があります。 一方で、デフォルトVPCには自身が把握していないルートテーブルやセキュリティグループが含まれる可能性があります。 そこでリスクヘッジのためにデフォルトVPCの削除を検討される方も多いかと思います。 今回はそんなデフォルトVPCを削除する前に確認しておくことを記載します。 いきなりまとめ リソースが紐づいていなければデフォルトVPCは削除しても大丈夫です。 また、デフォルトVPCが必要になった場合は再度作成することもできます。 削除前の確認 VPCは削除する際に関連するリソースが表示されます。 実際にやってみましょう。 VPCの画面からデフォルトVPCを削除します。 関連するリソースが存在すると怒られました。

TL;DR 東京リージョンを利用する際に2AZの冗長化で良い場合のAZ選定 「apne1-AZ1, apne1-AZ2」の組み合わせで利用するのが、レイテンシ観点からは良い。 レイテンシ: 900μs程度 大阪リージョンを利用する際に2AZの冗長化で良い場合のAZ選定 「apne3-AZ1, apne3-AZ2」の組み合わせで利用するのが、レイテンシ観点からは良い。 レイテンシ: 200μs程度 東京リージョンの方がAZ間レイテンシが平均的に高い(大阪リージョンと比較して) 大阪リージョンの方がAZ間レイテンシが平均的に低い(東京リージョンと比較して) 昨年2023年測定時との差異 2023年に測定した際の記事リンク(Zenn) 環境 インスタンスタイプ変更m5.large --> m6i.large 測定結果 東京リージョンにおける同一リージョン内のレイテンシが1/5~1/2程度になった

米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ

こんにちは、AWS事業本部の平木です！ AWS Systems Manager（SSM）パラメータストアのコンソール画面を見たところ、 「クロスアカウントパラメータ共有の紹介」と、アップデートが紹介されていました。 今まではPutResourcePolicy APIを活用して行う方法があったようですが、 今回のアップデートでより楽にパラメータを共有できるようになったので試してみました。 前提 共有先のアカウントからパラメータを利用する際は、AWS CLIまたはAWS SDKで利用します。 AWS CLIを最新のバージョンに引き上げておく必要があります。 構成 今回はせっかくなので少し工夫が必要なSecureStringのパラメータをKMSキーで暗号化し、 AWS Resource Access Manager(RAM)を使用し、Organizations内のメンバーアカウントから参照できる

https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17

2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro

はじめに こんにちは。クラウド事業部の野本です。 業務でモックサーバを作る際に、静的なファイルをふつうに URL でアクセスしてダウンロードできるようにする必要がありました。この用途に AWS の S3 を使いたいものの、バケットの設定を間違えると全世界に公開されてしまいそうで、公式ドキュメントを調べながら恐る恐る設定しました。 調べた結果、バケットポリシーで適切なアクセス制限を掛けるならパブリックアクセスブロック機能は有効のままでもいいことがわかりました。その設定方法や考え方について纏めます。 設定方法 S3 のオブジェクトを URL 直アクセスでダウンロードできるようにするには、 REST API GetObject を全員に許可するようにバケットポリシーを設定します。 リクエスト元を制限する際にポリシーが「非パブリック」と判定されるよう設定すれば、パブリックアクセスブロック機能はオン

この記事について 本記事は、筆者が普段AWSの各種サービスを使って感じた感想・気づきをもとに、クラウドアーキの設計やサービスのより良い使い方Tipsを考察するシリーズです。 第二弾も第一弾に引き続きDynamoDBについてです。 DynamoDBはkey-value型のNoSQLであり、従来よく使われていたRDBとは異なるDB特性・クエリ特性を持っています。 そのためRDBを設計するときと同じようなノリでスキーマ設計・テーブル設計を行うと、後から「この操作をやらせるならDynamoDBじゃないほうが良かったんじゃないか？」ということが発覚しがちです。 本記事では筆者が遭遇した「DynamoDBでやらせてみたら苦労した・できなくて設計変更を強いられた」というユースケースをまとめることで、DynamoDBのクエリ特性や適性を考察することを目指します。 使用する環境・バージョン 2024/1/1

こんにちは。プラットフォーム技術部の小林（雄）です。 クラウドサービスの普及により、セキュリティに対する要求も高まっている昨今、セキュリティ対策関連の運用業務も増加傾向にあるように感じます。 とりわけ定期的なパッチ適用、コンポーネントアップデート対応では多くの運用稼働を必要とし、場合によっては毎月本対応に追われることもあると思います。 本日はそんなパッチ適用、コンポーネントアップデート対応の手間を削減できるAWSのPatch Managerについてどのような仕組みなのか、どんなことができるのかについて確認していきたいと思います。 AWS Patch ManagerとはAWS Patch ManagerはAWS Systems Managerの一機能で、端的に表現するとEC2に対するOSパッチの適用を自動化できるマネージドサービスです。 各マネージドサービスの詳細は以下を参照ください。 Wi

なぜセキュリティグループで0.0.0.0/0からのインバウンドトラフィックを許可することが危険なのか？ はじめに こんにちは！AWS事業本部コンサルティング部の和田響です。 この記事では「なぜセキュリティグループで0.0.0.0/0からのインバウンドトラフィックを許可することが危険なのか？」について説明し、具体的な対策と検知の方法について記載します。 0.0.0.0/0からのトラフィックとは？ 0.0.0.0/0は、IPアドレスの範囲を指定するCIDR（Classless Inter-Domain Routing）表記の一つで、IPv4アドレス空間におけるすべてのIPアドレスを意味します。 つまり「0.0.0.0/0からのトラフィック」とはすべてのIPからの通信であり、インターネットのあらゆる場所からの通信と言い換えることもできます。(IPv6の場合は::/0と表記します。) なぜ危険なの

S3のコンテンツを管理したい そのWebサービスでは画像やJS、CSSなどの静的リソースをAWSのS3に上げて利用していたのですが、マネコンから手動でアップロードしている状態でした。 そのため、量が多いと作業も大変ですし、抜け漏れなどの人的ミスも発生していました。 元々その静的リソースはgitにも保存していたので、gitで管理しているリソースをawsのcliで aws s3 sync で同期した方が確実だし楽じゃん！、と思いデプロイ手順を変更しました。 gitとs3の手動同期 そもそも今gitとs3の中身って本当に同じなの？、という疑惑があったので、 aws s3 sync で全差分を出して一つずつチェック。 S3にしかないもの、gitにしかないもの、これどこで使ってるの？、みたいなファイルが山ほどあり、調整は時間を要しましたが、基本はS3に上がっているものが正なので、差分はS3のものを残

珍しく早起きをしてRSSを眺めてるとアッツアッツなアップデートが来ていました。 Amazon CloudFront announces CloudFront Functions, a lightweight edge compute capability 今回はCloudFront Functionsをご紹介していきます。 CloudFront Functionsとは？ CloudFront Functions(CF2)はLambda@Edgeより手前で、シンプルな処理をより高速に、素早く、安価に実行できるサービスです。 CloudFront Functionsを使うことでこれまでLambda@Edgeで実行していたシンプルな処理をよりユーザーに近いEdge Locationで実行しつつ、高速に処理を行う事ができます。 また、CloudFront FunctionsとLambda@Edge

先日10年勤務したNTTを退職してフリーランスエンジニアになりました。 流行りの？NTT退職エントリーですが、よくあるのはNTT研究所とかの超エリートがGAFAMでデータサイエンティストになりましたみたいな話ですが、 私の場合はグループでも底辺の話で、NTT持株会社から見るとひ孫会社で保守を専門にする会社で更に中途採用です。 研究所なんてほんの上位の話なので、NTTの実態として大量の底辺保守人材を抱えているので、ある意味リアルな話になるかなと。 自己紹介 NWエンジニア歴9年、AWSエンジニア歴1年の37歳。 NWエンジニアと言いつつほぼ監視のみという弱々エンジニアでしたが、AWSエンジニアに転向して1年でフリーランスに挑むことにしました。 前歴 新卒時は氷河期末期。 新卒は金融営業だったが1年で嫌気差し退社 次も金融だったがパワハラにあい1年で退社 鬱になり就職活動する気も起きないが金も

こんにちは。梅原です。 今日はECSのデプロイタイプについて改めて整理します。 ECSのデプロイ方法は3つあります。 ローリングアップデート Blue/Greenデプロイ 外部デプロイ の3つです。 この記事ではローリングアップデートとB/Gデプロイについて流れをおさらいします。 ECSの前段にALBを置いた構成を例にします。 ローリングアップデート ローリングアップデートの流れを見る B/Gデプロイ B/Gデプロイの流れを見る ローリングアップデートとB/Gデプロイの比較 最後に ローリングアップデート ローリングアップデートとは、稼働中のECSタスクをそのまま新しいタスクに置き換える方法です。一番オーソドックスなデプロイ方法なのではないでしょうか。 ECSのみでデプロイすることができ、設定箇所も主に後述する2つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた

はじめに こんにちは、ブランドソリューション開発本部バックエンド部SREブロックの小林（@mirai_kobaaaaaa）です。普段はWEARやFAANSというサービスのSREとして開発、運用に携わっています。 WEARではAmazon Elastic Kubernetes Service（以下、EKSと呼ぶ）を用いて複数システムのインフラ基盤を構築・運用しています。その中の1つとして、ワークフロー処理の実行基盤が存在しています。 本記事では、そのワークフロー実行基盤が抱えていた課題と、それらをどのように解決したのかを紹介します。また、付随して得られたメリットについても紹介いたします。 目次 はじめに 目次 WEARにおけるワークフロー ワークフロー処理内容 ワークフロー実行基盤の構成 ワークフロー実行基盤の課題 コスト内訳の調査 過剰なPodスペック Fargate実行時間の増大 ワーク

AWS Summit Tokyo 2016のセッション資料が最近になって公開されました。 http://aws.amazon.com/jp/summit2016-report/ 今回は、その中から「Amazon Aurora deep dive ～性能向上の仕組みと最新アップデート～」についてレポートします。 セッション資料 タイトル Amazon Aurora deep dive ～性能向上の仕組みと最新アップデート～ 動画 セッション資料 http://media.amazonwebservices.com/jp/summit2016/2D-02.pdf スピーカーについて 星野 豊 アマゾン ウェブ サービス ジャパン株式会社 データベースの専属ソリューションズ・アーキテクト San Francisco、Seatleなどにあるデータベース開発チームと一緒に仕事することが多い メディア