AWS Best Practices Version 2
Download as PPTX, PDF2 likes1,889 views
The document outlines best practices for resource tagging and naming conventions in AWS, emphasizing the importance of tagging for deployment, automation, and cost management. It provides detailed naming conventions for different resource types such as EC2, VPC, S3, and Security Groups, along with security practices like enabling MFA and restricting console access. Furthermore, it discusses infrastructure management strategies including automation, centralized jobs, pipelined tasks, and containerized deployments.
AWS Best Practices Version 2
- 1. AWS Primer on Best Practices and Resource Tagging Convention Kenichi Shibata
- 2. Why do we need naming convention? • Tagging for Deployment • Tagging based on application usage • Tagging based on ownership • Tagging for cost structure (can check cost breakdown based on tags) • Have to enable cost breakdown on the aws billing (usecase: for individual clients) • Tagging for Automation • All resources will be tagged and then can filtered or queried via tags • Tagging as context helpers • Not all resources are tagged appropriately by AWS and it could be confusing for understanding what a specific resource does
- 3. Naming Best Practices • Before we begin we have understand some key points in order to better maintain the infrastructure in the cloud 1. Build infrastructure to scale • This means that the infrastructure you handle right now will need to passed over very quickly to a new engineer for a minimal training with only documentation and the context. • Contexts should be provided with each resources to be able to identify how the resource fit in; 2. Automate all/most infrastructure tasks • Use Automation tools like cloudformation, boto3 or terraform for provisioning • If tasks is repeated at least thrice we should automate it. • Orchestration should be done automatically using config/template management like packer, ansible. • Use Infrastructure-As-A-Code whenever you run a new cluster • Tags should be automated
- 4. Deployment Best Practices 3. Centralized jobs • All cron jobs should be observable and should be visible to all devOps team. A local cron job for a specific server is discouraged. • Centralized jobs can help manage the workload among the Ops team and create a sense of teamwork when rotating tasks, It helps gain visibility ensures quick and efficient action when something unexpected occurs 4. Pipelined Tasks • Tasks like continuous integration and deployment should be pipelined in order to find out at which stage the task failed, • Infrastructure As A Code should be the norm when deploying new infrastructure. These tasks deployment should be pipelined within the centralized observable pipeline 5. Containerized/AMI Deployments • Blue Green Deployment should be done to each servers in order to test the code in a production like setting • Deployments to each new Instance should be done by using a snapshot of a proven instance running an application that starts on bootup • Running Clusters of Containers is Recommended however please keep in mind the overhead of running containers
- 5. Security Best Practices 6. Use MFA for all Users and set harder restrictions on password • Every engineer who has access to the AWS Console should have MFA enabled • The passwords policy can be configured from the IAM Console, The passwords should at least have one uppercase and one number. 7. Not Everyone should have access to the console • Developers who will only need a specific access can use the Command Line Interface with AWS AccessKey and SecretKey instead, • Use the principle of least privilege and only give access to specific resource, For example instead of giving write access to all s3 buckets, Only give list access and write access to a specific s3 bucket 8. Turn on CloudTrail • Get all the audit logs for each calls to the aws api using your account credentials
- 6. Resource Types • Currently this document covers the following resource types • EC2 • VPC • VPC Subnet • Sec Group • S3 • Routing Table
- 7. EC2 • Name – naming convention – {env/owner(count)-cluster-app} • e.g. mng01-infra-bastion, prd-web-abcd, acmecorp01-infra-yourapp1 • Environment – stg, dev, prd, mng • Cluster/Platform – Infra Management, ecommerce, crm,projectcode1 , (optional) • App – app1proxy, app1loadbalancer, app1api • Tier – Database, Web, API, App, Datastore, (for multi tiered architectures) • Subnet – {subnet-name} should be queried on terraform • Owner – {customer1} if owned by third party (optional) • Maintainer –email • Architecture- /Diagrams/file.uml, http://wiki (optional) • Count – 01, 02, 03 (for asg use e.g. prd01-web-app-asg) else use prd01-web-app
- 8. EC2 • Why is name prefixed on client instead of env when it is available? • We assume that the clients will always have production environment afforded to them if they will need to test or do acceptance test we can set it up on staging or development environments to share costs, using data encryption for the test data if need be. • e.g. mng01-infra-bastion, prd-web-abcd, acmecorp01-infra-yourapp1
- 9. VPC • Name – {platform}(count)-{tenancy}-vpc e.g. warehouse01-default-tokyo-vpc • Tenancy – Default/Dedicated • Count – 01, 02, 03 (You can also use names as instead of numbers) • Region – Use the common region name not the aws official name for brevity • Platform – Ecommerce, Warehouse management, CRM, projectcode1 • Most application platforms will be inside a single vpc so the name of the platform will suffice. However if we will need to scale to multiple regions, We will need to tag the Region as well to provide context where we would like to run this specific platform.
- 10. VPC Subnet • Name – {environment}-{availability}-{platform}-{accessibility}(count)-subnet • E.g. prd-pub-warehouse01-pmry-subnet, stg-pvt-ecommerce-sdry-subnet • Accessibility – Private, Public, Secured • Maintainer – email • Platform – Ecommerce, Warehouse management, CRM, projectcode1 • Cluster - DB, Web, API, App • Environment – prd, stg, dev, mng • Availability (Zone)– Primary(a), Secondary(c), Tertiary(b), • Some regions only has ‘a’ and ‘c’ zones
- 11. What is public/private/secured? • Public subnets are subnets which are directly connected to the internet using an internet gateway or a egress only internet gateway • There is a use case for a public -> nat -> public mapping of subnets if you want to whitelist all requests from a specific subnet • Public Subnets are best used for Internet facing Web Servers • They need a public ip address or elastic ip in order to connect • Usually the HTTPs termination is done on server running on public subnets • Private subnets are subnets which are connected to the internet using a NAT Gateway (network address translation) • The subnets are usually mapped using private -> nat -> public. However the limitation to these subnets are that they cannot serve traffic from Public DNS without port forwarding. • They are best suited for cache servers, database servers, middleware api, and secured transaction interfaces,
- 12. What is public/private/secured? • Secured Gateways • Secured Gateways are for directly connecting a specific IP Address to another IP Address. Without connecting to the rest of the internet, It is usually done by Network ACL. • A good alternative for Secured Gateways is AWS Direct Connect or AWS VPN Connection
- 13. NAT Gateways • The best practice in running NAT Gateway is using the AWS NAT Gateway it scales depending on traffic and is easier to setup than a manual EC2 NAT Gateway • however please be aware that since AWS NAT Gateway is a full managed service it is bound to limitations as well, Port forwarding for example is not supported as is sniffing logs from the gateway • To be able to get advanced functionality creating NAT Gateway from EC2 is needed however setting a single EC2 instance as a NAT Gateway is an anti- pattern since if the traffic grows enough then the NAT EC2 Instance will become a bottleneck • It is recommended to have a failover or a load balanced NAT Gateway if you are going to use EC2
- 14. S3 • Name – {company-name}-{environment}-{platform}-{application} • (S3 name is global and should be unique globally, so we add the company name or abbrev) • E.g. acme-prd-warehouse-stockinventory • Platform – Ecommerce, Warehouse management, CRM, projectcode1 • Application – Logs, Webapp, Webpage • Environment – prd, stg, dev, admin • File Naming – Inside the bucket please use random string to generate hashes if there are lots of files. AWS Stores files in different servers using file name hashes, it is faster to retrieve and store with more servers
- 15. Security Group • Name – {environment}-{accessibility}-{application/protocol}-{direction}-sg • E.g. prd-pvt-icmp-dx-sg, dev-pub-http-in-sg • Group Name – same as name (required by aws) • Protocol – ICMP, TCP, UDP • Accessibility – pub, pvt, sec • Direction – Inbound, Outbound, Duplex • Environment – Production, Staging, Development • Application – (if applicable) nginx, mongodb, ssh, • Description – Short description of why this security group is needed • Also Security Groups support per entry level descriptions
- 16. Routing Table • Name – {environment}-{availability}-{platform}-{accessibility}-rtb • E.g. prd-pub-warehouse01-pmry-rtb, stg-pvt-ecommerce-sdry-rtb • Accessibility – pub, pvt, sec • Platform – warehouse, ecommerce, publications, internal • Environment – Production, Staging, Development • Description – Short description of why this routing table is needed • Availability (Zone)– Primary(a), Secondary(c), Tertiary(b), • Some regions only has ‘a’ and ‘c’ zones