{"id":118,"date":"2025-01-20T20:45:43","date_gmt":"2025-01-20T19:45:43","guid":{"rendered":"https:\/\/www.raczynski.online\/?p=118"},"modified":"2025-01-21T14:26:35","modified_gmt":"2025-01-21T13:26:35","slug":"securing-an-aws-infrastructure-from-the-database-to-the-web-application","status":"publish","type":"post","link":"https:\/\/www.raczynski.online\/?p=118&lang=en","title":{"rendered":"Securing an AWS Infrastructure : From the Database to the Web Application"},"content":{"rendered":"\n<p>In a world where security risks scale as quickly as the cloud itself, building a robust AWS architecture requires weaving cybersecurity into each layer of the stack. From provisioning your first EC2 instance to orchestrating containerized applications on EKS\u2014and ensuring all traffic is encrypted by an HTTPS Load Balancer\u2014every decision impacts your overall security posture. This article dives deep into how Identity and Access Management (IAM) and network configurations function as pillars of a secure deployment, while suggesting both AWS-native and third-party tools to help you stay ahead of emerging threats.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><strong>Estimated Reading Time<\/strong>: ~10 minutes<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">1. Context: Scenario and Requirements<\/h2>\n\n\n\n<p>This scenario outlines deploying a database on an EC2 instance, hosting a containerized web application in an Amazon EKS cluster, and securing inbound traffic through an HTTPS Application Load Balancer. All resources need to adhere to best practices, including restricting network access, rotating credentials, and enforcing the principle of least privilege via IAM. Regular backups to Amazon S3, monitoring logs with CloudWatch, and using AWS-native or third-party cybersecurity tools (GuardDuty, WAF, Suricata, etc.) round out the requirements for a resilient, production-ready setup.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1.1 Database on EC2<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Primary Goal<\/strong>: Run MongoDB (or any other database) in a tightly secured environment. Restrict inbound connections to a specific CIDR range or private subnet.<\/li>\n\n\n\n<li><strong>Backups &amp; Disaster Recovery<\/strong>: Implement regular backups to Amazon S3, ensuring data is recoverable in the event of corruption or accidental deletion.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">1.2 Web Application on EKS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scalability &amp; Automation<\/strong>: Host containerized workloads in a Kubernetes-managed cluster (EKS), allowing rolling updates, auto-scaling, and standardized deployments.<\/li>\n\n\n\n<li><strong>Secret Management<\/strong>: Avoid storing credentials in Docker images; use AWS Secrets Manager or Parameter Store to provide them securely at runtime.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">1.3 HTTPS Load Balancer<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Secure Traffic<\/strong>: Enforce TLS\/SSL across the board, forcing HTTP (port 80) to HTTPS (port 443) redirection.<\/li>\n\n\n\n<li><strong>WAF Integration<\/strong>: Optionnaly deploy a Web Application Firewall (WAF) to inspect requests for malicious payloads (XSS, SQLi, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">1.4 IAM (Identity &amp; Access Management)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Fine-Grained Permissions<\/strong>: Implement roles with the principle of least privilege, granting only necessary access to each AWS service or component.<\/li>\n\n\n\n<li><strong>Traceability<\/strong>: Use CloudTrail and Security Hub to audit changes and detect potential misconfigurations.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">2. Deploying and Securing the Database on EC2<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">2.1 EC2 Instance Configuration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OS and AMI Choice<\/strong>\n<ul class=\"wp-block-list\">\n<li>Select <strong>Ubuntu 22.04 LTS<\/strong> (or another distribution with robust, frequent security updates).<\/li>\n\n\n\n<li>Optionally enable <strong>EBS encryption at rest<\/strong> for the root and data volumes.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Security Groups<\/strong>\n<ul class=\"wp-block-list\">\n<li>Restrict port 27017 (MongoDB) to internal traffic. If you must expose it publicly (for remote admin tasks), whitelist only trusted IP ranges or set up a VPN\/bastion approach.<\/li>\n\n\n\n<li>Limit SSH (port 22) to a bastion host or your office\u2019s IP range. For ephemeral remote access, consider <strong>AWS Systems Manager Session Manager<\/strong> to avoid exposing port 22 entirely.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"281\" src=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-1024x281.png\" alt=\"\" class=\"wp-image-123\" srcset=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-1024x281.png 1024w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-300x82.png 300w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-768x211.png 768w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-1536x422.png 1536w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-2048x562.png 2048w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-1200x330.png 1200w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-9-1980x544.png 1980w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure><\/div>\n\n\n<p>As shown in the security group rules for <strong>i-095d3062b983b51f3<\/strong> (KR-MongoDB), there are a few common misconfigurations to be wary of. First, inbound \u201cAll Traffic\u201d from the EKS group and wide-open ports (0\u201365535 from 0.0.0.0\/0) greatly expand the attack surface, exposing numerous unused ports to the internet. Similarly, leaving SSH (port 22) publicly accessible means potential brute-force attempts. Although this setup might work for quick tests, it\u2019s risky in a production or publicly accessible environment. Instead, restrict traffic to the necessary ports\u2014ideally behind a bastion or an ALB for inbound requests\u2014and limit SSH or ephemeral ports to known IPs or private subnets.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Extra Hardening<\/strong>\n<ul class=\"wp-block-list\">\n<li>Disable password login; rely exclusively on key-based SSH.<\/li>\n\n\n\n<li>Keep the system patched.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2.2 MongoDB Configuration<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Access Control<\/strong>\n<ul class=\"wp-block-list\">\n<li>Enable auth in <code>\/etc\/mongod.conf<\/code> by setting <code>security.authorization: enabled<\/code>.<\/li>\n\n\n\n<li>Create role-specific users: for instance, an <code>appUser<\/code> with <code>readWrite<\/code> on a single database, and an admin user with broader privileges.<\/li>\n\n\n\n<li>Store credentials securely (e.g., in AWS Secrets Manager).<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Transport Layer Security<\/strong>\n<ul class=\"wp-block-list\">\n<li>If external services need to connect to MongoDB, consider generating a TLS certificate for secured connections.<\/li>\n\n\n\n<li>For internal usage, at least ensure you\u2019re restricting MongoDB to the private subnet.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Regular Backups<\/strong>\n<ul class=\"wp-block-list\">\n<li>Script example (<code>mongodb_backup.sh<\/code>): <code>#!\/bin\/bash TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S) mongodump --host localhost --port 27017 --username \"appUser\" \\ --password \"securePassword\" --authenticationDatabase \"admin\" \\ --out \"\/backup\/$TIMESTAMP\" aws s3 sync \"\/backup\/$TIMESTAMP\" \"s3:\/\/my-backup-bucket\/$TIMESTAMP\"<\/code><\/li>\n\n\n\n<li>Integrate with <code>cron<\/code> for daily or weekly backups, then rotate old backups (e.g., older than 14 days).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">2.3 Logs &amp; Monitoring<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>AWS CloudWatch Logs<\/strong>\n<ul class=\"wp-block-list\">\n<li>Stream MongoDB logs to CloudWatch Logs using either an agent (e.g., the <code>awslogs<\/code> driver) or a sidecar approach in Docker if containerized.<\/li>\n\n\n\n<li>Set alarms on high error rates or repeated authentication failures.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>AWS CloudTrail<\/strong>\n<ul class=\"wp-block-list\">\n<li>Every change in security group rules, IAM policy updates, or new resource creation is logged here.<\/li>\n\n\n\n<li>Consolidate logs from multiple regions or accounts to avoid missing critical events.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<p>While hosting MongoDB on an EC2 instance is a valid approach\u2014especially if you need granular control\u2014AWS offers several managed solutions that can reduce operational overhead and enhance reliability. For instance, <strong>Amazon DocumentDB<\/strong> (with MongoDB compatibility) offloads patching, scaling, and automatic backups, and integrates natively with other AWS services. Alternatively, using a fully managed database service like <strong>Amazon RDS<\/strong> or <strong>Amazon Aurora<\/strong> might be more cost-effective and less maintenance-intensive if a relational model suits your use case. Evaluating these managed options not only saves you from manual updates and security patches, but also ensures high availability and automatic failover, letting you focus on application development rather than database administration.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Recommended Cybersecurity Tools<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Security Hub<\/strong>\n<ul class=\"wp-block-list\">\n<li>Regularly checks resources against CIS and PCI DSS benchmarks, highlighting misconfigurations.<\/li>\n\n\n\n<li><strong>Non-AWS Alternative<\/strong>: <strong>Wazuh<\/strong> (an OSSEC fork) or <strong>Elastic Security<\/strong> for compliance scanning and SIEM capabilities.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Amazon GuardDuty<\/strong>\n<ul class=\"wp-block-list\">\n<li>Monitors VPC Flow Logs and DNS queries to detect intrusion attempts or suspicious activity.<\/li>\n\n\n\n<li><strong>Non-AWS Alternative<\/strong>: <strong>Suricata<\/strong> or <strong>Zeek<\/strong> for deep packet inspection and intrusion detection.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Amazon Detective<\/strong>\n<ul class=\"wp-block-list\">\n<li>Correlates GuardDuty findings with CloudTrail, VPC logs for deeper incident investigations.<\/li>\n\n\n\n<li><strong>Non-AWS Alternative<\/strong>: Tools like <strong>Arkime<\/strong> or <strong>Malcolm<\/strong> for a self-managed network forensics platform.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Exposing the Web Application on EKS<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">3.1 EKS Cluster Setup<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Networking<\/strong>\n<ul class=\"wp-block-list\">\n<li>Separate subnets: <code>public<\/code> subnets for load balancers, <code>private<\/code> subnets for worker nodes.<\/li>\n\n\n\n<li>If using AWS Fargate for serverless Kubernetes pods, define appropriate Fargate profiles.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>RBAC &amp; IAM Roles<\/strong>\n<ul class=\"wp-block-list\">\n<li>Create a dedicated IAM role for the control plane, another for node instances.<\/li>\n\n\n\n<li>Map these roles to Kubernetes identities using <code>aws-auth<\/code> ConfigMap, ensuring each node or user gets only the necessary privileges.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Autoscaling &amp; Resilience<\/strong>\n<ul class=\"wp-block-list\">\n<li>Enable <strong>Cluster Autoscaler<\/strong> to handle node scaling based on real-time workload.<\/li>\n\n\n\n<li>Use <strong>Horizontal Pod Autoscaler<\/strong> to dynamically adjust pod replicas under CPU\/memory load.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">3.2 Containerization<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Dockerfile Hardening<\/strong>\n<ul class=\"wp-block-list\">\n<li>Base images: prefer minimal distributions (e.g., <code>alpine<\/code>), keep them updated.<\/li>\n\n\n\n<li>Multi-stage builds: remove development tools or secrets from the final image to reduce the attack surface.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Amazon ECR<\/strong>\n<ul class=\"wp-block-list\">\n<li>Encrypt images at rest by default.<\/li>\n\n\n\n<li>Use repository policies to limit push\/pull actions to certain IAM entities.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Application Secrets<\/strong>\n<ul class=\"wp-block-list\">\n<li>AWS Secrets Manager or Parameter Store integrates with EKS to inject secrets as environment variables or volumes.<\/li>\n\n\n\n<li>Avoid storing credentials in plain text within manifests or environment variables in Git.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">3.3 Kubernetes Policies &amp; Observability<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Network Policies<\/strong>\n<ul class=\"wp-block-list\">\n<li>Block cross-namespace traffic by default, then allow communication only where required.<\/li>\n\n\n\n<li>Tools like <strong>Calico<\/strong> or <strong>Cilium<\/strong> can implement advanced eBPF-level filtering, providing layer 7 controls.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Audit Logging<\/strong>\n<ul class=\"wp-block-list\">\n<li>Configure Kubernetes audit logs (api-server flags) for deeper visibility into cluster-level changes (e.g., new roles, events).<\/li>\n\n\n\n<li>Combine them with CloudWatch or an external SIEM (Splunk, Graylog).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"644\" src=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-1024x644.png\" alt=\"\" class=\"wp-image-126\" srcset=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-1024x644.png 1024w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-300x189.png 300w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-768x483.png 768w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-1536x966.png 1536w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-2048x1288.png 2048w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-1200x755.png 1200w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-12-1980x1246.png 1980w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure><\/div>\n\n\n<p>This screenshot displays critical details of an Amazon EKS cluster named <strong>eks-cluster-3<\/strong>, including its status (Active), the Kubernetes version in use (1.30), and the API server endpoint. It also shows the cluster\u2019s IAM role ARN, the certificate authority data (Base64-encoded), and the OIDC provider URL used for authenticating requests. These elements are essential for cluster operations but should typically be redacted if shared publicly to avoid exposing unique identifiers or endpoints.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Recommended Cybersecurity Tools<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon Inspector<\/strong>\n<ul class=\"wp-block-list\">\n<li>Scans containers for known CVEs or misconfigurations.<\/li>\n\n\n\n<li><strong>Non-AWS Alternatives<\/strong>: <strong>Trivy<\/strong> or <strong>Clair<\/strong> for open-source scanning, integrated into CI\/CD pipelines.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>OPA\/Gatekeeper<\/strong>\n<ul class=\"wp-block-list\">\n<li>Enforces policies like \u201cno container runs as root\u201d or \u201conly signed images are deployed.\u201d<\/li>\n\n\n\n<li><strong>Alternatives<\/strong>: <strong>Kyverno<\/strong>, <strong>Kubewarden<\/strong> for policy-as-code approaches.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Kubernetes Network Policies<\/strong>\n<ul class=\"wp-block-list\">\n<li>Minimizes lateral movement in case one pod is compromised.<\/li>\n\n\n\n<li><strong>Enhanced Tools<\/strong>: <strong>Istio<\/strong> or <strong>Linkerd<\/strong> for mTLS between services, providing zero-trust networking.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Load Balancing and Traffic Encryption<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">4.1 Application Load Balancer (ALB)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Annotations in the Service Manifest<\/strong>\n<ul class=\"wp-block-list\">\n<li>Example snippet (<code>service.yaml<\/code>): <code>apiVersion: v1 kind: Service metadata: name: my-webapp-service annotations: service.beta.kubernetes.io\/aws-load-balancer-type: \"alb\" alb.ingress.kubernetes.io\/scheme: internet-facing alb.ingress.kubernetes.io\/target-type: ip alb.ingress.kubernetes.io\/certificate-arn: \"arn:aws:acm:region:account:certificate\/1234-5678\" spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: my-webapp<\/code><\/li>\n\n\n\n<li>This config ensures an ALB is created, uses a specified SSL certificate (ACM), and routes traffic to pods on port 8080.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Certificate Management<\/strong>\n<ul class=\"wp-block-list\">\n<li>Use <strong>AWS Certificate Manager (ACM)<\/strong> to provision\/renew certificates automatically.<\/li>\n\n\n\n<li>For multi-domain or wildcard certs, validate ownership via DNS or email.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Health Checks &amp; Redirection<\/strong>\n<ul class=\"wp-block-list\">\n<li>Configure HTTP \u2192 HTTPS redirection at the ALB level, forcing secure connections.<\/li>\n\n\n\n<li>Health checks set to a custom path (e.g., <code>\/health<\/code>) with an HTTP 200 OK response.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"519\" src=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-1024x519.png\" alt=\"\" class=\"wp-image-128\" srcset=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-1024x519.png 1024w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-300x152.png 300w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-768x389.png 768w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-1536x778.png 1536w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-2048x1037.png 2048w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-1200x608.png 1200w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-14-1980x1003.png 1980w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure><\/div>\n\n\n<p>This screenshot provides essential information about an <strong>Application Load Balancer (ALB)<\/strong> named <strong>my-go-app-lb<\/strong>, including its type (Internet-facing), the AWS region and subnets it spans (eu-west-3a\/b), and the DNS name used to route traffic. You can also see the listener on port 80 forwarding requests to a target group (<strong>my-go-app-target-group<\/strong>), where stickiness is disabled. The ARN references, hosted zone, and creation date supply further context on the load balancer\u2019s operational details, though any sensitive identifiers\u2014like ARN or DNS name\u2014are best redacted or partially hidden when sharing publicly for security.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4.2 Security Group Rules<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Inbound<\/strong>\n<ul class=\"wp-block-list\">\n<li>Permit port 443 from the Internet, optionally allow port 80 only for an immediate redirect.<\/li>\n\n\n\n<li>If internal-only, set the load balancer as an \u201cinternal ALB\u201d in the scheme annotation.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Outbound<\/strong>\n<ul class=\"wp-block-list\">\n<li>Let the ALB connect to EKS nodes on the required node port or cluster IP.<\/li>\n\n\n\n<li>If pods require external calls (e.g., to third-party APIs), confirm those egress rules are tightly scoped.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Additional Hardening<\/strong>\n<ul class=\"wp-block-list\">\n<li>For advanced setups, combine the ALB with AWS WAF to filter malicious payloads.<\/li>\n\n\n\n<li>Export ALB logs to S3 or a SIEM platform and analyze patterns in real time.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h4 class=\"wp-block-heading\">Recommended Cybersecurity Tools<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS WAF<\/strong>\n<ul class=\"wp-block-list\">\n<li>Define rules to detect\/block common attacks (SQL injection, XSS).<\/li>\n\n\n\n<li><strong>Non-AWS<\/strong>: <strong>ModSecurity<\/strong> (as a WAF engine with Apache\/nginx) or <strong>Cloudflare WAF<\/strong> for broader multi-cloud or edge coverage.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>AWS Firewall Manager<\/strong>\n<ul class=\"wp-block-list\">\n<li>Centralize WAF or Shield Advanced policies across multiple accounts.<\/li>\n\n\n\n<li><strong>Alternatives<\/strong>: <strong>Imperva Cloud WAF<\/strong>, <strong>Akamai<\/strong> for distributed security enforcement.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>AWS Shield Advanced<\/strong>\n<ul class=\"wp-block-list\">\n<li>Enhanced DDoS mitigation for ALB, CloudFront, and Route 53.<\/li>\n\n\n\n<li><strong>Non-AWS<\/strong>: <strong>Cloudflare DDoS Protection<\/strong>, <strong>Radware<\/strong> for enterprise-level DDoS defense.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Main Challenges: IAM and Load Balancing<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">5.1 IAM (Identity &amp; Access Management)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Granular Policies<\/strong>\n<ul class=\"wp-block-list\">\n<li>Use JSON-based IAM policies specifying allowed actions, resources, and conditions.<\/li>\n\n\n\n<li>Tools like <strong>IAM Access Analyzer<\/strong> help find roles granting external or overly broad access.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Key &amp; Credential Rotation<\/strong>\n<ul class=\"wp-block-list\">\n<li>Rotate IAM user or service account credentials regularly.<\/li>\n\n\n\n<li>Link rotation events to CloudWatch Events or an SNS topic for alerts.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Auditing &amp; Compliance<\/strong>\n<ul class=\"wp-block-list\">\n<li><strong>AWS Config<\/strong>: Check if an S3 bucket has public read access or an EC2 instance has an open SSH port.<\/li>\n\n\n\n<li><strong>IAM Identity Center (AWS SSO)<\/strong>: Centralize employee access; tie user provisioning\/deprovisioning to corporate directories.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"622\" src=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11-1024x622.png\" alt=\"\" class=\"wp-image-125\" srcset=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11-1024x622.png 1024w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11-300x182.png 300w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11-768x467.png 768w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11-1536x933.png 1536w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11-1200x729.png 1200w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-11.png 1728w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure><\/div>\n\n\n<p>Granting <strong>AdministratorAccess<\/strong> plus multiple AWS-managed policies (like ECR Full, EKS policies, and a custom \u201cFull\u201d policy) to the same user significantly exceeds least-privilege principles, especially if those policies overlap. While convenient, this approach can create redundancies (e.g., multiple \u201cFull\u201d grants) and expand the potential attack surface if the user account is ever compromised. Instead, attach only the specific permissions each user or role requires, use separate roles for cluster services and worker nodes, and review custom policies (like \u201cJaceFull\u201d) to ensure they don\u2019t unnecessarily duplicate admin-level access.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Additional Tools for IAM<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Okta \/ Auth0<\/strong> \/ <strong>Keycloak<\/strong>: For single sign-on and identity federation in multi-cloud or hybrid environments.<\/li>\n\n\n\n<li><strong>HashiCorp Sentinel<\/strong> \/ <strong>Open Policy Agent<\/strong>: Extend policy-as-code to IAM, verifying each resource meets security constraints (e.g., no wildcards in roles).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.2 Load Balancing<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>HTTPS Enforcement<\/strong>\n<ul class=\"wp-block-list\">\n<li>Deny all HTTP if you do not plan to redirect. Otherwise, a 301\/302 redirect at the ALB ensures secure connections.<\/li>\n\n\n\n<li>Keep an eye on the certificate\u2019s expiration date (ACM auto-renew should handle it, but watch for domain or DNS changes).<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Scaling &amp; Performance<\/strong>\n<ul class=\"wp-block-list\">\n<li>If traffic surges, confirm your ALB scales out quickly.<\/li>\n\n\n\n<li>Monitor latency metrics in CloudWatch (e.g., <code>TargetResponseTime<\/code>) to detect configuration issues or health check failures.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Logging &amp; Analytics<\/strong>\n<ul class=\"wp-block-list\">\n<li>ALB access logs can be sent to S3, then queried via Amazon Athena or a self-hosted solution (e.g., ELK Stack).<\/li>\n\n\n\n<li>Look for repeated 4xx or 5xx errors, spikes in request volume, or suspicious paths that might indicate reconnaissance.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p>Securing AWS environments means meticulously orchestrating defenses across <strong>EC2<\/strong> (for your database), <strong>EKS<\/strong> (for containerized applications), and an <strong>HTTPS Load Balancer<\/strong> (for encrypted traffic and potential WAF integration). The pivotal elements\u2014<strong>IAM<\/strong> and <strong>load balancing<\/strong>\u2014demand special care. IAM roles must be strictly scoped, adopting a least-privilege approach, and regularly audited via AWS Security Hub or external tooling (Wazuh, Splunk). Meanwhile, your Load Balancer emerges as both an entry point for encrypted traffic and a platform for advanced protection (e.g., WAF, custom rules, DDoS mitigation).<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8-1024x576.png\" alt=\"\" class=\"wp-image-122\" srcset=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8-1024x576.png 1024w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8-300x169.png 300w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8-768x432.png 768w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8-1536x864.png 1536w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8-1200x675.png 1200w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-8.png 1920w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Datadog&rsquo;s Cloudcraft is a great way to map AWS ressources.<\/figcaption><\/figure><\/div>\n\n\n<p>While robust security and scalability are paramount, it\u2019s equally important to track the expenses tied to your AWS resources\u2014especially as you spin up EC2 instances, run EKS clusters, or deploy additional services. Tools like <strong>AWS Cost Explorer<\/strong> and <strong>AWS Budgets<\/strong> enable you to monitor usage patterns, set spending thresholds, and receive alerts before costs escalate unexpectedly. If you prefer more in-depth analysis or multi-cloud coverage, consider third-party solutions such as <strong>CloudHealth<\/strong> or <strong>CloudZero<\/strong>. By actively reviewing these metrics and adjusting resource allocations, you ensure a sustainable balance between security, performance, and budget.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"652\" src=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-7-1024x652.png\" alt=\"\" class=\"wp-image-121\" srcset=\"https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-7-1024x652.png 1024w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-7-300x191.png 300w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-7-768x489.png 768w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-7-1200x764.png 1200w, https:\/\/www.raczynski.online\/wp-content\/uploads\/2025\/01\/image-7.png 1470w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure><\/div>\n\n\n<p>Whether you rely solely on <strong>AWS-native services<\/strong> (GuardDuty, Inspector, Shield) or combine them with <strong>third-party<\/strong> or <strong>open-source<\/strong> alternatives (ModSecurity, Cloudflare, Suricata, etc.), your end goal remains the same: a consistently updated, closely monitored, and securely configured environment. As threat actors evolve their tactics, continuous improvement\u2014keeping OS patches current, rotating credentials, refining network policies\u2014is crucial. By treating security as a core design principle rather than an afterthought, you significantly boost the resilience of your cloud deployments while safeguarding your digital frontier.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">Author Bio<\/h3>\n\n\n\n<p><strong>Krzysztof Raczynski<\/strong> is a cybersecurity professional committed to sharing hands-on insights drawn from his work securing complex AWS infrastructures. He thrives on designing robust solutions around containers, threat detection, and cloud-native best practices. Outside of day-to-day engineering, Krzysztof invests in knowledge-sharing\u2014crafting thorough tutorials, speaking at industry meetups, and championing forward-thinking approaches to modern cyber defense.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In a world where security risks scale as quickly as the cloud itself, building a robust AWS architecture requires weaving cybersecurity into each layer of the stack. From provisioning your first EC2 instance to orchestrating containerized applications on EKS\u2014and ensuring all traffic is encrypted by an HTTPS Load Balancer\u2014every decision impacts your overall security posture. [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[],"class_list":["post-118","post","type-post","status-publish","format-standard","hentry","category-aws"],"_links":{"self":[{"href":"https:\/\/www.raczynski.online\/index.php?rest_route=\/wp\/v2\/posts\/118","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.raczynski.online\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.raczynski.online\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.raczynski.online\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.raczynski.online\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=118"}],"version-history":[{"count":4,"href":"https:\/\/www.raczynski.online\/index.php?rest_route=\/wp\/v2\/posts\/118\/revisions"}],"predecessor-version":[{"id":131,"href":"https:\/\/www.raczynski.online\/index.php?rest_route=\/wp\/v2\/posts\/118\/revisions\/131"}],"wp:attachment":[{"href":"https:\/\/www.raczynski.online\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=118"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.raczynski.online\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=118"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.raczynski.online\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=118"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}