It goes without saying that adoption of AWS – specifically for running production workloads – continues to build with unprecedented momentum. Some of you may refer to this acceleration within your organization as “cloud-first,” and you’re all likely somewhere along this journey. From the early stages of planning and experimenting, to deploying new apps and migrating your on-prem data centers as fast as humanly possible. And why not? It can be relatively easy to make the cloud work for you, helping transform the business for the better, from costs to competitive advantage and more.
However, cloud certainly doesn’t come without its fair share of challenges, and one of those challenges can be delineating where what was once our responsibility ends, and where the responsibilities of AWS start.
Shared Responsibility Model defines the distribution of security and compliance responsibilities between you, the customer and AWS. The basics can be broken down as:
- AWS is responsible for security of the cloud, i.e. the infrastructure that runs AWS Cloud services like hardware, software, networking, etc.
- The customer is responsible for security in the cloud, e.g. operating systems, applications, network configurations and data.
This diagram does a great job visually explaining this distribution in greater detail.
Not explained in this diagram – and certainly worth understanding – are how consumption of IaaS, PaaS and SaaS affect this dynamic (the diagram is based on IaaS). AWS will assume responsibility for items like operating systems and platforms in abstracted services like Amazon Relational Database Service (Amazon RDS) when compared with Amazon Elastic Compute Cloud (Amazon EC2) IaaS.
Regardless of the degree of service you are consuming, one thing holds true; responsibility for your data is never transitioned to AWS. Ensuring your data is secure, protected and always available is up to you.
Resilience in AWS
AWS defines resiliency as “the ability of a workload to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand and mitigate disruptions, such as misconfigurations or transient network issues.” In fact, AWS has a framework called the AWS Well-Architected Framework which is designed to help customers design and plan their AWS environments. There are five pillars that discuss different areas of planning. The reliability pillar has a few principles that are key:
- Test recovery procedures: you can use automation to simulate different failures or to recreate scenarios that led to failures before. This approach exposes failure pathways that you can test and fix before a real failure scenario occurs, thus reducing risk.
- Stop guessing capacity: in the cloud, you can monitor demand and workload utilization and automate the addition or removal of resources to maintain the optimal level to satisfy demand without over- or under-provisioning. There are still limits, but some quotas can be controlled, and others can be managed.
- Scale horizontally to workload availability: replace one large resource with multiple small resources to reduce the impact of a single failure on the overall workload.
- Manage change in automation: changes to your infrastructure should be made using automation.
When reviewing these principles, you can see that it is focused on the workloads and infrastructure themselves, but these principles are very much related to why you must have a good backup strategy.
Key AWS backup and recovery considerations
With any infrastructure design, regardless of location, protecting the workloads against data loss is critical. The considerations required to implement a backup solution, whether on-premises or in the cloud are very similar. Making sure that the backup solution understands and is aware of the environment the workloads are running is paramount.
If we think about a backup solution in general, it needs to be able to work within the capabilities of the service. One example of this is being able to protect workloads across multiple AWS accounts (see “scale horizontally” above). AWS leverages separate accounts as security boundaries as a best practice. Having the ability to protect and restore workloads across multiple accounts provides for a resilient and secure data protection solution.
Another key consideration in implementing a backup solution in the cloud is around cost. Cost is the critical piece in the puzzle when performing any task or operation in AWS. Making sure that the backup solution is fully aware of cost considerations like data storage charges (see “stop guessing capacity” above) as well as cross-region traffic, ingress and egress charges makes life a lot easier. Having built-in cost calculators to guide the backup administrator makes sure that costs are kept to a minimum but also that the solution implemented is successful to providing the business the capabilities it needs while minimizing costs.
The final consideration for this blog involves one of the great benefits of AWS – its elasticity and flexibility – resulting in workloads being instantiated and terminated constantly for greater cost efficiencies. Data protection in the cloud needs to be equally elastic and flexible, capable of automatically backing up workloads as they are created. Consider tagging workloads with data protection in mind and building backup policies with varying SLOs around these tags (see “manage change in automation” above) in order to mitigate gaps in retention and the resulting data loss.
Hopefully this blog post has made it apparent that backing up AWS is just as critical as it is for on-premises workloads and for the most part there are numerous similar best practices. If you’re looking for a solution that can help, Veeam has AWS-native backup and recovery available in a couple of different flavors, both equally easy, cost-effective and secure.
Existing Veeam Backup & Replication customers have this function built-in thanks to the latest release of v10A and the AWS plug-in for Veeam Backup & Replication. The best bit is you can manage all your data protection – cloud, virtual and physical – from one unified console, with unlimited data portability and the flexibility of Veeam Universal License. The files and some great walkthroughs are available for free here.
If you’re not a Veeam customer, you can still natively back up AWS with Veeam Backup for AWS. It’s the same technology for the most part (minus the data portability and VUL flexibility) available as a standalone solution. Check out our free version.
