Merge pull request #69 from kamranahmedse/master

Create a new pull request by comparing changes across two branches

Author: GulajavaMinistudio

public/best-practices/aws.png

@@ -62,6 +62,7 @@ We have also added a new form of visual content covering best practices:
 
 - [Frontend Performance Best Practices](https://roadmap.sh/best-practices/frontend-performance)
 - [API Security Best Practices](https://roadmap.sh/best-practices/api-security)
+- [AWS Best Practices](https://roadmap.sh/best-practices/aws)
 
 ![](https://i.imgur.com/waxVImv.png)
 

public/jsons/best-practices/aws.json

@@ -19,7 +19,7 @@ if (faqs.length === 0) {
 }
 ---
 
-<div class='border-t bg-gray-100'>
+<div class='border-t bg-gray-100 mt-8'>
   <div class='container'>
     <div class='flex justify-between relative -top-5'>
       <h1 class='text-sm sm:text-base font-medium py-1 px-3 border bg-white rounded-md'>Frequently Asked Questions</h1>

public/pdfs/best-practices/aws.pdf

@@ -0,0 +1,28 @@
+---
+jsonUrl: '/jsons/best-practices/aws.json'
+pdfUrl: '/pdfs/best-practices/aws.pdf'
+order: 3
+briefTitle: 'AWS'
+briefDescription: 'AWS Best Practices'
+isNew: true
+isUpcoming: false
+title: 'AWS Best Practices'
+description: 'Detailed list of best practices for Amazon Web Services (AWS)'
+dimensions:
+  width: 968
+  height: 1770.7
+schema:
+  headline: 'AWS Best Practices'
+  description: 'Detailed list of best practices for Amazon Web Services (AWS). Each best practice carries further details and how to implement that best practice.'
+  imageUrl: 'https://roadmap.sh/best-practices/aws.png'
+  datePublished: '2023-02-21'
+  dateModified: '2023-02-21'
+seo:
+  title: 'AWS Best Practices'
+  description: 'Detailed list of best practices for Amazon Web Services (AWS). Each best practice carries further details and how to implement that best practice.'
+  keywords:
+    - 'Amazon Web Services Tips'
+    - 'AWS Tips'
+    - 'AWS Best Practices'
+    - 'Amazon Web Services Best Practices'
+---

readme.md

@@ -0,0 +1,5 @@
+# Alerts as Notifications
+
+> Get your alerts to become notifications.
+
+If you've set everyting up correctly, your health checks should automatically destroy bad instances and spawn new ones. There's usually no action to take when getting a CloudWatch alert, as everything should be automated. If you're getting alerts where manual intervention is required, do a post-mortem and figure out if there's a way you can automate the action in future. The last time I had an actionable alert from CloudWatch was about a year ago, and it's extremely awesome not to be woken up at 4am for ops alerts any more.

src/components/FAQs/FAQs.astro

@@ -0,0 +1,3 @@
+# App Changes for AWS
+
+While a lot of applications can probably just be deployed to an EC2 instance and work well, if you're coming from a physical environment, you may need to re-architect your application in order to accomodate changes. Don't just think you can copy the files over and be done with it.

src/data/best-practices/aws/aws.md

@@ -0,0 +1,9 @@
+# Application State
+
+> Do not store application state on servers.
+
+The reason for this is so that if you server gets killed, you won't lose any application state. To that end, sessions should be stored in a database (or some other sort of central storage; memcached, redis, etc.), not on the local filesystem. Examples:
+
+- Logs should be handled via syslog (or similar) and sent to a remote store.
+- Uploads should go direct to S3 (don't store on local filesystem and have another process move to S3 for example). For S3 you can use [pre-signed URLs](http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html) to let your users directly upload to S3 by bypassing your server entirely.
+- Any post-processing or long running tasks should be done via an asynchronous queue (SQS is great for this).

src/data/best-practices/aws/content/alerts-as-notifications.md

@@ -0,0 +1,3 @@
+# Automate Everything
+
+This is more of general operations advice than AWS specific, but everything needs to be automated. Recovery, deployment, failover, etc. Package and OS updates should be managed by something, whether it's just a bash script, or Chef/Puppet, etc. You shouldn't have to care about this stuff. As mentioned in a different tip, you should also make sure to disable SSH access, as this will pretty quickly highlight any part of your process that isn't automated. Remember the key phrase from the earlier tip, if you have to SSH into your servers, then your automation has failed.