AWS Well-Architected Framework

AWS Well-Architected helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications and workloads. Based on six pillars — operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability — AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures, and implement designs that can scale over time.

Recent questions

see all
1/18

Why level up to AWS Organizations and Why not stick to AWS Account

**What is the advantage of AWS organization management over the account management ? Why take the leap****** Every Company has users and resources they interact with. End of the day - management of these users and resources (allowing the intended and blocking the un-intended usage) is the purpose of our job. Answer is to use an account level strategy or organizational level strategy. In AWS , few years back , focus was on securing an account and VPCs did the separation for production, development and testing stages. [Please understand Separate VPC is as good as a separate datacenter ]. Now idea is promoted that practically each developer or team will have an account and the department will work as an OU and Enterprise will run as a AWS organization - handling this multi account strategy. So along comes SCPs (at the end of the day they are DENY rules). Control Tower and Landing Zone. But the same things can be run on account level. *Are we Securing the blast radius by limiting to an account ? incase of an account compromise ? **I do not agree as firstly* when your running a multi-account system similar cross account access are also in place which needs to be secure along with the basic level account security management. Also top-managing account in organization can be compromised . In fact the attack surface largely increasing onto an other level. Causes difficulties to visibility and monitoring - ( Guard Duty can be enabled for multi accounts and Cloud Trails Aggregator can be used )- but it is getting complicated. Secondly, anyways one has to keep the account secure also. Clear demarcation is possible and good environment can be provided with VPC , Conditional statements , tagging. In case of merger there can be cross account access enabled with external ID. **I am not here to challenge but I want to gain an understanding in why the shift was undertaken. Also any resources in this regard will be great help. Even a comment might help. ****** **
2
answers
0
votes
26
views
asked 4 days ago

Create EC2 instance with NitroTPM Enabled

Hi, want to create an ec2 instance with nitroTPM 2.0 enabled. I followed the instructions from this site: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enable-nitrotpm-support-on-ami.html ``` { "Images": [ { "Architecture": "x86_64", "CreationDate": "2022-11-21T20:07:43.000Z", "ImageId": "ami-05683f60db56ff1b5", "ImageLocation": "293786889684/DebianImage", "ImageType": "machine", "Public": false, "OwnerId": "293786889684", "PlatformDetails": "Linux/UNIX", "UsageOperation": "RunInstances", "State": "available", "BlockDeviceMappings": [ { "DeviceName": "/dev/xvda", "Ebs": { "DeleteOnTermination": true, "SnapshotId": "snap-0c493ccaccd018881", "VolumeSize": 8, "VolumeType": "gp2", "Encrypted": false } }, { "DeviceName": "/dev/xvdf", "Ebs": { "DeleteOnTermination": true, "VolumeSize": 10, "VolumeType": "gp2", "Encrypted": false } } ], "EnaSupport": true, "Hypervisor": "xen", "Name": "DebianImage", "RootDeviceName": "/dev/xvda", "RootDeviceType": "ebs", "SriovNetSupport": "simple", "VirtualizationType": "hvm", "BootMode": "uefi", "TpmSupport": "v2.0" } ] } ``` So far it looks good, but if I try to launch an instance of this AMI, I cannot connect to the machine. If I create an instance from the management console without nitroTPM support I can connect to the machine via my Key. Also, I would like to get some measurements from the TPM, but I don't see any of the hashes in the response. I appreciate any help you can offer. Heres my ec2 description ``` { "Reservations": [ { "Groups": [], "Instances": [ { "AmiLaunchIndex": 0, "ImageId": "ami-05683f60db56ff1b5", "InstanceId": "i-03435c99e5a3a83b5", "InstanceType": "m6a.xlarge", "KeyName": "OPTI_PLEX_KEY_PAIR", "LaunchTime": "2022-11-21T20:53:29.000Z", "Monitoring": { "State": "disabled" }, "Placement": { "AvailabilityZone": "eu-central-1a", "GroupName": "", "Tenancy": "default" }, "PrivateDnsName": "ip-172-31-16-168.eu-central-1.compute.internal", "PrivateIpAddress": "172.31.16.168", "ProductCodes": [], "PublicDnsName": "ec2-18-159-62-7.eu-central-1.compute.amazonaws.com", "PublicIpAddress": "18.159.62.7", "State": { "Code": 16, "Name": "running" }, "StateTransitionReason": "", "SubnetId": "subnet-12bdf778", "VpcId": "vpc-d90e6cb3", "Architecture": "x86_64", "BlockDeviceMappings": [ { "DeviceName": "/dev/xvda", "Ebs": { "AttachTime": "2022-11-21T20:53:30.000Z", "DeleteOnTermination": true, "Status": "attached", "VolumeId": "vol-05814aff540510c1f" } }, { "DeviceName": "/dev/xvdf", "Ebs": { "AttachTime": "2022-11-21T20:53:30.000Z", "DeleteOnTermination": true, "Status": "attached", "VolumeId": "vol-03027ae670649544f" } } ], "ClientToken": "45856522-8833-4e31-985f-f5209b014fa1", "EbsOptimized": true, "EnaSupport": true, "Hypervisor": "xen", "ElasticGpuAssociations": [], "ElasticInferenceAcceleratorAssociations": [], "NetworkInterfaces": [ { "Association": { "IpOwnerId": "amazon", "PublicDnsName": "ec2-18-159-62-7.eu-central-1.compute.amazonaws.com", "PublicIp": "18.159.62.7" }, "Attachment": { "AttachTime": "2022-11-21T20:53:29.000Z", "AttachmentId": "eni-attach-01e82b7e623e8e9da", "DeleteOnTermination": true, "DeviceIndex": 0, "Status": "attached", "NetworkCardIndex": 0 }, "Description": "", "Groups": [ { "GroupName": "launch-wizard-10", "GroupId": "sg-05676ad26b7f6ed13" } ], "Ipv6Addresses": [], "MacAddress": "02:b8:28:63:4f:fc", "NetworkInterfaceId": "eni-095492d80db0313b8", "OwnerId": "293786889684", "PrivateDnsName": "ip-172-31-16-168.eu-central-1.compute.internal", "PrivateIpAddress": "172.31.16.168", "PrivateIpAddresses": [ { "Association": { "IpOwnerId": "amazon", "PublicDnsName": "ec2-18-159-62-7.eu-central-1.compute.amazonaws.com", "PublicIp": "18.159.62.7" }, "Primary": true, "PrivateDnsName": "ip-172-31-16-168.eu-central-1.compute.internal", "PrivateIpAddress": "172.31.16.168" } ], "SourceDestCheck": true, "Status": "in-use", "SubnetId": "subnet-12bdf778", "VpcId": "vpc-d90e6cb3", "InterfaceType": "interface", "Ipv4Prefixes": [], "Ipv6Prefixes": [] } ], "RootDeviceName": "/dev/xvda", "RootDeviceType": "ebs", "SecurityGroups": [ { "GroupName": "launch-wizard-10", "GroupId": "sg-05676ad26b7f6ed13" } ], "SourceDestCheck": true, "Tags": [ { "Key": "Name", "Value": "Ubuntu bla" } ], "VirtualizationType": "hvm", "CpuOptions": { "CoreCount": 2, "ThreadsPerCore": 2 }, "CapacityReservationSpecification": { "CapacityReservationPreference": "open" }, "HibernationOptions": { "Configured": false }, "Licenses": [], "MetadataOptions": { "State": "applied", "HttpTokens": "optional", "HttpPutResponseHopLimit": 1, "HttpEndpoint": "enabled", "HttpProtocolIpv6": "disabled", "InstanceMetadataTags": "enabled" }, "EnclaveOptions": { "Enabled": true }, "BootMode": "uefi", "PlatformDetails": "Linux/UNIX", "UsageOperation": "RunInstances", "UsageOperationUpdateTime": "2022-11-21T20:53:29.000Z", "PrivateDnsNameOptions": { "HostnameType": "ip-name", "EnableResourceNameDnsARecord": true, "EnableResourceNameDnsAAAARecord": false }, "TpmSupport": "v2.0", "MaintenanceOptions": { "AutoRecovery": "default" } } ], "OwnerId": "293786889684", "ReservationId": "r-0089af1cf650fc657" } ] } ```
0
answers
0
votes
27
views
asked 11 days ago

AWS Inspector V2 and AWS Inspector Classic findings are different

I am using Ubuntu 20.04 EC2 Instances and was investigating the difference between AWS Inspector Classic and AWS Inspector V2. There seemed to be many differences but the main one was the actual findings. With Inspector Classic a number of CVE would be found while with Inspector V2 the same instance once scanned would say `No Findings`. ### Inspector Classic finds 53 CVE's ![Enter image description here](/media/postImages/original/IM7H1iE2k8S2iL21F4CODGEQ) ### Same instance with InspectorV2 Just show `No findings` ![Enter image description here](/media/postImages/original/IMLgoOIjGzSqm7eZcT5bGH4Q) ------- With Inspector Classic I did attach a rule called `Common Vulnerabilities and Exposures-1.1`. I'm not sure what Inspector V2 actually checks against either. During my search to make this work did find that I needed the following Systems Managers manager Association needed to work `InspectorInventoryCollection-do-not-delete`. It's working now and show success for all ec2 instances. I am unsure if the `InvokeInspectorSsmPlugin-do-not-delete` Association needs to work as well. Not quite sure what this is used for but it shows skipped for all instances and when I look at the detailed status output on a specific instances is just says `InvalidPlatform`. Not sure if this is related. Can InspectorV2 actually be used to check Ubuntu 20.04 CVE's. If so how. Is there some special IAM or SSM config/setup that needs to be applied?
1
answers
0
votes
25
views
profile picture
dili
asked 16 days ago

Popular users

see all
1/18