Cloud and virtual mission operations
Cloud-based mission control cuts the cost and timeline of early operations, but every packet your spacecraft sends home transits infrastructure you do not own. Understanding what that means in practice is the starting point for any sovereign programme.
What cloud operations actually means in engineering terms
Cloud mission control is not a single product. It is a stack of services, each of which can be sourced independently or bundled: a ground-station network accessed via API (companies such as AWS Ground Station and KSAT's Lite service publish this model), a flight-dynamics and scheduling engine running on shared compute, a telemetry database with a web front-end, and an alerting layer that pages an operator when a limit is violated. The spacecraft itself does not change. The difference is that the processing chain between antenna and operator sits on rented infrastructure rather than dedicated hardware in a room your government controls.
For a first satellite, this arrangement is genuinely attractive. A government that wants on-orbit experience before committing capital to a permanent facility can be receiving and commanding a spacecraft within weeks of launch, using browser-based tools and a handful of trained staff. The operational learning is real; the sunk cost is low. That is the honest case for starting here.
The cost arithmetic, and where it inverts
Cloud operations pricing typically follows a consumption model: per-pass fees for ground-station access, compute charges for processing and storage, and a platform licence. For a single small satellite with four to six contacts per day, published indicative figures from AWS Ground Station suggest per-minute antenna fees in the range of a few dollars, which can total well under $200,000 per year for a low-Earth-orbit mission with modest downlink volume. Against the capital cost of a dedicated antenna, server room and 24/7 staffing, the early-mission saving is real.
The arithmetic inverts as the constellation grows. A three-satellite constellation with high-rate X-band downlinks can generate hundreds of gigabytes per day. Cloud egress charges, compute costs and per-pass fees accumulate. At some threshold, which varies by downlink rate, data volume and redundancy requirements, owned infrastructure becomes cheaper per gigabyte. That threshold is not always obvious in advance, and vendors have little incentive to help you find it. Any programme that anticipates growth should model the five-year total cost of ownership before signing a multi-year cloud contract.
Telemetry jurisdiction and the sovereignty question
This is the section most cloud-operations vendors prefer to summarise quickly. When your spacecraft downlinks telemetry to a commercial ground station in another country, that data is subject to the legal jurisdiction of that country at the moment of reception. It then transits the public internet or a private backbone to reach the cloud provider's data centre, which may be in a third jurisdiction. Your telemetry, commanding authority and mission logs may simultaneously touch three or four legal systems, each with its own data-access and interception laws.
For a weather or crop-monitoring satellite carrying no sensitive payload, this may be an acceptable risk. For a defence-adjacent Earth observation mission, a communications satellite serving government users, or any spacecraft whose orbital parameters and health data would reveal operational patterns, it is a material exposure. The relevant question to ask any cloud provider is not 'is the data encrypted?' (it will be) but 'under what legal instruments could a third-party authority compel you to provide access to our data or interrupt our commanding sessions?' Few providers answer this in their standard terms.
Limits, failure modes and the things vendors understate
Latency is manageable for most LEO operations but becomes a constraint for time-critical commanding. A cloud-routed command chain can introduce variable latency of tens to hundreds of milliseconds compared with a direct ground-station connection. For routine housekeeping this is irrelevant. For an emergency safe-mode recovery where you are racing a ground-station pass, it matters.
Vendor lock-in is structural, not incidental. Telemetry databases, scheduling engines and ground-station APIs are not interoperable across providers. Migrating from one cloud operations platform to another requires re-integrating every interface, re-validating procedures and retraining staff. Programmes that do not negotiate data-portability and API-export rights before signature often discover this at the worst moment, which is when they want to leave.
Availability guarantees deserve scrutiny. A published 99.9 percent uptime figure means roughly nine hours of potential downtime per year. For a LEO satellite with twelve-minute passes, nine hours of ground-system unavailability could mean missing dozens of contacts. The more important number is the provider's mean time to restore commanding capability after an outage, and most contracts do not specify it. Cloud providers also reserve the right to deprecate services with notice periods that may be shorter than your mission lifetime.
Exit strategies: planning the migration before you need it
A programme that starts in the cloud and intends to migrate to a sovereign operations centre later, as Satellize structures in its hybrid handover engagements, needs to engineer the exit from day one. That means insisting on open or documented telemetry formats (CCSDS standards are the baseline), maintaining a local copy of all mission data, and ensuring that flight-dynamics software can be re-hosted. It means training national operators on the underlying engineering, not just the vendor's GUI. And it means negotiating a contractual right to export all historical telemetry, procedures and configuration data in a machine-readable format.
The migration itself is not instantaneous. A parallel-operations period, typically three to six months, where both the cloud system and the incoming sovereign facility are active simultaneously, is the minimum prudent approach. During that period, commanding authority should transfer progressively, pass by pass, so that the national team accumulates real experience before the cloud contract lapses. Programmes that skip this step and perform a hard cutover frequently discover undocumented dependencies at the worst possible moment.
Engineering parameters
| Typical time-to-first-contact after launch | Days to weeks (vs. months for a new sovereign facility) |
| Ground-station access latency (cloud-routed) | Tens to low hundreds of milliseconds above direct connection |
| Per-pass antenna fee (indicative, published) | ~$1–5 per minute for S/X-band LEO (AWS Ground Station published rates) |
| Typical annual cost, single LEO smallsat | $100,000–$300,000 depending on pass frequency and downlink volume |
| Data sovereignty jurisdictions in transit | Typically 2–4 (ground station, backbone, cloud region, operator location) |
| Uptime SLA (typical published) | 99.9% (~8.7 hrs downtime/year); MTTR for commanding rarely specified |
| Telemetry format interoperability | Varies; CCSDS-compliant systems are portable, proprietary formats are not |
| Migration lead time to sovereign facility | 3–6 months parallel operations recommended as minimum |
| Cost inflection point (cloud vs. owned) | Typically 2–4 satellites with high-rate downlinks; model before signing |
One contract, one accountable engineer
Commissioned as one programme, not a stack of contracts: spacecraft, launch, ground segment, mission control, training and handover are priced together. Source-access terms and audit rights are agreed in writing before signature. Request a jurisdiction-risk briefing.