AWS

01Ռեգիոններ, availability zone-ներ և ընդհանուր պատասխանատվություն

AWS-ը բաժանված է ռեգիոնների՝ առանձին աշխարհագրական տարածքների, օրինակ՝ Ֆրանկֆուրտ կամ Իռլանդիա, որոնցից յուրաքանչյուրն ունի ծառայությունների մեծ մասի իր պատճենը։ Ռեգիոնը պարունակում է մի քանի availability zone (AZ)՝ մեկ կամ ավելի դատա կենտրոններ անկախ սնուցմամբ, սառեցմամբ և ցանցով, բավական մոտ իրար՝ արագ կապի համար։ Հավելվածն առնվազն երկու AZ-ում աշխատեցնելը պաշտպանում է մեկ դատա կենտրոնի խափանումից, իսկ մի քանի ռեգիոն օգտագործելը՝ ամբողջ ռեգիոնի խափանումից, բայց շատ ավելի բարձր գնով ու բարդությամբ։ Ընտրիր օգտատերերին մոտ և տվյալների կանոններին համապատասխանող ռեգիոն։ Անվտանգությունը ընդհանուր է. AWS-ը պատասխանատու է cloud-ի անվտանգության համար (սարքավորումներ, դատա կենտրոններ, hypervisor), իսկ դու՝ cloud-ի ներսում անվտանգության համար՝ քո IAM թույլտվությունները, ցանցային կանոնները, EC2 սերվերների patch-երը, տվյալների գաղտնագրումն ու դրանք բաց չթողնելը։

• Ռեգիոն = աշխարհագրական տարածք, AZ = դրա ներսում մեկուսացված դատա կենտրոն(ներ)։
• Բարձր հասանելիություն = բաշխված առնվազն երկու AZ-ի վրա։
• Քո կողմից սխալ կոնֆիգուրացիան cloud-ում արտահոսքերի ամենատարածված պատճառն է։

02Հիմնական ծառայությունները և երբ օգտագործել դրանք

Հարյուրավոր ծառայություններ պետք չեն. մեկ տասնյակը ծածկում է վեբ հավելվածների մեծ մասը։ Compute-ը լինում է երեք տեսակի՝ EC2 վիրտուալ մեքենաներ, որոնք ինքդ ես կառավարում, կոնտեյներներ ECS-ում (ավելի պարզ, AWS-ի սեփական) կամ EKS-ում (managed Kubernetes), ցանկության դեպքում՝ serverless Fargate-ով, և Lambda ֆունկցիաներ, որոնք աշխատում են իրադարձություններով՝ առանց սերվերների։ Տվյալները պահվում են S3-ում՝ ֆայլերի համար, և RDS-ում կամ Aurora-ում՝ կառավարվող ռելյացիոն բազաների համար։ CloudFront-ը առջևում կանգնած CDN-ն է, Route 53-ը՝ DNS և health check-ով routing։ VPC-ն քո մասնավոր ցանցն է, IAM-ը որոշում է, թե ով ինչ կարող է անել, իսկ SQS-ը կառավարվող հերթ է՝ աշխատանքը իրարից անջատելու համար։

• EC2՝ լիարժեք վերահսկողություն, երկար աշխատող սերվերներ, ցանկացած ծրագիր։
• ECS / EKS (+ Fargate)՝ կոնտեյներներ՝ առանց scheduler-ներն ինքդ կառավարելու։
• Lambda՝ կարճ, իրադարձություններով աշխատող խնդիրներ (մինչև 15 րոպե), վճար՝ ամեն կանչի համար։
• S3՝ object storage upload-ների, backup-ների, ստատիկ կայքերի համար. versioning և lifecycle կանոններ։
• RDS / Aurora՝ կառավարվող PostgreSQL կամ MySQL՝ backup-ներով, Multi-AZ failover-ով, replica-ներով։
• CloudFront + Route 53՝ CDN և DNS, SQS՝ հերթեր, VPC + IAM՝ ցանց և թույլտվություններ։

03Ցանց՝ VPC-ի խելամիտ կառուցվածք

VPC-ն (virtual private cloud) ռեգիոնի ներսում քո մեկուսացված ցանցն է։ Այն բաժանում ես subnet-ների, որոնցից յուրաքանչյուրը մեկ availability zone-ում է։ Public subnet-ներն ունեն route դեպի internet gateway և պարունակում են միայն այն, ինչը պարտադիր պետք է նայի ինտերնետին, սովորաբար load balancer-ը։ Private subnet-ներում են հավելվածի սերվերներն ու բազաները. դրանց ինտերնետից ուղղակիորեն հասնել հնարավոր չէ։ Security group-երը stateful firewall-ներ են, որոնք կցվում են յուրաքանչյուր ռեսուրսի. load balancer-ն ընդունում է 443-ը ցանկացած տեղից, հավելվածը տրաֆիկ է ընդունում միայն load balancer-ի security group-ից, բազան՝ միայն հավելվածի security group-ից։ Private ռեսուրսները, որոնց պետք է ելք դեպի ինտերնետ՝ փաթեթների թարմացումների կամ արտաքին API-ների համար, օգտագործում են NAT gateway, որը հարմար է, բայց ծախսերի դասական անակնկալներից մեկն է, ուստի արժե ավելացնել VPC endpoint-ներ S3-ի և AWS-ի այլ ծառայությունների համար։

• Public subnet՝ միայն load balancer։
• Private subnet՝ հավելված և բազա, որոնց հասնում են security group-ի հղումներով։
• Քո շերտերի միջև հղվիր security group-երին, ոչ թե IP միջակայքերին։

04IAM և least privilege

IAM-ը (Identity and Access Management) որոշում է, թե ով որ AWS API-ն կարող է կանչել որ ռեսուրսի վրա։ Least privilege սկզբունքը նշանակում է, որ յուրաքանչյուր identity ստանում է միայն այն թույլտվությունները, որոնք պետք են իր գործի համար։ Root հաշիվը պաշտպանիր MFA-ով և երբեք մի օգտագործիր ամենօրյա աշխատանքում։ Մարդիկ պետք է մտնեն IAM Identity Center-ով՝ ժամանակավոր credentials-ով, ոչ թե երկարակյաց access key-երով։ Հավելվածները պետք է օգտագործեն role-եր. EC2 instance profile-ը, ECS task role-ը կամ Lambda execution role-ը կոդին ավտոմատ տալիս են կարճաժամկետ credentials, ու ոչ մի key չի մնում .env ֆայլերում։ Գրիր նեղ policy-ներ, ինչպես օրինակում, որը հավելվածին թույլ է տալիս կարդալ ու գրել միայն մեկ bucket-ի մեկ prefix-ում։ Օգտագործիր IAM Access Analyzer՝ չօգտագործվող կամ չափազանց լայն թույլտվությունները գտնելու համար, և միացրու CloudTrail-ը՝ յուրաքանչյուր API կանչ գրանցելու համար։

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": ["s3:GetObject", "s3:PutObject"],
7      "Resource": "arn:aws:s3:::example-app-uploads/uploads/*"
8    }
9  ]
10}

05Ծախսերի թակարդներ և ինչպես խուսափել դրանցից

AWS-ի հաշիվները հազվադեպ են մեծանում մեկ մեծ սերվերի պատճառով. դրանք աճում են մանր բաներից, որոնց ոչ ոք չի հետևում։ NAT gateway-ները գանձում են ամեն ժամի և մշակված ամեն գիգաբայթի համար։ Դեպի ինտերնետ և availability zone-ների միջև data transfer-ը աննկատ կուտակվում է։ Յուրաքանչյուր public IPv4 հասցե վճարովի է ժամավճարով։ Չկցված EBS volume-ները, հին snapshot-ները, պարապ load balancer-ները և մոռացված թեստային միջավայրերը շարունակում են գումար «ուտել»։ CloudWatch-ում լոգերի ընդունումը կարող է ավելի թանկ արժենալ, քան այդ լոգերը գրող սերվերները։ RDS Multi-AZ-ը մոտավորապես կրկնապատկում է բազայի արժեքը. դա հաճախ ճիշտ է, բայց պետք է գիտակցված ընտրություն լինի։ Պաշտպանվիր առաջին օրվանից՝ դրիր AWS Budgets ծանուցումներ, յուրաքանչյուր ռեսուրսի tag տուր նախագծով ու միջավայրով, ամսական նայիր Cost Explorer-ը, սահմանիր լոգերի պահպանման ժամկետ և կայուն բեռների համար օգտագործիր Savings Plans կամ reserved capacity։

1aws budgets create-budget --account-id 111122223333 \
2  --budget '{"BudgetName":"monthly","BudgetLimit":{"Amount":"200","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
3  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"[email protected]"}]}]'

06AWS, թե՞ VPS

DigitalOcean-ի, Hetzner-ի կամ նմանատիպ մատակարարի VPS-ը տալիս է ֆիքսված ամսական գին, առատ ներառված bandwidth և մեկ պարզ կառավարման վահանակ։ Մեկ հավելվածի համար լավ կազմակերպված VPS-ը Docker Compose-ով, off-site backup-ներով և մոնիթորինգով հաճախ մի քանի անգամ ավելի էժան է, քան համարժեքը AWS-ում, և փոքր թիմի համար ավելի հեշտ է հասկանալի։ AWS-ը հաղթում է, երբ քեզ պետք է այն, ինչ ինքդ կառուցելը դժվար է՝ ավտոմատ failover-ով և point-in-time recovery-ով կառավարվող բազաներ, autoscaling կտրուկ փոփոխվող տրաֆիկի համար, բազմաթիվ ռեգիոններ, compliance սերտիֆիկացիաներ, որոնք պահանջում են enterprise հաճախորդները, կամ խորը ինտեգրացիա AWS-ի այլ ծառայությունների հետ։ Տարածված միջին ճանապարհը VPS-ն է compute-ի համար՝ գումարած մի քանի նպատակային managed ծառայություն, օրինակ՝ S3-համատեղելի պահոց upload-ների համար և CDN։ Որոշիր պահանջներով ու թիմի հմտություններով, ոչ թե մոդայով։

07Ինչպես է IAM-ը որոշում՝ թույլատրել, թե մերժել

AWS API-ի յուրաքանչյուր կանչ ստուգվում է իրեն վերաբերող բոլոր policy-ներով, և տրամաբանությունը խիստ է։ Ամեն ինչ սկսվում է անուղղակի մերժումից (implicit deny)։ Ցանկացած կիրառելի policy-ում բացահայտ Deny-ը միշտ հաղթում է։ Մեկ հաշվի ներսում հարցումը թույլատրվում է միայն այն դեպքում, երբ որևէ identity-based կամ resource-based policy թույլ է տալիս այն, և ոչինչ չի մերժում։ Դրանից վերև կան սահմանափակիչներ, որոնք կարող են միայն իրավունքներ վերցնել, երբեք չեն տալիս․ AWS Organizations-ի service control policy-ները, role-ի permission boundary-ները և session policy-ները նույնպես պետք է թույլ տան գործողությունը։ Condition-ները policy-ները դարձնում են ճշգրիտ․ սահմանափակել ըստ աղբյուր VPC endpoint-ի, պահանջել գաղտնագրում փոխանցման ժամանակ, պահանջել MFA կամ թույլ տալ միայն մեկ նախագծի tag ունեցող ռեսուրսները։ Երբ մուտքը ձախողվում է, սխալի հաղորդագրությունը և CloudTrail-ը սովորաբար ասում են, թե policy-ի որ տեսակն է մերժել, իսկ IAM policy simulator-ը կարող է վերարտադրել որոշումը։

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "DenyInsecureTransport",
6      "Effect": "Deny",
7      "Principal": "*",
8      "Action": "s3:*",
9      "Resource": ["arn:aws:s3:::example-app-uploads", "arn:aws:s3:::example-app-uploads/*"],
10      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
11    }
12  ]
13}

08Բազմահաշվային կառուցվածք AWS Organizations-ով

AWS հաշիվը (account) մեկուսացման ամենաուժեղ սահմանն է, որ առաջարկում է AWS-ը․ առանձին իրավունքներ, առանձին quota-ներ և հաշվում առանձին տող։ Այդ պատճառով հասուն համակարգերը օգտագործում են բազմաթիվ հաշիվներ՝ կառավարվող AWS Organizations-ով, այլ ոչ թե մեկ հաշիվ ամեն ինչի համար։ Տիպիկ կառուցվածքում կա management հաշիվ՝ միայն billing-ի և կազմակերպության կարգավորումների համար, log archive հաշիվ, որն ստանում է CloudTrail-ի և config-ի log-երը մնացած բոլոր հաշիվներից, և որը հավելվածների թիմերը չեն կարող փոփոխել, security հաշիվ՝ աուդիտի գործիքների համար, և առանձին workload հաշիվներ production-ի, staging-ի և sandbox-ների համար։ Կազմակերպության մակարդակի service control policy-ները պարտադրում են կանոններ, որոնք հաշվի ներսում ոչ ոք չի կարող շրջանցել, օրինակ՝ արգելել կազմակերպությունից դուրս գալը, արգելել CloudTrail-ի անջատումը կամ արգելել ցանկացած ռեգիոն, բացի օգտագործվողներից։ Մարդիկ մեկ անգամ մուտք են գործում IAM Identity Center-ով և անցնում են յուրաքանչյուր հաշվի role-երին։ AWS Control Tower-ը կարող է այս landing zone-ը կարգավորել խելամիտ լռելյայն արժեքներով։

• Վնասի շառավիղ․ staging-ի արտահոսած credential-ը չի կարող դիպչել production-ին։
• Quota-ներն ու ծախսերը բաժանված են ըստ հաշվի և ըստ թիմի։
• SCP-ները սահմանափակիչներ են․ դրանք նեղացնում են իրավունքները, բայց երբեք չեն տալիս։

09EC2-ին ճիշտ մուտք․ IMDSv2 և Session Manager

Յուրաքանչյուր EC2 instance կարող է կարդալ իր metadata-ն, ներառյալ իր instance role-ի ժամանակավոր credential-ները, լոկալ 169.254.169.254 հասցեից։ Սկզբնական IMDSv1-ում աշխատում էր ցանկացած պարզ GET հարցում, ուստի հավելվածում server-side request forgery (SSRF) սխալը, որը ստիպում է սերվերին բեռնել հարձակվողի տված URL-ը, կարող էր արտահոսել այդ credential-ները։ Հենց այդպես են տեղի ունեցել մի քանի հայտնի արտահոսքեր։ IMDSv2-ը պահանջում է PUT հարցումով ստացված session token և hop-երի սահմանափակում, ինչը փակում է SSRF-ի ուղիների մեծ մասը․ պարտադրիր այն յուրաքանչյուր instance-ի վրա, իսկ նոր instance տեսակներն ու AMI-ները գնալով ավելի հաճախ այն միացված են ունենում լռելյայն։ Shell մուտքի համար AWS Systems Manager Session Manager-ը session է բացում SSM agent-ի միջոցով՝ IAM-ով նույնականացված և CloudTrail-ում գրանցված, առանց մուտքային 22 port-ի, առանց bastion host-ի և առանց ռոտացիա պահանջող SSH key-երի։ Դրանով port forwarding անելով կարելի է debug-ի համար հասնել նաև մասնավոր բազաներին։

1# require IMDSv2 on an existing instance
2aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
3  --http-tokens required --http-endpoint enabled
4 
5# shell without SSH or open ports
6aws ssm start-session --target i-0123456789abcdef0
7 
8# tunnel to a private RDS instance through that host
9aws ssm start-session --target i-0123456789abcdef0 \
10  --document-name AWS-StartPortForwardingSessionToRemoteHost \
11  --parameters '{"host":["db.internal.example.com"],"portNumber":["5432"],"localPortNumber":["5432"]}'

10Ուր է գնում ցանցի գումարը, և ինչպես այն պահել

Ցանցն այն տեղն է, որտեղ AWS-ի հաշիվները մարդկանց ամենից հաճախ են զարմացնում, որովհետև տրաֆիկը գնահատվում է ըստ ուղու։ Ինտերնետից AWS մտնող տվյալներն անվճար են։ Դեպի ինտերնետ դուրս եկող տվյալները վճարովի են ըստ գիգաբայթի, ընդ որում CloudFront-ի սակագները սովորաբար ավելի ցածր են, քան EC2-ից կամ S3-ից ուղղակի մատուցելիս, և կա անվճար ամսական ծավալ, ուստի CDN-ը հաճախ խնայում է և՛ գումար, և՛ latency։ Availability zone-երի միջև տրաֆիկը վճարովի է երկու ուղղությամբ, ուստի տարբեր zone-երում գտնվող «շատախոս» service-ները կամ այլ zone-երում գտնվող replica-ները իրական արժեք ունեն։ NAT gateway-ը վճար է գանձում ըստ ժամի և ըստ մշակված գիգաբայթի՝ սովորական փոխանցման վրա ավելացած, ուստի NAT-ով մեծ image-ներ կամ backup-ներ քաշող մասնավոր սերվերները վճարում են երկու անգամ։ S3-ի և DynamoDB-ի gateway VPC endpoint-ներն անվճար են և այդ տրաֆիկը հանում են NAT-ի ուղուց․ այլ ծառայությունների interface endpoint-ները վճարովի են ըստ ժամի, բայց դեռ կարող են ավելի էժան լինել։ Յուրաքանչյուր հանրային IPv4 հասցե նույնպես վճարովի է ըստ ժամի։

• Մասնավոր subnet-ներ ունեցող յուրաքանչյուր VPC-ում ավելացրու անվճար S3 gateway endpoint-ը։
• Հանրային asset-ները մատուցիր CloudFront-ով, ոչ թե ուղիղ S3-ից կամ EC2-ից։
• NAT-ի և փոխանցման ծախսերը գտնելու համար օգտագործիր Cost Explorer-ը՝ խմբավորած ըստ usage type-ի։