使った分だけ利用料金が発生するAWS（パブリッククラウド）環境、EC2などをメインで利用されている方は、停止しておけば完全無料！と考えられている方もおられるのではないでしょうか。 VPC内で作成できるリソースには、存在するだけで料金が発生するものもいくつかあります。 私も検証環境でいつの間にか料金が発生し、もったいない！という経験が何度かありました。 今回は停止できずに料金がかかってしまうリソースを整理してみたいと思います。 みなさまの利用料金削減に貢献できれば幸いです。 想定するVPC構成 以下のような構成で環境構築しているとします。 作成されているリソースは以下の通りです。 （対象をVPC1内のみとします。） VPC ×１ サブネット×４ Internet Gateway ×１ NAT Gateway ×１ VPC Endpoint（S3用） ×１ VPC Peering ×１ Tra

はじめに AWS上で仮想ネットワークを構築できるAmazon VPCは、多くのAWSサービスが動作する基盤となる、非常に重要かつ多機能なサービスです。 多機能ゆえに公式ドキュメントやネット上の記事も断片的な機能の解説が多く、全体像を把握することが難しいサービスとも言えます。 そこで本記事はVPCの全体像を理解できるよう、各機能のつながりや動作原理を丁寧に解説し、 「VPC界の百科事典」 (あくまで例えですが…笑) となるような記事を目指したいと思います。 【追記】 実践編の記事を追加しました VPCの実画面での構築方法は、以下の別記事にまとめました。「VPCを実際に触ってみたい！」という方は、こちらもご一読いただけると嬉しいです。 VPCとは 「Virtual Private Cloud」の略で、クラウド上に仮想的なネットワークを構築するためのサービスです。 例えば、オンプレ環境でWebア

はじめに AWS上に立てたEC2(WindowsServer2019)を手動で日本語化する手順をアウトプットしていきたいと思います。 OSは、Microsoft Windows Server 2019 Baseを使用します。 ※デフォルトでは、英語になっている。 前提 AWS上にEC2(WindowsServer2019)を作成したばかりの状態 リモートデスクトップ接続ができるよう設定済み 作業の流れ ①日本語化パッケージインストール・適用 ②時計合わせ 作業手順 ①日本語化パッケージインストール・適用 1.スタートボタンをクリックし、設定(歯車のマーク)を開く。 2.設定画面より「Time & Language」を開く。 3.「Language」を開く。 4.「Add a language」をクリックする。 5.「Japanese」と検索し、日本語を選択。選択後、「Next」をクリックす

Amazon Web Services ブログ AWS ファイルストレージサービスの選び方 オフィス文書や画像データなどの様々な非構造化ファイルを、ファイル共有サーバや NAS（Network Attached Storage） などに格納して共有で利用されている方も多いと思います。AWS のファイルストレージサービスを利用することで、ファイル共有ストレージを簡単にクラウド上へ構築できます。また、AWS が提供するフルマネージドサービスのため、パッチ適用やストレージのディスク増設などの運用負荷を軽減できるメリットがあります。初期費用が不要の従量課金のため手軽に利用でき、調達が不要なのですぐに利用を開始することができます。また、ストレージのバックアップ機能が備わっているため、手間のかかるバックアップの設計や運用負荷も軽減できます。 AWS のファイルストレージサービスは、Amazon Ela

(追記) 自動ログイン機能が利用規約に抵触していたらしく、マーケットプレイスより削除されました。 GitHubにAPIを使ったものは残っているので、知識があれば動作させられるかと思います。（自己責任） これを使った再配布等の行動はトラブルの元なので控えた方がよいでしょう。 ChatGPT いいよね 最近一番メッセージやりとりしてるのChatGPTだし、なんなら1日にしゃべる量よりChatGPTと話してることの方が多い可能性まであります ChatGPTのチャットツール自体はこちらから参加して試せるわけですが、プログラムを書くときに使ったことのない言語やライブラリを開拓する際ここまで有難い存在はありません． このようにネット上を探し回ると地味に時間のかかる情報もチャット形式で手に入ります． さて、今回の話題ですが、我が愛しのテキストエディタ「Visual Studio Code」のChatGP

概要 今回はTerraformを使って VPC パブリックサブネットとプライベートサブネット IGW ルートテーブルおよびルーティングの設定 Elastic IP NATゲートウェイ を構築したいと思います 今回作成するインフラ構成は下記の図のようになります 前提 東京リージョンを使用 AWSを使用 main.tfとvariables.tfを設定済み ネットワークに関する基本的な知識をある程度持っている 上記のファイルをまだ作成していない方は下記の記事を参考にしてください AWSにおけるネットワークの概要について知りたい方は以下の記事を参考にしてください また、コンテナ経由でTerraformを使用すると複数ブロジェクトで使用する際にバージョンによる違いを意識せずに済みます コンテナを使用したい方はこちらの記事も参考にしてみてください ディレクトリ構成 構成は以下の通りです # -----

あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。

はじめに 先日、エンジニア界隈では有名なポッドキャストであるfukabori.fmに出させていただきまして、そのときのトピックがサーバーレスでした。 ポッドキャストはこちらで聞けますのでぜひどうぞ。 fukabori.fm そこでもいろいろお話ししたのですが改めて話せなかったことなども含めて書こうかなと。つまり、ポエムです。散らかった文章な上に少し長めなのでお時間のある方だけどうぞ。 なお、サーバーレスの黎明期の話とかそういう思い出話は以前に書いたこちらの投稿があります。 サーバーレスと僕のこれまでとこれから - Sweet Escape 今回は思い出話ではなく、サーバーレスに個人として魅力を感じ、仕事としてその良さを広めたり、実装のお手伝いをし続けてきた自分がそういった仕事から離れた2022年現在どういう風に向き合ってるかについてのポエムです。 前提 現在の自分は株式会社Singular

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 自分がAWSをこれっぽっちも知らない頃、 ググって出てきたどこか知らんサイトからだと、「欲しい情報はこれじゃない」ってのが多くあった。 そんなこと繰り返していると エラー、トラブル時に即対応できない 間違って構築したせいで運用時に悪化してしまう 古いソースコードでエラーがでて動かない これで無駄な時間を過ごすことになる。 要は「ググって得たその情報で、作ったものは正しいのか？」 AWSは常にアップデートされ続ける 欲しい情報を手に入れるまで調べる時間を割くなら、 公式展開してるサイトから得たほうが正確である。 ということで、最

仕事力と技術力と不安に関する雑文 | YuheiNakasaka’s Diary を読んで、自分も勉強とは技術力とはなんぞやと考えてみたくなったのでポエムです。 詰まるところ人それぞれではあるものの、考えることは少なからず良い方向に向かう、そう願いたいものです。 勉強とは 世の中にある意見として、エンジニアは生涯勉強だとか、強々エンジニアになるための勉強だとか、色んなモノを見かけます。そういう勉強に対する意見ってたいていネガティブな印象の内容が多く、なんだか迷走しているなぁという感想を持つことが多いです。 良い子ちゃん視点では、学ぶこと、その全てには意義がある、と言いたいところですが、こと仕事においては無駄な学びもあるし、将来無駄になる学びもあります。また、自発的かどうかでその効果は天地の差があるので、他人に向かってこれくらいやるべきとか言うことの意味は薄く、突き詰めると自己責任の範囲の話

「あァァァんまりだァァアァ」 これ、「ジョジョの奇妙な冒険」第二部、主人公ジョジョの強敵エシディシというキャラクターの台詞です。 戦いの最中に突然泣きわめきはじめるのですが、それによって短時間で戦うための冷静さを取り戻して精神を安定させるというエシディシが使うメンタル調整法。それを見た主人公ジョジョは戦慄する、ジョジョ独特の名シーンです。 ぼくも(エシディシのように)気持ちを切り替える、スイッチするために言っていることあるな……と思ったので今日はぼくが気分をスイッチするために「言っていること」について書きたいと思います。 「また痛みを知って強くなってしまったな」 失敗をしたり上手くいかないことがあるとき、過度にクヨクヨしたり失敗したことを考え続けると疲れるし、反省を通り越してネガティブなことばかり考えちゃいますよね。 そういうときスイッチするために「失敗を知ったことで、またまた強くなってし

こんにちは。オペレーション部の橋本です。 ストレージ容量を必要に応じて手軽にサイジングできるのがEC2及びEBSボリュームの魅力ですね。 今回はEC2 WindowsにアタッチしているEBSのボリュームサイズを拡張してするための手順を、自分の備忘録も兼ねて書いてみました。 今回実施する手順 EBSボリュームのサイズを増やす AWSマネジメントコンソールから操作する場合 AWS CLIから操作する場合 OS(Windows)側の設定でボリュームサイズを拡張する 下記のドキュメントの手順を参考に進めます。 EBSボリュームのサイズを増やす AWSマネジメントコンソールから操作する場合 対象インスタンスのルートボリュームにアタッチされているEBSボリュームを選択します。 「アクション」→「ボリュームの変更」をクリックすると、ポップアップが表示されます。サイズの値を50から60に変更してみます。

マネージャーは非常に重要な役割であり、従業員の業績に大きな影響を与えます。優れたマネージャーの条件を共有し、能力開発の機会を提供し、優れたマネージャーを称賛するなどの方法で、従業員をサポートしましょう。 Google はこれまで、マネジメント業務の大切さを必ずしも正当に評価してきたわけではありません。2002 年、すべてのマネージャーを廃止して管理職のいない組織にするという「実験」を行いました。しかし、この実験は失敗に終わりました。2008 年には、調査チームが、マネージャーは重要な存在ではないという一部の意見を証明しようと試みますが、すぐにまったくの正反対であることがわかりました。つまり、マネージャーはきわめて重要な存在だったのです。 そこで、Google における優れたマネージャーの条件とは何かを正確に突き止めるため、「Project Oxygen」という調査プロジェクトが実施されまし

先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ／ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か？技術力が高くないとなぜ不安なのか？みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ

猛烈なスピードでテクノロジーが進化する予測不可能な社会、いまはどうにも解決しがたい問題、未知のウィルスなど……不確実性を持つ要素は、世にあふれかえっています。 不確実性は人々を不安に陥れ、不十分で焦った判断や行動を促進させますが、すぐには答えの出ない事態に耐える力「ネガティブ・ケイパビリティ」があれば、物事の本質に深く迫ることができ、気づきを生み出せるのだとか。今回は、ネガティブ・ケイパビリティの高め方に取り組んでみました。 不確実性によく効く能力とは 最近、ビジネスの現場でよく耳にする「VUCA（ブーカ）」は、Volatility（変動性）・Uncertainty（不確実性）・Complexity（複雑性）・Ambiguity（曖昧性）の頭文字をとった、現代社会を表す言葉。複雑性が増し、想定外のことが次々と起こる予測困難な状態を指します。 日本アイ・ビー・エム部長の河野英太郎氏によれば、

自分は問題解決は得意な方だと思っている。しかし逆に不確実な状況・不安な状況・課題がある状況をそのままにして耐える力をもっと付けたいなと思っている。そこで最近目にした「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」であるネガティブ・ケイパビリティについて学ぶため本を読んでみた。 ネガティブ・ケイパビリティ　答えの出ない事態に耐える力 (朝日選書) 作者:帚木　蓬生朝日新聞出版Amazon 正直、この本は歴史的な話とか雑談も多く、少し頭に入りにくかったが、一方で示唆のあることを学べた。例えば どうにも対処が難しい課題を見つけた時に、拙速に解決策を見出すのではなく、興味を抱いてその宙吊りの状態を耐えると良い。それによって深い理解に行き着く 問題解決があまりに強調されると、まず問題設定の時に、問題そのものを平易化してしまう傾向が生まれる。この時、複雑さを削ぎ落としているので、現実

たとえば、詳細設計から結合試験までを行う場合なら、 13sp + 13sp + 13sp + 19.5sp = 58.5sp と計算します。 スクラムでやるなら1スクラムあたり何sp消化できるか、ウォーターフォールなど日数を見積もりたい場合は、そこから1spが何人日かを予め定義しておいて、実際の工数を割り出します。 (1スプリントで10sp消化できるとした場合は6スプリントかかる計算になるし、1sp=0.5人日とした場合は、29.5人日≒1.5人月となります) なお、この比率は求められる品質レベルから算出します。 たとえばドキュメントをかっちり書く必要があるのなら設計の比率を上げる必要がありますし、メモレベルでよかったり、GitのPullRequestなどに記載する程度でいい場合は比率は下がるでしょう。テストの工数も同様です。なお、上記のは「ある程度かっちりやる」場合の比率です。 比率を算

Cloud Native Days Tokyo 2022 Session: https://event.cloudnativedays.jp/cndt2022/talks/1518

●発表のアーカイブ動画はこちら：https://youtu.be/4rgGkoyUaZw ●発表の中で紹介しているUdemy講座：https://www.nextskill.co.jp/courses === プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「…

バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。