🎉 回答者が「いい質問」に選出しました 🎉

09月07日

質問者さん

共同ASPでの提供が困難なベンダーが一社だけおり単独ASP環境を当市の運用管理補助者に委託して作成予定です。 その場合、単独ASP用のAWSアカウントにはEC2以外に必要となるAWSリソースはないかなと想定しておりますが、これ必要じゃないかなどアドバイスいただけますと幸いです。 ・DBはRDSではなくEC2上に構築します ・小規模システムのためEC2は本番と検証で1個ずつ想定

09月07日

高橋 広和/Hirokazu TAKAHASHI

高橋 広和/Hirokazu TAKAHASHIさん

コンピュートリソースと言う意味合いであればEC2のみで概ね良いかと思いますが、その周辺といいますか、運用回りで諸々必要になってくるという認識です。 どの程度の粒度を求められているか分かりかねますが、思いつく限り記載します。 なお、ネットワークアカウント(ネットワーク運用管理補助者)が別に居る想定とします。またデジタル庁のテンプレートで強制的に設定されるものは割愛します。 ■ ネットワーク系 VPC:EC2を立てる前段としてVPCが必須になります。 サブネット:VPC内のネットワークを分割するものです。こちらも必須です。 ファイアウォール機能:EC2にはセキュリティグループ。サブネットにはネットワークACLと言うファイアウォール機能が自動作成され、その設定を行う必要があります。 ネットワーク接続機能:TransitVIF接続の場合はネットワーク運用管理者が所管するTGWと接続するためのアタッチメントをサブネットに作成する必要があります。またPrivateVIF接続の場合はVPCにVGWを作成する必要があります。 インターネット接続機能:EC2を利用する限り、OSのセキュリティパッチやウイルス対策をどうするかという課題が残ります。詳細構成は割愛しますが、他の事業者や庁内から提供を受けるのでない限り、インターネットに接続するための環境を自前で用意する必要があります。NATゲートウェイ、踏み台サーバとしてのEC2等が必要になる可能性があります。 エンドポイント:AWSの各マネージドサービスはインターネット側にあるので、各サービスにセキュアな方法で接続するために(また通信のインターネットアウトバウンド課金を逃れるために)VPCにエンドポイントという穴をあける必要があります。そしてエンドポイントはサービスごとに作成が必要です。他の事業者が作成したエンドポイントを利用できる可能性はあるので、要調整です。 ルーティング機能:クラウド上のルータ機能としてVPCルートテーブルを設定する必要があります。 ■ 名前解決 ネームサーバ機能:ネームサーバ機能としてのRoute53プライベートホストゾーンをVPCに作る必要があります。非推奨ですが、名前解決を実施せず、生IP直打ち運用するなら不要です。 リゾルバ&フォワーダー機能:ネットワーク運用管理補助者等がRoute53リゾルバを作成してくれて、関連付けをしてくれれば良いのですが、そうでなければ自前でRoute53リゾルバを作成し、オンプレDNSへ問い合わせる仕組みを作る必要があります。名前解決を実施しないなら不要です。 ■ ストレージ ストレージ:S3です。標準準拠システムのストレージや連携機能として利用していなくても、EC2やEBSのバックアップや各種ログの保存先として必要になります。 ■ セキュリティ 証明書管理関連:通信の暗号化に証明書が必須であり、その管理にCertificate Manager (ACM) を使う必要があります。とりわけ考慮すべきはプライベート認証局で、ネットワーク運用管理補助者が用意して管理してくれないのであれば、自前で作成する必要があります。 暗号鍵管理関連:各種リソースの暗号化に暗号鍵が必要であり、その管理のためKMSが必要になります。総務省の定めるセキュポリガイドラインではクラウド利用終了時に暗号化消去を行う事としており、そのため必須です。 ウイルス・脆弱性対策:EC2はOSがある以上、利用者側で諸々の対策が必要になります。前述のインターネット接続機能の他、脆弱性検知のAmazon Inspectorを利用することが推奨されます。 ■ 監視 監視機能:EC2の死活監視のためCloudwatch(メトリクス、アラート、ログ)が必要になります。場合によってはEventbridgeも必要になります。 通報機能:アラートの通報にAmazonSNSが必要になります。

高橋 広和/Hirokazu TAKAHASHIさんに 質問してみましょう!

高橋 広和/Hirokazu TAKAHASHI

高橋 広和/Hirokazu TAKAHASHI

名古屋市総務局デジタル改革推進課/システム標準化担当課長補佐/ツィート内容は全て個人の意見や感想等であり、所属する地方公共団体の公式見解ではありません/AWSちょっとだけ分かる。 共創PFに常駐しています。Facebookは余り見ません。Noteはたまに更新。 資格試験用垢 @techniczna2

関連する質問

09月09日

続き質問

(質問ではなく感謝のメッセージとなります) 粒度が荒い質問だったのにもかかわらず詳細にご説明いただきありがとうございます。 予算計上に向けて必要事項を精査することに苦労してましたので、本当に大変感謝申し上げます(´;ω;`) ご回答ありがとうございました!

高橋 広和/Hirokazu TAKAHASHIさんが

「いいね」した質問

いいね!

09月07日

共同ASPでの提供が困難なベンダーが一社だけおり単独ASP環境を当市の運用管理補助者に委託して作成予定です。 その場合、単独ASP用のAWSアカウントにはEC2以外に必要となるAWSリソースはないかなと想定しておりますが、これ必要じゃないかなどアドバイスいただけますと幸いです。 ・DBはRDSではなくEC2上に構築します ・小規模システムのためEC2は本番と検証で1個ずつ想定

いいね!

08月21日

単独利用方式の場合のrootアカウントは各自治体が保有している認識で合ってますでしょうか?

いいね!

08月13日

名古屋市と同様、ガバメントクラウド早期移行団体検証事業に採択された自治体の担当ベンダーで標準化移行対象業務の担当を行っている者です。 先般、標準化システムへの移行についてスケジュールが示されましたが、ガバメントクラウドへの接続回線が整備されたのがつい先日、標準化システムへデータ移行や切り替えの作業は期限とされる令和7年度末より1年以上前倒しの令和6年12月28日~令和7年1月5日と提示されました。 現行環境のハードウェア保守期限は限度一杯まで延長すればもう半年程度、令和7年夏までは可能のようですが、ガバクラは共同利用方式であるために使用している全団体(10団体前後)を一度に移行しなければならないと開発元より伺っております。開発元では勤務先のベンダー以上に先行する団体はなく、さらに年末年始では開発元は休業であるために支援も得られにくい状況、何よりも移行期間が短期間過ぎるために不安でたまりません。年末年始の旅行も勤務先から禁止されました。 そこで質問です。早期移行の予定が令和6年度末までであったとして、ベンダーがガバクラ移行をギブアップしてきたらどう対応しますか。

高橋 広和/Hirokazu TAKAHASHIさんが

最近答えた質問

09月11日

名人にお聞きしたいのですが、住基及び附票の標準準拠システムへの移行については現行システム自体がJ-LISの改造仕様書に基づいて、連携仕様などが定義づけされているので、これをそのまま標準仕様書として、より細かく設定すれば住基の標準仕様はスムーズに終えることが出来たのではないかと思うのですがいかがでしょうか。

09月11日

バズりおめでとうございます。住民担当課の職員なので今さら遅いですが個人的には20業務を指定したのが全ての間違いで住基システムは他19業務に絡む根幹の基幹システムなので、2025に合わせるのは住基システムだけにしとけば、他19業務もスムーズに2025以降にシフト、リフトできたのかなーと思っているんですがいかがですか。

09月09日

続き質問

(質問ではなく感謝のメッセージとなります) 粒度が荒い質問だったのにもかかわらず詳細にご説明いただきありがとうございます。 予算計上に向けて必要事項を精査することに苦労してましたので、本当に大変感謝申し上げます(´;ω;`) ご回答ありがとうございました!