It goes without saying that the adoption of AWS – specifically for running production workloads – continues to build with unprecedented momentum. Some of you may refer to this acceleration as “cloud-first,” and you’re all likely somewhere along this journey, from the early stages of planning and experimenting, to deploying new apps or migrating your on-prem data centers. This all makes sense – the value of the cloud is clear. It can be relatively easy to make the cloud work for you, helping transform the business for the better, from decreased costs, higher availability, or global reach.
However, the cloud certainly doesn’t come without its fair share of challenges, and one of those challenges can be determining what is your responsibility and that of AWS. Although AWS can take care of the underlying infrastructure, among other things, it is YOUR responsibility to secure what’s in your cloud.
In this blog, we will discuss the user’s responsibility in the AWS cloud and the best practices of AWS Backup while keeping the shared responsibility model in mind.
The AWS 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 the 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.
As the customer, you will oversee protecting your own data in the AWS cloud. You will also be responsible for configuring things like Identity and Access Management, patching of your operating system, and more. The chart below highlights exactly what else you’re responsible for in the cloud. As for AWS, it is their responsibility to ensure that the underlying infrastructure for it’s service offerings are updated, available, and patched. AWS will also adhere to the environmental standards tied to running the physical datacenters.
Don’t forget that there are also shared responsibilities between the customer and AWS. As covered above, configuration and patch management are covered by both, but at different levels. This is also the case for awareness and training on tools – you must train your staff to work with AWS properly.
Impact of Service Types on Responsibility Model
For a deeper break down on who is responsible for what in the AWS cloud, please review the diagram below. You can see how much responsibility AWS gains as you move from an on-premises to SaaS. It is crucial to know what you are responsible for because it only takes one mistake for a bad actor to gain access to your environment.
Regardless of the degree of service you are consuming, one thing holds true; responsibility for your data is never transitioned to AWS. Ensuring that your data is secure, protected and always available is entirely up to you.
Resilience and Well-Architected Framework 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 often refers to its Well Architected Framework, which helps 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. Resiliency is made easy with backup, as you can immediately get your applications back up and running in the case of a bad actor getting through.
Key Considerations for AWS Backup and Recovery
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.
Multi-Account Protection
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. 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.
Cost Awareness
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, cross-region traffic, and ingress/egress charges, makes life a lot easier for your backup admin. 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 in providing the business the capabilities it needs.
Adaptability to Workload Changes
The final consideration for this blog involves one of the great benefits of AWS – its elasticity and flexibility. 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 in order to mitigate gaps in retention and the resulting data loss.
How Veeam Can Help
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 is here for you whether you have an AWS only environment or a hybrid/multi-cloud environment. We offer a simple, cost-effective and secure backup no matter where your workloads live.
With Veeam you will be able to manage all of your data protection – cloud, virtual and physical – from one unified console, with unlimited data portability and flexibility. To learn more, watch our demos of Veeam Backup for AWS. You can also get hands on with our Veeam Backup for AWS Free Edition here!
