POC for Ghost Environment

1. Technical Assessment

2. Contents
● About Me
● Infrastructure
● Disaster Recovery
● Application Deployment Pipeline
● Lambda Function
● Logging and Monitoring
● Conclusions
● Questions
● Thank You

3. About Me
● I have total 12+ years of professional experience out of 7 years in AWS Platform and 2 years in Azure
Platform.
● Core Skill Sets:
○ AWS Infrastructure Design, Hands-On Deployment and Automation
○ Terraform & CloudFormation (Based on Project Requirement)
○ CI/CD Tools like - Git, Teamcity, Octopus, Jenkins, AWS CodePipeline
○ AKAMAI CDN (Including KONA support)
○ Scripting
● Major Recent Projects:
○ Migration from ECS Cluster based solution to EKS Cluster - Currently working
○ EKS Migration from EC2 based solution to EKS Cluster for 300+ websites and subsites -
Completed
○ High traffic oriented website migration across AWS account - Completed

4. Technical Assessment Project Objectives
● The Ghost Environment deployment and Application deployment will be
automated
● The application should be scalable depending on the load
● There should not be any obvious security flaws
● Observability
● Feature of Lambda function that can delete all posts of Ghost blog using Admin
API

5. Infrastructure Deployment Modules/Environments
Environments
● Primary Region
● Secondary Region
Modules
● VPC/Network
○ VPC Flow Logs
● KMS (Customer Managed Key)
○ Cross Region Key Replication
● RDS (MySQL)
● EFS
● ECS
○ ECS Cluster
○ Container Definition
○ Task Definition
○ ECS Service
● AWS Backup
○ Cross Region Backup Replication
● Application Load Balancer
○ Target Group & Listener
● ACM
● AWS Secrets Manager
● CodeBuild
● CodePipeline
● SNS Topic
● Route 53
● Lambda
● S3

6. Key Points Considered at the Infrastructure Modules
● VPC: Network/VPC module has flexibility to choose number Availability Zone and Number of NAT Gateway will be deployed.
● KMS: Customer Managed Key has been used along with cross region replication.
● AWS Backup: AWS Backup solution has been used to backup RDS snapshot and EFS along with cross region replication as part of DR.
● ECS Cluster: ECS solution has been considered over EC2 based solution because Docker containers improve efficiency by providing a
lightweight, efficient isolation model. Unlike a heavier virtual machine, we can run many small docker containers on a single machine.
To minimize cost, EKS solution has not been considered since EKS control plane itself has a recurring cost.
○ ECS node based solution has been considered over Fargate solution to optimize cost by using Savings Plan, Reserved Instance
or Spot Instance
○ ECS node based solution also provide benefit to access container by logging in to the node. Node can be accessed over SSH
connection or simply using SSM agent.
● AWS Secrets Manager: AWS secrets manager has been used to store various secrets across services. It is not recommended to store
any password or secret in tfvars file or any other deployment file.
● Horizontal Autoscale: ECS Service and ECS Nodes are capable to autoscale horizontally on occasion of high traffic usage and scale up
upto desired number of tasks or nodes.
● Cloudwatch Logs/Monitoring: Most of the resources has integration with Cloudwatch Logs/Alarms, based on defined thresholds,
Cloudwatch is capable to trigger alarm and send notification to SNS subscriber.

7. Security Measures Considered
● Ensure traffic is served over HTTPs protocol including HTTP to HTTPs redirection.
● Ensure no secrets has been stored at Git files or state file (without encryption).
● Using basic security measures like hosting infrastructure at Private Subnet.
● Optional addition of AWS WAF
○ Web traffic filtering
■ Admin page protection
■ Drop invalid headers
○ Bot Control
● Optional addition of AWS Cloudfront
○ Protection against Network and Application Layer DDoS Attacks
○ Compliance - CloudFront infrastructure and processes are all compliant with PCI-
DSS Level 1, HIPAA, and ISO 9001, ISO/IEC 27001:2013, 27017:2015, 27018:2019,
SOC (1, 2 and 3), FedRAMP Moderate and more to ensure secure delivery for
sensitive data.
○ High Availability and Caching

8. Disaster Recovery
Active/Passive
● Standby infrastructure code for DR environment which can be provisioned without error with
minimum provision time
● Using AWS Backup Service to replicate encrypted RDS Snapshot and EFS backup across region
● Cross region ECR image replication
● Cross region replica of S3 bucket
● Optional - Place failover record type which will point DNS on health check failure to holding page?
Active/Active
● Run parallel infrastructure like VPC, ECS at DR region (GDPR policy needs to be taken care if
applicable)
● Use RDS read replica across region
● Use AWS Data Sync to sync EFS files across region over VPC peering
● Use Route 53 health check - On occasion of health failure traffic can be routed to DR ALB
● Cross region ECR image replication
● Cross region replica of S3 bucket
Things to consider
● Backup of Source Code available at third party Git repository

9. Logging & Monitoring
● Logging is a very crucial part of any infrastructure, we have used AWS native logging tool like AWS
Cloudwatch Logs/Log Groups. Applicable resources are,
○ ECS Services
○ VPC Flow Logs
○ Application Load Balancer Logs (We have used S3 bucket to store ALB Logs)
● Similar to Cloudwatch Logs, Cloudwatch metric is also an important component to monitor service
metrics and create alarms based on mentioned threshold. Applicable resources are,
○ RDS
○ EFS
○ ECS Service
● To trigger alarm based on threshold and send notification to group of people or on-call person, we
can use a third-party service like OpsGenie which can be integrated with SNS topic as SNS
Subscriber using HTTPs API Endpoint.

10. Conclusion

11. Questions Please

12. Thank You!