こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「海が走るエンドロール」です。 私は業務でお客様に AWS の様々なトレーニングを提供しているのですが、コースによっては AWS を利用したシステムのアーキテクチャ図を受講者自身に描いていただく演習を取り入れており、よくこんな相談を受けます。 「どうやって AWS のアーキテクチャ図を描くのが正解なんですか ?」 AWS のアーキテクチャ図を描く状況は以下のように様々な場面であり、同じような疑問や悩みをお持ちの方も多いのではないでしょうか ? 詳細設計で構成図が必要 チームで wiki などに図を貼り付けて残したい 構成検討フェーズなどで図を見てディスカッションしたい ワークショップを試しながら理解を深めるなど自分のために描きたい そこで今回は AWS アーキテクチャ図をどうやって描けば良いか悩んでいる方へ、

スライドマスターを使えば、 プレゼン資料作りを効率化できる スライドマスターとは「プレゼン資料全体で使う共通要素を一括管理できる、パワーポイントの機能」です。たとえば新しいスライドを挿入したとき、タイトルやページ番号、コピーライト表記などの要素は自動で配置されるのではないでしょうか。これはスライドマスターによるもので、プレゼン資料定番の要素に対してあらかじめ枠を用意し、資料作りをスムーズに進めやすくしているかたちです。 また、プレゼン資料ではスライドの決まった位置に会社のロゴマークを配置することがあります。そして、後からこのロゴマークの差し替えが必要になったとして、スライドの枚数が100ページほどあった場合、「古いロゴの削除・新しいロゴの貼り付け」この作業をひたすら繰り返さなければならないでしょうか？ 実際にはそうならないと思います。こんなときはスライドマスターにロゴマークを配置し、各スラ

要件定義で意識していることを言語化したくなった こんにちは、のんピ(@non____97)です。 皆さんは要件定義で意識していることを言語化したくなったことはありますか? 私はあります。 いくつかのプロジェクトで要件定義をしてきましたが、改めて考えると、普段は感覚でやっている箇所も多くあったなと感じています。 そこで、改めて言語化することで、プロジェクトごとのブレを抑えたり、さらにどういった対応が必要なのかが整理できる予感がしてきました。 ということで、以降、要件定義で意識していることと要件の例を紹介します。 なお、「要件定義とは」や「要件定義の進め方」は語りません。書籍やインターネット上に先人たちが大量にアウトプットしてくださっているため、そちらを参照ください。 特にIPAが公開している「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」や「システム再構築を成功

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 地方公共団体情報システムの標準化に関連して、ガバメントクラウドへの移行が本格的になってきています。 自治体はオンプレミスの庁舎やデータセンターから CSP 環境へ接続して、ベンダーとの調整も多く発生していると思いますが、パブリッククラウドはオンプレミスとは異なる調整が求められるし、分からないことも多く、困っている自治体職員も多いはずです。 そこで、AWS の話に限定されますが、ガバメントクラウドに環境の構築でベンダーと調整していくに当たり、持っておくと役に立つのではないかと自分が思った AWS のネットワークやガバナンスなどの知識につい

ドーモ、読者のミナ=サン、LayerX Fintech事業部（三井物産デジタル・アセットマネジメント（MDM）に出向）で、@ken5scalです。 久しぶりのAmazon SecurityLakeとログ系のブログです。セキュリティにおいても、紀元前よりサーバー、ネットワーク機器、アプリケーションなどから出力されるログを一元的に収集し、監視や分析を行うことで、インシデントの早期発見や対応が可能になることはよく知られています。その代表的なソリューションが、そう、皆様よくご存じのSIEMです。 当社では、従来のSIEM（DataDog SIEM）に加え、データエンジニアリング的なアプローチにチャレンジ、より強力なデータ基盤を用いた検知エンジンを目指しデータレイクハウスであるAWS SecurityLakeを採用しました。 こういった従来のSIEMにおける課題や経緯については、下記のブログをご参照

先日 AWS から Route 53 リゾルバーのエンドポイントを使ったプライベートホストゾーンへのサブドメインの委任がサポートされたとの発表がありました。 domain name system (DNS) delegation for private hosted zone subdomains can be used with Route 53 inbound and outbound Resolver endpoints. This allows you to delegate the authority for a subdomain from your on-premises infrastructure to the Route 53 Resolver cloud service and vice versa, これまで Route 53 側へサブドメインを委任することはサポー

こんにちは、こーへいです。 先日、「自治体標準化対象20業務・ベンダー向けガバメントクラウドワークショップ」に参加しました。 本記事ではワークショップで得られた知見や印象に残ったセッション内容について共有します。 本セッションについて 自治体標準化対象20業務・ベンダー向けガバメントクラウドワークショップ では、自治体におけるクラウド活用の最新事例や生成AI活用事例、コスト管理戦略について学ぶことができました。 開催日時：2025年6月17日（火）12:30-19:30 JST 場所：アマゾン ウェブ サービス ジャパン合同会社(東京都品川区上大崎 3-1-1 目黒セントラルスクエア) 同日にCG向けガバメントクラウドワークショップも開催されており、以下にて一緒に参加した同僚レポートしています。 アジェンダ アジェンダは以下の通りです、以下は私が印象に残った項目についてピックアップします。

上記の例だと、sftp.intra.example.com という独自ドメインのホスト名を名前解決すると、元のインターフェースエンドポイントのプライベート DNS ホスト名（endpoint_id.service_id.region.vpce.amazonaws.com）を名前解決した結果の IP アドレスが返ってくる仕組みです。 同様に、ALB などの AWS リソースに対するルーティングも Alias レコードで設定できます。 エイリアスレコードを使用すると、CloudFront ディストリビューションや Amazon S3 バケットなど、選択した AWS リソースにトラフィックをルーティングできます。また、エイリアスレコードにより、ホストゾーン内のあるレコードから別のレコードにトラフィックをルーティングできます。 CNAME レコードと Alias レコードとの違い ここで、DNS

＜要約＞ 5月に実施された自治体システム標準化ヒアリングでは、デジタル庁など国側が事業者に威圧的な質問を浴びせ、SNSで批判が噴出した。料金設定については「強気な価格だ」と決めつけて追及し、公共SaaSへの懸念を示した事業者には「メリットがないならやらなくてよい」と突き放す姿勢を見せた。投資回収期間など企業機密の開示を迫る場面もあり、価格圧迫に利用される懸念から独占禁止法上のリスクまで指摘されている。運用コスト3割削減をめぐっては「貴社がコミットしたのではないか」と詰問し、事業者を弁明に追い込む一幕もあった。一方、国はモダン化や公共SaaSを万能の“銀の弾丸”と位置づけるものの、効果検証や現場負担への配慮は後回しのまま。 全国1,741自治体を巻き込む国家プロジェクトだからこそ、官民の信頼が揺らげば計画全体が瓦解しかねない――今こそ対立ではなく「共創」のテーブルを再構築しなければ、デジタル

前回投稿した「コスト増の本質」これをご覧になった方から以下のようなコメントを寄せていただいた。少しでも説明できるよう綴れたらと思う。 これどうやって弊社内で説明しよう… この前上司が「そうかモダン化してないから高いのか…、モダン化ってなんだ？」て言ってて暗澹たる気持ちに… https://t.co/vtDEoRL0Z6 — 某市情シス@標準化担当 (@3xqeTWA_BOJO) June 8, 2025 ３割削減という目標をちゃんと考えよう　コストが下がるどころか上がることで全国の自治体が危機感を持っている。しかし待ってほしい。3割削減目標をちゃんと理解しているだろうか？ ３割削減目標とデジタル3原則①目指すと言っているだけ　あくまで当時の施策を作る段階での方向性で目指して進めて行こうというものだ。ましてや、システムが変わっただけで、個々の自治体それぞれなんてどこにも書いていない。おそらく

いよいよ数年前から誰もが予想し予想通りの結果になりつつある自治体システム標準化のコスト増の問題。最近、共闘プラットフォームなる組織から衝撃的なnoteがリリースされた。 これまで長い間この国の施策に汗水を流してきた事業者を自治体システムの知識が低いワーキングメンバーがあたかもコスト増は事業者の責任の如く失礼極まりない会議が行われ公開処刑に近い形の議事要旨が公開された。界隈にいる人ならどの事業者かは想像に難くないだろう。 99％政治マターに踊らされた国の失敗である。無論これまでの自治体システムにおいて事業者側にもやるべきことがあったことは認める。しかし、今回の失敗は国の責任だ。これは曲げようもない事実。こちらは何度も軌道修正を呼び掛けたが応答することはなかった。いや、失敗が明らかになってから応答したものもある。時すでに遅し。処方箋は病気発覚後すぐに投薬するのがベストだ。お迎えまじかの患者に投

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システム間で認証認可が必要なファイル連携をすることを考える時、例えば連携したいシステムがいずれも AWS に構築しているのであれば、Amazon S3 を使うのが効率的です。 ここで、地方公共団体情報システムの標準化における標準準拠システム間でファイル連携をする場合は、オブジェクトストレージを使った連携を行う仕様となっており、閉域の環境からオブジェクトストレージにアクセスした上で、通信を暗号化し、認証認可も必要なことから、AWS 環境同士の連携であれば S3 を使った連携を構築することが多いです。 一方、AWS と他の CSP 環境、オ

AWS Invoice Summary API（請求サマリー）が利用できるようになったとアナウンスがありました。 API のドキュメントを読んだら、レスポンスに "CurrencyExchangeDetails" という項目を持っており、もしかしたら AWS から送付される PDF の請求書でしか確認できない、請求時点のドル円レートを確認できるのでは？と思ったので、早速試してみました。 AWS CLI のアップデート AWS CLI の CHANGELOG を読むと、バージョン 2.27.29 から "Invoicing ListInvoiceSummaries API Operation" が追加されているようなので、まずは AWS CLI を最新版にアップデートしました。 Request の JSON を作成 API のドキュメントに沿って、請求サマリーを要求するパラメーターを JSO

Today, AWS announces the general availability of the Invoice Summary API. This allows you to retrieve your AWS invoice summary details programmatically via SDK. You can retrieve multiple invoice summary details by making a single API call that accepts input parameters like AWS Account ID, AWS Invoice ID, billing period, or a date range as input. The output of the Invoice Summary API will include d

Amazon Web Services ブログ 寄稿：株式会社ドワンゴによる「AWS で実現するニコニコの大規模セキュリティ改革の概観」 本稿は、株式会社ドワンゴ（以下、ドワンゴ）におけるクラウド環境のセキュリティ改革をリードされた青木 良樹様/結城 清太郎様/坂井 薫平様に寄稿いただきました。 はじめに 株式会社ドワンゴ は（以下、ドワンゴ）、デジタルテクノロジーによって新たな価値を生み出し続けるエンターテインメント企業です。当社の事業の中でもニコニコ事業は国内有数の動画・生放送配信プラットフォームとして多くのユーザーおよびクリエイターの皆様に愛され、ご利用いただいています。本稿はそんなニコニコ事業における従来のセキュリティ対策に加え、2024年6月初旬に発生したサイバー攻撃を契機に取り組んだセキュリティ改革の概観を紹介するものです。 改革の経緯 ニコニコ事業はインフラストラクチャの大改

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS には Compute Optimizer という、リソースの使用状況などから最適なサイジングなどの推奨事項を提案してくれるサービスがあり、EC2 や Lambda、ECS などのコンピューティングリソースに対応しています。 Compute Optimizer は基本機能だけならば無料で使えて、Organizations のアカウント全体に対して有効にすることができることを知ったので、早速試してみました。 Organizations で Compute Optimizer を全てのアカウントにオプトインする Organizatio

集約すると嬉しいこと VPCエンドポイント自体のコストを大きく削減できるのが一番のポイントですが、 他にもこんなメリットがあると思います。 NAT GatewayやTransit Gatewayへの通信量（≒コスト）が減る場合がある アカウント全体でVPCエンドポイントを作成する回数が1回で済む パブリック/プライベートを意識せずに済む（強制的にプライベートな通信経路となる） などなど コストはどれだけ減るのか 例えば50アカウントで10個のVPCエンドポイント（全て東京リージョン）を利用している場合、 月に $5,110 (¥740,950 $1=¥145）発生します。 これを1つのアカウントに集約すると、 純粋にアカウント数で割ったら月に $102.2(¥14,819 $1=¥145）に下がり、 約98％削減できることになります。 ちなみにVPCエンドポイントは1AZにつき1つ作成する

はじめに 本シリーズでは、Amazon Web Services (AWS) が提供しているAWS Well-Architected Frameworkのハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、後編の信頼性、パフォーマンス効率、コスト最適化のチェックポイントについてご紹介します。 AWS Well-Architected Frameworkおよびハイブリッドネットワーキングレンズの概要については、前編の記事をご覧下さい。 本記事で得られるメリット ハイブリッドネットワーキングレンズは関連する追加のベストプラクティスが提供されていますが、「どのような時に何をすればよいか」が一目で分かりづらいことがあります。そこで、本記事はベストプラクティスをシンプルかつ明解なチェックポイントに要約