Category Archives: Uncategorized

AWS Backup for IaaS Workloads: The Basics

Use Cases & Technologies

Cloud providers market their platform-as-a-service features, e.g., for AI or IoT. In contrast, many companies currently focus on moving their existing Windows and Linux applications into the cloud. “Lift-and-shift” is the motto. Rearchitecting is a task for later. As you might remember, neither the rise of C nor Java caused the immediate death of COBOL applications. Thus, in the cloud, the ability to backup IaaS workload is one of the most crucial topics when moving to the cloud – and AWS Backup is Amazon’s cloud-native solution for backups. How does it help?

What does the workload look like, and which use cases should be supported? With the focus on IaaS, the VMs with their disks, file storage, and object storage are in place. The latter is a web service, but object storage is the new main storage variant in the cloud for new components configured or developed in a public cloud environment.

AWS Backup supports a long list of AWS services, including the following IaaS-related ones:

  • EC2, AWS’s term for VMs
  • Amazon Elastic Block Store (Amazon EBS), aka block storage for EC2 instances
  • Amazon Elastic File System (Amazon EFS), a file system solution working with EC2 with Linux operating system, a technology typically needed by many traditional applications
  • Amazon FSx supporting various file systems, including Windows File Server or NetApp ONTAP
  • Amazon Simple Storage Service (Amazon S3) as the object storage service

So, this blog post covers how to organize backups for IaaS workload running on Windows and Linux EC2 instances with attached EBS volumes on which applications run relying on EFS and FX file systems for classic file storage, plus incorporating S3 buckets as the new dominant storage type in clouds. Figure 1 visualizes this.  

Figure 1: IaaS Workloads and Backups

Typical technical use cases for backup solutions are:

  1. Ad-hoc Backups, i.e., engineers make a manual copy before complex, risky changes
  2. Periodic Backups to prepare if something goes wrong and one has to restore a recent or long-ago state
  3. Continuous backups for Point-in-Time Recovery (PITR) as a solution covering both use cases above

AWS links to the solutions for 1 and 2 directly on the dashboard page for AWS in the AWS portal (Figure 2), whereas number 3 is part of the configuration options for 2.

Figure 2: AWS Backup (Dashboard)

A fourth aspect is geo-redundancy, important for disaster recovery events, such as the loss of complete data centers or region-wide blackouts (4). Finally, we look at Frameworks, a governance and compliance tool (5).

AWS Backup Plan

Setting up an AWS Backup Plan in AWS Backup means configuring one or more backup rules (Figure 3, 1) and one or more resource assignments (Figure 3, 2).

Figure 3: AWS Backup Plan Example

There are many ways to configure the various settings for backup rules. Thus, we focus on the settings for two scenarios. The first one is for periodic backups that have to be stored for years and which should be safe even in case of larger catastrophes. Thus, the configuration shown in Figure 4 sets the interval to four hours, whereas the retention time is 10 years, and a copy is stored in a different region than the original backup.

Figure 4: AWS Backup Plan for periodic backups with long retention and copy to another region

The second scenario is about backups needed for misconfigurations in operations. A wrong patch is deployed, an admin – by mistake – drops production data, etc. For this scenario, a continuous backup is perfect, allowing for point-in-time recovery (Figure 5). Just a warning: the fine print states that the continuous backup is available only for three AWS services: RDS, S3, and SAP Hana on EC2. For other services, the “hourly” periodicity counts. So, when looking at the IaaS services in AWS mentioned in the beginning, PITR is not available for EBS Volumes and EFS File Systems which are assigned to EC2 instances.

Figure 5: AWS Backup Rule with continuous backup for Point-in-Time Recovery (PITR)

The resource assignment defines what is in scope for the backup. It allows filtering based on the resource type (e.g., EBS, S3) and tags assigned to resources (Figure 6). Once resource assignments and backup rules are defined, everything is ready, and Azure performs the (next) backup as specified in the rule.

Figure 6: Resource assignments in AWS Backup

Frameworks for AWS Backup

Backups help bring up an application or a complete data center again when something goes severely wrong. However, if backups are missing in such an emergency, this is not just bad luck but a result of insufficient organization, governance, and oversight. AWS helps to prevent such situations by providing Frameworks for AWS Backups. They define the expected state (or configurations) for backups helping to identify a gap between how the world should be and how it is. It is a pretty exhaustive list, as Figure 3 illustrates.

Figure 7: Configuration options for AWS Backup Frameworks in the AWS Portal

On-Demand Backups

On-demand backups are easy to configure and start in AWS: Choose the resource type and a concrete instance, make sure that the retention period is set correctly (remember: too many unnecessary backups require a lot of storage), and maybe define the vault to be used for storing the backup, and you are done (Figure 8).

The most notable aspect – besides that there is a single GUI for creating on-demand backups for all relevant services – is that one can back up just one instance of one resource. Sufficient for small applications, but for anything slightly complex, the tag-based definition of what is part of a backup (as known from the periodic backups) is much more efficient.

Figure 8: On-demand Backups in AWS Backup

Additional Backup Services in AWS

AWS unites backup features for all resource types in the single AWS Backup GUI. Still, there are other options to make backups. Amazon Data Lifecycle Manager can back up EBS Volumes. The EFS-to-EFS backup solution is an option for file systems. And, S3 has a versioning feature allowing to restore previous versions of the object; it even has to be activated for backups. However, from a governance perspective, having all backups in one place – AWS Backup or a 3rd party solution – eases the governance. And do not forget: AWS Backup comes with this clever and easy-to-use feature for governance, AWS Backup Frameworks. Use it!

Protecting AWS PaaS Workloads with VPC Endpoints

Routing network traffic between data centers over the internet? Web services within a data center interacting with traffic passing through the public internet – just to save a couple of hours or days of work? Both have been frowned upon for years, but such shortcuts are the new normal in the cloud world. So, are VPC Endpoints in AWS a solution?

Understanding the Use Case

In the following, we look at a solution relying on AWS S3, Lambda, and Dynamo DB services. The architecture in Figure 1 consists of an application running on an EC2 instance (i.e., a VM) alpha5 in subnet SN714. It accesses a lambda function lf6c, an S3 object storage s3delta and an AWS Dynamo database dy_epsilon (Figure 1). By default, lf_gamma, s3delta , and dy_epsilon are reachable publicly web services. As such, they are accessible from the internet. Traffic to and from them leaves the subnet and VPC and goes via the public internet to the AWS service endpoints / URLs for the S3 and Lambda services. To end this, VPC Endpoints in AWS are an option to keep this network traffic private. It is a scenario in which the EC2 instance acts as a service customer, whereas AWS acts as a service provider.

Figure 1: The network connectivity challenge for IaaS workload accessing AWS cloud services

VPC Endpoints and Interfaces

VPC Endpoints come in different flavors. We look first at how they allow integration of AWS services, thereby avoiding traffic via the internet (Figure 2, A). For such scenarios, AWS offers two VPC Endpoint variants: gateway endpoints and interface endpoints (Figure 2, B).  

Figure 2: Creating a Gateway Endpoint in AWS for AWS Services

Gateway endpoints and interface endpoints achieve their aims differently:

  • An interface endpoint means the AWS service gets a local IP address within the subnet. So, it looks (and can be reached, e.g., by EC2 instances) as any EC2 instance in this subnet.
  • A gateway endpoint allows routing traffic within the AWS network from the subnet to the AWS endpoint with the help of a routing table.

Figure 2 illustrates the creation of a gateway endpoint (B), which requires selecting the VPC into which the gateway should be deployed (C) and the routing table (D), which ensures that the relevant traffic goes to the S3 endpoint just created. Usually, engineers do not have to worry about which option to choose because not many AWS services support gateway endpoints; most have (only) interface endpoints. The following Table 1 provides an overview.

ServiceInterface EndpointGateway Endpoint
Dynamo DBNot availableAvailable
LambdaAvailableNot available
CassandraAvailableNot available
Sage Maker StudioAvailableNot available
RedshiftAvailableNot available
Table 1: Endpoint Options for Selected AWS Services

By default, a VPC Endpoint allows traffic from everyone within the VPC to the resource. So, every user and application with access to the VPC can reach the VPC Endpoint (and the resource behind the VPC Endpoint) on the network layer. The access rights in the IAM solution can still prevent reading or writing the data. However, it is usually better to rely not only on one security mechanism – IAM – but on two, IAM and network security – and VPC Endpoints can be a solution for the latter.

The other way around …

We have now looked at how to access AWS services from your VPC securely. The scenario: an application on an EC2 instance that accesses AWS services such as Dynamo DB or Lambda Functions. But what about a scenario where an AWS Lambda function orchestrates a couple of legacy (micro-)services of applications running on EC2 instances? How can the AWS Lambda function invoke them without going through the internet and making the EC2 instance accessible from the internet

Specifically for Lambda Functions, AWS provides a solution. Engineers can “connect” AWS Lambda Functions with VPCs. Then, the Lambda Function accesses resources exactly like an EC2 instance in the VPC.

Figure 3: Creating an AWS Lambda Function accessing VPC resources privately

Without going into details, this aspect illustrates the importance of understanding the different scenarios of how applications and AWS services interact to implement a security posture – especially since not every AWS service might have such an elegant solution. The challenge grows further if you not only combine IaaS-workloads on EC2 with PaaS features like Dynamo DB and Lambda Function but if you also consider Web Services from external partners, customers, or suppliers.

AWS’s Ecosystem Spirit

The most frustrating experience when integrating software-as-a-service solutions into your company application landscape is how negligent software vendors are when it comes to securing the integration of their solution into company ecosystems. Thus, I was surprised when I looked at AWS’s VPC Endpoint concept. I was fascinated by two aspects:

  • VPC Endpoints work not only for AWS-provided cloud-native services. You can also connect to VPC Endpoints of AWS Marketplace vendors – or any other AWS tenant. That helps integrate services hosted by vendors on the AWS cloud (Figure 4, left).
  • Suppose you are a service provider. Your customers might expect from you the same level of security as AWS’s service. The good news is that everybody on AWS can provide VPC Endpoints. So, suppose you are a service provider. You can provide your services precisely with the same security mechanisms as AWS (Figure 4, right).
Figure 4: Endpoint- and Endpoint Service-related Creation

Do VPC Endpoints make a Difference?

VPC endpoints are like seat belts – if you use them, they reduce your risks. External attackers have a much smaller attack surface if you shield your interfaces, data, and service instances from the internet. No traffic via the internet makes interference with your traffic impossible. Suppose every (micro-)service and every S3 instance has internet connectivity because all invocations from your EC2 instances go via the internet. In such a case, every single IAM misconfiguration can cause a disaster. So, VPC Endpoints are a great innovation, such as seat belts. However, they are not the complete solution, especially since PaaS services are shaking corporate IT departments. Cloud-native PaaS services such as database-as-a-service (e.g., Dynamo DB) or middleware-as-a-services (e.g., AWS EventBrdige) change how IT organizations develop and operate applications. Database and middleware teams shrink or even disappear. The reason: application teams can use Dynamo DB or EventBridge without company-internal support. You click a button and get an instance – and always patched. Suddenly, hundreds of engineers create database instances, not frequently but maybe every quarter or so. Ensuring all configurations are correct becomes a nightmare. In this sense, VPC Endpoints can prevent exposing databases to the internet. However, they do not make detective and preventive controls obsolete. The challenge is the consistent, 100% correct usage and configuration of AWS components and VPC Endpoints by potentially hundreds of engineers in an IT department. The rule for such scenarios is sim

Book Summary – Ben Buchanan: The Hacker and the State

Over the holiday, I took my time to read this book about state-sponsored attacks. Quite interesting if you want to model potential attacks on your company and organization. My summary in three parts distilled my learnings from reading the book.

Part 1: Espionage

Part 2: Attack

Part 3: Destabilization