How to migrate to the new AWS Ground Station Agent launching March 28

On April 12, 2023, Amazon Web Services (AWS) announced the general availability of Wideband Digital Intermediate Frequency (DigIF) for satellite operators using Software Defined Radios (SDRs) with AWS Ground Station. Wideband DigIF data can be delivered to Amazon Simple Storage Service (Amazon S3) or to Amazon Elastic Compute Cloud (Amazon EC2). Customers using Wideband DigIF delivery to Amazon EC2 need to provision AWS Ground Station Agent (agent) on Amazon EC2. The agent enables secure, reliable, high rate and low jitter data delivery.

On March 28, AWS will release a new version of the agent, which is not compatible with past agent releases. In order to maintain operational continuity of Ground Station environments, agent users must follow the instructions provided in this blog post before upgrading to the March 28 version of the agent.

Note: If your Amazon EC2 receiver instance is already configured to have an Elastic IP associated with a network interface—which is associated with a public subnet—and if the agent on the instance has CPU cores allocation corresponding to the new agent version (shown in Table 1), then there is no action needed. Please still consider reading this post to be aware of the changes.

The new release of the agent introduces the following changes, which require actions from current users:

• With past releases, the Amazon EC2 receiver instances (instances with provisioned agent) were allowed to have the Elastic IP associated with a network interface, which is associated with a private subnet. The new agent version requires that the Elastic IP is associated with a network interface associated with a public subnet (see the Security aspects of agent operations section of this post). If you already have your Elastic IP associated with a network interface associated with a public subnet, then no change is required for this step.
• The new agent version requires additional CPU cores, shown in Table 1.

Migration to the new agent version

The migration path to the new version of the agent is shown in Figure 1 and is described in the text that follows.

Figure 1. A timeline of the release of the new version of the agent and the changes which customers must make.

• Do before March 13: In your AWS account, identify your existing Wideband DigIF stacks which you want to have operational after March 28, and collect AWS CloudFormation templates for them. We call them customer “legacy” CloudFormation templates. The customer legacy CloudFormation templates are normally based on the Wideband DigIF CloudFormation template, released on April 12, 2023 (we call it the “legacy” Wideband DigIF CloudFormation template).
• Do before March 13: Fetch the updated Wideband DigIF CloudFormation template provided by AWS. The CloudFormation template is compatible with the requirements of the new agent version. We will call it a “new” Wideband DigIF CloudFormation template.
• Do before March 13: Create a customer “test” CloudFormation template by adding your SDR-specific code into the new Wideband DigIF CloudFormation template, which makes sure the receiver Amazon EC2 instance has an elastic network interface (ENI) in a public subnet. Alternatively, if customers have highly customised Wideband DigIF CloudFormation templates, they may choose to modify their existing templates to make sure the receiver Amazon EC2 instance has an ENI in a public subnet. In addition, please increase the amount of cores allocated to the agent following the values in Table 1. You will need to edit parameter agentCpuCores of AGENT_CONFIG in the UserData. Please make sure you also reallocate CPU cores to SDR and other processes, so they don’t interfere with the agent cores (this might be reflected in the Updated SDR & customer-specific code step in Figure 1).

Table 1. CPU core allocation for agent

• Do before March 13: Deploy test stacks based on your customer test CloudFormation template. The customer test CloudFormation template is based on the new Wideband DigIF template, which makes sure the receiver Amazon EC2 has an Elastic IP associated with a network interface associated with a public subnet. Values of CloudFormation template parameters SubnetId and PublicSubnetId determine how the Amazon EC2 instance will be deployed. The following Table 2 has two alternatives.

Table 2. Deployment options for the receiver Amazon EC2

The deployment (if done before March 28) will use the current (legacy) version of the agent and is intended to make sure that the new vCPU allocation for the agent and (potentially) new Amazon EC2 placement in the VPC work nominally.

• Do before March 13: Schedule a test contact with the test workload deployed in the previous step, and make sure the contact works and the SDR receives and processes the satellite data as expected. Please contact your AWS account team in case the contact doesn’t work as expected.
• Do before March 13: If you are satisfied with the preceding test results, please delete your test workload (it’s based on the legacy agent and won’t work after March 28).
• Do before March 13: Confirm with your AWS account team that you are ready to migrate to the new agent version.
• Do before March 28: Cancel your AWS Ground Station contacts scheduled for March 28 and onwards with your legacy production workloads.
• On March 28 (the new agent version is released): Deploy your “new production” workload using the customer test CloudFormation template from the previous step. The deployment will fetch and use the new agent version (the new agent version will be available from March 28 on the same URL as the legacy agent).
• On March 28: Schedule your post-March 28 contacts with the mission profile, corresponding to the new production workload.
• On or after March 28: Delete your legacy production workloads.
• Final state: All customer Wideband DigIF workloads are provisioned with the customer new production CloudFormation template and use the new agent version.

Contact your AWS account team if you face any difficulties during the migration.

Security aspects of agent operations

Security is job zero at AWS. AWS employs the Shared Responsibility Model where AWS is responsible for “Security of the Cloud” and customers are responsible for “Security in the Cloud.”

The following diagrams show possible deployment options of Wideband DigIF workloads with the new agent (for brevity, the diagrams omit the AWS Lambda starting and stopping the receiver Amazon EC2 instance). Figure 2 illustrates deployment into a public subnet.

Figure 2. Architectural diagram of a receiver Amazon EC2 instance deployed into a public subnet. AWS Ground Station sends Wideband DigIf data to the Elastic IP, associated with an ENI associated with a public subnet.

Figure 3 illustrates deployment into a network address translation (NAT-ed) private subnet.

Figure 3. Architectural diagram of a receiver Amazon EC2 instance deployed into a private NAT-ed subnet. AWS Ground Station sends Wideband DigIf data to the
Elastic IP, associated with an ENI associated with a public subnet.

The receiver Amazon EC2 (running the agent and SDR) along with the associated ENIs are customer-managed resources and therefore it is important that the customers employ the following security best practices to manage the resources:

Security of data in transit

• Data sent between AWS Ground Station and the agent is encrypted with a KMS key. See the documentation about the Data Delivery Key.
• Customers accessing the control panel of SDR provisioned on the receiver have to contact the SDR vendor to clarify what secure types of communication the SDR offers for the control panel (for example, it can be HTTPS for web-based control panels).
• Customers moving data decoded by the SDR outside Amazon EC2 should use secure channels, such as copying the decoded data as files to an Amazon S3 bucket via HTTPS. In cases of real-time streaming of the data out of SDR, the SDR vendor may guide the customer about the traffic encryption options, otherwise the customer may consider employing solutions like SSL encryption for Ncat.

Network security

• As the receiver Amazon EC2 has an ENI in a public subnet, it’s important to make sure the ENI receives only allowed traffic. To control the incoming traffic, customers use security groups. The provided CloudFormation template (see InstanceSecurityGroup on line 221) allows UDP traffic to ports 42000-50000 from AWS Ground Station (limited to source addresses, which are part of the service prefix), along with SSH traffic.
• Instead of opening an SSH port on Amazon EC2, we recommend using AWS Systems Manager Session Manager (Session Manager) as a more secure option. Session Manager allows users to remotely connect to the receiver Amazon EC2 instance using the Session Manager agent instead of SSH. Systems Manager Session Manager uses an always open connection from the agent to Systems Manager endpoints and does not require inbound rules on the security group attached to the instance.
• The provisioned SDR may require opening more ports, and hence adding them to the InstanceSecurityGroup, for example to access the SDR’s control panel. We recommend customers consult with their SDR vendor to understand what ports are required to be opened.
• The customers operating AWS Ground Station workloads at scale, who would like to manage security groups in a centralised way, may consider using AWS Firewall Manager or AWS Config.

Security of data in rest

• The receiver Amazon EC2 has storage through Amazon Elastic Block Store (Amazon EBS). Customers may consider Amazon EBS encryption by default which applies at Region-level, or for more granular control at the CloudFormation template level for each deployed stack, as described in documentation.

Software updates and vulnerability management

• The customer is responsible for regular updates of software provisioned on the receiver Amazon EC2, including OS components, the agent, and SDR.
• Customers can update and patch their OS of the receiver Amazon EC2 instance with Systems Manager Run Command. using AWS-RunPatchBaseline. This document will not update the Ground Station Agent or SDR vendor software installed without the OS tools.
• Customers can automate the update of the agent with Systems Manager Run Command. Customers must create their own Systems Manager document to specify to Systems Manager how to download, install, and reload the agent on the target agent instances.

The code snippet bellow contains an Systems Manager document example in JSON format to download the latest version of the agent, update the agent, and reload the agent after update.

{
  "schemaVersion": "2.2",
  "description": "Download and installs latest version of Ground Station Agent (GSA).",
  "mainSteps": [
    {
      "action": "aws:downloadContent",
      "name": "downloadGSA",
      "inputs": {
        "SourceType": "S3",
        "SourceInfo": {
          "path": "https://groundstation-wb-digif-software-us-east-2.s3-us-east-2.amazonaws.com/aws-groundstation-agent/latest/amazon_linux_2_x86_64/aws-groundstation-agent.rpm"
        },
        "destinationPath": "/tmp/"
      }
    },
    {
      "action": "aws:runShellScript",
      "name": "UpdateGSA",
      "inputs": {
        "timeoutSeconds": "3600",
        "runCommand": [
          "#!/bin/bash",
          "yum -y install /tmp/aws-groundstation-agent.rpm"
        ]
      }
    },
    {
      "action": "aws:runShellScript",
      "name": "GSAReload",
      "inputs": {
        "timeoutSeconds": "3600",
        "runCommand": [
          "#!/bin/bash",
          "systemctl restart aws-groundstation-agent",
          "systemctl status aws-groundstation-agent"
        ]
      }
    }
  ]
}

• Once you have created the document, please follow instructions to run the document through the Systems Manager Run Command.
• We recommend customers seek guidance from their SDR vendors about the recommended ways of updating their SDR software.
• We recommend customers establish a test environment, isolated from their production environment, for testing updates of OS, the agent, and SDR on the receiver Amazon EC2 instances. Please schedule a test contact with a satellite in the test environment after doing the update of the components to ensure everything operates nominally. Once the nominal operation in the test environment is confirmed, you can perform the respective updates in your production environment.

Conclusion

In this post, we described new requirements imposed by the new version of AWS Ground Station Agent which will be released March 28. We described a migration process from the legacy version of the agent to the new version. We encourage current users of the agent to follow the migration procedure and the security best practices covered in the post.