Commercial and government satellite programs have shifted ground system architectures from purpose-built on-prem hardware toward cloud-native patterns. AWS Ground Station and Azure Orbital provide managed antenna connectivity as a service — eliminating the need for programs to build and operate physical ground station infrastructure. The software processing that follows (data ingest, pipeline processing, product distribution, mission operations) runs in standard cloud compute.
This architectural shift creates new design problems: real-time constraints in a distributed environment, data volume management across satellite passes, compliance for programs handling defense or sensitive remote sensing data, and resilience when passes are time-critical and can't be replayed.
Ground Contact Architecture: AWS Ground Station Integration
AWS Ground Station provides managed S-band and X-band antenna contacts at global antenna sites. For programs using AWS Ground Station:
# Satellite configuration in Terraform
resource "aws_groundstation_config" "antenna_downlink" {
name = "${var.satellite_name}-downlink"
config_data {
antenna_downlink_config {
spectrum_config {
bandwidth {
units = "MHz"
value = var.bandwidth_mhz
}
center_frequency {
units = "MHz"
value = var.center_frequency_mhz
}
polarization = "RIGHT_HAND"
}
}
}
}
resource "aws_groundstation_mission_profile" "main" {
name = "${var.satellite_name}-mission-profile"
minimum_viable_contact_duration_seconds = 30
tracking_config_arn = aws_groundstation_config.tracking.arn
dataflow_edges {
source = aws_groundstation_config.antenna_downlink.arn
destination = aws_groundstation_config.dataflow_endpoint.arn
}
}
Data flows from the antenna directly into the program's data ingest pipeline via a delivery endpoint — typically an EC2 instance or Kinesis Data Stream configured to receive the contact data. Contact windows are scheduled in advance; the architecture must handle the burst data arrival at contact time without losing packets.
Contact Data Ingest Pipeline
The ingest pipeline receives burst data during antenna contact windows (typically 5-12 minute passes) and must: - Accept the high-throughput data stream without drops - Buffer for processing (pass data isn't always processed in real time — processing queue must handle post-pass batch) - Preserve original raw data before any processing (Level 0 archive) - Trigger downstream processing workflows on contact completion
import boto3
import json
import logging
from datetime import datetime
from typing import Optional
logger = logging.getLogger(__name__)
class ContactIngestHandler:
def __init__(self, s3_bucket: str, queue_url: str):
self.s3 = boto3.client('s3')
self.sqs = boto3.client('sqs')
self.raw_bucket = s3_bucket
self.processing_queue = queue_url
def handle_contact_data(
self,
contact_id: str,
satellite_id: str,
contact_timestamp: datetime,
data_stream: bytes
) -> dict:
"""
Ingest raw contact data: archive Level 0, trigger processing.
Returns artifact location for audit trail.
"""
# Archive raw data immediately — never process from archive,
# always process from the archived copy
raw_key = (
f"raw/{satellite_id}/"
f"{contact_timestamp.strftime('%Y/%m/%d')}/"
f"{contact_id}.bin"
)
self.s3.put_object(
Bucket=self.raw_bucket,
Key=raw_key,
Body=data_stream,
ServerSideEncryption='aws:kms',
SSEKMSKeyId=self._get_kms_key_id(),
Metadata={
'contact-id': contact_id,
'satellite-id': satellite_id,
'ingest-timestamp': contact_timestamp.isoformat(),
}
)
# Trigger processing pipeline
processing_message = {
'contact_id': contact_id,
'satellite_id': satellite_id,
'contact_timestamp': contact_timestamp.isoformat(),
'raw_s3_key': raw_key,
'raw_s3_bucket': self.raw_bucket
}
self.sqs.send_message(
QueueUrl=self.processing_queue,
MessageBody=json.dumps(processing_message),
MessageGroupId=satellite_id, # FIFO queue — order within satellite
)
logger.info(
"Contact ingested: %s | satellite: %s | raw_key: %s",
contact_id, satellite_id, raw_key
)
return {
'contact_id': contact_id,
'raw_location': f"s3://{self.raw_bucket}/{raw_key}",
'processing_queued': True
}
Critical pattern: Raw data is archived before any processing begins. Processing always runs against the archive copy — if processing fails or produces incorrect results, the raw data is still intact and can be reprocessed.
Multi-Satellite Scheduling and Conflict Resolution
Programs with multiple satellites and limited antenna capacity require contact scheduling that optimizes antenna allocation across competing demands:
- Priority contacts (time-critical missions) scheduled before best-effort contacts
- Housekeeping contacts (telemetry/state-of-health) balanced against data downlink demand
- Contact window constraints (orbital mechanics define when contacts are possible; antenna site coverage determines which sites can serve which contacts)
For cloud-native scheduling, the contact priority queue uses SQS FIFO with message group IDs per satellite for ordering, combined with a scheduling lambda that resolves conflicts based on mission priority configuration.
View Rutagon's aerospace cloud capabilities → rutagon.com/aerospace
Frequently Asked Questions
What data rates do satellite ground station contacts typically generate?
Data rates vary significantly by mission type. Earth observation satellites (optical and SAR) with high-resolution sensors can generate hundreds of megabytes to several gigabytes per pass. Low-Earth orbit small satellites with telemetry-only payloads may generate only megabytes per contact. The ingest architecture must be sized for peak data rate during the contact window — not average throughput. Typical X-band downlink rates for imaging missions range from 100-800 Mbps.
How is timing handled for time-critical contact operations?
Contacts have precise timing windows driven by orbital mechanics. AWS Ground Station contacts are scheduled with UTC timestamps and the ground system must be ready to receive data at contact start. Lambda cold starts and queue processing delays can introduce latency — the critical ingest path uses pre-warmed Lambda functions (provisioned concurrency) or EC2 instances that remain running throughout the contact window, accepting streaming data directly.
How do government programs handle data classification from commercial ground stations?
Programs with classified or CUI-bearing satellite data can't use commercial cloud ground station services in the same way as unclassified programs. Options: (1) Use AWS GovCloud for all ground system components, ensuring the data remains within the FedRAMP boundary. (2) Use specialized ground stations with appropriate classification handling for the downlink segment, with cloud-only used for the processing and distribution segment after the data has been appropriately handled. Specific options depend on the data classification level and applicable security requirements.
What is Level 0 data in satellite ground systems?
Level 0 is the raw instrument data as received from the satellite — unprocessed, in the original engineering unit format (counts, not physical units). Higher data levels represent successive processing: Level 1 (calibrated instrument data), Level 2 (geophysical parameters in sensor coordinates), Level 3 (geophysical parameters mapped to uniform grids). The archive preserves Level 0 data permanently — it allows any processing error to be corrected by reprocessing from the raw data. Higher processing levels may be reprocessed when algorithms improve.
Can AWS Ground Station be used for programs with International Traffic in Arms Regulations (ITAR) restrictions?
AWS GovCloud is the appropriate platform for ITAR-controlled satellite programs — GovCloud is operated exclusively by US Persons (a US citizens / US permanent residents requirement on GovCloud staff). For ITAR-controlled programs, all technical data related to the satellite, its capabilities, and its processed outputs must remain within ITAR-compliant infrastructure. AWS GovCloud's operational controls provide the personnel access requirements. Programs must still implement appropriate access controls, encryption, and information handling procedures on top of the GovCloud baseline.