Beyond the broad strategy to move to cloud enterprise customers will need to establish fundamental
cloud infrastructure patterns that will be used to house our applications on AWS. The most significant challenge is lack of
experience and lack of cloud patterns. The following patterns need to be
established:
- Compute
- Storage
- Networking
- Security
- Firewalls
- Authentication and Identity
- Monitoring
- Logging
- Backup
- DR
- Automation
- CI/CD Pipeline
- Migration of applications
To implement cloud we need the following
patterns:
1. Create AWS
Account design pattern
2. Create AWS
VPC design pattern
3. Provide AWS
estimated costs (+/- 30% accuracy) based on “like for like” infrastructure.
Require the following CMDB data for all
servers:
i)
Hostname
ii)
Operating
system type
iii)
Environment:
Prod/Dev/UAT/SIT/etc
iv)
vCPUs
v)
Memory
vi)
Storage
capacity and tier
vii)
Backup retention
4.
Create new
AWS accounts(s)
https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/
i) Create internal email address for each account
ii) Payment will be invoice/credit card
5.
Create AWS
Organisation
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_create.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html
-
Create new
accounts under master account
-
Create
Organisational Units, Service Control Policies
6.
Setup
consolidated billing:
7.
Create VPC,
subnets, routing tables, NAT gateway, VPC endpoints as per design
i)
Initially
manually - Ensure AZ ID is consistent across different accounts
ii)
Subsequently
using cloudformer,
update cloudformation, then test stack on different account
iii)
Test VPC
build with CLI
8.
Create
Transit Gateway to allow access to AWS:
i)
Create
transit gateway attachments
ii)
Update
routes
9.
Create VPN
from the CGW (Customer Gateway) to AWS VPW (Virtual Private Gateway) :
i)
Create CGW
ii)
Create VPG
iii)
Create new
VPN Connection
iv)
Configure
Palo Alto VPN Connection
v)
Check
Transit Gateway / VPC routing
10.
Configure
Okta for federated login to multiple AWS accounts via user groups:
11.
Create IAM
roles that federated users can assume via SAML 2.0/Okta:
i)
Create IAM
roles:
-
saml-Global-Admin
(same as root) – AdministratorAccess policy
-
saml-Admin
(can not modify VPC/IAM) – use template SystemAdministrator policy
-
saml-Developer
(can not modify VPC/IAM, only Sydney regions, only certain service)
- use
template PowerUserAccess policy
-
saml- ec2 -
AmazonEC2FullAccess policy
-
saml-Read-Only
– ReadOnlyAccess policy
ii)
Create
Windows AD user groups to map to roles
12.
Configure
Cloudtrail on all AWS accounts to send
data to AWS logging/monitoring account:
13.
Configure
AWS Guardduty threat protection to review/alert on log data
14.
Review and
create pattern for AWS security tool patterns including:
i)
AWS
Inspector (recommended)
ii)
Open source
scout2 (recommended)
iii)
Open source
prowler (recommended)
iv)
AWS
Security Hub
v)
Qualys
vi)
CloudSpoilt
vii)
RedLock
viii)
Alert Logic
15.
Review and
create pattern for securing externally facing web sites:
i)
Akamai Site
Shield (recommended)
ii)
Squid
reverse proxy
iii)
NginX
revserve proxy
iv)
AWS WAF
v)
WAF
sandwich
vi)
Akamai WAF
16.
Review and
create pattern for cloud backup
i)
Veeam Cloud
Protection Manager (recommended)
ii)
Cloud
snapshots based on our own code
iii)
Legacy
Backup product
17.
Review and
create pattern for data bunker
i)
Use another
AWS account in same region as data bunker (recommended)
ii)
Use another
AWS in another region as data bunker
iii)
No data
bunker
18.
Review and
create pattern for cloud based monitoring/alerting and logging:
i)
Cloudwatch
(recommended)
ii)
Slpunk
(recommended)
iii)
Sumo Logic
iv) OpsGenie
v) PagerDuty
19.
Review and
create pattern for cloud governance and cost optimisation:
i)
Cost
Explorer (recommended)
ii)
Cloudhealth
(recommended)
iii)
Cloud CMDB
based on our own code
20.
Create Base AMI SOE images including authentication,
monitoring, standard tools, security hardening
i) Linux
ii) Windows
21.
Review and
create pattern for VDI on AWS:
i)
Use AWS Workspaces
(recommended)
ii)
Use Citrix
22.
Create
tagging policy and process for business approved services. Recommendation:
-
Service
- Identify the service/product
-
Owner
- Owner email address
-
SupportTeam
- Group email address of team supporting the service
-
Environment
- Prod/Dev/SIT/UAT/PreProd/DR
-
CostSavings
- A tag dedicated to cost savings such as AWS Scheduler
-
Rightsize
– Automation to recommend appropriate instance type based on historical data
23.
Create
automation to enforce tagging policy and reduce cloud sprawl:
i)
List
Instances
ii)
Check tags
iii)
Terminate
non-conforming instances
24.
Create
automation to stop non-production instances nights/weekends:
i)
List
Instances
ii)
Check tag
CostSavings:
Example:
CostSavings:Sun:Mon 07.00 23:00:Tue 07.00
23.00:Wed 07.00 23.00:Thu 07.00 23.00:Fri 07.00 23.00:Sat:31.12.2100:JiraDev
iii)
Stop and change instance type/Start
instances based on CostSavings/Rightsize tag
25.
Create simple web app to start non-prod applications
that are in stopped state:
-
Login using
SSO via Okta
-
Dashboard
will show all non-prod applications and status (running/stopped)
-
Choose
non-prod application that you wish to start
-
Web app will:
- Start non-prod application instances (in defined
order)
- Log action
26.
Create
automation for daily clean up and security controls:
i)
Delete ELB
no traffic >=5 days
ii)
Delete
unattached EBS volumes >=5 days
iii)
Delete EC2
instances shutdown for >=5 days
iv)
EC2 Security
Groups with ‘unrestricted access’ (0.0.0.0/0) are detached/deleted
v)
EC2
Security Groups with ‘unrestricted ports’ detached/deleted - Snapshots >=90
days
vi)
Unassigned
Elastic IP Addresses >=5 days
vii)
Open S3
Buckets
- No public read access
- Tags required (and reported) for public write
viii)
Prevention
tag - If the resource has the tag of ‘preserve=true’ it will be ignored
27.
Review and
create pattern for access to cloud environment:
i)
All DCS
users access from internal legacy network (recommended)
ii)
All public
internet access internet facing cloud servers via Akamai Site Shield
(recommended)
iii)
Access
using Zero trust network like Akamai EAA
iv)
Administrator
access to cloud servers:
- From internal network only
- From AWS Workspaces (Cloud VDI)
28.
Review and
create pattern for DR of EC2 instances.
i)
Tier 1:
- Apps: High available application with Multi-AZ
design
- DB: Use RDS with Multi-AZ or EC2 database
instances with database replication
ii)
Tier 2:
- Apps: Automated recovery applications from EBS
snapshots
- DB: Automated recovery of database from EBS
snapshots
- DNS: Automated change
iii)
Tier 3:
- Apps: Manual recovery of applications from EBS
snapshots
- DB: Manual recovery of database from EBS snapshots
- DNS: Manual change
29.
Review and
create pattern for automated infrastructure build on AWS EC2:
i)
Cloudformation
(recommended)
ii)
Terraform
30.
Review and
create pattern for migration from on-premise infrastructure to AWS EC2:
i)
CloudEndure
multi-phase:
- Phase 1 - On migration account:
·
CloudEndure
migration from on-prem virtual/physical server to EC2
· Change DNS to new EC2 IP address
· No need to resolve firewall issues
·
Create AMI
and EBS snapshot and share with other account
- Phase 1 - On destination account:
·
Create EC2
instance from AMI/snapshots
·
Change DNS
to new EC2 IP address
·
Resolve
firewall issues
ii)
CloudEndure single-phase:
- CloudEndure migration from on-prem
virtual/physical server to EC2
- Change DNS to new EC2 IP address
- Resolve firewall issues
iii)
Rebuild:
- Use Windows/Linux SOE as base for application
- Customise operating system for applications
- Install application
- Change DNS to new EC2 IP address
- Resolve firewall issues
31. Review and create pattern for Build Pipeline (CI/CD):
i) Jenkins (recommended)
ii) AWS CodeCommit private git repo (recommended)
iii) AWS ECR container registry (recommended)
iv) Atlassian Bamboo
v) SOE Management - base for all CI/CD builds
vi) Cold deployment pattern - Bake instance, teardown and create new instance
vii) Hot deployment pattern - Update application on existing instances
viii) Blue-Green deployment pattern
32. Document all patterns
i) Atlassian Confluence Wiki (recommended)
ii) Sharepoint
No comments:
Post a Comment