こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。 昨年 令和5年度はガバメントクラウド関連のプロジェクトに関わる機会をいただき、地方自治体様向けにAWSの役務費用・利用料金の見積をお手伝いする機会が多々ありました。そのなかでエンジニアとして感じた苦労ポイントを本BLOGでご紹介させていただきます。 このBLOGを書いているちょうど先日、3月29日に「令和6年度ガバメントクラウド早期移行団体検証事業（第一回）」の公募および採択結果がデジタル庁より公示されました。「第一回」とあることから、年度内に追加で公募が行われると予想されますので、第二回以後に申込を検討している地方自治体ご担当様の参考になれば幸いです。 www.digital.go.jp 役務費用 依頼する作業範囲（スコープ）が不明 マイナンバー系ネットワークとAWSネットワーク間の責任分界点

コーヒーが好きな木谷映見です。 AWS Cloud WAN が GA（一般提供）されてから早 1 か月経ちました。 本記事では、AWS Cloud WAN の概要と、簡単なセットアップを試します。 AWS Cloud WAN ドキュメント AWS Cloud WAN 概要 イメージ図 VPC 混雑時代 AWS Transit Gateway の登場 AWS Cloud WAN の登場 Cloud WAN を使ってみる 準備しておくリソース Cloud WAN の設定 グローバルネットワークとコアネットワークの作成 セグメントネットワークの作成 アタッチメントポリシーの設定 VPC アタッチメント コアネットワークのルートテーブル確認 VPC 内ルートテーブル編集 疎通確認 コアネットワークのダッシュボードを見る お片付け おわりに 追記 参考 AWS Cloud WAN ドキュメント ドキ

営業部 佐竹です。 本日は、AWS 上のリソースを悪用され Crypto Currency （仮想通貨/暗号通貨）の採掘をされてしまわないように、利用者側にどのような対策がとれるのか、また実際に採掘を行われてしまった場合の対応について記載します。 はじめに キーワード 暗号通貨とその種類 採掘（マイニング） ウォレットへの送金 採掘悪用の概略図 悪用行為が増えている背景 ビットコインの高騰 イーサリアムの台頭 暗号通貨採掘悪用の攻撃経路 EC2 インスタンスに侵入し、侵入したインスタンス上で採掘を行う IAM Role を悪用し、悪意のある AMI から採掘用インスタンスを大量に横展開して採掘を行う 漏洩した IAM Credentials を悪用し、採掘用インスタンスを大量に横展開して採掘を行う 暗号通貨採掘悪用の防御手段 侵入させない SSH や RDP が意図せず解放されてしまいその

CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを

4月から劇団サーバーワークスに加わりました。伊藤です。 社内ではくりゅーと呼ばれております。 AWS環境では、わずか数クリックでサーバーができたり、AutoScalingで自動的にサーバーが増えたり、 オンプレミスの監視運用のスピードでは全く追いつけません。 そこで、今回はAuto Scalingなどで監視対象のインスタンスが自動で増えたり減ったりしても、Zabbixで常に対象インスタンスを自動登録し、監視対象にする方法をご紹介します。 自動構成ツールなどには依存しないので、どんな方法で（マネージメントコンソール、SDK、CLI、API、Elastic Beanstalk等々）構築、運用していても適用できます。 監視対象インスタンスのAgent側設定 zabbix_agentd.confにおいて、以下の点を設定します。 Server=127.0.0.1 #Zabbix-serverのIPも

最近色んな方から生暖かい目で見られる事が増えた気がする小室です。 本日はEC2関連を使って行く上で出てくる数字に関して記載します。 ※見つけたら追記する予定です。 ※間違っていたらすいません、@ayakomuro に教えてください。 ※情報は 2014/3/4時点のものです。 前提条件 1 AWSアカウント 各リージョンをベース（それ以外はコメントに追記） 数字は最大数（最小の場合はその旨コメントに追記） 共通 上限緩和可否 リソース ディフォルト上限数 コメント × タグ 1リソースに対して最大10個 参考URL Amazon EC2 上限緩和可否 リソース ディフォルト上限数 コメント ● EIP 5個 ● オンデマンドインスタンス数 タイプよって変わる ● スポットインスタンス数 タイプよって変わる ● リザーブドインスタンス数 アベイラビリティゾーン毎に毎月20個 × セキュリティ

こんちには！ インフラエンジニアの柳瀬です！ AWSにはElastic Load BalancerやRDSのMulti-AZなど冗長化を構成する上で便利な機能が盛り込まれています。 今回は英語版のフォーラムで紹介されているElastic IPとHeartBeatを使用した冗長化を試してみました。 今回テストを行った環境は以下の通りです。 Ubuntu 10.04 LTSHeartBeat 3.0.3 それでは環境を用意しましょう。これから記載する設定はHAを構成するノードそれぞれで行ってください。 まずはそれぞれのUbuntuにHost名を定義します。 $ vi /etc/hostname 1 heartbeat01 次にHeartBeatをインストールして設定を行います。 $ sudo apt-get install heartbeat $ sudo vi /etc/ha.d/ha.cf