AWS Snowcone(snow cone)は、重さ2.1kgの筐体にストレージと小さなコンピュートを詰めた、AWS Snow Familyで最小のデバイスでした。2024年11月12日にサービスが廃止され、既存デバイスのサポートも2025年11月12日で終わっています。この記事では、Snowconeが担っていた役割を仕様から整理したうえで、手元に残ったジョブをAWS CLIで洗い出す方法、転送用途をDataSyncエージェントのVMへ、エッジ処理をIoT Greengrassへ移すコマンド、国内で代替先を選ぶときに詰まる点までを、作業の順に解説します。
まとめ:Snowconeは用途ごとに移し先を分けて置き換える
Snowconeを新たに注文する手段は、もうありません。AWS Storage Blogの告知によると、2024年11月12日に新規・既存とも注文が止まり、既存デバイスのサポートは2025年11月12日までとされました。後継機は用意されていません。
置き換えは「何に使っていたか」で決まります。ネットワーク越しの転送ならDataSyncエージェントを社内のVMに立てる。現場でのデータ処理なら、自前の小型機にIoT Greengrassを入れる。回線が細く物理的に運びたい場合が最も難しく、公式の代替であるData Transfer Terminalは2026年10月時点で国内の拠点が案内されていません。まずは返却漏れのジョブが無いかを確認し、そのうえで用途ごとに移し先を決めてください。
AWS Snowconeの仕様とDataSync・EC2・NFSで担っていた3つの役割
移し先を選ぶ前に、Snowconeが1台で何を兼ねていたかを分解しておきます。
2.1kg・2vCPU・4GBメモリのHDD 8TBとSSD 14TBの仕様比較
Snowconeは2020年6月17日に発表されました。About Amazonの紹介記事では、寸法は23cm×15cm×8cm、重さ2.1kg、CPU 2基・メモリ4GB・使用可能なストレージ8TBで、USB-C給電か別売りのバッテリーで動くと説明されています。
2021年9月にはSSD版のSnowcone SSDが加わり、容量は14TBに増えました。CPUとメモリはHDD版と同じです。以後、AWS CLIやAPIでは前者がSNC1_HDD、後者がSNC1_SSDという種別名で扱われています。
プリインストールのDataSyncエージェントとNFS共有によるオンライン転送の仕組み
Snowconeの使い方で多かったのが、現場でデータを受け取り、回線越しにAWSへ送る形です。デバイスにはDataSyncのエージェントが最初から入っており、NFS共有として書き込んだファイルを、Amazon S3やAmazon EFSへ転送できました。回線が無い場所ではデバイスごとAWSへ送り返し、取り込んでもらうこともできます。
つまりSnowconeは「NFSファイルサーバー」「DataSyncエージェント」「輸送用の媒体」の3役を1台で兼ねていました。置き換えでは、この3役を別々の手段に割り振ることになります。
snc1インスタンスとIoT Greengrassでエッジ処理を動かしていた構成
もう一つの役割がエッジでの処理です。AWS公式ブログの紹介記事には、EC2インスタンスとしてsnc1.micro(1CPU・1GiB)、snc1.small(1CPU・2GiB)、snc1.medium(2CPU・4GiB)の3種類が載っています。AWS IoT Greengrassを動かして、センサーデータの前処理を現場で済ませる構成も取れました。
ここで押さえておきたいのは、処理能力の小ささです。最大でも2CPU・4GiBなので、移し先に求める性能は高くありません。後述するように、現行のDataSyncエージェントの要件のほうがSnowconeの全リソースより大きいという逆転が起きています。
2024年11月の販売終了から2025年11月のサポート終了までの経緯と現状
Snowconeだけでなく、Snow Family全体と、AWSが案内する代替先の一部にも変化が続いています。
Snowconeと関連する転送・エッジ製品の提供終了を確認する時系列
2026年10月時点の公式ページから、Snowcone廃止、Snowball Edgeの新規受付停止、Outposts serversの販売終了を時系列で整理したものが次の表です。
| 時期 | 出来事 |
|---|---|
| 2024-11-12 | Snowcone廃止・注文停止 |
| 2025-11-07 | Snowball Edgeの新規受付停止 |
| 2025-11-12 | 既存Snowconeのサポート終了 |
| 2026-10時点 | Outposts serversは販売終了 |
Snowball Edgeについては提供条件の変更ページが、新規顧客はSnow Familyのどのデバイスも注文できなくなったと明記しています。Snowball側の経緯と現行の2機種はAWS Snowballとは?2025年の新規提供終了と現行デバイス・移行手段の選び方で詳しく扱っています。Snowconeの後継としてSnowball Edgeを選ぶには、既存顧客であることが条件です。
AWS CLIのlist-jobsで手元に残るSnowconeのジョブを洗い出す手順
サポートが終わった今も、返却されていないデバイスや、状態が完了になっていないジョブが残っていることがあります。AWSは告知の中で、ジョブを完了させてデバイスを返却するよう強く求めていました。list-jobsのリファレンスにあるとおり、ジョブごとにSnowballTypeとJobStateが返るため、Snowconeだけを絞り込めます。
# 東京リージョンで注文したSnowcone(HDD/SSD)のジョブを一覧する
aws snowball list-jobs \
--region ap-northeast-1 \
--query "JobListEntries[?SnowballType=='SNC1_HDD' || SnowballType=='SNC1_SSD'].[JobId,JobState,JobType,CreationDate]" \
--output table
ジョブはリージョン単位で管理されるので、注文した可能性のあるリージョンごとに実行します。JobStateがWithCustomerのままなら、デバイスが社内に残っています。CompleteやCancelled以外が出たら、資産管理の台帳と突き合わせ、所在と返却の状況をサポートへ確認してください。
公式の代替先を国内の利用条件に当てはめたときの移し先の選び方
AWSは用途ごとに代替を案内していますが、そのまま国内の案件に持ち込むと候補から外れるものがあります。
データ転送・エッジ処理・物理搬送の3用途で分ける代替サービスの対応表
Snowball Edgeの変更ページが挙げる代替は、オンライン転送にDataSync、物理転送にData Transfer Terminalかパートナー製品、エッジ処理にAWS Outpostsです。Snowconeの3役に当てはめ、国内での現実的な選択肢を併記しました。
| Snowconeの役割 | 公式の代替 | 国内での現実解 |
|---|---|---|
| 回線越しの転送 | DataSync | 社内VMにエージェント |
| 現場での処理 | Outposts | 自前機器にGreengrass |
| 物理的な搬送 | Data Transfer Terminal | 回線増強かパートナー |
実務で最初に検討するのは1行目です。転送の大半は、回線の太さと日数の見積もりで片がつきます。
国内の新規案件で物理転送とエッジ処理の公式代替先を選びにくい理由
Data Transfer Terminalのユーザーガイドには、現時点でEnterprise Supportの契約者だけが使えると書かれています。料金ページに載っている拠点は北米と欧州のみで、アジア内の転送は1ポート1時間あたり1,050ドルです。国内の中堅企業が、Snowconeの代わりとして気軽に使える手段ではありません。
物理転送のData Transfer Terminalに続き、エッジ処理の代替であるOutposts serversも、国内の新規案件では選びにくい候補です。Outposts serversのユーザーガイドの冒頭には、1Uと2UのOutposts serversの販売を終了し、新規顧客を受け付けていないと告知されています。残るOutposts racksは42Uのラックで、2kgの箱を置き換える選択肢としては規模が合いません。
Snowconeの転送用途をDataSyncエージェントのVMに置き換えるCLI手順
ここからは、最も多い「現場のNFSからS3へ送る」用途を、社内のVMで組み直す手順です。
4vCPU・32GBメモリが必要なエージェントVMの要件とSnowconeとの違い
DataSyncエージェントの要件では、VMに割り当てる資源がBasicモードで4vCPU・メモリ32GB・ディスク80GB、Enhancedモードで8vCPU・32GB・80GBとされています。Snowcone全体の2CPU・4GBを大きく上回るため、Snowconeと同じ大きさの小型機で代わりを務めることはできません。
動かせるハイパーバイザーは、VMware ESXi 7.0と8.0、KVM、Microsoft Hyper-V(2012 R2・2016・2019)、そしてAmazon EC2です。デプロイ手順のページは、オンプレミスのストレージに対してEC2上のエージェントを使うのは遅延が増えるため推奨しないとしています。NFSサーバーと同じ拠点の仮想化基盤に置くのが基本です。モードの違いと料金はAWS DataSyncとは?転送の仕組み・EnhancedとBasicの違い・料金と採用判断を実装者目線で解説にまとめています。
アクティベーションキーの取得からcreate-agentまでのコマンド例
VMを起動してIPアドレスを確かめたら、エージェントをAWSアカウントに登録します。アクティベーションの公式手順に沿うと、作業端末からの流れは次のとおりです。
# 1. 作業端末からエージェントVMの80番ポートへ届くか確認する
nc -vz 192.0.2.10 80
# 2. 東京リージョン・パブリックエンドポイント用のアクティベーションキーを取得する
curl "http://192.0.2.10/?gatewayType=SYNC&activationRegion=ap-northeast-1&no_redirect"
# 3. 返ってきたキーでエージェントを登録し、一覧で確認する
aws datasync create-agent \
--activation-key F0EFT-7FPPR-GG7MC-3I9R3-27DOH \
--agent-name factory-nfs-agent
aws datasync list-agents
キーは使わなければ30分で失効します。80番ポートは登録が済むとDataSync側で閉じられるので、ファイアウォールの穴を開けっ放しにする心配はありません。create-agentのリファレンスでは、VPCエンドポイント経由にする場合の追加オプションも確認できます。
NFSロケーションとS3ロケーションを作りタスクを実行するコマンド例
エージェントが登録できたら、転送元と転送先を「ロケーション」として作り、両者を結ぶタスクを実行します。必須オプションはcreate-location-nfsとcreate-location-s3のリファレンスで確かめられます。
# 転送元:現場のNFSサーバー(Snowconeに書き込んでいた共有の置き換え先)
aws datasync create-location-nfs \
--server-hostname 192.0.2.20 \
--subdirectory /export/sensor-data \
--on-prem-config AgentArns=arn:aws:datasync:ap-northeast-1:111122223333:agent/agent-0123456789abcdef0
# 転送先:S3バケット(DataSyncが書き込むためのIAMロールを指定)
aws datasync create-location-s3 \
--s3-bucket-arn arn:aws:s3:::example-sensor-archive \
--s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Access \
--subdirectory /snowcone-migration
# 2つのロケーションを結ぶタスクを作って実行する
aws datasync create-task \
--source-location-arn <NFSロケーションのARN> \
--destination-location-arn <S3ロケーションのARN> \
--name snowcone-replacement
aws datasync start-task-execution --task-arn <タスクのARN>
Snowconeのときは注文時のジョブ種別で転送先が決まっていましたが、この構成では転送先をあとから増やせます。2回目以降のタスク実行は差分だけを送るため、現場から毎晩送る運用にもそのまま使えます。
8TBを回線で送る日数と転送料金を公式の計算式で見積もる方法
物理搬送をやめられるかを判断する基準は、回線転送に必要な日数の見積もりです。DataSyncの移行期間の見積もりページは、データ量・回線帯域・利用率・1日の稼働時間から理論上の最短日数を出す式を示しています。Snowcone 1台分の容量で計算してみます。
# DataSync公式の計算式で、理論上の最短転送日数を求める
def transfer_days(data_tb, circuit_mbps, utilization=0.8, hours_per_day=24):
data_bytes = data_tb * 1_000_000_000_000
circuit_bps = circuit_mbps * 1_000_000
return (data_bytes * 8) / (circuit_bps * utilization * 3600 * hours_per_day)
for tb in (8, 14): # Snowcone HDD・SSDの容量
for mbps in (100, 1000):
print(f"{tb}TB {mbps}Mbps: {transfer_days(tb, mbps):.1f}日")
利用率80%・24時間稼働で、8TBは100Mbpsなら約9.3日、1Gbpsなら約0.9日です。14TBでは100Mbpsで約16.2日、1Gbpsで約1.6日になります。夜間の12時間しか回線を使えないなら、日数は倍です。
費用はDataSyncの料金ページに例示された米国東部の単価で、BasicモードがGBあたり0.0125ドル、Enhancedモードが0.015ドルにタスク実行ごと0.55ドルです。8TB(約8,000GB)を送るとBasicで約100ドル、Enhancedで約120ドルに実行料金が加わります。東京リージョンの単価は料金ページの計算ツールで確かめてください。
Snowconeのエッジ処理を自前ハードウェアのIoT Greengrassへ移す判断基準
EC2インスタンスやGreengrassで現場の処理を動かしていた場合は、汎用の小型機に移すのが現実的です。
Greengrass nucleusのディスクとメモリ要件に基づく機器の選定基準
Greengrass nucleusの要件では、Linuxの場合、ソフトウェア本体にディスク256MB以上とメモリ96MB以上、Java 8以上のランタイムが必要です。この数字にはデプロイする処理(コンポーネント)の分は含まれません。メモリが限られる機器向けには、バージョン2.14.0から軽量版のnucleus liteも用意されています。
Snowconeのsnc1.mediumが2CPU・4GiBだったことを考えると、同等以上のメモリを積んだ産業用の小型PCで十分に置き換えられます。Greengrass自体の仕組みと料金はAWS IoT Greengrassとは?仕組み・機能・料金とIoT Coreとの違いで確認できます。
自前の小型機にGreengrassを入れてSnowconeの処理を移すインストール例
自動プロビジョニングによるインストール手順に沿うと、Linux機での最小の流れは次のとおりです。AWSの認証情報は、権限を絞った一時的なものを環境変数で渡します。
# Greengrass Coreソフトウェアを取得して展開する
curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip > greengrass-nucleus-latest.zip
unzip greengrass-nucleus-latest.zip -d GreengrassInstaller && rm greengrass-nucleus-latest.zip
# IoTのモノ・グループ・IAMロールを自動作成し、systemdのサービスとして登録する
sudo -E java -Droot="/greengrass/v2" -Dlog.store=FILE \
-jar ./GreengrassInstaller/lib/Greengrass.jar \
--aws-region ap-northeast-1 \
--thing-name site-a-edge-01 \
--thing-group-name site-a-edge \
--thing-policy-name GreengrassV2IoTThingPolicy \
--tes-role-name GreengrassV2TokenExchangeRole \
--tes-role-alias-name GreengrassCoreTokenExchangeRoleAlias \
--component-default-user ggc_user:ggc_group \
--provision true \
--setup-system-service true
Snowcone上のEC2で動かしていた処理は、Greengrassのコンポーネントとして作り直すことになります。AMIをそのまま持ち込めるわけではない点は、移行の工数見積もりに入れておいてください。
Snowconeの後継探しで採用すべき構成と見送るべき構成の判断
最後に、どの構成を選び、どれを避けるかの線引きを示します。
DataSyncのVM構成へ寄せる条件と物理搬送を残すべき条件
拠点に100Mbps以上の回線があり、送るデータが月に数TB程度なら、DataSyncのVM構成へ寄せてください。先の計算どおり、8TBでも10日以内に収まり、物理デバイスの手配と返送の待ち時間が消えます。回線そのものが足りない場合は、AWS Direct Connectとは?専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】で扱う専用線を、移行期間だけ借りる方法も公式ドキュメントで案内されています。
物理搬送を残すのは、回線を引けない現場で、毎回数十TB単位のデータが生まれる場合に限られます。この条件ではAWS Marketplaceのパートナー製品を検討することになり、Snowconeほどの手軽さは期待できません。
既存のSnowball Edge契約に寄せて延命する移行が失敗しやすい理由
既存顧客としてSnowball Edgeを使い続けられる企業でも、Snowconeの後継をそこへ寄せる判断は勧めません。現行のSnowball EdgeはStorage Optimized 210TBとCompute Optimizedの大型機で、2kgの箱を持ち運ぶ用途とは大きさが合いません。加えて新規顧客の受付が止まった製品なので、数年先の更新時に同じ問題がもう一度起きます。
避けたいのは、移行のたびに「次の物理デバイス」を探す流れです。転送は回線とDataSync、処理は汎用機とGreengrassに分けておけば、特定のデバイスの終了に振り回されにくくなります。
AWSのデータ移行とエッジ構成の見直しを外部へ相談する作業範囲の目安
DataSyncの登録やGreengrassのインストール自体は、手順どおりに進めれば社内で完結します。外部の手を借りる価値があるのは、拠点ごとの回線とデータ量を棚卸しし、どの拠点を回線転送に、どの拠点をエッジ処理に寄せるかを一度に決める局面です。Snowconeで動かしていた処理をコンポーネントへ作り直す作業も、まとまった工数がかかります。一創ではインフラ構築(AWS・Google Cloud・Azure)として、データ移行の経路設計からエッジ側の構成、運用の自動化までを請け負っています。
よくある質問
Snowconeの終了後によく挙がる質問をまとめます。
AWS Snowconeは今も使えますか?
使えません。2024年11月12日にサービスが廃止され、新規・既存とも注文が止まりました。既存デバイスのサポートも2025年11月12日で終了しています。手元に返却していないデバイスが残っている場合は、AWS CLIのaws snowball list-jobsでジョブの状態を確認し、サポートへ返却方法を問い合わせてください。
Snowconeの後継機はありますか?
同じ形の後継機はありません。Snowball Edgeも2025年11月7日から新規顧客の受付を止めており、新規に注文できるSnow Familyのデバイスは無くなりました。AWSは転送にDataSync、物理転送にData Transfer Terminalかパートナー製品、エッジ処理にOutpostsを案内しています。
Snowconeのデータを回線で送るとどれくらいかかりますか?
DataSyncの公式の計算式で、利用率80%・24時間稼働を仮定すると、8TBは100Mbpsで約9.3日、1Gbpsで約0.9日です。14TBなら100Mbpsで約16.2日になります。実際には回線の混雑やストレージの性能で延びるため、事前に小さなデータで転送速度を測ってから計画を立ててください。
Snowconeの代わりに小型PCでDataSyncエージェントを動かせますか?
Snowconeと同じ大きさの機器では難しいでしょう。DataSyncエージェントのVMには、Basicモードで4vCPU・メモリ32GB・ディスク80GBが必要です。動かせるのはVMware ESXi、KVM、Hyper-V、Amazon EC2のいずれかなので、社内の仮想化基盤に1台分の資源を確保するのが現実的です。
Snowconeの名前の由来になったスノーコーンとは何ですか?
英語のsnow coneは、削った氷にシロップをかけて紙のコーンに盛った、かき氷に近い冷菓を指します。AWSのSnow Familyは雪にちなんだ名前で揃えられており、最大のSnowmobile、中くらいのSnowball、最小のSnowconeという大きさの序列になっていました。検索結果でかき氷の情報とAWSの情報が混ざるのはこのためです。
関連記事
- AWS Outpostsとは?ラックとサーバーの違い・対応サービス・導入判断を実装者目線で解説:AWSが案内するエッジ処理の代替の全体像を確認できます
- クラウドデータ移行の手順とは?移行ツール・整合性検証・大容量転送の実務を実装者向けに解説:DataSync以外も含めた大容量転送の手順と検証の進め方が分かります
- AWS Storage Gatewayとは?3種のゲートウェイの使い分けとオンプレ段階移行の構成を実装者目線で解説:NFS共有を残したままクラウドへ段階的に寄せる構成を比較できます