Introduction
Security in Public Cloud is utmost important. Losing access to your website or attackers deleting your database are catastrophic-company-ending-events.
Shared Responsibility Model
Security and Compliance is a shared responsibility between AWS and the customer.
AWS is responsible for the "Security of the Cloud". AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
Customer is responsible for the “Security in the Cloud”. Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities.
Refer AWS Documentation for more information on Shared Responsibility Model.
Best Practices
Luckily, AWS provides you with a host of security services to improve your security posture from Day One. Note that this is not an exhaustive list and "it depends" on where you run and what services you use. Here are some of the steps to secure your microservices architecture in AWS:
- Use AWS Shield for DDoS protection
- Use AWS GuardDuty for intelligent threat detection.
- Use AWS IAM for managing identities and access to AWS resources
- Use AWS WAF to protect your web applications from common exploits.
- Use AWS Certificates Manager for encrypting website data in transit using TLS/SSL certificates.
- Use AWS KMS keys to encrypt all EBS volumes and Aurora DB (data at rest)
- Use AWS Secrets Manager to store your application secrets.
- Run all your workloads in private subnets. Allow only needed traffic using Security Groups and NACLs.
- If your applications need Internet connectivity to download updates then configure NAT GW in public subnet.
- You could also use VPC peering to isolate specific workloads in a different VPC in a different AWS account.
- Use Amazon Inspector to scan EC2 for security vulnerabilities
- Use Amazon Security Hub to automate AWS security checks and centralize security alerts.
- Use AWS Cognito for authentication and authorization of the API requests.
- Use CloudTrail for audit logging.
Conclusion
Security should not be an after thought when building and running applications in AWS. Utilize some or all of these AWS security services to make your microservices architecture secure.
What have I missed? This post assumed microservices are running in EC2 VMs. If microservices are running in Amazon EKS then it calls for a totally new approach and very long post. I will post about EKS security soon.
Follow me on LinkedIn at https://www.linkedin.com/in/vijaykodam/ where I post articles about AWS, Kubernetes and cloud computing in general. I also post all my articles to my blog at https://vijay.eu/posts
Header Image generated using DALL.E. Microservices architecture made by me using draw.io
Top comments (0)