SSL certificates? But we don't use SSL anymore?

How do you feel about the term "SSL certificate"?

It's kind of an interesting artifact.  Marketing over the decades has burned the term "SSL certificate" into our IT vocabulary.  But no one should be using SSL right now to secure their website.

It's interesting how this is showing up in the various documentation around the cloud.  In AWS the ACM docs say "SSL/TLS certificates".  Google is trying to just use HTTPS but it looks like they still have it hanging out in their cloud API.  But of course, all of the certificate authorities are still selling "SSL certificates".

Google trends probably explains why, people are still searching for ssl certificates.




But maybe SSLv4 will come out someday and set the world right again.  ;)

HA != DR

HA = High Availability.
  The ability for your application (or infrastructure) to survive the failure of one or more components and continue to operate.

DR = Disaster Recovery
  The ability to recover from a failed state.

I was recently in a discussion where the idea came up that if you have HA in the cloud you don't need DR.  I used this opportunity to remind everyone that even in this new world of on-demand, scalable, redundant infrastructure the age old mantra of "always have a backup" still holds true.

The discussion centered around AWS and if you have redundant services running your application, spread across multiple regions, the catastrophic loss of an entire region wouldn't affect the running application.

The above statement is true, to be highly available your application should be multi-component, multi-availability zone, multi-region, multi-provider even.  But the question brought the discussion to an interesting place.  If you have that level of HA, why would you need DR?

A few years back a company learned that lesson the hard way.  In 2014 a hosted source code repository company called CodeSpaces, billed as "full redundancy", had all of their data permanently deleted by a hacker and went out of business.  How?  The hacker got login to their root console and pressed the delete button.  Not to diminish the need for proper security and the need to protect your root account, it was not having a Disaster Recovery plan which was the fatal mistake.

If after reading about that hard lesson learned and still not convinced that something like that could happen to your product because of all of the redundancy and resiliency which is built into your system, you should think of DR as an insurance policy.  You have it on your house, your car, your life?  Why not put an insurance policy on your job?  Accidents do happen.

AWS Well-Architected Framework Product Review Document Template

The AWS Well-Architected Framework is a set of guidelines developed by Amazon Web Services to help customers follow best practices in developing cloud based architectures utilizing Amazon Web Services.

The AWS Well-Architected Framework guidelines can be used to help make sure that your cloud application architecture is built on a standard set of principles.  The Well Architected Framework is based off the following five principles, Security, Reliability, Performance Efficiency, Cost Optimization, and Operational Excellence.

The process of building a Well-Architected Product is an iterative one and the recommendations that your teams put into this document are not intended to be the end all list of what makes a Well-Architected Product.  A document such as this is just one part of the process and through iteration and re-evaluation your products will be well architected.

This document template outlines each pillar of the AWS Well Architected Framework and lets your teams and subject matter experts fill in the information on how these AWS best practices have been applied to your product.

By filling out each section and making a list of what has been implemented and what your teams recommend to meet the design principles of each pillar, your teams will be able to effectively answer the questions presented at the end of the document.  This will prepare your organization to have the AWS team stop by to review your product and gain all of the benefits of having a Well-Architected Product.

The document hosted on google docs

Amazon Web Services Well-Architected Review 2017 Questions quick-list.

  When preparing for an Amazon Web Services Well-Architected Review, have answers to the following questions.  The details and links to all of the AWS Well-Architected documents can be found on the AWS site Here.

Security

SEC 1. How are you protecting access to and use of the AWS root account credentials?

SEC 2. How are you defining roles and responsibilities of system users to control human access to the AWS Management Console and API?

SEC 3. How are you limiting automated access to AWS resources? (e.g., applications, scripts, and/or third-party tools or services)

SEC 4. How are you capturing and analyzing logs?

SEC 5. How are you enforcing network and host-level boundary protection?

SEC 6. How are you leveraging AWS service level security features?

SEC 7. How are you protecting the integrity of the operating systems on your Amazon EC2 instances?

SEC 8. How are you classifying your data?

SEC 9. How are you encrypting and protecting your data at rest?

SEC 10. How are you managing keys?

SEC 11. How are you encrypting and protecting your data in transit?

SEC 12. How do you ensure you have the appropriate incident response?

Reliability

REL 1. How do you manage AWS service limits for your accounts?

REL 2. How are you planning your network topology on AWS?

REL 3. How does your system adapt to changes in demand?

REL 4. How are you monitoring AWS resources?

REL 5. How are you executing change?

REL 6. How are you backing up your data?

REL 7. How does your system withstand component failures?

REL 8. How are you testing for resiliency?

REL 9. How are you planning for disaster recovery?

Performance

PERF 1. How do you select the best performing architecture?

PERF 2. How do you select your compute solution?

PERF 3. How do you select your storage solution?

PERF 4. How do you select your database solution?

PERF 5. How do you select your network solution?

PERF 6. How do you ensure that you continue to have the most appropriate resource type as new resource types and features are introduced?

PERF 7. How do you monitor your resources post-launch to ensure they are performing as expected?

PERF 8. How do you use tradeoffs to improve performance?

Cost Efficiency

COST 1. Are you considering cost when you select AWS services for your solution?

COST 2. Have you sized your resources to meet your cost targets?

COST 3. Have you selected the appropriate pricing model to meet your cost targets?

COST 4. How do you make sure your capacity matches but does not substantially exceed what you need?

COST 5. Did you consider data-transfer charges when designing your architecture?

COST 6. How are you monitoring usage and spending?

COST 7. Do you decommission resources that you no longer need or stop resources that are temporarily not needed?

COST 8. What access controls and procedures do you have in place to govern AWS usage?

COST 9. How do you manage and/or consider the adoption of new services?

Operational Excellence

OPS 1. What best practices for cloud operations are you using?

OPS 2. How are you doing configuration management for your workload?

OPS 3. How are you evolving your workload while minimizing the impact of change?

OPS 4. How do you monitor your workload to ensure it is operating as expected?

OPS 5. How do you respond to unplanned operational events?

OPS 6. How is escalation managed when responding to unplanned operational events?