AWS Security Architect https://awssecurityarchitect.com/ Experienced AWS, GCP and Azure Security Architect Mon, 12 Jan 2026 18:50:24 +0000 en-US hourly 1 https://wordpress.org/?v=6.9 214477604 ALBs with EC2 instances https://awssecurityarchitect.com/albs-on-aws/albs-with-ec2-instances/ https://awssecurityarchitect.com/albs-on-aws/albs-with-ec2-instances/#respond Mon, 12 Jan 2026 18:50:24 +0000 https://awssecurityarchitect.com/?p=509 <!doctype html>   AWS ALB to Protect Instances with Public IPs (Elaborated) If your EC2 instances have public IPs, an AWS Application Load Balancer (ALB) can help — but the […]

The post ALBs with EC2 instances appeared first on AWS Security Architect.

]]> <!doctype html>

 

AWS ALB to Protect Instances with Public IPs (Elaborated)

If your EC2 instances have public IPs, an AWS Application Load Balancer (ALB) can help
— but the strongest security improvement is using the ALB to eliminate direct internet reachability
to those instances.

Best practice: Make the ALB the only internet-facing endpoint and place compute in
private subnets with no public IPs.

1) Best-Practice Architecture: Public ALB, Private Instances

  • ALB: internet-facing, deployed in public subnets
  • Targets (EC2/ECS/EKS): deployed in private subnets, no public IPs
  • Security Groups:
    • ALB SG: allow 443 (and optionally 80 for redirect) from approved sources
    • Instance SG: allow app port(s) only from the ALB SG

Protection You Gain

  • No direct scanning/exploitation of instances from the internet (instances are not reachable)
  • Centralized TLS termination (ACM certs, modern cipher policies, redirects)
  • Single ingress choke-point for WAF, routing rules, and logging
  • Health checks reduce exposure to unhealthy nodes

2) If Instances Already Have Public IPs: How ALB Still Helps

You can still place an ALB in front of instances that have public IPs, but you must ensure those instances are
not directly reachable by tightening security groups.

Pattern: “ALB in Front, Public IPs Exist but Are Useless”

  • Keep public IPs on instances (not ideal, but sometimes required temporarily)
  • Instance SG inbound rules:
    • Remove inbound from 0.0.0.0/0 (and ::/0) to app ports
    • Allow app port(s) only from the ALB Security Group
  • Administrative access: do not expose SSH/RDP to the internet. Use:
    • AWS Systems Manager Session Manager (preferred)
    • or a bastion host with strict IP allowlist
    • or VPN/Direct Connect
Key point: A public IP is not “safe” just because an ALB exists. It becomes safe when
security groups (and NACLs, if used) block all direct inbound except from the ALB.

3) What ALB Protects You From (and Enables)

3.1 Architectural Protection: Remove Direct Exposure

  • Forces a single entry point (ALB)
  • Reduces attack surface by preventing direct-to-instance traffic

3.2 TLS Termination & Policy Enforcement

  • Centralized certificate management with AWS Certificate Manager (ACM)
  • HTTP to HTTPS redirects
  • Consistent TLS policies across apps

3.3 Attach AWS WAF to ALB

WAF is usually where “web protection” lives (not the ALB alone).

  • Managed rule groups (OWASP-style, known patterns and bots)
  • Rate limiting / throttling
  • Geo restrictions / allowlists
  • Custom rules for paths, headers, payload patterns

3.4 Observability & Audit Trails

  • ALB access logs to S3
  • CloudWatch metrics (4xx/5xx, target response time)
  • Centralized view of traffic and anomalies (especially with WAF logs)

3.5 Safer Deployments

  • Health checks and target group routing
  • Blue/green and canary releases via weighted target groups

4) What ALB Does NOT Protect You From

  • Compromise via other vectors (stolen credentials, SSRF, supply chain issues)
  • Non-HTTP(S) protocols (ALB is Layer 7; for TCP/UDP you typically need an NLB)
  • Direct-to-instance access if inbound rules still allow it
  • Large-scale DDoS by itself (use AWS Shield + WAF + architecture)

5) Recommended Secure Internet Application Stack

  • CloudFront (optional but strong) → WAF → ALB → Private compute
  • Instances: no public IPs
  • Admin access: SSM Session Manager
  • Centralized logging: CloudTrail, ALB/WAF logs → S3 (with retention/immutability controls)

6) Quick Checklist

  • EC2 targets in private subnets with no public IPs
  • Instance SG inbound allows app ports only from ALB SG
  • No SSH/RDP from the internet; use SSM or VPN/bastion
  • Attach AWS WAF to ALB (or CloudFront)
  • Enable ALB access logs (and WAF logs if used)
  • Enforce HTTPS (redirect + hardened TLS policy)

7) Example Security Group Intent (Conceptual)

ALB Security Group (Inbound)
- TCP 443 from approved sources (0.0.0.0/0 or stricter allowlist)
- TCP 80 optional (redirect to 443)

Instance Security Group (Inbound)
- App Port (e.g., TCP 80/443/8080) ONLY from ALB Security Group
- Admin ports: NONE from internet (use SSM/VPN/Bastion)

Outbound (Both)
- As required (prefer least privilege; consider egress controls/proxy)

 

The post ALBs with EC2 instances appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/albs-on-aws/albs-with-ec2-instances/feed/ 0 509 Shared VPCs for Production and Non Production Assets https://awssecurityarchitect.com/shared-vpcs/shared-vpcs-for-production-and-non-production-assets/ https://awssecurityarchitect.com/shared-vpcs/shared-vpcs-for-production-and-non-production-assets/#respond Fri, 05 Dec 2025 18:25:49 +0000 https://awssecurityarchitect.com/?p=504 Overview A Shared VPC lets one AWS account (the Host) own a VPC and subnets and share those subnets with other AWS accounts (the Participants). This pattern centralizes networking while […]

The post Shared VPCs for Production and Non Production Assets appeared first on AWS Security Architect.

]]>

Overview

A Shared VPC lets one AWS account (the Host) own a VPC and subnets and share those subnets with other AWS accounts (the Participants). This pattern centralizes networking while keeping workload control in the participant accounts.

High-level approach

  • Create separate subnet groups for prod and non-prod inside the host VPC.
  • Participant accounts deploy workloads (EC2, RDS, EKS, etc.) which attach ENIs into those shared subnets.
  • Host account manages routing, firewalls, NAT, endpoints, DNS and logging — not application compute.

What belongs in the Host VPC account

This account is your centralized networking account. Typical items:

  • The VPC and its CIDR(s).
  • Subnets — clearly labeled and separated for prod vs non-prod (e.g. Prod-App-Subnet-A, NonProd-DB-Subnet-A).
  • Route tables, IGW, VGW/TGW attachments.
  • Network appliances: NAT gateways, centralized firewall (AWS Network Firewall or 3rd party), IDS/IPS, etc.
  • VPC endpoints (S3, DynamoDB, Systems Manager) and endpoint policies.
  • DNS (Route 53 Resolver endpoints) and centralized logging/flow-logs.

Do not run application compute in the Host account — keep it a networking services account to reduce blast radius and permission complexity.

What belongs in the Participant accounts

Participant accounts own the workloads and most of the application-level controls:

  • Compute: EC2, ECS tasks, EKS worker nodes & pods (that create ENIs), Lambda functions (if VPC-enabled), etc.
  • Managed database resources such as RDS / Aurora (service ENIs attach to shared subnets).
  • Security groups — participants create and manage their own SGs.
  • Deployment pipelines, application IAM roles, monitoring/alerting agents.

Participants cannot modify VPC-level objects (subnets, route tables, IGW/TGW) — this restriction provides network control and safety.

Segmenting Production vs Non-Production

Key controls to host both environments safely in one shared VPC:

  • Subnet separation: distinct subnets for Prod and Non-Prod, ideally across multiple AZs.
  • Routing: Prod subnets route to prod-specific firewalls / TGW attachments; non-prod routes to non-prod appliances.
  • Network-level filtering: security groups, NACLs, and firewall policies that strictly control cross-environment traffic.
  • Org policy & IAM: use AWS Organizations SCPs, IAM role boundaries and least privilege to prevent privilege escalation between envs.
  • Separate logging & monitoring: keep prod logs and metrics isolated or labeled and access-controlled.

Example subnet layout (recommended)

Subnet Purpose Shared To
Prod-App-Subnet-A/B/C Production application tier (multi-AZ) Production participant accounts
Prod-DB-Subnet-A/B Production databases (private) Production participant accounts
NonProd-App-Subnet-A/B/C Dev/Test application tier Dev/Test participant accounts
NonProd-DB-Subnet-A/B Non-prod databases Dev/Test participant accounts
Shared-Services-Subnet Centralized services: logging, bastion, SSM endpoints Shared-services account + selected participants

Routing & NAT recommendations

  • Use separate NAT Gateways for prod and non-prod to avoid accidental traffic mixing and to charge-back costs accurately.
  • Route prod traffic through prod firewall or dedicated TGW attachment.
  • Consider Transit Gateway + route tables to control cross-account connectivity at scale.

Governance & security controls

  • Enforce AWS Organizations SCPs to block participant accounts from creating or modifying VPC infrastructure.
  • Use IAM and resource-based policies to restrict who can share/attach subnets.
  • Apply strict endpoint policies for VPC endpoints (S3, Secrets Manager, etc.) to control access by environment.
  • Use separate monitoring/alerting channels and RBAC for prod vs non-prod.

When NOT to share a VPC

Consider separate VPCs if any of the following are true:

  • You require absolute network separation for compliance (PCI-DSS, FedRAMP, HIPAA) with independent audit trails.
  • The environments have fundamentally different routing/firewall/peering needs that are hard to satisfy with one VPC.
  • You lack governance to centrally control network configuration and access.

Recommended organization structure (example)

The post Shared VPCs for Production and Non Production Assets appeared first on AWS Security Architect.

]]>
					
					https://awssecurityarchitect.com/shared-vpcs/shared-vpcs-for-production-and-non-production-assets/feed/
			0
		
		
		504	
		
		DNS Isolation on AWS
		https://awssecurityarchitect.com/aws-network-security/dns-isolation-on-aws/
					https://awssecurityarchitect.com/aws-network-security/dns-isolation-on-aws/#respond
		
		
		Tue, 25 Nov 2025 20:11:40 +0000
				
		
		https://awssecurityarchitect.com/?p=500

					DNS Isolation on AWS DNS isolation on AWS refers to designing your Amazon Web Services environment so that certain workloads or networks can only resolve DNS names you explicitly allow, […]


The post DNS Isolation on AWS appeared first on AWS Security Architect.

]]>
										dns isolation aws
dns isolation aws


DNS Isolation on AWS


DNS isolation on AWS refers to designing your Amazon Web Services environment so that certain workloads or networks can only resolve DNS names you explicitly allow, while blocking or segregating access to all other DNS sources—internal or external.


It is often used for security-sensitive, regulated, or multi-tenant architectures where you want to strictly control what resources can discover each other via DNS.


What DNS Isolation Means


DNS isolation ensures that a workload or subnet does not automatically inherit DNS visibility from the broader VPC or the internet. Instead, you tightly control where it gets DNS answers from (e.g., Route 53 Resolver rules, inbound/outbound resolvers, private hosted zones).


    

  • Isolates DNS Resolution Paths: Prevents workloads from resolving public DNS names or internal/private AWS names not intended for them.
    • 

  • Controls Resource Discovery: Restricts which internal services can be discovered by name.
    • 

  • Prevents Data Exfiltration via DNS: Cuts off malware from using DNS to exfiltrate data.
    • 



How to Implement DNS Isolation in AWS


1. Disable the Default VPC Resolver


At the subnet level, set enableDnsSupport = false or override DNS servers via DHCP option sets to force workloads to use only your DNS servers.


2. Use Custom DNS Servers or Route 53 Resolver Endpoints


Point instances/subnets to custom DNS appliances or Route 53 outbound resolver endpoints with controlled forwarding rules.


3. Use Route 53 Resolver Rules for Fine-Grained Control


Define conditional forwarding rules, e.g.:


    

  • corp.local → internal DNS server
    • 

  • serviceA.internal → specific resolver
    • 

  • Block everything else
    • 



4. Private Hosted Zones (PHZs) for Segregation


Attach PHZs only to specific VPCs to achieve multi-tenant DNS isolation and environment separation (dev vs prod).


5. Use Security Groups or Route 53 Resolver DNS Firewall


Create DNS firewall rule groups to:


    

  • Allow only approved domains
    • 

  • Block malware/TLDs
    • 

  • Prevent access to external DNS servers
    • 



Common Use Cases for DNS Isolation


    

  • Zero-Trust Network Design: Only authorized services resolve each other.
    • 

  • Regulated Workloads: Ensures workloads resolve only internal names (HIPAA, FedRAMP, PCI).
    • 

  • Multi-Tenant SaaS Platforms: Each tenant/VPC uses separate PHZs and resolver rules.
    • 

  • Highly-Sensitive Internal Apps: Prevents accidental communication.
    • 

  • Preventing Data Exfiltration: Blocks DNS tunneling by design.
    • 



Example Architecture for Isolated DNS


VPC (DNS Support Disabled)
   |
   +-- DHCP Option Set: DNS = Custom DNS Servers
   |
   +-- Route 53 Outbound Resolver Endpoint
           |
           |-- RULE: *.corp.local → Internal Data Center DNS
           |-- RULE: *.aws.local → AmazonProvidedDNS (private endpoints only)
           |-- RULE: BLOCK everything else



Workloads in this VPC cannot resolve public DNS, cannot query VPC private DNS unless allowed, and cannot access external resolvers.


 


The post DNS Isolation on AWS appeared first on AWS Security Architect.

]]>
					
					https://awssecurityarchitect.com/aws-network-security/dns-isolation-on-aws/feed/
			0
		
		
		500	
		
		How to tell whether an endpoint is public facing?
		https://awssecurityarchitect.com/apis-on-aws/how-to-tell-whether-an-endpoint-is-public-facing/
					https://awssecurityarchitect.com/apis-on-aws/how-to-tell-whether-an-endpoint-is-public-facing/#respond
		
		
		Tue, 25 Nov 2025 16:34:04 +0000
				
		
		https://awssecurityarchitect.com/?p=498

					  Interpreting a JSON 404 Response Context: you received a JSON response with status: 404 detail: "no static resource /api/v2/users/myapp" Quick answer This does not prove the API endpoint is […]


The post How to tell whether an endpoint is public facing? appeared first on AWS Security Architect.

]]>
										 



Interpreting a JSON 404 Response


Context: you received a JSON response with


status: 404
detail: "no static resource /api/v2/users/myapp"


Quick answer


This does not prove the API endpoint is publicly accessible. It only shows your request reached a web server or proxy which could not find a matching static resource or route.


What this response does indicate


    

  • The request reached a server or reverse proxy. The phrase “no static resource” is commonly emitted by web servers or frameworks when a path is not mapped to a file or route.
    • 

  • The server attempted to treat the path as a static/file request and didn’t find a corresponding file or route.
    • 

  • You hit an upstream layer (NGINX, CDN, API Gateway, Spring Boot static handler, Express static middleware, etc.) that answered on behalf of the infrastructure.
    • 



What this response does not mean


    

  • It does not mean the endpoint is public. Protected or internal endpoints often return 404 (instead of 401/403) to avoid revealing existence.
    • 

  • It does not prove you reached the backend API handler. You may be stopped at a routing/gateway/static file layer before auth or controller logic runs.
    • 



Likely causes


    

  • Wrong HTTP method (e.g., using GET when the API expects POST).
    • 

  • Missing URL prefix, incorrect path, or path is only accessible behind authentication or a different route.
    • 

  • Gateway/router misconfiguration or the backend service is not registered or not healthy.
    • 

  • Security configuration that masks endpoints (returns 404 for unauthorized callers).
    • 



How to investigate further (practical checks)


    

  1. Try an OPTIONS request (CORS preflight):

    OPTIONS /api/v2/users/myapp
    

    If public/web-facing, OPTIONS often returns 200/204 and CORS headers. A 404 for OPTIONS suggests the route isn’t exposed at the public layer.
    2. 

  2. Compare several paths:If both a known-valid endpoint and random paths return the same no static resource text, the gateway is likely returning a generic fallback instead of routing to APIs.
    3. 

  3. Inspect response headers:

    Access-Control-Allow-Origin: *
Server: nginx
x-envoy-response-flags: ...

    

    Headers like Access-Control-Allow-Origin or absence/presence of proxy headers (x-envoy, x-amzn-) give clues about whether you’re hitting a public API gateway or internal proxy.
    4. 

  4. Validate method and payload: Ensure you used the correct HTTP verb, required headers (Authorization, Content-Type), and correct URL encoding.
    5. 

  5. Check authentication behavior: Try an authenticated request (if permitted). If the server then returns a different error (401/403/200), the earlier 404 was likely a security masking behavior.
    6. 

  6. Test another known endpoint on the same domain: If other documented endpoints respond normally, the issue is likely the specific path. If none respond, routing or gateway is the problem.
    7. 



Example diagnostic flow


// 1. Preflight
OPTIONS /api/v2/users/myapp

// 2. Simple GET (no auth)
GET /api/v2/users/myapp
→ 404 "no static resource /api/v2/users/myapp"

// 3. GET with Authorization (if you have creds)
GET /api/v2/users/myapp
Authorization: Bearer 
→ 200 / 401 / 403 / other

// 4. Try a different known endpoint
GET /api/v2/health
→ 200  (gateway routing ok) OR 404 (gateway not routing)



Bottom line: The message indicates you reached a server layer that did not find a matching static resource or route — but it does not prove the API is public. Additional checks (OPTIONS, headers, authenticated requests, and testing known endpoints) will help determine whether the route is exposed or is being intentionally hidden behind authentication/routing logic.


If you want, paste the full HTTP response headers (no secrets) and I’ll analyze them and suggest next steps.


The post How to tell whether an endpoint is public facing? appeared first on AWS Security Architect.

]]>
					
					https://awssecurityarchitect.com/apis-on-aws/how-to-tell-whether-an-endpoint-is-public-facing/feed/
			0
		
		
		498	
		
		Control Tower Integrated SSO and Permission Sets
		https://awssecurityarchitect.com/aws-iam/control-tower-integrated-sso-and-permission-sets/
					https://awssecurityarchitect.com/aws-iam/control-tower-integrated-sso-and-permission-sets/#respond
		
		
		Fri, 21 Nov 2025 18:34:23 +0000
				
		
		https://awssecurityarchitect.com/?p=491

					AWS Permission Sets vs Control Tower SSO AWS Permission Sets vs Control Tower SSO 1. AWS Control Tower SSO Purpose: Provides a managed way to centrally set up and govern […]


The post Control Tower Integrated SSO and Permission Sets appeared first on AWS Security Architect.

]]>
										





    

    AWS Permission Sets vs Control Tower SSO






AWS Permission Sets vs Control Tower SSO


1. AWS Control Tower SSO


Purpose: Provides a managed way to centrally set up and govern multiple AWS accounts with pre-configured security and governance best practices.


Integration: Built on top of AWS IAM Identity Center (formerly AWS SSO).


Primary Use Case:


    

  • Centralized identity management across all AWS accounts in your organization.
    • 

  • Simplifies user access management in a multi-account environment.
    • 



Features:


    

  • Users log in via a single portal to access multiple AWS accounts.
    • 

  • Integrates with existing identity providers (IdPs) like Azure AD, Okta, etc.
    • 

  • Works with Control Tower to automatically apply baseline guardrails and account structures.
    • 



2. AWS Permission Sets


Purpose: Define what permissions users get when they access an AWS account via IAM Identity Center (SSO).


Integration: Used within Control Tower SSO / IAM Identity Center to assign access to AWS accounts.


Primary Use Case:


    

  • Assign role-based permissions to groups or users.
    • 

  • Can define permissions using AWS managed policies, custom policies, or a combination.
    • 



Features:


    

  • Can be reused across multiple accounts.
    • 

  • Can assign session duration, permission boundaries, and MFA requirements.
    • 

  • Supports fine-grained control over user permissions in multi-account setups.
    • 



Key Differences





Aspect
Control Tower SSO
Permission Sets




Function
Centralized identity access across multiple accounts
Defines permissions/roles for users within SSO




Scope
Multi-account user login and governance
Specific permissions in each account




Setup
Part of Control Tower landing zone
Created and assigned inside IAM Identity Center




Granularity
Account-level access
Role/permission-level access inside accounts





How They Work Together


    

  1. Control Tower SSO provides the portal and identity integration for all users.
    2. 

  2. Permission Sets are assigned to users or groups to define exactly what they can do in each AWS account they have access to.
    3. 

  3. Example:

      

    • Control Tower SSO gives Alice access to accounts Dev and Prod.
      • 

    • Permission Sets assign AdministratorAccess in Dev and ReadOnlyAccess in Prod.
      • 

    

    4. 








aws controltower SSO
aws controltower SSO


The post Control Tower Integrated SSO and Permission Sets appeared first on AWS Security Architect.

]]>
					
					https://awssecurityarchitect.com/aws-iam/control-tower-integrated-sso-and-permission-sets/feed/
			0
		
		
		491	
		
		Backup Policies for Servers migrated to AWS
		https://awssecurityarchitect.com/aws-backups/backup-policies-for-servers-migrated-to-aws/
					https://awssecurityarchitect.com/aws-backups/backup-policies-for-servers-migrated-to-aws/#respond
		
		
		Fri, 21 Nov 2025 17:03:40 +0000
				
		
		https://awssecurityarchitect.com/?p=488

					  Backup Policy for Windows Servers on AWS Policy ID: IT-BACKUP-001 Version: 1.0 Effective Date: [Insert Date] Owner: IT Operations / Cloud Infrastructure Team 1. Purpose This policy defines standardized […]


The post Backup Policies for Servers migrated to AWS appeared first on AWS Security Architect.

]]>
										 




Backup Policy for Windows Servers on AWS


Policy ID: IT-BACKUP-001


Version: 1.0


Effective Date: [Insert Date]


Owner: IT Operations / Cloud Infrastructure Team


1. Purpose


This policy defines standardized procedures for backing up Windows servers hosted on AWS, ensuring data integrity, availability, and recoverability in the event of hardware failure, application issues, or disaster.


2. Scope


    

  • All Windows Server instances running in AWS (EC2) that host production applications.
    • 

  • All attached EBS volumes containing system or application data.
    • 

  • Critical databases and application files hosted on these instances.
    • 



3. Policy Statements


3.1 Backup Frequency


    

  • Full backups: Weekly, capturing the entire system volume (EBS snapshot).
    • 

  • Incremental backups: Daily, capturing changed data on EBS volumes.
    • 

  • Application-specific backups: Database backups (SQL Server, Exchange) must occur at least daily.
    • 



3.2 Backup Methodology


    

  • AWS Backup will be the primary mechanism for automated backups.
    • 

  • VSS (Volume Shadow Copy Service) must be enabled for application-consistent snapshots.
    • 

  • File-level backups of configuration files and critical application data should be copied to S3 for redundancy.
    • 



3.3 Retention


    

  • Daily backups: Retain for 14 days.
    • 

  • Weekly backups: Retain for 90 days.
    • 

  • Monthly backups: Retain for 1 year.
    • 

  • Offsite / Cross-region backups: Critical systems must have at least one copy in a different AWS region.
    • 



3.4 Roles and Responsibilities


    

  • IT Operations / Cloud Infrastructure Team: Configure and monitor AWS Backup and snapshots, ensure SSM agents are installed, validate application-consistent backups.
    • 

  • Application Owners: Confirm backup schedules meet business RPO/RTO requirements and provide scripts for pre/post backup processes if required.
    • 



3.5 Monitoring and Reporting


    

  • Use CloudWatch metrics and alarms to track backup success/failure and disk space usage.
    • 

  • Generate AWS Backup compliance reports weekly and review with IT management.
    • 

  • Investigate and remediate any failed or missed backups within 24 hours.
    • 



3.6 Testing and Validation


    

  • Quarterly restore tests must be performed to ensure backups are recoverable.
    • 

  • Document results, including issues, corrective actions, and improvements.
    • 



3.7 Security


    

  • All backup data must be encrypted at rest and in transit.
    • 

  • Limit access to backups using IAM roles and policies.
    • 

  • Audit access logs periodically for compliance.
    • 



4. Exceptions


Any deviation from this policy requires formal approval from IT management and must be documented with reasons, risks, and mitigation measures.


5. References



AWS Backup Plan for Windows Servers


The following JSON template can be used in AWS Backup to implement this policy:


{
  "BackupPlanName": "Windows-Prod-Backup-Plan",
  "Rules": [
    {
      "RuleName": "Daily-Incremental-Backup",
      "TargetBackupVaultName": "Default",
      "ScheduleExpression": "cron(0 2 * * ? *)",
      "StartWindowMinutes": 60,
      "CompletionWindowMinutes": 180,
      "Lifecycle": {
        "MoveToColdStorageAfterDays": 30,
        "DeleteAfterDays": 14
      },
      "RecoveryPointTags": {
        "Environment": "Production",
        "Application": "WindowsServer"
      }
    },
    {
      "RuleName": "Weekly-Full-Backup",
      "TargetBackupVaultName": "Default",
      "ScheduleExpression": "cron(0 3 ? * 1 *)",
      "StartWindowMinutes": 120,
      "CompletionWindowMinutes": 360,
      "Lifecycle": {
        "MoveToColdStorageAfterDays": 60,
        "DeleteAfterDays": 90
      },
      "RecoveryPointTags": {
        "Environment": "Production",
        "Application": "WindowsServer"
      }
    },
    {
      "RuleName": "Monthly-Archive-Backup",
      "TargetBackupVaultName": "Default",
      "ScheduleExpression": "cron(0 4 1 * ? *)",
      "StartWindowMinutes": 240,
      "CompletionWindowMinutes": 720,
      "Lifecycle": {
        "MoveToColdStorageAfterDays": 90,
        "DeleteAfterDays": 365
      },
      "RecoveryPointTags": {
        "Environment": "Production",
        "Application": "WindowsServer"
      }
    }
  ]
}


 


The post Backup Policies for Servers migrated to AWS appeared first on AWS Security Architect.

]]>
					
					https://awssecurityarchitect.com/aws-backups/backup-policies-for-servers-migrated-to-aws/feed/
			0
		
		
		488	
		
		Aurora Postgres versus RDS Postgres
		https://awssecurityarchitect.com/aws-migration/aurora-postgres-versus-rds-postgres/
					https://awssecurityarchitect.com/aws-migration/aurora-postgres-versus-rds-postgres/#respond
		
		
		Thu, 20 Nov 2025 21:36:55 +0000
				
		
		
		https://awssecurityarchitect.com/?p=484

					Phase 1 — Assessment & Planning Choose target engine Aurora PostgreSQL (recommended for PostgreSQL features & ecosystem). Aurora MySQL if your app is already MySQL-based. Inventory & compatibility assessment Catalog […]


The post Aurora Postgres versus RDS Postgres appeared first on AWS Security Architect.

]]>
										

Phase 1 — Assessment & Planning


    

  1. Choose target engine

      

    • Aurora PostgreSQL (recommended for PostgreSQL features & ecosystem).
      • 

    • Aurora MySQL if your app is already MySQL-based.
      • 

    

    2. 

  2. Inventory & compatibility assessment

      

    • Catalog databases, tables, indexes, constraints, stored procedures, triggers, views, jobs, and linked servers.
      • 

    • Identify MSSQL-specific items: T-SQL procedures, CLR assemblies, SQL Server Agent jobs, IDENTITY, DATETIME2, MONEY, NVARCHAR(MAX), temp-table patterns, use of WITH (NOLOCK), etc.
      • 

    

    3. 

  3. Select migration tools

      

    • AWS Schema Conversion Tool (SCT) — converts schema & flags manual work.
      • 

    • AWS Database Migration Service (DMS) — full load + change data capture (CDC) for minimal downtime migration.
      • 

    • Supplemental: custom scripts, logical replication, or third-party ETL tools for complex transformations.
      • 

    

    4. 

  4. Define success criteria

      

    • Data correctness (row counts, checksums), application functional tests, latency/throughput targets, and acceptable cutover window.
      • 

    

    5.

Phase 2 — Schema Conversion

  1. Run AWS SCT
    • Point SCT at MSSQL source and Aurora PostgreSQL target. Export conversion report and generated DDL.
    • Review automated conversions (green) and manual items (yellow/red).
  2. Refactor database code
    • Rewrite stored procedures, functions and triggers in PL/pgSQL where SCT cannot convert automatically.
    • Replace T-SQL constructs: IIF → CASE, TOP → LIMIT, OUTPUT semantics → RETURNING, etc.
    • Convert identity/sequence logic: MSSQL IDENTITY → Postgres SERIAL / GENERATED / sequences.
  3. Create schema on Aurora
    • Apply cleaned SCT DDL to a staging Aurora cluster. Validate constraints, indexes and privileges.
  4. Plan datatype & timezone handling
    • Decide canonical types (e.g., MSSQL DATETIMEOFFSET → Postgres timestamptz).

Phase 3 — Data Migration (DMS)

  1. Initial full load
    • Use AWS DMS in full load + ongoing replication mode to seed data and keep source/target in sync.
  2. Incremental / CDC
    • Enable CDC so DMS continually replicates changes during cutover prep.
  3. Validation
    • Row counts, checksums (e.g., hashed checks per table), sample record comparison, and referential integrity checks.
    • Resolve encoding, numeric precision, or timezone mismatches encountered during validation.
  4. Performance & tuning during load
    • Consider temporarily disabling non-critical indexes during full load and re-creating them after to speed up load.
    • Monitor DMS task logs, CPU, memory, and replication lag.

Phase 4 — Cutover

  1. Prepare applications
    • Ensure connection strings can point to Aurora endpoints and that driver/ORM supports PostgreSQL dialect.
    • Deploy application query changes (T-SQL → Postgres SQL) to staging beforehand.
  2. Final sync & freeze
    • Schedule a brief write freeze on MSSQL. Allow DMS to apply remaining CDC events until lag is zero.
  3. Switch traffic
    • Update application connection endpoints to Aurora; perform smoke tests and critical-path transactions.
    • Monitor errors, latencies, and DB metrics closely.
  4. Fallback plan
    • Have a rollback checklist — how to point apps back to MSSQL and any data reconciliation steps.

Post-cutover & Decommission

  • Keep both systems read-only for a short verification window if feasible.
  • Run full application test suite and load tests to validate performance.
  • After stabilization, schedule decommission of MSSQL resources and archive backups as required by compliance.

Checklist / Validation Items

  • Data correctness: row counts, CRCs/checksums for key tables.
  • Application functional tests & business process validation.
  • Performance tests: latency, throughput, read/write patterns.
  • Monitoring & alerts configured on Aurora (CPU, connections, replication lag, storage).
  • Backups & PITR verified.
  • Security: users, roles, parameter groups, VPC/subnet groups, KMS encryption keys.

Aurora PostgreSQL vs RDS PostgreSQL — Side-by-side

Feature Aurora PostgreSQL RDS PostgreSQL
Architecture Decoupled compute & distributed storage. Six copies across 3 AZs, auto-healing storage. Traditional single-instance with EBS-backed storage; optional Multi-AZ standby for HA.
Replication & readers Up to 15 low-latency reader instances using shared storage (fast failover & scaling). Up to 5 replicas using physical/logical replication; typically more lag than Aurora readers.
Failover time Typically sub-30 seconds (fast automated failover). Usually 1–2+ minutes depending on Multi-AZ configuration.
Performance Optimized storage/engine — often 2–3× higher throughput vs vanilla Postgres for similar hardware. Standard PostgreSQL performance characteristics.
Storage scaling Auto-scales up to 128 TB without downtime. Pre-allocated EBS; resizing may require downtime or I/O changes.
Backups & PITR Continuous backup to S3-backed storage with minimal impact. Automated snapshots and PITR using WAL archives; can have higher I/O impact.
Feature parity & versions Aurora may lag behind upstream PostgreSQL for new major releases; Aurora adds proprietary enhancements. Closer to upstream PostgreSQL; often quicker to support newest Postgres versions.
Cost Typically higher (engine/IO/replica benefits). Cost-effective for high-scale workloads where performance offsets price. Generally lower; predictable for standard workloads.
Best fit High-scale, low-latency, read-heavy, enterprise apps needing fast failover and large auto-scaling storage. Conventional workloads, smaller DBs, or teams wanting tight upstream Postgres compatibility and lower cost.

Aurora tips

  • Use parameter groups to tune Aurora for your workload (connection limits, work_mem, maintenance_work_mem, etc.).
  • For heavy writes, benchmark commit behavior — Aurora’s storage engine handles commit differently than typical Postgres on EBS.
  • Test long-running queries and background jobs (cron/pg_cron) after migration; scheduling may change semantics.
  • Consider using logical replication or pglogical for some specialized patterns if DMS/SCT aren’t appropriate.

The post Aurora Postgres versus RDS Postgres appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/aws-migration/aurora-postgres-versus-rds-postgres/feed/ 0 484 Tableau – No Authentication Visualizations https://awssecurityarchitect.com/tableau-on-aws/tableau-no-authentication-visualizations/ https://awssecurityarchitect.com/tableau-on-aws/tableau-no-authentication-visualizations/#respond Fri, 14 Nov 2025 19:16:06 +0000 https://awssecurityarchitect.com/?p=482 Tableau – Publishing Without Authentication Can Tableau Publish Content Without Authentication? Yes — Tableau can publish content that does not require authentication, but only under specific configurations. 1. Tableau Public […]

The post Tableau – No Authentication Visualizations appeared first on AWS Security Architect.

]]>



Tableau – Publishing Without Authentication

Can Tableau Publish Content Without Authentication?

Yes — Tableau can publish content that does not require authentication, but only under specific configurations.

1. Tableau Public — No Authentication Required

If your goal is to publish dashboards that anyone on the internet can view with zero login, then Tableau Public is the native option.

What it allows

  • Dashboards are fully public
  • No authentication required
  • Can be embedded in websites, blogs, etc.

Limitations

  • Data must be fully public
  • No row-level security
  • No sensitive or internal corporate data
  • No control over who views the dashboard

2. Tableau Server / Tableau Cloud (Server) — “Guest Access”

If you want unauthenticated access inside your own network or controlled environment, Tableau Server has a setting called Guest User Access.

What it allows

  • Users can view dashboards without logging in
  • Can be used internally for non-sensitive content
  • Embeddable in internal sites (SharePoint, portals, Confluence, etc.)

Requirements

  • Your Tableau Server admin must:
    • Enable “Enable Guest User” in Authentication settings
    • Ensure “Embedded Credentials” are used in the data source
    • Assign permissions to the Guest user for specific projects

Limitations

  • Only available on Tableau Server, not Tableau Cloud
  • Still requires the viewer to access via allowed network/URL
  • Guest user permissions are relatively coarse-grained

3. Tableau Cloud (formerly Tableau Online)

Tableau Cloud does not allow anonymous access.

There is no guest user in Tableau Cloud.

Key Considerations for No-Auth Dashboards

Option Authentication Data Sensitivity Notes
Tableau Public None (open Internet) ❌ None allowed Best for blogs, public data
Tableau Server Guest User None (within allowed network) ✔ Low–Medium Admin must enable; uses embedded credentials
Tableau Cloud Authentication required n/a No anonymous/public access supported

Summary

  • Yes, Tableau can publish “no login required” reports if:
    • You use Tableau Public, or
    • You enable Guest Access on Tableau Server
  • No, if you are using Tableau Cloud and want public/anonymous access.


The post Tableau – No Authentication Visualizations appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/tableau-on-aws/tableau-no-authentication-visualizations/feed/ 0 482 AWS Resource Tag Recommendations https://awssecurityarchitect.com/automation/aws-resource-tag-recommendations/ https://awssecurityarchitect.com/automation/aws-resource-tag-recommendations/#respond Fri, 14 Nov 2025 01:14:03 +0000 https://awssecurityarchitect.com/?p=473 Recommended AWS Resource Tagging Strategy Recommended AWS Resource Tagging Strategy This document provides a comprehensive tagging framework for AWS EC2 and other AWS resources, including S3, RDS, Lambda, and networking […]

The post AWS Resource Tag Recommendations appeared first on AWS Security Architect.

]]>




Recommended AWS Resource Tagging Strategy


Recommended AWS Resource Tagging Strategy

This document provides a comprehensive tagging framework for AWS EC2 and other AWS resources, including S3, RDS,
Lambda, and networking components. Tagging improves visibility, cost allocation, governance, and automation across environments.

Core Identification Tags

Tag Key Example Value Purpose
Name web-server-prod-01 Human-readable identifier for quick recognition.
Environment dev / test / prod Segregate resources by environment.
Application payment-api / crm-portal Group resources by application or service.
Project migration-wave1 / finops-dashboard Track resources by project or initiative.
BusinessUnit finance / marketing / engineering Link usage to department or cost center.
Owner anuj.varma@company.com Assign accountability for resource ownership.

Cost Allocation & FinOps Tags

Tag Key Example Value Purpose
CostCenter CC1234 Enable billing reports and cost allocation.
BillingCode APP567 Alternative identifier for budget association.
CreatedBy terraform / cloudformation / manual Identify resource provisioning source.
Purpose frontend / backend / analytics Categorize resources by business purpose.
Lifecycle temporary / long-term / archive Define expected resource duration.

Security & Compliance Tags

Tag Key Example Value Purpose
DataClassification confidential / pii / public Specify sensitivity for data handling.
Compliance CIS / HIPAA / SOC2 / ISO27001 Associate resource with compliance framework.
BackupPolicy daily / weekly / none Define backup strategy for automation.
PatchGroup linux-prod / windows-dev Group instances for patching baselines.
Retention 30d / 90d / indefinite Specify retention period for logs or backups.

Operations & Automation Tags

Tag Key Example Value Purpose
Schedule office-hours / 24×7 Used by schedulers to manage uptime.
AutoStop true Flag for auto-stop of idle resources.
MaintenanceWindow Sun-02:00-UTC Define maintenance or patch time.
SupportTier gold / silver / bronze Define SLA expectations.
Monitoring datadog / cloudwatch / prometheus Identify monitoring tool integration.

Cloud Migration & Governance Tags

Tag Key Example Value Purpose
Map.Migrated true Identify AWS MAP migrated resources.
Map.Stage wave1 / cutover Track migration stage or wave.
SourceSystem onprem-vsphere / azure / legacy Identify source platform for migrations.
LandingZone shared-vpc / prod-security Specify target AWS landing zone or VPC group.

Networking & Infrastructure Tags

Tag Key Example Value Purpose
VPC shared-vpc-prod Identify VPC association.
SubnetType public / private / isolated Classify subnet purpose.
SecurityZone dmz / core / restricted Tag for segmentation and policy enforcement.

Example Tagging Policy (JSON)

You can enforce tagging consistency via AWS Organizations Tag Policies or AWS Config rules. Example baseline policy:

{
  "tags": {
    "Environment": { "tag_key": "Environment", "tag_value": ["dev", "test", "prod"] },
    "Owner": { "tag_key": "Owner", "tag_value": ".*@company.com" },
    "CostCenter": { "tag_key": "CostCenter", "tag_value": "^[A-Z]{2}[0-9]{4}$" }
  }
}
Tip: Standardize keys and allowed values with Tag Policies; use IAM/Config/SCPs to block creation of untagged resources in critical accounts.


The post AWS Resource Tag Recommendations appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/automation/aws-resource-tag-recommendations/feed/ 0 473 Security of Signed URLs (for S3 content) https://awssecurityarchitect.com/s3-security/security-of-signed-urls-for-s3-content/ https://awssecurityarchitect.com/s3-security/security-of-signed-urls-for-s3-content/#respond Fri, 14 Nov 2025 01:11:12 +0000 https://awssecurityarchitect.com/?p=474 Security of AWS Pre-Signed URLs Are AWS Pre-Signed URLs Safe? Yes—if used correctly. A pre-signed URL is a time-limited, object-scoped URL that grants access to a specific S3 operation (GET/PUT) […]

The post Security of Signed URLs (for S3 content) appeared first on AWS Security Architect.

]]>



Security of AWS Pre-Signed URLs



Are AWS Pre-Signed URLs Safe?

Yes—if used correctly. A pre-signed URL is a time-limited, object-scoped URL that grants access
to a specific S3 operation (GET/PUT) without exposing AWS credentials. Security ultimately depends on
expiration, distribution, and transport.

What Is a Pre-Signed URL?

It’s an S3 request signed with AWS Signature V4 using the generator’s IAM credentials. Anyone in possession of
the URL can perform the allowed action until the URL expires. 

https://mybucket.s3.amazonaws.com/file.pdf?
X-Amz-Algorithm=AWS4-HMAC-SHA256&
X-Amz-Credential=AKIA.../20251112/us-east-1/s3/aws4_request&
X-Amz-Date=20251112T220000Z&
X-Amz-Expires=3600&
X-Amz-Signature=abcd1234...

Why They’re Safe (When Used Properly)

Feature Security Property
Time-limited Automatic expiry (minutes/hours), reducing exposure window.
Object-scoped Grants access only to a specific object and verb (GET/PUT/HEAD).
Cryptographic signature HMAC-SHA256 (SigV4); cannot be forged without the signer’s credentials.
No static creds in clients Callers never see IAM keys or assume roles directly.

Common Risks (Misuse Patterns)

Risk Impact
Overlong expiration Effectively becomes public access for the duration.
Public sharing or logging It’s a bearer token—anyone with the URL can use it until expiry.
HTTP instead of HTTPS Interception exposes the URL to attackers.
Over-privileged generators Can sign access to sensitive objects unintentionally.
No contextual limits Base S3 presigned URLs can’t restrict by IP/geo without a proxy/CDN.

Best-Practice Guidelines

  • Use short expirations: 5–15 minutes for downloads; ≤1 hour for uploads.
  • Enforce HTTPS: Generate and distribute only over TLS; block HTTP at the edge.
  • Restrict generation: Let only specific backend services/Lambdas create URLs.
  • Generate on demand: Don’t embed in static pages/apps; fetch from your backend per request.
  • Audit access: Enable S3 server access logs and CloudTrail data events for the bucket.
  • Rotate credentials: Use short-lived role creds; rotate keys to limit blast radius.
  • Protect sensitive data: Use SSE-KMS and least-privilege KMS key policies.
  • Need IP/time controls? Front S3 with CloudFront and use CloudFront Signed URLs/Cookies for finer policy (IP, geo, shorter TTLs).

Typical Safe Usage Scenarios

Scenario Recommended Pattern
User downloads from a web app Backend authenticates user, generates short-lived GET URL, returns it once.
Mobile/browser uploads Backend issues short-lived PUT URL with content-type/size constraints; client uploads directly to S3.
Partner/temporary share URL with 15–30 min TTL sent via a secure channel; revoke by object rotation if needed.
CI/CD or Lambda artifact exchange Ephemeral URLs for just-in-time transfers; logs enabled for traceability.

Quick CLI Examples

# Generate a GET pre-signed URL (default expiry ~3600s)
aws s3 presign s3://mybucket/report.pdf --expires-in 900

# Generate a PUT pre-signed URL (upload)
aws s3api put-object --bucket mybucket --key upload/photo.jpg --body photo.jpg
# Then generate a presigned PUT URL from your SDK/backend for controlled uploads

Prefer generating URLs in your backend using AWS SDKs (SigV4). Validate user auth & authorization before issuing the URL.

Summary

Pre-signed URLs are safe for temporary, scoped access when you keep TTLs short, use HTTPS,
restrict who can generate them, and log usage. For IP/geo enforcement or more advanced controls, place S3 behind
CloudFront with signed URLs/cookies.



The post Security of Signed URLs (for S3 content) appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/s3-security/security-of-signed-urls-for-s3-content/feed/ 0 474