閉域の AWS 環境からさくらのクラウドのオブジェクトストレージにアクセスする

これまでガバメントクラウドで実際に選択できる CSP は Amazon Web Services、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructure の 4 事業者でしたが、2026 年度から新たにさくらのクラウドも選択できるようになりました。

地方自治体のガバメントクラウドの利用状況として、AWS のシェアが大きいと言われていますが、これからガバメントクラウドでさくらのクラウドを利用するケースが現れると思いますので、どのようなユースケースが考えられるか、自治体職員としては気になるところです。

クラウド基盤を AWS をメインに構築している場合、いきなり全部をさくらのクラウドへ移行するようなことは難しいと思われますが、例えば AWS 環境のデータのバックアップの一部をさくらのクラウドに保存するようなユースケースは考えられそうです。

しかし、地方自治体の基幹業務システムのように、閉域接続を求められるネットワーク要件がある場合、AWS とさくらのクラウドは直接接続されているわけではないので、閉域ネットワークの中で相互にネットワーク接続する方法を考えなければなりません。

そこで、AWS とさくらのクラウドの両方に閉域ネットワークで接続するルーターを用意し、互いの環境をルーティングできるようにし、AWS 側のリソースからさくらのクラウドのオブジェクトストレージにアクセスできないか検証してみました。

AWS とさくらのクラウドの閉域ネットワーク接続の概要

ネットワーク構成図は次のとおりです。

私の自宅のルーター（YAMAHA RTX1210）は、既に AWS 側に立てた EC2 の VPN サーバーと VPN 接続し、プライベートサブネットへ接続できるようになっています。

今回新たに RTX1210 からさくらのクラウド側にも VPN 接続し、RTX1210 で AWS 側とさくらのクラウド側を相互にルーティングできるようにします。

さくらのクラウド側には、AWS でいうプライベートサブネットを用意し、プライベートサブネット内にオブジェクトストレージへの サービスエンドポイントゲートウェイ を作成することで、プライベートサブネット内からさくらのクラウドのオブジェクトストレージへ接続できるようにします。

実はこれがすんなりとは行きませんでした。

さくらのクラウドのオブジェクトストレージへの閉域アクセスは簡単ではなかった

当初この構成を思いついた時は、さくらのクラウドのサービスエンドポイントゲートウェイが AWS のインターフェース型 VPC エンドポイントのような機能だと思っていました。しかし実際は、サービスエンドポイントゲートウェイと同じサブネット内のサーバーからのみアクセスできる仕様となっており、AWS のゲートウェイ型 VPC エンドポイントに近い機能であることが分かりました。

サービスエンドポイントゲートウェイを有効化したスイッチに接続されているサーバからのみご利用いただけます。

そのため、AWS 側のリソースからサービスエンドポイントゲートウェイを経由して直接さくらのクラウドのオブジェクトストレージにアクセスすることはできないので、今回は さくらのクラウド側に踏み台サーバーを立て、AWS 側のEC2 から踏み台経由でサービスエンドポイントゲートウェイにアクセスする 方法を取ることにしました。

個人的にはこの仕様が残念で、今後 AWS のインターフェース型 VPC エンドポイントのように他のネットワークからも接続できる機能が欲しいと感じました。

それでは実際にさくらのクラウドへの閉域ネットワークの構築手順を見ていきます。

さくらのクラウドの VPN ルーターの設定

実際にガバメントクラウドでさくらのクラウドを使って基幹業務システムを構築するときは、インターネット VPN 接続は認められておらず、専用線（AWS だと Direct Connect）で接続する必要があります。

さすがに自宅の個人検証の環境に専用線は引けないので、さくらのクラウドがマネージドサービスとして提供している「VPN ルーター」を使うことにしました。

スイッチの作成

さくらのクラウドでは、スイッチと呼ばれるものが AWS のサブネットに相当するようです。さくらのクラウドでプロジェクトという AWS の VPC のようなものを最初に作成すると「共有セグメント」というパブリックサブネットが作られています。

今回共有セグメントに VPN ルーターを作成し、VPN ルーター経由でプライベートサブネットに接続させたいので、最初にプライベートサブネットに相当するスイッチを作成します。

さくらのクラウドのコントロールパネル（管理コンソール）から、「ネットワーク」→「スイッチ」へ進み、スイッチを追加します。名前以外は特に設定はしていません。後でこのスイッチを VPN ルーターへ接続するのですが、その時にサブネットを設定することになります。

ちなみに上記のスクリーンショットのように、さくらのクラウドのコントロールパネルでリソースを作成する画面では一月あたりの予想料金が表示されます。これは結構いいですね。

VPN ルーターの作成

さくらのクラウドのコントロールパネルから「アプライアンス」→「VPN ルーター」へ進み、VPN ルーターを作成します。最初にプランを選んで一旦 VPN ルーターを作成した後、具体的な VPN 接続や先ほど作成したスイッチへの接続をする流れです。

VPN ルーターが作成されたら、VPN ルーターの「詳細」→「インターフェース」に進み、「プライベート 1」の編集画面から先ほど作成したスイッチを VPN ルーターに接続します。

この時、スイッチ（プライベートサブネット）側のゲートウェイとなる IP アドレスとプリフィックスを設定します。ここではプライベートサブネットで 10.131.0.0/24 のサブネットを使うこととし、IP アドレスは 10.131.0.254/24 を設定することにしました。

VPN ルーターのインターフェースの設定ができたら、VPN ルーターのグローバル側はパブリックサブネットである共有サブネットに、プライベートサブネット側は作成したスイッチが接続された状態になっています。

サイト間 VPN の設定

自宅の RTX1210 とサイト間 VPN 接続するための設定をします。VPN ルーターの「詳細」→「サイト間 VPN」に進み、サイト間 VPN の設定を追加します。

項目	設定値
対向 IP アドレス	対向ルーター（自宅 RTX1210）のグローバル IP アドレス
対向 ID	対向ルーターに設定する ID の値
Pre Shared Secret	対向ルーターに設定する事前共有キーの値
対向 Prefix	さくらのクラウド側からルーティングさせたいサブネット。ここでは AWS のプライベートサブネットの値をセットしている。
ローカル Prefix	AWS 側からルーティングさせたいサブネット。ここではスイッチに設定したプライベートサブネットの値をセットしている。

設定ができたら、対向ルーターの設定をします。

対向ルーター（自宅 RTX1210）の設定

設定は さくらのクラウドのマニュアル に記載のとおりで大丈夫です。

VPN トンネルに関する部分のみ抜粋します。

# さくらのクラウド側のプライベートサブネットへのスタティックルートの追加
ip route 10.131.0.0/24 gateway tunnel 4

# VPN トンネルの設定
tunnel select 4
 ipsec tunnel 4
  ipsec sa policy 4 4 esp aes-cbc sha-hmac
  ipsec ike always-on 4 on
  ipsec ike encryption 4 aes-cbc
  ipsec ike group 4 modp1024
  ipsec ike hash 4 sha
  ipsec ike keepalive use 4 on dpd 15 2
  ipsec ike local address 4 10.1.4.254 # さくらのクラウドの VPN ルーターに設定した対向 ID と同じ値
  ipsec ike local id 4 10.1.4.254 # さくらのクラウドの VPN ルーターに設定した対向 ID
  ipsec ike pfs 4 on
  ipsec ike pre-shared-key 4 hogefuga # さくらのクラウドの VPN ルーターに設定した事前共有キー
  ipsec ike remote address 4 203.0.113.123 # さくらのクラウドの VPN ルーターのグローバル IP アドレス
  ipsec ike remote id 4 203.0.113.123 # 同上
  ipsec auto refresh 4 on
 ip tunnel mtu 1280
 ip tunnel tcp mss limit auto
 tunnel enable 4

# NAT の設定
nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 10.1.4.254 udp 500
nat descriptor masquerade static 1 2 10.1.4.254 esp

なお、AWS 環境側にもさくらのクラウドのプライベートサブネットへの経路情報を追加する必要があります。AWS 側の VPN の設定は過去に記事を書きましたので良かったら参考にしてください。

対向ルーターの設定が終わったら、さくらのクラウドのコントロールパネルから VPN ルーターの「詳細」→「電源操作」から「起動」してください。

正常に VPN 接続が確立したら、コントロールパネル上のステータスが「UP」に切り替わります。

これで AWS 環境とさくらのクラウド環境が互いにルーティングできるようになりました。

さくらのクラウドのオブジェクトストレージにバケットを作成

さくらのクラウドのコントロールパネルから「オブジェクトストレージ」へ進みます。

まずはどのリージョンのサイトにオブジェクトストレージを作成するか選びます。

ちなみに今回 VPN ルーターやスイッチは石狩第 3 リージョンに作成したのですが、オブジェクトストレージではこのサイトが選べないようです。

しかし、今回オブジェクトストレージにはサービスエンドポイントゲートウェイ経由でアクセスするため、リージョンを跨いで接続することが可能なので心配しなくて大丈夫です。

ここでは石狩第 1 リージョンを選択することにします。

作成したオブジェクトストレージにアクセスするためのアクセスキーとシークレットアクセスキーが表示されるのでメモしておきます。

この後さくらのクラウドのオブジェクトストレージには、Amazon S3 互換 API に AWS CLI からアクセスできるようになるのですが、その際のクレデンシャルに上記のアクセスキー、シークレットアクセスキーを使います。

AWS だとアクセスキーを使わずにバケットポリシーへ IAM ロールを設定することで認証認可をコントロールできるのですが、さくらのクラウドのオブジェクトストレージでは私がマニュアルを読んだ範囲ではこれに相当する設定が見つかりませんでした。ここも今後に期待したい部分です。

サイトが作成できたら、後で API へアクセスするのに必要となるリージョン名とエンドポイント名をメモしておきます。

次にバケットを作成します。バケット名は API アクセス時に必要となります。

バケットが作成できたら「バケット ACL の編集」から現在のセキュリティ設定を確認します。

アクセス権限が「private」になっていれば、認証なしでバケットにアクセスできない状態になっています。

オブジェクトストレージの設定が完了したので、次はプライベートサブネットからオブジェクトストレージにアクセスできるようにサービスエンドポイントゲートウェイを設定します。

サービスエンドポイントゲートウェイの有効化

最初に触れたのですが、さくらのクラウドのサービスエンドポイントゲートウェイは、AWS のゲートウェイ型 VPC エンドポイントと似たような機能になっており、サービスエンドポイントゲートウェイと同じプライベートサブネットのサーバーからしか接続できないようになっています。

また、サービスエンドポイントゲートウェイに名前解決クエリを転送すると、サービスエンドポイントゲートウェイに設定したサービスのプライベート IP アドレスを返す機能があり、Route 53 インバウンドエンドポイントのようなこともできます。

新サービス「サービスエンドポイントゲートウェイ(SEG)」の紹介 〜オブジェクトストレージへのプライベート接続を試す〜

サービスエンドポイントゲートウェイはスイッチのコントロールパネルから有効化します。

サービスエンドポイントゲートウェイに使用する IP アドレスを設定します。ここではさくらのクラウド側のプライベートサブネット内で設定します。この IP アドレスは、あとで踏み台サーバーが参照する DNS サーバーの IP アドレスとして使用します。

サービスエンドポイントゲートウェイが作成できたら、オブジェクトストレージと連携するために「編集」に進みます。

石狩第 1 リージョンを選択します。

これでプライベートサブネットから石狩第 1 リージョンのサイトのオブジェクトストレージにサービスエンドポイントゲートウェイ経由でアクセスできるようになりました。

踏み台サーバーの作成

繰り返しですがサービスエンドポイントゲートウェイにアクセスできるのは、同じスイッチに接続されたサーバーのみです。

そこで、スイッチ内に AWS 環境からの踏み台サーバーを起動します。OS は何でも構いませんが、SSH サーバーにできるものを選びます。

手順は省略しますが、ここで重要なことは、踏み台サーバーがサービスエンドポイントゲートウェイで名前解決をするように、DNS リゾルバーの参照先をサービスエンドポイントゲートウェイの IP アドレスにすることです。

踏み台サーバーがオブジェクトストレージのエンドポイントの名前解決をできることが今回の構成のポイントです。

踏み台サーバーへ SSH ポートフォワーディングする

ここで再度ネットワーク構成図を見てみます。

ここまでの設定で AWS 環境の EC2 から自宅の RTX1210 を経由してさくらのクラウドの踏み台サーバーまでルーティングできるようになっています。

EC2 から踏み台サーバーに SSH で接続し、ポートフォワーディングを使って EC2 からサービスエンドポイントゲートウェイ宛ての通信を SSH トンネルに転送します。これにより、サービスエンドポイントゲートウェイから見ると踏み台経由でのアクセスとなるので接続できる仕組みです。

$ sudo ssh -fN -L 443:s3.isk01.sakurastorage.jp:443 'ユーザー名'@'踏み台サーバーの IP アドレス' -i '秘密鍵ファイルのパス'

これで EC2 の localhost:443 にアクセスすると、踏み台サーバー経由で isk01.sakurastorage.jp:443 へアクセスできるようになりました。

この状態のまま、EC2 の AWS CLI から Amazon S3 互換 API にアクセスすれば、さくらのクラウドのオブジェクトストレージにアクセスできるはずです。

Amazon S3 互換 API 経由でさくらのクラウドのオブジェクトストレージにアクセス

ゴールまであと少しです。

AWS CLI のクレデンシャルをセット

Amazon S3 互換 API を使ってさくらのクラウドのオブジェクトストレージへアクセスするためには、オブジェクトストレージを作成したときに表示されていたアクセスキー、シークレットアクセスキーを、AWS CLI を実行する際のクレデンシャルに設定する必要があります。

~/.aws/credentials

[sakura-test04]
aws_access_key_id = 'オブジェクトストレージのアクセスキー'
aws_secret_access_key = 'オブジェクトストレージのシークレットアクセスキー'

Amazon S3 互換 API から aws s3 コマンドを実行

Amazon S3 互換 API を使って EC2 の AWS CLI から aws s3 ls コマンドを実行してみます。

--endpoint-url に指定するのはオブジェクトストレージの作成画面で確認したエンドポイントを、--region も同様にリージョンを指定します。

$ aws --endpoint-url https://s3.isk01.sakurastorage.jp --region jp-north-1 --profile sakura-test04 s3 ls

ここで、このままコマンドを実行すると、EC2 は SSH トンネルではなく isk01.sakurastorage.jp に直接アクセスしてしまいます。

そのため、ちょっと反則ですが、EC2 の /etc/hosts ファイルに以下のとおり設定し、s3.isk01.sakurastorage.jp 宛ての通信を localhost 宛ての通信に偽装します。

/etc/hosts

127.0.0.1 s3.isk01.sakurastorage.jp

この設定で再度 aws s3 ls コマンドを実行します。

$ aws --endpoint-url https://s3.isk01.sakurastorage.jp --region jp-north-1 --profile sakura-test04 s3 ls

2026-04-17 22:22:22 test04-dev-bucket

作成したバケット名が返ってきました。さくらのクラウドのオブジェクトストレージに、閉域ネットワーク内から Amazon S3 互換 API で aws s3 コマンドが実行できることを確認できました。

早速適当なファイルをオブジェクトストレージにアップロードしてみます。

$ touch dummy.txt
$ aws --endpoint-url https://s3.isk01.sakurastorage.jp --region jp-north-1 --profile sakura-test04 s3 cp ./dummy.txt s3://test04-dev-bucket/
upload: ./dummy.txt to s3://test04-dev-bucket/dummy.txt
$ aws --endpoint-url https://s3.isk01.sakurastorage.jp --region jp-north-1 --profile sakura-test04 s3 ls s3://test04-dev-bucket/
2026-04-18 02:21:11                    0 dummy.txt

ファイルのアップロードも問題なくできました。

オブジェクトストレージのコントロールパネル側も見てみます。

aws s3 cp コマンドでアップロードしたファイルが表示されていました。

以上で、閉域の AWS 環境からさくらのクラウドのオブジェクトストレージにアクセスできることが検証できました。

なお、実際に構築するとしたら、SSH ポートフォワーディングではなく、踏み台サーバーに Squid などを立てれば、localhost の名前解決の問題も発生しないので良いのではないかと思います。

さくらのクラウドを使ってみた感想

今回の検証は、さくらのクラウドの公式のマニュアルを読むだけでできましたので、ドキュメントは分かりやすいと感じました。

コントロールパネルもシンプルで、操作もある程度迷わずにすることができました。

一方、サービスエンドポイントゲートウェイの仕様や、オブジェクトストレージのアクセス制限についてなど、AWS だったらこういうことができるのに、というものも結構ある印象です。ここはこれからどんどん機能強化していってくれたらいいなあと思っています。

自治体職員の拙い検証だったので認識違いもあるかと思いますが、これからも気になる機能があれば使ってみようと思います。

最後に、ガバメントクラウドへの採択おめでとうございます。国産クラウドということで期待しています。