Automate and improve your security posture using AWS Backup and AWS PrivateLink

Enterprises set up their AWS environment preconfigured in-line with organizational security policies, compliance, and detective and preventive controls codified right from the beginning. Furthermore, enterprises want to access cloud-native services in a manner similar to how they have been consuming services in the past, from within their own secured networking environment according to their security policies. When consuming cloud-native services via their public endpoint, the request/response traffic (although encrypted) is still exposed to the public internet. This may not be acceptable to security-conscious enterprises.

In this blog, I demonstrate how enterprises can uplift their security posture when using AWS Backup, helping them comply with their regulatory requirements. AWS Backup now supports AWS PrivateLink, allowing enterprises to access AWS Backup from their Amazon Virtual Private Cloud (VPC) by using a VPC endpoint placed within their private network space. In short, it eliminates the need to use the public internet for service access. In addition, extra controls can be added via security group and VPC endpoint policy when accessing the service through the VPC endpoint.

Background

Orchestration and operations on the various AWS services, using methods such as AWS CLI and/or service API/SDK, are done via the underlying service’s endpoint. A service’s endpoint is the URL that provides the entry point to that service. These service endpoints are public and accessible over the public internet (HTTPS). For example, the Sydney Region’s endpoint for the AWS Backup service is backup.ap-southeast-2.amazonaws.com.

AWS PrivateLink provides a network abstraction that links the enterprise’s VPC with the given AWS service (such as AWS Backup) and presents the service’s endpoint as a VPC endpoint within the enterprise’s network address space as depicted in Figure 1. Therefore, when using the AWS Backup PrivateLink all request/response traffic to the AWS Backup endpoint now stays internal and within the enterprise’s private network.

Figure 1: AWS PrivateLink block diagram

Some other benefits that become available with VPC endpoint are private DNS and the VPC endpoint policy. The private DNS for VPC endpoint ensures that the same familiar DNS (example backup.ap-southeast-2.amazonaws.com) in the enterprise’s environment is automatically made to point to a private IP address assigned to the VPC endpoint.  Thereby making private the consumption of the service without changing the experience for the workload teams. When the service is accessed through the VPC endpoint, VPC endpoint policies can be added for even more control when the service is accessed through the VPC endpoint.

A complete list of the AWS Backup endpoints in the various AWS Regions is available in the Reference guide. The APIs that can be invoked via this endpoint are listed at the AWS Backup Developer Guide.

Prerequisites

The easiest way to experiment and set up the AWS Backup PrivateLink feature is to use:

1. An AWS Account and the AWS Management Console
2. AWS Cloud9 IDE instance, which comes bundled with the AWS CLI and other tools.

Getting started

The AWS Backup commands in AWS CLI use the AWS Backup’s public service endpoint URL (backup.ap-southeast-2.amazonaws.com), which can be inspected for a given Region in an AWS Cloud9 IDE terminal as shown in Figure 2.

Figure 2: Example of AWS Backup service endpoint

An enterprise can organize its AWS environments in multiple ways with various segmentation approaches used to contain the blast radius—the maximum impact that might be sustained in the event of a system failure. A typical approach is a multi-account strategy for the workload teams and centralized accounts for core services (networking, security, logging, and so on). Furthermore, each workload team can be assigned their own VPCs or have an optimized shared-VPC design. Therefore, the AWS Backup Privatelink can be deployed into each of the workload VPCs or into a shared-services VPC. For the sake of simplicity, we will deploy the VCPE into the default VPC (CIDR – 172.31.0.0/16) that is automatically created for a new account.

Figure 3: Example of default VPC with default subnets.

To create a new VPC endpoint for AWS Backup service, using the AWS Management Console, navigate to VPC. Under the Endpoints tab, choose Create endpoint. In the Name tag field, provide a tag. Under Service category, select AWS services.

Figure 4: AWS Management Console to create a new VPC endpoint

Then, in the Filter services search bar, search and select the backup service for your Region (example: com.amazonaws.ap-southeast-2.backup). All the AWS services that currently support the PrivateLink feature are listed at the AWS PrivateLink Documentation.

Figure 5: Service selection when creating VPC interface endpoint

For the VPC dropdown, select the VPC where we want to deploy the endpoint (for example, the default VPC). Also, the selection Enable DNS name under Additional settings is checked by default. This allows for applications, clients and SDKs using the public endpoint DNS name (backup.ap-southeast-2.amazonaws.com) to continue to use the same DNS name but have it now mapped to the local/private address in the selected VPC. This helps with portability as any scripts, code, or SDKs continue to operate using the same DNS name without having to recode, rewrite, and recompile.

Figure 6: VPC selection and DNS setting when creating VPC interface endpoint

The VPC endpoint can be deployed into multiple subnets across the Availability Zones. This is to have highly available access to the AWS Backup service endpoint. We select one subnet for each of the three Availability Zones. As a result, three elastic network interfaces will be created for the VPC endpoint and placed in the corresponding subnets. In addition, as we will see later, three Zonal DNS records will be created for each of the Availability Zones pointing to the corresponding network interfaces and another DNS record will be created at the Regional level pointing to all three network interfaces, similar to the official Regional DNS name (backup.ap-southeast-2.amazonaws.com), which will also be remapped to the three network interfaces created for the VCPE.

Figure 7: Subnet selection when creating VPC interface endpoint

Further tightening of the security posture is done by the security groups that get attached to the network interfaces created for the VCPE. Ensure that your AWS Cloud9 instance is also part of the same chosen security group so that it can access the AWS Backup endpoint, as we will experiment with the PrivateLink once it is up. More granular controls can be codified using the endpoint policy which can be associated with the VCPE. This allows for very fine-grain control of the access to the AWS Backup service in accordance to the principle of least privilege. For now we leave the policy set to Full access.

Figure 8: Associating Security Groups with VPC interface endpoint

With the above settings, go ahead and select Create endpoint. Once the endpoint is created and the status is Available, it will be listed in the VPC service console under the Endpoints section. Here the details of the endpoint can be inspected along with the private DNS names and also the Zonal and Regional DNS records that have been created and associated with the endpoint.

Figure 9: Details for VPC interface endpoint post creation

The details of the network interfaces that have been created for the VCPE and placed in the chosen subnets across the three Availability Zones can be viewed in the Subnets tab.

Figure 10: AWS Elastic Network Interface (ENI) created for and associated to a VPC interface endpoint

Now back in the AWS Cloud9 IDE, we can validate that the private DNS has been activated and that the formal DNS name is now pointing to the private IP addresses of the corresponding network interfaces:

Figure 11: AWS Backup service endpoint available via the newly created VPC interface endpoint

With the service endpoint available in the private IP address space, we can start interfacing with the AWS Backup APIs. A convenient way to experiment with the APIs is to use the AWS CLI for AWS Backup and invoke the service through that.

Figure 12: CLI commands for the AWS Backup service

First, we list the currently available backup plans. Create a few through the console and you will be able to list it with the AWS CLI list-backup-plans command:

Figure 13: Example of AWS Backup service’s list-backup-plans command

We can confirm that the AWS CLI is using the private DNS by switching on debug mode when running the AWS CLI command (using the –debug flag) where a dump of the actual GET call is available.

Figure 14: Example of AWS Backup service’s list-backup-plans command in debug mode

Next, we will start a new backup job for an EBS volume (let’s use the volume associated with our AWS Cloud9 EC2 instance) and have it placed in the default vault. Using the list-backup-vaults command, we get a list of available vaults:

Figure 15: Example of AWS Backup service’s list-backup-vaults command

Then we use the start-backup-job to kick-start the job providing the details of the vault, resource (EBS volume in this case), and the IAM role to use. These details can be easily gathered from the AWS Management Console. Once we kick off the job a BackupJobId is returned that can be used to track the state of the job.

Figure 16: Example of AWS Backup service’s start-backup-job command

Finally, we use the describe-backup-job command to track the progress of the backup job:

Figure 17: Example of AWS Backup service’s describe-backup-job command

Cleaning up

In order to avoid incurring future costs, please make sure to delete any resources created in this walkthrough that are no longer needed. This includes:

1. Cloud9 IDE instance
2. VPC Interface endpoint created for the AWS Backup service

Conclusion

In summary, security-conscious enterprises can uplift their security posture when consuming AWS Backup with the AWS PrivateLink feature.

AWS PrivateLink support brings the AWS Backup service to within the enterprise’s private network environment. That is, the AWS Backup service orchestration and operation can be triggered from the enterprise’s own AWS or on-premises environment without having to leave their secure and private internal network.

Secondly, the use of AWS PrivateLink can uplift the security posture by creating a private service access point (VCPE) and then securing it with a centralized policy composed using explicit security-group and endpoint-policy. For example, the backup report aggregation solution can get a security posture uplift by the use of the PrivateLink feature.

Finally, it allows enterprises to take AWS Backup processes and weave them into their CI/CD pipelines for infrastructure and applications, in a manner that is secure and has immense scope for automation.

Learn more about this new feature on the AWS Backup documentation page. Let us know how you plan to use AWS Backup and AWS PrivateLink in the comments section.